Are We There Yet On RPKI Deployment and

Are We There Yet? On RPKI Deployment and Security Yossi Gilad joint work with: Avichai Cohen, Amir Herzberg, Michael Schapira, Haya Shulman 1

The Resource Public Key Infrastructure (RPKI) maps IP prefixes to organizations that own them [RFC 6480] • Intended to prevent prefix/subprefix hijacks – We will show that this is often not the case • Lays the foundation for protection against more sophisticated attacks on interdomain routing – BGPsec, So. BGP, … 2

Talk Outline • Background • Quantify RPKI’s deployment and security – Who uses the RPKI? – How “good” is RPKI in partial deployment? • Discuss the obstacles facing full deployment – Insecure deployment – human error – inter-organization dependencies • Propose and evaluate solutions 3

Prefix Hijacking prefers shorter route AS X 91. 0/10 Path: Y-3320 91. 0/10 Path: 3320 AS Y AS 3320 AS 666 Deutsche Telekom BGP Ad. 91. 0/10 Path: 666 Data flow 4

Certifying Ownership with RPKI • RPKI assigns an IP prefix to a public key via a Resource Certificate (RC) • Owners can use their private key to issue a Route Origin Authorization (ROA) • ROAs identify ASes authorized to advertise an IP prefix in BGP 5

Example: Certifying Ownership Deutsche Telekom certified by RIPE for address space 91. 0. 0. 0/10 *This presentation uses real-world examples. See slide 54 for details on data sources. 6

RPKI should prevent prefix hijacks AS X uses the authenticated mapping (ROA) from 91. 0/10 to AS 3320 to discard the attacker’s route-advertisement 91. 0/10 Path: Y-3320 AS Y AS 3320 91. 0/10 Path: 666 AS X 91. 0/10 AS 3320 AS 666 Deutsche Telekom BGP Ad. Data flow 7

Talk Outline • Background • Quantify RPKI’s deployment and security – Who uses the RPKI? – How “good” is RPKI in partial deployment? • Discuss the obstacles facing full deployment – Insecure deployment – human error – inter-organization dependencies • Propose and evaluate solutions 8

But who actually filters bogus advertisements? Route-Origin Validation (ROV): use ROAs to discard route-advertisements from unauthorized origins [RFC 6811] Autonomous System RCs and ROAs RPKI cache RPKI pub. point Verify: • signer authorized for subject prefix • signature is valid 91. 0. 0. 0/10: AS = 3320, max-length = 10 BGP Routers 9

But who actually filters bogus advertisements? Major router vendors support ROV with negligible overhead Any AS, anywhere, can do ROV. But which AS actually does ROV? We present the first measurement study of ROV adoption 10

ROV adoption: Measurements ROA issuing rates are constantly monitored Information accessible since ROAs are public ¹ Measuring ROV adoption is challenging: How to tell if a BGP router performs ROV? ¹ https: //rpki-monitor. antd. nist. gov/ 11

ROV adoption: Measurements We gain empirical insights regarding ROV enforcement via invalid BGP advertisements We monitored BGP paths from multiple vantage points afforded by 44 Route Views sensors ² ² http: //www. routeviews. org/ 12

Measurements: Non-Filtering ASes that propagate invalid BGP advertisements do not perform filtering 15003 6416 191. 96. 100. 0/24 AS 15003 and AS 42926 advertise in BGP the RPKI-invalid IP prefixes 191. 96. 100. 0/24 and 185. 70. 84. 0/24 42926 1239 4637 RV sensor 1299 6939 RV sensor 9121 185. 70. 84. 0/24 *This presentation provides examples based on empirical data. See slide 54 for details on data sources. 13

Measurements: Non-Filtering ASes that propagate invalid BGP advertisements do not perform filtering 15003 Route Views sensor observes “bad” route to: 191. 96. 100. 0/24 AS path: 4637, 6416, 15003 6416 191. 96. 100. 0/24 1239 42926 185. 70. 84. 0/24 9121 4637 RV sensor Route Views sensor observes “bad” route to: 185. 70. 84. 0/24 AS path: 6939, 1299, 9121, 42926 1299 6939 RV sensor 14

Measurements: Non-Filtering ASes that propagate invalid BGP advertisements do not perform filtering 15003 6416 191. 96. 100. 0/24 42926 1239 4637 RV sensor 1299 6939 RV sensor 9121 185. 70. 84. 0/24 ASes that don’t filter invalid advertisements colored 15

Measurements: Filtering ASes Seek ASes that advertise both “good” & “invalid” routes. Conclude that an AS performs ROV if it discards “bad” advertisements, but relays “good” ones, from 3 origins 15003 6416 191. 96. 100. 0/24 AS 42926 announces another BGP advertisement for prefix 79. 98. 130. 0/24 42926 1239 4637 RV sensor 1299 6939 RV sensor 9121 185. 70. 84. 0/24 79. 98. 130. 0/24 16

Measurements: Filtering ASes Seek ASes that advertise both “good” & “invalid” routes. Conclude that an AS performs ROV if it discards “bad” advertisements, but relays “good” ones, from 3 origins. 15003 6416 191. 96. 100. 0/24 AS 42926 announces another BGP advertisement for prefix 79. 98. 130. 0/24 42926 Route Views sensor observes ``good’’ route to: 79. 98. 130. 0/24 AS path: 4637, 1239, 9121, 42926 1239 4637 RV sensor 1299 6939 RV sensor 9121 185. 70. 84. 0/24 79. 98. 130. 0/24 17

Measurements: Filtering ASes Seek ASes that advertise both “good” & “invalid” routes. Conclude that an AS performs ROV if it discards “bad” advertisements, but relays “good” ones, from 3 origins Conclude: AS 1239 receives adv. by AS 42926, but 15003 did not relay the invalid 6416 one (only non-red AS on legitimate adv. path) 191. 96. 100. 0/24 AS 42926 announces another BGP advertisement for prefix 79. 98. 130. 0/24 42926 Route Views sensor observes ``good’’ route to: 79. 98. 130. 0/24 AS path: 4637, 1239, 9121, 42926 1239 4637 RV sensor 1299 6939 RV sensor 9121 185. 70. 84. 0/24 79. 98. 130. 0/24 18

Measurements: Results Our measurement techniques provide a view of ROV enforcement amongst the ASes at the core of the Internet – since ASes at the core are likely to be on the paths covered by the Rout Views sensors At least 80 of top 100 ISPs do not perform ROV 19

Measurements: Results An anonymous survey of over 100 network operators and security practitioners • advertised in different mailing lists, including ‘closed’ lists • 80% of respondents are network operators/managers and most of the others are security/networking consultants Does not protect against subprefix hijacks [Heilman et al. 2014] Do you apply RPKI-based route-origin validation? *See slide 55 for more details on survey participants 20

Talk Outline • Background • Quantify RPKI’s deployment and security – Who uses the RPKI? – How “good” is RPKI in partial deployment? • Discuss the obstacles facing full deployment – Insecure deployment – human error – inter-organization dependencies • Propose and evaluate solutions 21

What is the impact of partial ROV adoption? • We identify two phenomena: – Collateral benefits: Adopters protect other ASes ``behind’’ them – Collateral damages: ASes not doing ROV might cause ASes that do ROV to fall victim to attacks! 22

What is the impact of partial ROV adoption? • Collateral benefits: – Adopters protect ASes behind them by discarding invalid routes AS 666 To: 1. 1. 1/24 AS path: 666 AS 2 Origin AS 1 AS 3 is only offered a good route AS 3 To: 1. 1/16 AS path: 2 -1 23

What is the impact of partial ROV adoption? • Collateral damages: Disconnection – Adopters might be offered only bad routes To: 1. 1/16 AS path: 2 -666 AS 2 prefers to advertise routes from AS 666 over AS 1 Origin AS 1 AS 2 AS 3 receives only bad advertisement and disconnects from AS 1 To: 1. 1/16 AS path: 2 -1 24

What is the impact of partial ROV adoption? • Collateral damages: Control-Plane-Data-Plane Mismatch! – Control/data plane discrepancy causes data to flow to attacker, although AS 3 discarded it! • Occurs even when AS 2 deprefers invalid routes AS 666 AS 2 advertises both prefix & subprefix routes AS 2 does not filter and uses bad route for subprefix Origin AS 1 To: 1. 1. 1/24 AS path: 2 -666 AS 3 discards bad subprefix route AS AS 2 3 To: 1. 1/16 AS path: 2 -1 25

Quantify Security in Partial Adoption • We ran simulations to quantify security: – empirically-derived AS-level network from CAIDA • Including inferred peering links [Giotsas et al. , SIGCOMM’ 13] – using the simulation framework in [Gill et al. , CCR’ 12] • We measured the attacker success rate – in terms of #ASes attracted – for different attack scenarios – for different ROV deployment scenarios – averaged over 1 M attacker/victim pairs 26

Quantify Security in Partial Adoption • Collateral benefits: – Top ISP adopts with probability p (p=¼, ½, ¾, 1) – Significant benefit only when p is high (p= ¾, 1) Prefix hijack success rate Subprefix hijack success rate 27

Quantify Security in Partial Adoption • Collateral damages: – Top ISP adopts with probability p (p=¼, ½, ¾, 1) – Avoid collateral damage only when p is high (p= ¾, 1) Prefix hijack leads to disconnection Subprefix hijack causes control-planedata-plane inconsistency 28

Quantify Security in Partial Adoption • Comparison between two scenarios: – today’s status, as reflected by our measurements – all top 100 ISPs perform ROV • Each other AS does ROV with fixed probability Adoption by the top 100 ISPs makes a huge difference! Prefix hijack Subprefix hijack 29

Quantify Security in Partial Adoption Bottom line: ROV enforcement by the top ISPs is both necessary and sufficient for substantial security benefits from RPKI 30

Talk Outline • Background • Quantify RPKI’s deployment and security – Who uses the RPKI? – How “good” is RPKI in partial deployment? • Discuss the obstacles facing full deployment – insecure deployment – human error – inter-organization dependencies • Propose and evaluate solutions 31

Security Vulnerability: Loose ROAs Longest-prefix-match routing ensures that the hijacker’s route to AS 666 is preferred AS 3303 originates 81. 62/16 but not 81. 62. 0/24 81. 62/16 Path: 3303 AS 3303 Swisscom BGP Ad. Data flow AS X 81. 62/15 -24 AS 3303 Valid advertisement since AS 3303 is the “origin” 81. 62. 0/24 Path: 666 -3303 AS 666 Swisscom’s ROA allows advertising subprefixes up to length /24 32

Security Vulnerability: Loose ROAs Manifests even in large providers, e. g. , Swisscom • ROA allows up to /24, but only /16 s announced • To hijack all traffic to prefix 81. 62. 0. 0/16, attacker announces 81. 62. 0. 0/17 and 81. 62. 128. 0/17 with AS-path 666 -3303 • Swisscom should set the max. Length to 16 33

Security Vulnerability: Loose ROAs • Loose ROAs are common! – almost 30% of IP prefixes in ROAs – 89% of prefixes with max. Len > prefix. Len • Attacker can hijack all traffic to nonadvertised subprefixes covered by a loose ROA 34

Talk Outline • Background • Quantify RPKI’s deployment and security – Who uses the RPKI? – How “good” is RPKI in partial deployment? • Discuss the obstacles facing full deployment – Insecure deployment – human error – inter-organization dependencies • Propose and evaluate solutions 35

Obstacles to Deployment: Human Error Many other mistakes in RPKI (see RPKI monitor) – legitimate prefixes are often considered invalid – ROV causes disconnection from legitimate destinations – Extensive measurements in [Iamartino et al. , PAM’ 15] Using RPKI database of July 2016. See details in slide 54. 36

Obstacles to Deployment: Human Error Concern for disconnection was also pointed out in our survey: What are your main concerns regarding executing RPKI-based origin authentication in your network? 37

Obstacles to Deployment: Human Error Who is responsible for “bad ROAs”? • Hundreds of organizations are responsible for invalid IP prefixes, but… • Good news: most errors are due to a small number of organizations 38

Talk Outline • Background • Quantify RPKI’s deployment and security – Who uses the RPKI? – How “good” is RPKI in partial deployment? • Discuss the obstacles facing full deployment – Insecure deployment – human error – inter-organization dependencies • Propose and evaluate solutions 39

Obstacles to Deployment: Inter-Organization Dependencies Upward dependencies: Level 3 Communications did not obtain an RC. Consequently, its customers cannot obtain an RC 40

Obstacles to Deployment: Inter-Organization Dependencies Good news: Not many organizations are upward-dependent 41

Obstacles to Deployment: Inter-Organization Dependencies Downward dependencies: Orange issued a ROA which renders routes to other organizations invalid 42

Obstacles to Deployment: Inter-Organization Dependencies Good news: Only a handful of prefixes are downward dependent 43

Obstacles to Deployment: Inter-Organization Dependencies Bad news: These are large prefixes that belong to large Internet providers – Orange and Level 3 are but two examples 44

Talk Outline • Background • Quantify RPKI’s deployment and security – Who uses the RPKI? – How “good” is RPKI in partial deployment? • Discuss the obstacles facing full deployment – Insecure deployment – human error – inter-organization dependencies • Propose and evaluate solutions 45

Three Obstacles to RPKI adoption • Insufficient value • Justified mistrust • Inter-organizational dependencies 46

Generating Value • Incentivize ROV adoption by the top ISPs! • Both sufficient and necessary for significant security benefits. 47

Building Trust: ROAlert • roalert. org allows you to check whether your network is properly protected by ROAs • … and if not, why not 48

Building Trust: ROAlert • Online, proactive notification system • Retrieves ROAs from the RPKI and compares them against BGP adv. – Online feed through CAIDA BGPStream ³ • Alerts network operators from “bad ROAs” (offenders and victims alike!) • Enter ROAlert. org! ³ https: //bgpstream. caida. org/ 49

Building Trust: ROAlert 50

Building Trust: ROAlert • Unlike existing systems 4 : – constant monitoring (not only at registration) – not opt-in • Initial results are promising! – notifications reached 168 victims and offenders (over 6 months period) – 42% of errors were fixed within a month • We advocate that ROAlert be adopted and adapted by RIRs! 4 https: //www. nanog. org/sites/default/files/RPKI%20 -%20 NANOG 63. pdf 51

Improving RPKI • Eliminate downward dependencies via “wildcard ROAs” (see our NDSS’ 17 paper for details) • Max. Length considered harmful. Why not remove? [Gilad, Ossaga & Goldberg 2016] 52

Thank You! This work will also appear at NDSS’ 17 Tech report at https: //eprint. iacr. org/2016/1010. pdf Questions? 53

Data Sources • BGP advertisements are constantly fed to ROAlert using CAIDA’s BGPStream • ROAs and RCs obtained from RPKI repositories – trust anchors: afrinic, arin, ripe, lacnic, apnic, iana • Simulations use CAIDA’s AS topology graph from July 2016 – Including inferred peering links • Measurements and examples are from a snapshot of our dataset from July 26 th 2016 54

Survey Participants What is your role? `Which of the following best describes your network? ’’ 55

Survey Participants How many IP addresses does your network include? Where is your network? ’ Does your organization have an AS number? 56