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

The Resource Public Key Infrastructure 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, SoBGP,…

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

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

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

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.

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 X 91.0/10 Path: 666 AS Y 91.0/10  AS 3320 AS 666 Deutsche Telekom AS 3320 BGP Ad. Data flow

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

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

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

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/

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/

Measurements: Non-Filtering ASes ASes that propagate invalid BGP advertisements do not perform filtering 42926 1299 RV sensor 185.70.84.0/24 9121 1239 4637 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 6939 *This presentation provides examples based on empirical data. See slide 54 for details on data sources.

Measurements: Non-Filtering ASes ASes that propagate invalid BGP advertisements do not perform filtering 42926 1299 RV sensor 185.70.84.0/24 Route Views sensor observes “bad” route to: 191.96.100.0/24 AS path: 4637, 6416, 15003 9121 6939 1239 4637 6416 15003 191.96.100.0/24 Route Views sensor observes “bad” route to: 185.70.84.0/24 AS path: 6939, 1299, 9121, 42926

Measurements: Non-Filtering ASes ASes that propagate invalid BGP advertisements do not perform filtering 15003 191.96.100.0/24 42926 1299 RV sensor 185.70.84.0/24 9121 6939 1239 4637 6416 ASes that don’t filter invalid advertisements colored red

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 6416 15003 191.96.100.0/24 42926 1299 RV sensor 185.70.84.0/24 9121 6939 1239 79.98.130.0/24 AS 42926 announces another BGP advertisement for prefix 79.98.130.0/24 4637

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. 42926 1299 RV sensor 185.70.84.0/24 Route Views sensor observes ``good’’ route to: 79.98.130.0/24 AS path: 4637, 1239, 9121, 42926 9121 6939 1239 4637 79.98.130.0/24 6416 15003 191.96.100.0/24 AS 42926 announces another BGP advertisement for prefix 79.98.130.0/24

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 42926 1299 RV sensor 185.70.84.0/24 9121 6939 1239 4637 79.98.130.0/24 Route Views sensor observes ``good’’ route to: 79.98.130.0/24 AS path: 4637, 1239, 9121, 42926 Conclude: AS 1239 receives adv. by AS 42926, but did not relay the invalid one (only non-red AS on legitimate adv. path) 6416 15003 191.96.100.0/24 42926 1299 RV sensor 185.70.84.0/24 9121 6939 1239 4637 79.98.130.0/24 AS 42926 announces another BGP advertisement for prefix 79.98.130.0/24

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

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

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

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!

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 3 is only offered a good route AS 2 AS 3 To: 1.1/16 AS path: 2-1 Origin AS 1

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

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 To: 1.1.1/24 AS path: 2-666 AS 3 discards bad subprefix route AS 2 advertises both prefix & subprefix routes AS 2 AS 3 AS 2 does not filter and uses bad route for subprefix To: 1.1/16 AS path: 2-1 Origin AS 1

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 1M attacker/victim pairs

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

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-plane-data-plane inconsistency

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

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

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

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 Valid advertisement since AS 3303 is the “origin” AS X 81.62/16 Path: 3303 81.62.0/24 Path: 666-3303 AS 3303 81.62/15-24  AS 3303 AS 666 Swisscom Swisscom’s ROA allows advertising subprefixes up to length /24 BGP Ad. Data flow

Security Vulnerability: Loose ROAs Manifests even in large providers, e.g., Swisscom ROA allows up to /24, but only /16s 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 maxLength to 16

Security Vulnerability: Loose ROAs Loose ROAs are common! almost 30% of IP prefixes in ROAs 89% of prefixes with maxLen > prefixLen Attacker can hijack all traffic to non-advertised subprefixes covered by a loose ROA

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

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.

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?

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

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

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

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

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

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

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

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

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

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

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

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/

Building Trust: ROAlert

Building Trust: ROAlert Unlike existing systems : 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 4 https://www.nanog.org/sites/default/files/RPKI%20-%20NANOG63.pdf

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

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

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 26th 2016

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

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