Don’t Secure Routing, Secure Data Delivery

1. Availability Centric Routing (ACR): A Multipath Alternative to Secure BGP Protocols. Don’t Secure Routing, Secure Data Delivery Dan Wendlandt (CMU) With: Ioannis Avramopoulos (Princeton), David G. Andersen (CMU), and Jennifer Rexford (Princeton)

2. Availability Centric Routing (ACR) The point of this talk: You don’t need to secure BGP! Instead: 1) Multipath routing exposes possible paths 2) Hosts find and securely use working paths => More bang for your security buck!

3. Requirements for Secure Communication? • Secrecy of Data • Authenticity of Data • Availability of the Communication Channel Needs end-to-end security (e.g., SSL & IPsec). Depends on routing and forwarding.

4. Requirements for Routing & Forwarding? Claim: The routing and forwarding infrastructure need only ensure availability. Any additional security should be end-to-end. Control plane Define: Availability A source can learn about and use a working network path to the destination if such a path exists. Data plane

5. S*BGP is too much AND too little! Deployment Requirements: Global agreement on a protocol + PKI, Heavy-weight, Internet-wide router upgrades. Too Much: Limited Protection: Cannot avoid data plane attacks or outages on valid BGP paths. Too Little:

6. Achieving Availability Achieving availability is easier than securing the routing protocol: Multi-path routing + check that path “works” + alternate path selection = Availability Even if the routing protocol is insecure! Traffic Sources provide end-to-end check (e.g., SSL or IPSec)

7. Realizing ACR Host or Edge Router Availability Provider (AP): Expose path diversity Traffic Source: Select & use routes. Control Plane Selecting from set of alternate paths Collect & offer multiple routes. Data Plane “Deflect” packets on alternate paths. Monitor quality of current path.

8. APs Offer Alternate Path “Deflections” AS D Host B AS X AS Y Deflections use IP-in-IP to traverse alternate BGP paths learned by the AP Egress #1 AP Egress #2 AS Z AS A Host A

9. APs Offer Alternate Path “Deflections” 1. The AP stores all BGP path information learned by border routers. AS D Host B AS X AS Y Egress #1 AP Egress #2 Route Monitor AS Z AS A Host A

10. APs Offer Alternate Path “Deflections” AS D Host B 2. Source requests alternate paths from the AP. Recieves: “Y D” via Egress #2 AS X AS Y Egress #1 AP Egress #2 Route Monitor AS Z AS A AS A Host A

11. APs Offer Alternate Path “Deflections” AS D 3. Source chooses desired alternate path, which is deflected by egress #2. Host B AS X AS Y Egress #1 AP Egress #2 Route Monitor AS Z AS A Host A

12. APs Offer Alternate Path “Deflections” 4. Source encapsulates packet to the egress point, includes deflection ID. AS D Host B AS X AS Y Egress #1 AP Egress #2 SRC: Host A Route Monitor DST: Egress #2 Deflection ID: Y AS Z SRC: Host A DST: Host B AS A Data Host A

13. APs Offer Alternate Path “Deflections” 5. Packet forwarded with IP to alternate egress. AS D Host B AS X AS Y Egress #1 AP Egress #2 SRC: Host A Route Monitor DST: Egress #2 Deflection ID: Y AS Z SRC: Host A DST: Host B AS A Data Host A

14. APs Offer Alternate Path “Deflections” 6. Egress point decapsulates packet, sends it to alternate next-hop AS based on ID. AS D Host B AS X AS Y Egress #1 AP Egress #2 Deflection ID: Y Route Monitor SRC: Host A AS Z DST: Host B Data AS A Host A

15. APs Offer Alternate Path “Deflections” AS D Host B 6. Packet is forwarded over IP to the destination. AS X AS Y Egress #1 AP Egress #2 Route Monitor SRC: 10.1.1.1 AS Z DST: 20.2.2.2 Data AS A Host A

16. Properties of Routing Deflections • ACR != source routing. • Source can select only valid BGP paths. • APs can easily limit or deny access to any path. 2) Deflections already supported in hardware!

17. Functionality Implemented at Source Host or Edge Router Traffic Source: Select & use routes. Selecting from set of alternate paths Monitor quality of current path.

18. Sources Monitoring Path Quality Two criteria for a “working path”: • Does current path preserve authenticity? • (e.g., IPSec, SSL) • Was initial destination authentication valid? • Are packets being corrupted on the path? • 2) Does current path perform well? • (e.g., detect TCP-failures, NetFlow) • Is loss rate, etc., sufficient to consider this path usable?

19. Selecting Alternate Paths Key Insight: Single-path BGP limits bogus paths from attackers! Evaluation of Shortest AS-Path Hueristic: Hosts will explore several a few bad paths per attacking AS before finding a legit path. => Internet outages become brief delays in connection setup.

20. Optimizing Path Selection: History • 1) History of stable/working routes. • Prefer AS-paths that worked in the past. • Also prefer similar paths. • Past work suggests that AS-paths change infrequently in practice: • Rexford, et al. (IMW ’02) • Chang, et al. (ICNP ’03) • Butler, et al. (CCS ’06)

21. Optimizing Path Selection: Hints 2) Destination-specific connectivity “hints” indicate what upstream ASes are most likely to be legitimately announcing their prefix. AS X AS Z If bank.com provides NO hints AP AS C AS D

22. Optimizing Path Selection: Hints 2) Destination-specific connectivity “hints” indicate what upstream ASes are most likely to be legitimately announcing their prefix. AS D AS X AS Z If bank.com provides hint: “D” AP AS C AS D

23. Optimizing Path Selection: Hints 2) Destination-specific connectivity “hints” indicate what upstream ASes are most likely to be legitimately announcing their prefix. AS D AS C AS X AS Z If bank.com provides hint: “C D” AP AS C AS D

24. Hints are Simple and Effective No additional PKI required Hints verified using end-to-end authentication mechanism. Evaluation of simple hints: Only a few TOTAL paths must be explored regardless of the number of attackers!

25. Evaluation: Resistance to BGP Hijacks • Realistic simulation on inferred AS topology: • A single tier-1 ISP acts as an availability provider. • Vary number of attackers, placed in random ASes. • Test each AS to see if it receives a “valid” route. What attack resistance can this offer, even with only one AS participating?

26. Resistance to BGP Hijacks Evaluate how often three source types have a path to the valid destination, while varying the number of attackers. 1) Single-Path BGP ASes use single “best’’ BGP path, as today. 2) Intelligent Multi-homing Stub ASes with 5 upstreams succeed if any provider offers a valid route. 3) Tier-1 Availability Provider A single tier-1, offering deflections via peer and customer- learned routes.

27. ACR Resists BGP Hijacks

28. ACR Resists BGP Hijacks

29. Preventing BGP Availability Attacks Single-Path BGP ACR Attacker must get victim to hear a path that is “better” than its current path. Attacker must prevent AP from hearing any valid path Requirements for a successful BGP availability attack

30. Adoptability Advantages Low Barriers to Entry Strong Deployment Incentives Drives Incremental Control Plane Security Performance Benefits of Multipath

31. Adoptability Advantages Low Barriers to Entry • No routing PKI, registries, or S*BGP standardization. • End-to-end security is already widely deployed. • Router hardware already supports deflections. Strong Deployment Incentives Drives Incremental Control Plane Security Performance Benefits of Multipath

32. Adoptability Advantages Low Barriers to Entry Strong Deployment Incentives • Large ISPs can sell “path diversity” as a service. • Edge networks receive immediate security benefits. Drives Incremental Control Plane Security Performance Benefits of Multipath

33. Adoptability Advantages Low Barriers to Entry Strong Deployment Incentives Drives Incremental Control Plane Security • Path selection optimizations (e.g., “hints”) provide incentives for additional routing security. Performance Benefits of Multipath

34. Adoptability Advantages Low Barriers to Entry Strong Deployment Incentives Drives Incremental Control Plane Security Performance Benefits of Multipath • Multipath also supports selection of high performance (e.g., low latency) paths.

35. Contributions of ACR • Secure communication without secure routing. • ACR’s benefits (e.g. avoiding data plane threats) are valuable even with s*BGP. • Low barriers to entry and clear benefits for early adopters.

36. Thanks! Questions & Comments Please! Joint work with: Ioannis Avramopoulos (Princeton) David G. Andersen (CMU) Jennifer Rexford (Princeton) Contact: Dan Wendlandt (CMU) dwendlan@cs.cmu.edu

37. Handling Traffic Analysis Attacks? S*BGP ACR Path selection heuristics like route history and “hints” avoid new and suspicious paths Cryptographic path attestation makes it difficult for attacker to get “on path” Is it worth the added complexity of S*BGP? S*BGP provides stronger protection against malicious ASes getting “on path”, but both are vulnerable to traffic analysis by well-connected ASes. Only end-to-end techniques (e.g., mix-nets) offer strong protection.

38. Handling Hijacks of Unused Address Space? S*BGP ACR Routers accept all announcements. Cryptographic database of prefix ownership has routers reject invalid announcements. Is it worth the added complexity of S*BGP? Unused hijacks are a lesser threat, as they do not compromise availability. Those needing to block traffic from such addresses can easily use “bogon-like” filters.

39. What about stupid users? Single-Path: If an e2e authentication check fails, the only alternative is no reachability. Thus, they prompt the user as a last resort. Multi-Path: If one check fails, explore alternates until authentication works. No need to prompt the user unless all paths fail.

40. But You’re Just Asking for More From Sources! Yes! But consider that: • End-to-end security is already widely deployed for many types of traffic. • Deploying changes on the edge is easier (look at speed of SSL/IPSec adoption!) • No need for global agreement on a “single best approach” • Immediate benefits for any application that adds end-to-end security.

41. Sure, But Isn’t This Just a Stop-gap? Not really: It would likely solve the problem more quickly than S*BGP, but: • It helps drive improvements to the security of control plane data, helping S*BGP. • Prevents data-plane availability attacks not handled by S*BGP => ACR offers evolving adoptability path.

42. Compromised routers in AP network? • Attacks on AP’s internal routes possible, but prevention & detection is significantly easier • Internal network probing can easily be done securely. • Defenses can use knowledge of complete “true” network topology • Link-state routing protocols are significantly easier to secure. • Paths through other egress routers will still be valid. • Highest robustness from having multiple independent tier-1s as availability providers.

43. Q1: Resistance to Attacks Tier-1 AP protection degrades slightly with “local” attackers.

44. Q1: Adding Customer-Only Filters

45. Q2: Path Exploration with Intelligent Attacker

46. Handling Availability Attacks? S*BGP ACR Multi-Path, probing to find working paths Control Plane Availability Single-Path, PKI, registry & signatures None Data Plane Availability

47. Two Views The Pessimist: This is NEVER going to happen. The Optimist: It will be YEARS before S*BGP is in full use. Members of both sides are asking: - How will everyone agree on one protocol, and one PKI? - What incentives are there for ISPs to invest in adoption? - What can we do in the mean time? - What is the real problem here???

48. Progress with Secure Routing Protocols ‘96: Smith, path and origin validation ‘97: S-BGP started ’04: Listen & Whisper ’05: psBGP ’03: IRV ’93: Kumar, authenticated inter-domain route updates ’06: APNIC begins cert. generation software dev. ’02: so-BGP ‘98: Bates, DNS to verify AS origin ’04: SPV Still, no agreement on a protocol or a PKI