Robert Lychev Sharon Goldberg Michael Schapira Georgia Tech - PowerPoint PPT Presentation

Robert Lychev Sharon Goldberg Michael Schapira Georgia ¡Tech ¡ Boston ¡University ¡ Hebrew ¡University ¡ Boston ¡University ¡ 1 ¡

q Many widely used communication protocols on the Internet were not originally designed with security considerations in mind q When working on designing and deploying new secure protocols we are faced with the following question: o How can we provide sufficient protection against attackers, while minimizing our resources and without introducing new complications? q This is especially crucial, when the new secure protocols have to be partially deployed together with legacy insecure protocols 2 ¡

What does (partially-deployed) BGPSEC offer over RPKI? Security Benefits or Juice q road to BGPSEC full-deployment is very tricky because introducing security only partially introduces new vulnerabilities (Or, is the juice worth the squeeze?) q not fully deployed BGPSEC provides only meager benefits over RPKI if network operators do not prioritize security in their routing policies • In standardization • In deployment • Crypto done online • Crypto done offline BGP and BGPSEC x i e f r p , n g r x O i e f 8 , r 2 p 8 , 2 n g coexistence r O x f i 8 , e 2 r 8 p 2 , , n 3 g 2 r 3 O 4 , 8 S 2 8 2 3 , 2 3 4 P , S S S RPKI BGP BGPSEC ( origin authentication ) 3 ¡

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

4323, 2828, Orgn prefix ¡ ¡ Sprint,4323,2828,Orgn Sprint ¡ prefix ¡ 4323 ¡ 2828, Orgn prefix ¡ 2828 ¡ A ¡ Orgn prefix ¡ Origin ¡ prefix ¡ 5 ¡ 5 ¡

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

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

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

2828, Orgn, prefix 4323,2828, Orgn, prefix SP, 4323,2828,Orgn, prefix S S S Sprint ¡ BGPSEC invalid! P/S 4323 ¡ ? ¡ ¡ A,Orgn,prefix P/S SP,A,Orgn,prefix S Sprint can verify that the Origin never sent 2828 ¡ A, Orgn, prefix P/S S A ¡ P/S 2828, Orgn, prefix S Origin ¡ prefix ¡ P/S RPKI 9 ¡ 9 ¡

Security Benefits or Juice suppose RPKI is fully deployed and focus on 1-hop hijack prevent route manipulations prevent prefix hijacks What happens when BGP x f i e p r n , g and BGPSEC coexist? O r x f i , e 8 p r 2 8 n , 2 g O r x , f i 8 e 2 p r 8 2 n , 3 , g 2 3 O r 4 , 8 S 2 8 2 , 3 2 3 4 , P S S S RPKI BGP BGPSEC ( origin authentication ) 10 ¡

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

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

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

Security 1 st 1. local preference (prefer customer routes over peer over provider routes) Security 2 nd 2. prefer short routes Security 3 rd 3. break ties in a consistent manner ² To ¡study ¡rouMng ¡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 ¡ 14 ¡

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

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

No ¡protocol ¡ No ¡collateral ¡ No ¡rouNng ¡ We ¡prove… ¡ downgrades? ¡ damages? ¡ anomalies? ¡ J ¡ J Security ¡1st ¡ L ¡ L Security ¡2nd ¡ L ¡ L Security ¡3rd ¡ ? Sprint Protocol downgrade attack: P/S 4323 A, Orgn P/S A secure AS with a secure route before prefix the attack, downgrades to an insecure 2828 ¡ P/S A bogus route during the attack. P/S Siemens Origin prefix ¡ P/S 17 ¡

20960 3257 52142 12389 3356 5617 174 P/S 3491 P/S 10310 P/S M ¡ 7922 P/S 40426 prefix ¡ P/S

Before X deploys BGPSEC W ? X offers the Y Secure ASes: 5 shorter route Happy ASes: 8 Z X V P/S ? Shorter route! P/S P/S M ¡ P/S Orgn prefix ¡ P/S

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

No ¡protocol ¡ No ¡collateral ¡ No ¡rouNng ¡ We ¡prove… ¡ downgrades? ¡ damages? ¡ anomalies? ¡ J ¡ L ¡ J L Security ¡1st ¡ L ¡ L ¡ L L Security ¡2nd ¡ L ¡ J ¡ L J Security ¡3rd ¡ 20960 3257 Collateral damage (during the attack): ? 52142 12389 More secure ASes leads to more insecure 3356 5617 5617 174 P/S P/S ASes choosing bogus routes ? 3491 P/S 10310 P/S prefix A 7922 P/S 40426 21 ¡ P/S

q Routing policies can also interact in ways that can cause BGP Wedgies [Griffin and Huston, rfc-4264, 2005] o can result in unpredictable and undesirable routing configurations 22 ¡

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

31027 ¡ for 29518 , local pref P/S is more important 29518 ¡ than security un intended P/S routing configuration for 31283 security 31283 ¡ is more important 3 ¡ P/S than local pref P/S 8928 ¡ Origin ¡ prefix ¡ P/S 24 ¡

No ¡protocol ¡ No ¡collateral ¡ No ¡rouNng ¡ We ¡prove… ¡ downgrades? ¡ damages? ¡ anomalies? ¡ J ¡ L ¡ J ¡ J L J Security ¡1st ¡ L ¡ L ¡ J ¡ L L J Security ¡2nd ¡ L ¡ J ¡ J ¡ L J J Security ¡3rd ¡ Routing anomalies such as BGPSEC Wedgies and persistent routing oscillations and can be avoided as long as all ASes prioritize security the same way. Otherwise, these routing anomalies could happen. 25 ¡

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

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