1 / 49

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. General Theme.

duena
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. General Theme • Many widely used communication protocols on the Internet were not originally designed with security considerations in mind • When working on designing and deploying new secure protocolswe are faced with the following question: • How can we provide sufficient protection against attackers, while minimizing our resources and without introducing new complications? • This is especially crucial, when the new secure protocols have to be partially deployed together with legacy insecure protocols

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

  4. Outline • Background: • BGP, RPKI, BGPSEC • routing policies when BGPSEC is only partially deployed • BGPSEC in partial deployment is tricky • Is the juice worth the squeeze? • Summary

  5. The Border Gateway Protocol (BGP) 4323, 2828, Orgn prefix Sprint Sprint,4323,2828,Orgn prefix 4323 2828, Orgn prefix 2828 A Orgn prefix Origin prefix 5

  6. Prefix Hijack 4323, 2828, Orgn prefix Sprint 4323 • ? A prefix A 2828 • Which route to choose? • Use routing policies: • e.g. prefer shorter routes. A Origin prefix prefix 6

  7. RPKI Prevents Prefix Hijacks 4323, 2828, Orgn prefix Sprint RPKI invalid! RPKI 4323 A prefix Sprint checks that A is not authorized for this prefix A 2828 Origin prefix prefix Binds prefixes to ASes authorized to originate them. 7

  8. The 1-Hop Hijack 4323, 2828, Orgn prefix Sprint RPKI invalid! RPKI 4323 • ? A, Orgn prefix A prefix A 2828 • Which route to choose? • Use routing policies: • e.g. prefer shorter routes. Origin prefix Binds prefixes to ASes authorized to originate them. 8

  9. BGPSEC Prevents the 1-Hop Hijack Sprint can verify that the Origin never sent Sprint 2828, Orgn, prefix BGPSEC invalid! RPKI A, Orgn, prefix 4323 4323,2828,Orgn, prefix • ? A,Orgn,prefix 4323,2828, Orgn, prefix A 2828 SP, 4323,2828,Orgn, prefix SP,A,Orgn,prefix 2828, Orgn, prefix 2828, Orgn, prefix S Origin S S S S P/S P/S P/S P/S P/S S S S prefix 9

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

  11. What Happens in Partial BGPSEC Deployment? • ? In BGPSEC insecure ASes use legacy BGP, and secure ASes must accept legacy insecure routes! Should Sprint choose the long secure route OR the short insecure one? Sprint RPKI 4323 A, Orgn prefix 4323, 2828, Orgn, prefix A 2828 SP, 4323, 2828, Orgn, prefix A 2828, Orgn, prefix Siemens S Origin P/S P/S P/S P/S P/S P/S S S prefix It depends on how Sprint prioritizes security in its routing decision! 11

  12. How to Prioritize Security? • local preference (often based on business relationships with neighbors) 2. prefer short routes … 3. break ties in a consistent manner

  13. How to Prioritize Security? Local Pref, Route Length Security Local Pref, Route Length Security Security 1st • local preference (often based on business relationships with neighbors) Security 2nd 2. prefer short routes Security 3rd 3. break ties in a consistent manner • NANOG survey of 100 network operators shows that 10%, 20%, and 41% would place security 1st, 2nd, and 3rdrespectively [Gill, Schapira, Goldberg’12]

  14. Our Routing Model Security 1st • local preference (prefer customer routes over peer over provider routes) Security 2nd 2. prefer short routes Security 3rd 3. break ties in a consistent manner • To study routing outcomes, we use a concrete model of local preference.[Gao-Rexford’00, Huston’99, etc.] • Our results are robust with respect to various local pref models

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

  16. Protocol Downgrade Attack, Security 3rd! • ? Security 3rd: Route length trumps route security! Sprint 4323 A, Orgn prefix 4323,2828, Orgn, prefix A 2828 SP, 4323, 2828, Orgn, prefix 2828, Orgn, prefix Origin S S P/S P/S P/S P/S S prefix Protocol downgrade attack: Before the attack, Sprint has a legitimate secure route. During the attack, Sprint downgrades to an insecure bogus route . 16

  17. 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, Orgn prefix 2828 Siemens Origin prefix

  18. 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

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

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

  21. 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

  22. BGPSEC Wedgies • Routing policies can also interact in ways that can cause BGP Wedgies[Griffin and Huston, rfc-4264, 2005] • can result in unpredictable and undesirable routing configurations

  23. BGPSEC Wedgie 31027 for 29518, local pref is more important than security 29518 intended routing configuration for 31283 security is more important than local pref 31283 3 8928 P/S P/S P/S P/S P/S Origin prefix

  24. BGPSEC Wedgie 31027 for 29518, local pref is more important than security 29518 unintended routing configuration for 31283 security is more important than local pref 31283 3 8928 P/S P/S P/S P/S P/S Origin prefix

  25. Partial Deployment is Very Tricky! Routing anomalies such as BGPSEC Wedgiesand persistent routing oscillations and can be avoided as long as all ASes prioritize security the same way. Otherwise, these routing anomalies could happen.

  26. Outline • Background: BGP, RPKI, BGPSEC, routing policies • BGPSEC in partial deployment is tricky • Is the Juice worth the Squeeze? • How can we quantify BGPSEC benefits? • Can we bound BGPSEC benefits without knowing who may deploy it? • What are BGPSEC benefits beyond what RPKI can provide? • Summary

  27. How to Quantifying BGPSEC Benefits? Fix a particular Origin, attacker A and let S be the set of ASes deploying BGPSEC The set of ASes choosing a legitimate route is Sprint 4323 2828 S = | Happy(S, A, Origin)| = 3 A Siemens Origin prefix prefix Happy S, , Origin 27 prefix A

  28. How to Quantify BGPSEC Benefits? Fix a particular Origin, attacker A and let S be the set of ASes deploying BGPSEC The set of ASes choosing a legitimate route is Sprint 4323 2828 S = everyone | Happy(S, A, Origin)| = 5 A Siemens Origin prefix prefix P/S P/S P/S P/S P/S P/S Happy S, , Origin 28 prefix A

  29. Quantifying Security: A Metric Fix a particular Origin, attacker A and let S be the set of ASes deploying BGPSEC Our metric is the average of the set of Happy ASes Sprint 4323 ∑ S = everyone | Happy(S, A, Origin)| = 5 2828 A Siemens allA allO Origin prefix prefix 1 P/S P/S P/S P/S P/S P/S Happy S, , Metric(S) = 3 |V| Origin 29 prefix A

  30. Who Should Deploy BGPSEC? • We can efficiently compute bounds on BGPSEC benefits independently of who deploys it • to do this we figure out which ASes do not benefit from BGPSEC by considering only the scenario when no AS deploys BGPSEC

  31. Bounding BGPSEC Benefits: Security 3rd Sprint The bogus route is shorter! 4323 A, Orgn prefix A 2828 Siemens Origin prefix 31

  32. Bounding BGPSEC Benefits: Security 3rd Sprint Sprint is doomed The bogus route is shorter! 4323 A, Orgn prefix A 2828 Siemens Origin P/S P/S P/S P/S P/S prefix Regardless of who is secure, Sprint will select the shorter bogus route! 32

  33. Bounding BGPSEC Benefits: Security 3rd Sprint Sprint is doomed The bogus route is shorter! The legitimate route is shorter! 4323 A, Orgn prefix A 2828 Siemens Origin P/S P/S P/S P/S P/S prefix 33

  34. Bounding BGPSEC Benefits: Security 3rd Sprint Sprint is doomed The bogus route is shorter! 2828 and 4323 are immune The legitimate route is shorter! 4323 A, Orgn prefix A 2828 Siemens Origin prefix Regardless of who is secure, 4323 and 2828 will select legitimate routes! 34

  35. Bounding BGPSEC Benefits: Security 3rd Sprint Sprint is doomed The bogus route is shorter! 2828 and 4323 are immune The legitimate route is shorter! 4323 A, Orgn prefix A 2828 Siemens Origin prefix Only Siemans is neither doomed nor immune! 35

  36. Bounding BGPSEC Benefits: Security 3rd Sprint Sprint is doomed The bogus route is shorter! 2828 and 4323 are immune The legitimate route is shorter! 4323 A, Orgn prefix A 2828 Siemens Origin P/S P/S P/S P/S P/S prefix Only Siemans is neither doomed nor immune! Regardless of who is secure, only Siemans can benefit from BGPSEC! 36

  37. Quantifying BGPSEC Benefits • Regardless of who deploys BGPSEC: • Doomed ASeswill always choose bogus routes • Immune ASeswill always choose legitimate routes • Only protectableASes can be benefit from BGPSEC • Security benefits lowerbound = fraction of immuneASes • Security benefits upper bound = 1 - fraction of doomedASes • Most ASes are immune or doomed when security is 3rd

  38. BGPSEC Benefits Bounds over RPKI upper bound with BGPSEC 47% 36% 17% 53% Average Fraction of Happy ASes lower bound with RPKI In the most realistic security 3rd model, the best we could do is make extra 17% happy with security!

  39. Securing 213 High Degree ASes & their Stubs(13 Tier 1’s + 100 Tier 2’s + 100 Tier 3’s + all their stubs) Securing 56% of ASes on the Internet 47% 36% 25% 17% 53% Average Fraction of Happy ASes lower bound with RPKI Improvements in the security 3rd and 2nd models are only 5% and 10% respectively.

  40. Our Methodology • Graph: A UCLA AS-level topology from 09-24-2012 • 40K ASes, 73.5K and 62K customer-provider and peer links • Used large-scale simulations to determine • upper and lower bounds on metric improvement • security-benefits for many different BGPSEC deployments • 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 • repeated analysis with respect to different local pref models

  41. The LPk Local Pref Model • Survey shows ~80% of network operators prefer customer over peer routes, but some (e.g. content providers) prefer shorter peer routes over longer customer routes [Gill, Schapira, Goldberg 2012] • In the LPk model, for any k ≥ 0, rank routes as follows: • customer routes of length 1 • peer routes of length 1 • … • customer routes of length k • peer route of length k • customer routes of length > k • peer routes of length > k • provider routes

  42. Securing 213 High Degree ASes & their Stubs(13 Tier 1’s + 100 Tier 2’s + 100 Tier 3’s + all their stubs) Securing 56% of ASes on the Internet 12% 9% 0.8 12% 17% Sec 3rd Average Fraction of Happy ASes 0.4 53% 68% 80% 81% 0.0 LP50 LP1 LP0 LP2 As k increases, metric improvements are 5%, 4%, 4%, and 6%.

  43. So Is the Juice Worth the Squeeze? • Unless Security is 1st or BGPSEC deployment is very large, security benefits from partially deployed BGPSEC are meager on average • On average, not much observable difference between Sec 2nd and 3rd • Tier 1 ASes are good candidates for initial deployment when security is 1stbut terrible candidates otherwise (see paper for details) • Security Benefits or Juice protocol downgrades collateral damages routing anomalies (very important) 4323,2828, Orgn, prefix SP, 4323, 2828, Orgnprefix 2828, Orgn, prefix BGP and BGPSEC coexistence: very tricky S S S • RPKI (origin authentication) • BGP • BGPSEC

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

  45. Securing 213 High Degree ASes & their Stubs(13 Tier 1’s + 100 Tier 2’s + 100 Tier 3’s + all their stubs) Securing 56% of ASes on the Internet 0.4 Sec 3rd Average Fraction of ASes 0.2 21% 18% 10% 10% 6% 6% 4% 3% 0.0 LP50 LP1 LP0 LP2 As k increases, the fraction of ASes with secure routes grows, but most of them are happy anyway.

  46. Securing 213 High Degree ASes & their Stubs(13 Tier 1’s + 100 Tier 2’s + 100 Tier 3’s + all their stubs) Securing 56% of ASes on the Internet 14% 15% 24% 0.8 36% Sec 2nd Average Fraction of ASes 0.4 53% 68% 80% 81% 0.0 LP50 LP1 LP0 LP2 As ASes become more stubborn (i.e. k increases), metric improvements are 9.9%, 9.7%, 10.1%, and 9.8%

  47. Securing 213 High Degree ASes & their Stubs(13 Tier 1’s + 100 Tier 2’s + 100 Tier 3’s + all their stubs) Securing 56% of ASes on the Internet 0.4 Sec 2nd Average Fraction of ASes 0.2 21% 19% 12% 12% 4% 4% 3% 3% 0.0 LP50 LP1 LP0 LP2 As ASes become more stubborn (i.e. k increases), fraction of ASes with secure routes grows, but most of them are happy anyway

  48. Securing 213 High Degree ASes & their Stubs(13 Tier 1’s + 100 Tier 2’s + 100 Tier 3’s + all their stubs) Securing 56% of ASes on the Internet 19% 20% 32% 0.8 47% Sec 1st Average Fraction of ASes 0.4 53% 68% 80% 81% 0.0 LP50 LP1 LP0 LP2 As ASes become more stubborn (i.e. k increases), metric improvements are 24.8%, 24.7%, 17.2%, and 16.1%

  49. Securing 213 High Degree ASes & their Stubs(13 Tier 1’s + 100 Tier 2’s + 100 Tier 3’s + all their stubs) Securing 56% of ASes on the Internet 0.4 Sec 1st 10% 9% Average Fraction of ASes 14% 14% 0.2 22% 23% 18% 18% 0.0 LP50 LP1 LP0 LP2 As ASes become more stubborn (i.e. k increases), fraction of happy ASes with secure routes grows

More Related