1. One Hop for RPKI, One Giant Leap for BGP Security Yossi Gilad (Hebrew University) Joint work with Avichai Cohen (Hebrew University), Amir Herzberg (Bar Ilan University) and Michael Schapira (Hebrew University)

2. The Inter-Net: A Network of Networks Over 52,000 Autonomous Systems (ASes) The Border Gateway Protocol (BGP) computes routes between ASes (Network of networks). Destinations: IP prefixes (a.b.c.d/x). Google Verizon AT&T Comcast

3. The Internet AS 1AS 666 BGP is insecure! My prefix is 1.2.0.0/16 My prefix is 1.2.3.0/24 Prefix/Subprefix Hijack

4. The Internet AS 1AS 666 BGP is insecure! My prefix is 1.2.0.0/16 AS 1 is my neighbor False Path: next-AS

5. The Internet AS 1AS 666 BGP is insecure! My prefix is 1.2.0.0/16 I have a short path to AS 1 False Path: n-hops

6. BGP is insecure! Many security incidents: Telekom Malaysia route leak – June 12 th 2015 More specific attack on Amazon – March 27 th 2015 Syria Telecom hijacks YouTube – Dec. 9 th 2014. The Canadian ISP bitcoin hijack – Feb-May 2014. Turkey hijacks global DNS providers – Mar. 29 th 2014. Opin Kefri hijacks traffic to Beltelecom – Feb, May 2013. China Telecom, Pakistan Telecom… Some are malicious (Bitcoin) Some are misconfigurations (Telekom Malaysia) and some remain a mystery (Beltelecom)

7. Current Paradigm: A Two Step Solution Origin Authentication (RPKI) Periodic sync with trust-anchor, keeps BGP message format Protects against prefix hijacks Slowly gaining traction (protects 6% of prefixes) Path Validation (BGPsec) Real-time signature validation Protects against false paths Builds on the RPKI

8. Origin Authentication - RPKI RPKI: Resource Public Key Infrastructure Maps IP prefixes to ASes that own them.

9. Origin Authentication - RPKI RPKI: Resource Public Key Infrastructure Maps IP prefixes to ASes that own them. Slowly gaining traction

10. RPKI is not Enough Still vulnerable to the “next AS” attack v, Prefix m, v, Prefix AS 1 AS 3 AS 2 m IP Prefix v

11. Current Paradigm: A Two Step Solution Origin Authentication (RPKI) – Not enough! Path Validation (BGPsec)

12. Path Validation - BGPsec Use digitally signed BGP announcements. AS 1: (v, Prefix) AS 4: (a 1, v, Prefix)

13. Problems with BGPsec Changes to BGP routers: Online crypto requires new hardware [Goldberg’14, Comm ACM] Different message format legacy messages coexist with new format Meager benefits in partial deployment [Lychev et al., SIGCOMM2013] Legacy routers force downgrade to (insecure) BGP Attackers can advertise legacy BGP paths BGPsec is not “a small extension” of BGP

14. Our Goals Significant security benefits in partial deployment Avoid changes to routing infrastructure

15. Path-end Validation RPKI provides origin authentication Path-end validation also authenticates the “last hop” Not a `limited BGPsec’ d v a RPKI Did d approve reaching it via v? BGPSEC Design Choices and Summary of Supporting Discussions draft-sriram-bgpsec-design-choices-08

16. AS 1 1.2.3.0/24 Router AS 2 4.5.6.0/24 Router The Internet RPKI Repository AS 10 AS 20 Path-end Validation

17. AS 1 1.2.3.0/24 Router AS 2 Router The Internet RPKI Repository AS 10 AS 20 PathEndRecord ::= SEQUENCE { timestamp Time, origin ASID, adjList SEQUENCE (SIZE(1..MAX)) OF ASID } Path-end Validation

18. AS 1 1.2.3.0/24 Router AS 2 Router The Internet RPKI Repository AS 10 AS 20 Path-end Records ip as-path access-list as1 deny _[^(10|20)]_1_ ip as-path access-list allow-all permit ip as-path access-list as1 deny _[^(10|20)]_1_ ip as-path access-list allow-all permit Path-end Validation

19. Router Configuration Compatible with today’s routers Only one rule per-AS An order of magnitude less rules than origin authentication The implementation can be found at: https://github.com/routingsec/pathend AS 2 Router ip as-path access-list as1 deny _[^(10|20)]_1_ ip as-path access-list allow-all permit ip as-path access-list as1 deny _[^(10|20)]_1_ ip as-path access-list allow-all permit

20. Our Goals Avoid changes to routing infrastructure (like RPKI) Significant security benefits in partial deployment

21. Intuition AS 666 wants to attract AS 3’s traffic to IP prefix 1.2.3.0/24, but… It can’t lie about business relationship It can’t announce that it owns the prefix or is AS 1’s neighbor It has to launch 2-hop attack: (666,2,1,prefix) AS 3 Attacker, AS 666 Victim, AS 1 1.2.3.0/24 AS 2 Adopter Legacy Provider Customer Legend 4 4.5 3.5

22. Path-end vs. BGPsec AS 666 wants attract AS 3’s traffic to IP prefix 1.2.3.0/24, but… With BGPsec in partial deployment AS 3 does not learn any secure route attacker can announce (666,1,prefix) AS 3 Attacker, AS 666 Victim, AS 1 1.2.3.0/24 AS 2 Adopter Legacy Provider Customer Legend

23. Path-end vs. BGPsec Path-end validation is not just restricted BGPsec Offline vs. online keep message format and use today’s routers Important implication for security AS 666 launches a next-AS attack against AS 1 Not prevented by BGPsec Prevented by path-end validation AS 3 Attacker, AS 666 Victim, AS 1 1.2.3.0/24 AS 2 Adopter Legacy Provider Customer Legend

24. Simulation Framework Empirically-derived AS-level network from CAIDA Including inferred peering links [Giotsas et al., SIGCOMM’13] Evaluate fraction of ASes an attacker can attract For different adoption scenarios For different types of attack Using the simulation framework in [Gill et al., CCR’12]

25. Simulation Results Security in partial deployment

26. Simulation Results Path-end Validation vs. RPKI vs. BGPsec

27. Additional Results Large content providers are typically connected via short paths and hence better protected Path-end validation mitigates recent high profile incidents Deployment by large ISPs within a geographic region protects local traffic Governments may incentivize to protect local users

28. Simulation Results Biggest Content Providers

29. High Profile Past Incidents Results for Prefix Hijack

30. High Profile Past Incidents Results for Best Attack Strategy

31. Geography Based Deployment Governments can incentivize local large ISPs to adopt Users often retrieve content from servers in their geographic region (e.g. from CDNs)

32. Conclusions Path-end validation Is a modest extension to RPKI Can significantly impact BGP security while avoiding BGPsec’s deployment hurdles We advocate Incorporating path-end validation into RPKI Regulatory/financial efforts on gathering critical mass of adopters

33. Thank You!

34. Privacy-Preserving Mode Some ISPs may be reluctant to disclose the identities of their customers. Our design supports a private mode: an ISP deploys path-end filtering but does not register its neighbors. AS 1 neighbors list: AS 378 AS 111 AS 5719