1 / 63

BGP Security in Partial Deployment Is the Juice Worth the Squeeze?

BGP Security in Partial Deployment Is the Juice Worth the Squeeze?. Robert Lychev Sharon Goldberg Michael Schapira. Georgia Tech Boston University. Boston University. Hebrew University. How Secure is Today’s Internet Routing?. February 2008: Pakistan Telecom hijacks YouTube!.

vartouhi-hansen
Download Presentation

BGP Security in Partial Deployment Is the Juice Worth the Squeeze?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. BGP Security in Partial DeploymentIs the Juice Worth the Squeeze? Robert Lychev Sharon Goldberg Michael Schapira Georgia Tech Boston University Boston University Hebrew University

  2. How Secure is Today’s Internet Routing? • February 2008: Pakistan Telecom hijacks YouTube! The Internet Pakistan Telecom YouTube I’m YouTube: IP 208.65.153.0/22 Multinet Pakistan Telnor Pakistan Aga Khan University

  3. How Secure is Today’s Internet Routing? • What should have happened… drop packets Pakistan Telecom X YouTube I’m YouTube: IP 208.65.153.0/22 Multinet Pakistan Telnor Pakistan Aga Khan University

  4. How Secure is Today’s Internet Routing? • What did happen Pakistan Telecom No, I’m YouTube! IP 208.65.153.0/24 Pakistan Telecom YouTube I’m YouTube: IP 208.65.153.0/22 Multinet Pakistan Telnor Pakistan Aga Khan University

  5. Nov 2013

  6. Rare Occurances? Not Really!

  7. Outline • Background: • BGP, RPKI, BGPSEC • routing policies in BGPSEC partial deployment • BGPSEC in partial deployment is tricky • Is the juice worth the squeeze? • Summary

  8. The Inter-Net:A Network of Networks Over 45,000 Autonomous Systems (ASes) AT&T Comcast Microsoft Verizon

  9. Border Gateway Protocol (BGP) 4323, 2828, D 69.63.176.0/24 Sprint Sprint, 4323, 2828, D 69.63.176.0/24 4323 2828, D 69.63.176.0/24 2828 A D 69.63.176.0/24 D 69.63.176.0/24 9

  10. The “1-hop hijack” 4323, 2828, D 69.63.176.0/24 Sprint 4323 • ? A, D 69.63.176.0/24 A 2828 • Which route to choose? • Use routing policies. • e.g. “Prefer short paths” D 69.63.176.0/24 10

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

  12. RPKI Prevents Prefix Hijacks Sprint RPKI X RPKI invalid! 4323 A 69.63.176.0/24 Sprint checks that A is not authorized for 69.63.176.0/24 A 2828 D 69.63.176.0/24 69.63.176.0/24 Binds prefixes to ASes authorized to originate them. 12

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

  14. BGPSEC Prevents the “1-hop hijack” Sprint can verify that D never sent Sprint X BGPSEC invalid! 2828, D, prefix RPKI A, D prefix 4323 4323, 2828, D, prefix • ? A, D, prefix 4323,2828, D, prefix A 2828 SP, 4323, 2828, D, prefix SP, A, D, prefix 2828, D, prefix 2828, D, prefix D S P/S P/S P/S S P/S S P/S S S S S S 69.63.176.0/24 14

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

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

  17. BGP Decision Process • local preference (often based on business relationships with neighbors) 2. prefer short routes … 3. break ties in a consistent manner

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

  19. Our Routing Model Security 1st • local preference (cost) (prefer customer routes over peer over provider routes) Security 2nd 2. prefer short routes (performance) Security 3rd 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.] • We test the robustness of this local pref model.

  20. Outline • Background: BGP, RPKI, BGPSEC, routing policies • BGPSEC in partial deployment is tricky • Protocol downgrade attacks • Collateral damages • Routing instabilities • Is the Juice worth the squeeze? • Summary

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

  22. Partial Deployment is Very Tricky! A • ? Sprint Protocol downgrade attack:A secure AS with a secure route before the attack, downgrades to an insecure bogus route during the attack. 4323 P/S P/S P/S P/S P/S A, D 69.63.176.0/24 2828 Siemens D 69.63.176.0/24

  23. Collateral Damages; Security 2nd 20960 3257 52142 12389 3356 5617 174 3491 10310 P/S P/S P/S P/S P/S M 7922 40426 prefix

  24. Collateral Damages; Security 2nd Before X deploys BGPSEC W • ? Y X offers the shorter path Secure ASes: 5 Happy ASes: 8 Z X V • ? Shorter path! P/S P/S P/S P/S P/S M D prefix

  25. Collateral Damages; Security 2nd After X deploys BGPSEC W • ? Y experiences collateral damage because X is secure! Y W offers the shorter path! Z X V • ? Security 2nd: Security trumps path length! Secure ASes: 6 Happy ASes: 7 P/S P/S P/S P/S P/S P/S M D prefix

  26. Partial Deployment is Very Tricky! 20960 3257 Collateral damage (during the attack): Moresecure ASes leads to more insecure ASes choosing bogus routes • ? 52142 P/S P/S P/S P/S P/S P/S 12389 A 3356 5617 5617 174 • ? 3491 10310 prefix 7922 40426

  27. Partial Deployment is Very Tricky! Theorem: Routing converges to a unique stable state if all ASes use thesame secure routing policy model.  But, if they don’t, there can be BGP Wedgies and oscillations.

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

  29. Quantifying Security: A Metric Let S be the set of ASes deploying BGPSEC, Abe the attacker and d be the destination Our metric is the average of the set of Happy ASes 5617 174 20960 3257 3491 52142 12389 10310 ∑ 3356 5617 7922 • ? d | Happy(S, A, d)| = 7 prefix allA alld A 1 Happy S, , Metric(S) = 3 |V| d prefix A

  30. It is Hard to Decide Whom to Secure 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, , d prefix A

  31. Bounding Security Metric. Security 3rd Sprint The bogus path is shorter! 4323 A, D 69.63.176.0/24 A 2828 Siemens D 69.63.176.0/24 31

  32. Bounding Security Metric. Security 3rd Sprint Sprint is doomed The bogus path is shorter! 4323 A, D 69.63.176.0/24 A 2828 Siemens D P/S P/S P/S P/S P/S 69.63.176.0/24 Regardless of who is secure, Sprint will select the shorter bogus route! 32

  33. Bounding Security Metric. Security 3rd Sprint Sprint is doomed The bogus path is shorter! The legitimate path is shorter! 4323 A, D 69.63.176.0/24 A 2828 Siemens D P/S P/S P/S P/S P/S 69.63.176.0/24 33

  34. Bounding Security Metric. Security 3rd Sprint Sprint is doomed The bogus path is shorter! 2828 and 4323 are immune The legitimate path is shorter! 4323 A, D 69.63.176.0/24 A 2828 Siemens D 69.63.176.0/24 Regardless of who is secure, 4323 and 2828 will select legitimate routes! 34

  35. Different Idea: Bound Security Benefits! Problem: Find upper and lower bound on Happy S, , Metric(S) = ∑ allA alld • Key observation. Regardless of who is secure: • Doomed ASeswill always choose bogus routes • Immune ASeswill always choose legitimate routes • Lower bound on Metric(S) = fraction of immune ASes • Upper bound on Metric(S) = 1 – fraction of doomed ASes 1 3 |V| d prefix A

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

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

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

  39. Ongoing and Future Research:New Paradigms • A grassroots approach to routing security • anonymity service in lieu of a PKI • Outsourcing interdomain routing to a non-trusted center • via Secure MultiParty Computation (SMPC)

  40. THANK YOU check out the full version at http://arxiv.org/abs/1307.2690 Proofs More empirical analysis and plots Robustness tests BGPSEC deployment guidelines

  41. Our Methodology • Graph: A UCLA AS-level topology from 09-24-2012 • 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 09-24-2012 • 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

  42. Bounding Security Metric. Security 3rd Sprint Sprint is doomed The bogus path is shorter! 2828 and 4323 are immune The legitimate path is shorter! 4323 A, D 69.63.176.0/24 A 2828 Siemens D 69.63.176.0/24 Only Siemans is neither doomed nor immune! 42

  43. Bounding Security Metric. Security 3rd Sprint Sprint is doomed The bogus path is shorter! 2828 and 4323 are immune The legitimate path is shorter! 4323 A, D 69.63.176.0/24 A 2828 Siemens D P/S P/S P/S P/S P/S 69.63.176.0/24 Only Siemans is neither doomed nor immune! Regardless of who is secure, only Siemans can benefits from BGPSEC! 43

  44. Security Benefits Bounds over RPKI upper bound with BGPSEC upper bound with BGPSEC 11% 30% 17% 79% lower bound with RPKI 53% 10% In the most realistic security 3rd model, the best we could do is make extra 17% happy with security!

  45. Securing 113 top Tier and their Stubs Securing 50% of the Internet 11% 30% 24% 17% 79% lower bound with RPKI 53% 10% Improvements in the security 3rd and 2nd models are only 4% and 8% respectively.

  46. Final Remarks • we highlight operational issues of BGPSEC partial deployment • results are not meant to be predictive, but our trends are robust

  47. BGPSEC Deployment Guidelines • Network administrators have to agree on security prioritization • otherwise, unpredictable routing behavior may be encountered • ASes deploying BGPSEC experience noticeable security benefit improvements when routing to secure destinations • secure islands could form with different security prioritizations • Overall security benefits are almost the same even when STUBs deploying BGPSEC do not verify routes themselves • Tier 1 networks are not a good choice for initial deployment • protocol downgrades • most ASes are immune (i.e. happy to begin with)

  48. Security Benefits Bounds over RPKI upper bound with BGPSEC 11% 25% 15% 77% lower bound with RPKI 60% 12% In the most realistic security 3rd model, the best we could do is make extra 15% happy with security!

  49. Security Benefits Bounds over RPKI IXP-links augmented graph upper bound with BGPSEC 10% 22% 16% 80% lower bound with RPKI 62% 10% average over all attackers

  50. Security Benefits Bounds over RPKI IXP-links augmented graph upper bound with BGPSEC 10% 27% 19% 82% lower bound with RPKI 54% 8% average over only non-stub attackers

More Related