14
14 State of the Art – S-BGP and soBGP  S-BGP  Certificates to verify origin AS  Cryptographic attestations added to routing announcements at each hop  Mechanism: identify which routes are invalid and filter them  soBGP  Build a (partial) AS level topology database

15
15 Limitations of the Secure Protocols  Previous solutions  Benefits only for large deployments (~10,000s)  No incentive for early adopters  No deployment for over a decade  Our goal: Provide incentives to early adopters!

16
16 Our Approach  Challenges  Non-participants outnumber participants  Participants rely on non-participants  Each AS exports only one route  Focus on raising the bar for the adversary rather than residual vulnerabilities  Secure routing within a small group  cooperating nodes  All participants’ routes are secured

18
18 Experimental Evaluations  Performance of existing techniques  They work well in large scale deployments  How do they do in small groups?  Evaluate performance of state-of-the art: soBGP  Evaluate partial deployment  If two ASes participate, a valid link connecting them must be in the registry

20
20 soBGP – Random Participation, 1 adversary Participants have a higher chance to have a valid route! Groups of 1 – 30 participants Number of Participant ASes Percentage of ASes % of the Internet with valid routes Participant ASes All ASes

21
21 soBGP – Deployment by 30 Random + Some Largest ISPs Better performance Cooperation of many large ISPs needed! Number of Large ISPs Percentage of ASes Participant ASes All ASes

22
22 Perfect Detection  Simulations: give ability to detect routes that don’t work  Is this sufficient to secure routing?  How useful is it to have perfect detection?  Can be done in practice:  Data-plane probing verifies validity of route by using it

23
23 Perfect Detection at 30 Random + Some Largest ISPs Perfect detection helps but not sufficient by itself! Percentage of ASes Number of Large ISPs Participant ASes All ASes

38
38 Shout + SBone – 1 Adversary With as few as 10 participants + 3 large ISPs, 95% of all ASes can reach the victim! Percentage of ASes Group Size (ASes) 5 large ISPs 3 large ISPs 1 large ISP 0 large ISPs

40
40 Performance and Scalability of Shout  Shout can be used reactively  Only shout if an attack is detected  Changes in routing table sizes negligible  Alternate routes must be saved in routing tables  The average table size increased by less than 5%  After shouting path lengths increase modestly  Paths less than 1.35 times longer  Detailed results next

41
41 Shout + SBone – Increase in Path Length With as few as 3 large ISPs the penalty is negligible! Length Ratio Group Size (ASes) 0 large ISPs 1 large ISP 3 large ISPs 5 large ISPs

46
46 Future Work  Deployment in larger groups where participants don’t trust each other  Secure routing protocol on the overlay?  Analytic models of the deployment  Predict which additional ASes to enlist to boost performance?  Effects of the structure of the graph on the outcomes?

47
47 Thank you for your attention!

48
48 Discussion 1.Effects of subprefix hijacking 2.What if participants not willing to choose less profitable routes? 3.What if N large ISPs are used instead of N largest ones? 4.Average results and error bars

49
1. Subprefix Hijacking  Threat: adversary deaggregates the victim’s prefix, all traffic is directed to the adversary  Key security mechanisms  Deaggregate the prefix and use shout to announce it  Tunnel endpoints already secure if announced with /24 prefixes  Only deaggregate when attack detected  Attack detected if at least one participant sees an unauthorized subprefix