Limiting the Power of RPKI Authorities Kris Shrishak Haya Shulman - - PowerPoint PPT Presentation

▶
limiting the power of rpki authorities
SMART_READER_LITE
LIVE PREVIEW

Limiting the Power of RPKI Authorities Kris Shrishak Haya Shulman - - PowerPoint PPT Presentation

Dec 13, 2023 178 likes •587 views

Applied Networking Research Workshop 2020 acm sigcomm Limiting the Power of RPKI Authorities Kris Shrishak Haya Shulman TU Darmstadt and Fraunhofer SIT Motivation - Resource Public Key Infrastructure (RPKI) secures the interdomain routing

slide-1
SLIDE 1

Applied Networking Research Workshop 2020

acm sigcomm

Limiting the Power of RPKI Authorities

Kris Shrishak Haya Shulman

TU Darmstadt and Fraunhofer SIT

slide-2
SLIDE 2

Motivation

  • Resource Public Key Infrastructure (RPKI) secures the interdomain routing

against prefix and subprefix hijacks

  • However, significant power lies with the Regional Internet Registries (RIRs)

This Work

  • Distributed RPKI system that relies on threshold signatures
  • Prevention rather than detection
  • Ensures that any change to the RPKI objects requires a joint action by a number
  • f RIRs, avoiding unilateral IP address takedowns
  • No changes required at Relying Parties

1 / 19

slide-3
SLIDE 3

Outline

RPKI MPC Our work

slide-4
SLIDE 4

Prefix hijacks

2 / 19

slide-5
SLIDE 5

RPKI

RPKI [RFC 6480] is a hierarchical PKI that includes: Routing Certificate (RC) Binds IP prefix to a public key Route Origin Authorization (ROA) Binds the prefix to AS

  • Signed by the public key associated with the RC

Route Origin Validation (ROV) Validates the origin of BGP route announcements RPKI is a prerequisite for BGPSec [RFC 8205] that provides path validation.

3 / 19

slide-6
SLIDE 6

Delegated and Hosted RPKI

Delegated RPKI

  • Members run their own CA
  • Member generates its own certificate, gets it signed by the parent CA

1https://ripe77.ripe.net/presentations/156-RPKI-deployment-at-scale-RIPE-1.pdf 4 / 19

slide-7
SLIDE 7

Delegated and Hosted RPKI

Delegated RPKI

  • Members run their own CA
  • Member generates its own certificate, gets it signed by the parent CA

Hosted RPKI

  • RIR runs the CA for the members and manages the keys and repo
  • Convenient option for members as they do need to run their own CAs
  • Even some large providers such as Cloudflare use hosted RPKI 1

1https://ripe77.ripe.net/presentations/156-RPKI-deployment-at-scale-RIPE-1.pdf 4 / 19

slide-8
SLIDE 8

Delegated and Hosted RPKI

Delegated RPKI

  • Members run their own CA
  • Member generates its own certificate, gets it signed by the parent CA

Hosted RPKI

  • RIR runs the CA for the members and manages the keys and repo
  • Convenient option for members as they do need to run their own CAs
  • Even some large providers such as Cloudflare use hosted RPKI 1

1https://ripe77.ripe.net/presentations/156-RPKI-deployment-at-scale-RIPE-1.pdf 4 / 19

slide-9
SLIDE 9

Power imbalance

  • RPKI authorities can revoke and allocations
  • RPKI authorities can unilaterally takedown IP prefixes
  • Law enforcement 2 3
  • ASes not necessarily in the same country as the RIR

(no recourse, loss of business)

  • RIRs do not usually collude with each other, and often disagree with each other

when it comes to their response to law enforcement agencies 4

2RIPE NCC Blocks Registration in RIPE Registry Following Order from Dutch Police (2011) 3ICANN Tells U.S. Court That ccTLDs Are Not “Property” — Files Motion to Quash in U.S. Legal Action

Aimed at Seizing Top-Level Domains (2014)

  • 4M. Mueller, M. van Eeten, and B. Kuerbis. In important case, RIPE-NCC seeks legal clarity on how it

responds to foreign court orders (2011)

5 / 19

slide-10
SLIDE 10

Prior Works

  • Adding transparency logs and .dead objects to signify consent 5
  • Relying parties take a part of the burden
  • Detection after the fact
  • Parent manages the signing in hosted RPKI and can sign the .dead objects itself
  • Blockchain to replace RPKI 6
  • Scalability
  • Deployment issues such as consensus algorithm and incentive for the nodes to run

the blockchain

  • If Proof-of-Stake is used, large providers will become powerful players; another form
  • f power imbalance

5Heilman, et. al. From the consent of the routed: Improving the transparency of the RPKI (SIGCOMM’14) 6Adiseshu Hari and T. V. Lakshman. The Internet blockchain: A distributed, tamper-resistant transaction

framework for the Internet (HotNets’16)

6 / 19

slide-11
SLIDE 11

Outline

RPKI MPC Our work

slide-12
SLIDE 12

Multiparty Computation (MPC)

x1 x2 x3 Trusted Third Party

7 / 19

slide-13
SLIDE 13

Multiparty Computation (MPC)

x1 x2 x3 Trusted Third Party x1 x2 x3 MPC

7 / 19

slide-14
SLIDE 14

MPC

Threshold Signatures

Traditional Signatures

sk Indistinguishable

Threshold Signatures {sk1, sk2, sk3} ← Share(sk)

sk1 sk2 sk3 MPC

8 / 19

slide-15
SLIDE 15

MPC

Threshold Signatures

Traditional Signatures

sk Indistinguishable

Threshold Signatures {sk1, sk2, sk3} ← Share(sk)

sk1 sk2 sk3 MPC

8 / 19

slide-16
SLIDE 16

Outline

RPKI MPC Our work

slide-17
SLIDE 17

Threat model

x1 x2 x3 x2 x3 MPC

Individual RIRs not entirely trusted

9 / 19

slide-18
SLIDE 18

Threat model

x1 x2 x3 x2 x3 MPC

Individual RIRs not entirely trusted Adversary power

  • Passive
  • Active

9 / 19

slide-19
SLIDE 19

Threat model

x1 x2 x3 x2 x3 MPC

Individual RIRs not entirely trusted Adversary power

  • Passive
  • Active

How many can be corrupt?

  • Minority

9 / 19

slide-20
SLIDE 20

Threat model

x1 x2 x3 x2 x3 MPC

Individual RIRs not entirely trusted Adversary power

  • Passive
  • Active

How many can be corrupt?

  • Minority
  • Majority

9 / 19

slide-21
SLIDE 21

System Setup

Trust Anchor Hosted CA Threshold Signature Module RPKI DB Hosted RPKI RIR CA Threshold Signature Module RPKI DB repos repos

10 / 19

slide-22
SLIDE 22

Distributed RPKI

CA Threshold Signature Module RIPE NCC ARIN LACNIC AFRINIC APNIC repos repos MPC

11 / 19

slide-23
SLIDE 23

Threshold signatures for RPKI

{sk1, sk2, sk3, sk4, sk5} ← Share(sk)

12 / 19

slide-24
SLIDE 24

Threshold signatures for RPKI

{sk1, sk2, sk3, sk4, sk5} ← Share(sk)

sk1 sk2 sk3 sk4 sk5 consent MPC repos repos

12 / 19

slide-25
SLIDE 25

Threshold signatures for RPKI

{sk1, sk2, sk3, sk4, sk5} ← Share(sk)

sk1 sk2 sk3 sk4 sk5 consent MPC repos repos

12 / 19

slide-26
SLIDE 26

Threshold signatures for RPKI

{sk1, sk2, sk3, sk4, sk5} ← Share(sk)

sk1 sk2 sk3 sk4 sk5 consent MPC repos repos

12 / 19

slide-27
SLIDE 27

Threshold signatures for RPKI

{sk1, sk2, sk3, sk4, sk5} ← Share(sk)

sk1 sk2 sk3 sk4 sk5 consent MPC repos repos

12 / 19

slide-28
SLIDE 28

Threshold signatures for RPKI

{sk1, sk2, sk3, sk4, sk5} ← Share(sk) Threshold signing should not be expensive

sk1 sk2 sk3 sk4 sk5 consent MPC repos repos

12 / 19

slide-29
SLIDE 29

Threshold Signature in 3 phases

MPC Preprocessing

  • Member independent

Preprocessing

  • Member independent
  • Message independent

Online phase

13 / 19

slide-30
SLIDE 30

Threshold Signature in 3 phases

MPC Preprocessing

  • Member independent

Preprocessing

  • Member independent
  • Message independent

Online phase

13 / 19

slide-31
SLIDE 31

Threshold Signature in 3 phases

sk1 sk2 sk3 sk4 sk5 MPC Preprocessing

  • Member independent

Preprocessing

  • Member independent
  • Message independent

Online phase

13 / 19

slide-32
SLIDE 32

Threshold Signature in 3 phases

sk1, M sk2, M sk3, M sk4, M sk5, M MPC Preprocessing

  • Member independent

Preprocessing

  • Member independent
  • Message independent

Online phase

13 / 19

slide-33
SLIDE 33

Deployment Scenarios

  • Two-layered
  • Is compatible with delegated RPKI
  • Upper layer generates a distributed TA to the five RIRs
  • Distributed key generation
  • All RIRs have the same subjectPublicKeyInfo in their TAL
  • Lower layer uses the threshold signing module for the Hosted CAs
  • Generates signed objects
  • Not entirely immune to state coercion
  • Flat
  • Combines RIR CA and hosted CA
  • Replaces the hierarchical RPKI with a flat architecture
  • Not compatible with delegated RPKI

14 / 19

slide-34
SLIDE 34

Evaluations

Frankfurt Sydney Sao Paolo Mumbai

  • N. Virginia

114.9|109 85.6|142 228.3|49 196.7|57 119.9|99 301.0|36 180.6|64 203.7|56 283.2|39 308.7|35

Figure: Latency in milliseconds|Bandwidth in Mbits/s between regions

15 / 19

slide-35
SLIDE 35

Evaluations

❤❤❤❤❤❤❤❤❤❤❤ ❤

Majority Adversary power Passive Active Honest Shamir

  • Mal. Shamir

Dishonest

  • Semi. OT

MASCOT

Table: Four MPC protocols

LAN WAN Preprocessing Online Preprocessing Online MASCOT 209 529 20 0.95 Semi OT 1042 662 111 2.05

  • Mal. Shamir

699 714 91 3.53 Shamir 1020 769 265 3.54

Table: Breakdown of throughput for preprocessing (tuples/sec) and online phases (signatures/sec)

16 / 19

slide-36
SLIDE 36

ROAs

2 1 5

  • 1

2 1 6

  • 1

2 1 7

  • 1

2 1 8

  • 1

2 1 9

  • 1

2 2

  • 1

Dates

20000 40000 60000 80000 100000

ROAs added

AFRINIC APNIC ARIN LACNIC RIPENCC 2 1 5

  • 1

2 1 6

  • 1

2 1 7

  • 1

2 1 8

  • 1

2 1 9

  • 1

2 2

  • 1

Dates

20000 40000 60000 80000 100000

ROAs removed

AFRINIC APNIC ARIN LACNIC RIPENCC

Figure: Number of ROAs added and removed from March 2015 to February 2020

17 / 19

slide-37
SLIDE 37

Evaluations

In the WAN setting,

  • MASCOT: 0.95 signatures/sec or 82080 signatures/day
  • Shamir: 3.53 signatures/sec or 304992 signatures/day
  • Even our slowest protocol is able to satisfy the requirements on an average day.
  • Our other protocols are able to generate enough signatures even on peak days

18 / 19

slide-38
SLIDE 38

Summary of our work

  • Distributed RPKI with a stronger threat model
  • Using threshold signatures in preprocessing model
  • No changes at Relying Parties
  • Technical solution that requires legal and policy barriers to be addressed to make

the work truly practical

19 / 19

slide-39
SLIDE 39

kris.shrishak@sit.tu-darmstadt.de

CA Threshold Signature Module RIPE NCC ARIN LACNIC AFRINIC APNIC repos repos MPC