1 Robert Lychev Sharon GoldbergMichael Schapira Georgia Tech Boston University Hebrew University

2 BGP RPKI ( origin authentication ) BGPSEC S S 4323,2828, FB, prefix S S 2828, FB, prefix S S SP, 4323, 2828, FB, prefix In deployment Crypto done offline In standardization Crypto done online What does (partially-deployed) BGPSEC offer over RPKI? (Or, is the juice worth the squeeze?) Security Benefits or Juice BGP and BGPSEC coexistence  road to BGPSEC full-deployment is very tricky because introducing security only partially introduces new vulnerabilities  not fully deployed BGPSEC provides only meagre benefits over RPKI if network operators do not prioritize security in their routing policies

3 1. Background: 1. BGP, RPKI, BGPSEC 2. routing policies in BGPSEC partial deployment 2. BGPSEC in partial deployment is tricky 3. Is the juice worth the squeeze? 4. Summary

44 Sprint D /24 D /24 D / , D / , D / , 2828, D / , 2828, D /24 A Sprint, 4323, 2828, D /24 Sprint, 4323, 2828, D /24

55 Sprint D /24 Which route to choose? Use routing policies. e.g. “Prefer short paths” 4323, 2828, D / , 2828, D /24 ? A A, D /24 A, D /24

66 Sprint D /24 Which route to choose? Use routing policies. e.g. “Prefer short paths” 4323, 2828, D / , 2828, D /24 ? A A /24 A /24 A, D /24 A, D /24

A A /24 A /24 77 Sprint D /24 RPKI Binds prefixes to ASes authorized to originate them. X RPKI invalid! Sprint checks that A is not authorized for / /24

8 BGP RPKI ( origin authentication ) BGPSEC S S 4323,2828, FB, prefix S S 2828, FB, prefix S S SP, 4323, 2828, FB, prefix Security Benefits or Juice prevent prefix hijacks assume RPKI is fully deployed, and focus on 1-hop hijack. prevent route manipulations

A S S SP, A, D, prefix A, D, prefix X BGPSEC invalid! 99 Sprint D /24 P/S S S 4323,2828, D, prefix S S 2828, D, prefix S S SP, 4323, 2828, D, prefix S S 2828, D, prefix S S 4323, 2828, D, prefix 2828, D, prefix S S P/S ? Sprint can verify that D never sent A, D prefix S S RPKI

What happens when BGP and BGPSEC coexist? 10 BGP RPKI ( origin authentication ) BGPSEC S S 4323,2828, FB, prefix S S 2828, FB, prefix S S SP, 4323, 2828, FB, prefix Security Benefits or Juice prevent prefix hijacks assume RPKI is fully deployed, and focus on 1-hop hijack. prevent route manipulations

A 11 Sprint D Siemens /24 P/S Should Sprint choose the long secure path OR the short insecure one? P/S ? Secure ASes must accept legacy insecure routes Depends on the interaction between BGPSEC and routing policies! RPKI S S 4323,2828, D, prefix S S 2828, D, prefix S S SP, 4323, 2828, D, prefix A, D /24 A, D /24

12 1. local preference (often based on business relationships with neighbors) 2.prefer short routes … 3.break ties in a consistent manner

Security 1 st 1. local preference (cost) (often based on business relationships with neighbors) Security 2 nd 2.prefer short routes (performance) Security 3 rd 3.break ties in a consistent manner 13  Survey of 100 network operators shows that 10%, 20% and 41% would place security 1 st, 2 nd, and 3 rd, [Gill, Schapira, Goldberg’12] Security Cost,Performance SecurityCost,Performance

14 Security 1 st 1. local preference (cost) (prefer customer routes over peer over provider routes) Security 2 nd 2.prefer short routes (performance) Security 3 rd 3.break ties in a consistent manner  To simulate routing outcomes, we use a concrete model of local preference. [Gao-Rexford’00, Huston’99, etc.]  Our ongoing work tests the robustness of this local pref model.

15 1. Background: BGP, RPKI, BGPSEC, routing policies 2. BGPSEC in partial deployment is tricky 1. Protocol downgrade attacks 2. Collateral damages 3. Routing instabilities 3. Is the Juice worth the squeeze? 4. Summary

A 16 Sprint D /24 P/S S S 4323,2828, D, prefix S S 2828, D, prefix S S SP, 4323, 2828, D, prefix P/S Security 3 rd : Path length trumps path security! ? Protocol downgrade attack: Before the attack, Sprint has a legitimate secure route. During the attack, Sprint downgrades to an insecure bogus route. A, D /24 A, D /24

17 A D Siemens /24 P/S A, D /2 4 A, D /2 4 P/S ? Protocol downgrade attack: A secure AS with a secure route before the attack, downgrades to an insecure bogus route during the attack. Sprint P/S

M prefix P/S

W XZ Y M Before X deploys BGPSEC ? X offers the shorter path ? Shorter path! prefix D V P/S Secure ASes: 5 Happy ASes: 8

W XVZ Y M ? W offers the shorter path! ? Security 2 nd : Security trumps path length! Y experiences collateral damage because X is secure! P/S Secure ASes: 6 Happy ASes: 7 After X deploys BGPSEC prefix D P/S

A ? ? 5617 Collateral damage (during the attack): More secure ASes leads to more insecure ASes choosing bogus routes prefix P/S

22 Theorem: Routing converges to a unique stable state if all ASes use the same secure routing policy model.  But, if they don’t, there can be BGP Wedgies and oscillations.

23 1. Background: BGP, RPKI, BGPSEC, routing policies 2. BGPSEC in partial deployment is tricky 3. Is the Juice worth the Squeeze? 1. Can we efficiently select the optimal set of secure ASes? 2. Can we bound security benefits invariant to who is secure? 3. Is the BGPSEC juice worth the squeeze given RPKI? 4. Summary

Let S be the set of ASes deploying BGPSEC, A be the attacker and d be the destination The set of ASes choosing a legitimate route is Happy S,, prefix ? d A d prefix A | Happy(S, A, d) | = 7

∑ all A all d Let S be the set of ASes deploying BGPSEC, A be the attacker and d be the destination Our metric is the average of the set of Happy ASes Happy S,, 25 | Happy(S, A, d) | = 7 |V| 3 1 Metric(S) = prefix ? d A A d prefix

Problem: find set S of secure ASes that maximizes s. t. |S| = k, for a fixed attacker A and destination d Theorem: This problem is NP-hard for all three routing models. Happy S,, 26 A d prefix

∑ all A all d Problem: Compute upper and lower bounds on for any BGPSEC deployment set S 27 Happy S,, |V| 3 1 Metric(S) = A d prefix

A 28 Sprint D Siemens /24 A, D /24 A, D /24 The bogus path is shorter!

A 29 Sprint D Siemens P/S Sprint is doomed The bogus path is shorter! P/S Regardless of who is secure, Sprint will select the shorter bogus route! /24 A, D /24 A, D /24

A 30 Sprint D Siemens P/S /24 A, D /24 A, D /24 The legitimate path is shorter! Sprint is doomed The bogus path is shorter!

A 31 Sprint D Siemens / and 4323 are immune The legitimate path is shorter! A, D /24 A, D /24 Regardless of who is secure, 4323 and 2828 will select legitimate routes! Sprint is doomed The bogus path is shorter!

∑ all A all d Problem: Find upper and lower bound on 32  Key observation. Regardless of who is secure: 1.Doomed ASes will always choose bogus routes 2.Immune ASes will always choose legitimate routes  Lower bound on Metric(S) = fraction of immune ASes  Upper bound on Metric(S) = 1 – fraction of doomed ASes Happy S,, |V| 3 1 Metric(S) = A d prefix

33 lower bound with RPKI 17% upper bound with BGPSEC In the most realistic security 3 rd model, the best we could do is make extra 17% happy with security! 53% 36% 47% Average Fraction of Happy ASes results based on simulations on empirical AS-level graphs

34 lower bound with RPKI 17% 53% 36% 47% Securing 50% of ASes on the Internet Improvements in the security 3 rd and 2 nd models are only 4% and 8% respectively. 24% Average Fraction of Happy ASes results based on simulations on empirical AS-level graphs

35  Graph: A UCLA AS-level topology from  39K ASes, 73.5K and 62K customer-provider and peer links  For each attacker-destination pair, simulated routing and determined the sets of doomed and immune ASes  Quantified security-benefit improvements for many different BGPSEC deployment scenarios  Robustness Tests  added 550K extra peering links inferred from IXP data on  accounted for traffic patterns by focusing on only certain destinations (e.g. content providers) and attackers  currently repeating all analysis with respect to different local pref models

36 BGP RPKI ( origin authentication ) BGPSEC S S 4323,2828, FB, prefix S S 2828, FB, prefix S S SP, 4323, 2828, FB, prefix Security Benefits or Juice prevent prefix hijack  Unless Security is 1 st or BGPSEC deployment is very large, security benefits from partially deployed BGPSEC are meagre  Typically little observable difference between Sec 2 nd and 3 rd prevent route manipulations BGP and BGPSEC coexistence: very tricky *protocol downgrades collateral damages routing instabilities

37 check out the full version at 1Proofs 2More empirical analysis and plots 3Robustness tests 4BGPSEC deployment guidelines