Availability Centric Routing (ACR) Robust Interdomain Routing Without BGP Security July 25 th, 2006

Current Routing Security Focus Current proposals like S-BGP, etc. use cryptography to provide control plane: 1) origin authentication 2) path validity

Too Much and Too Little? These proposals are: 1) Heavy-weight: requiring modifications to routers, continually updated address registries, increased BGP complexity. 2) Insufficient: providing no protection from malicious routers in the data-plane or links made unusable by congestion or bad route convergence.

A Different Approach Today end-hosts/edge routers often already provide end-to-end security using mechanisms such as SSL or IPSec. With end-to-end security, we claim that: The routing infrastructure only has to worry about providing availability, i.e. the ability to find and use a valid path if it exists.

High-level Approach 1) Clients learn multiple potential paths to a destination, instead of a single “best path”. 2) Clients use end-to-end security mechanisms and monitor path performance to detect good paths. 3) Clients can use adequate paths and change routes if necessary.

Taxonomy of Attacks Snooping & Traffic Modification Traffic Analysis Destination Impersonation Spam Sources (unused space hijack) Black-holing Traffic Traffic Degradation Let’s think about whether the routing system should handle them….

Attack: Data Confidentiality & Integrity Where: Data & Control Plane A secure control plane could make it harder for an attacker to get on path, but data-plane adversaries can access traffic. Verdict: Use end-to-end encryption & MACs, rather than rely on routing protocol.

Attack: Traffic Analysis Where: Data & Control Plane Again, secure control plane makes attack more difficult, but providing real guarantees at the network layer is extremely difficult or even impossible (data worm-hole attack). Verdict: Use mix-nets or other end-to-end mechanisms if needed, as Internet routing cannot provide an guarantees.

Attack: Destination Impersonation Where: Data & Control Plane Problems with data-plane attacker (local or router) or DNS compromise means that even with secure control plane identity is not certain. Difficulty in having ISPs create and update address registry. Verdict: End-to-End certificates or other authentication are still needed, and obviate requirement for identity in control plane (still useful as an optimization though).

Attack: Spam Sources (unused hijack) Where: Control Plane Spam is really caused by incentives and identity problems within higher-level systems (e.g. ), which would exist even with secure routing. The real “cost” of this vulnerability is minimal. Verdict: While authenticated address ownership may be desirable, it is not a requirement for reliable communication.

Attack: Black-holing Traffic Where: Data & Control Plane The ability to completely prevent communication, particularly when another valid path exists, is the key threat to a routing protocol. Verdict: Yes, this is central to routing.

Attack: Traffic Degradation / DoS Where: Data Plane, remote hosts Paths can be rendered unusable for an application even if they are not completely unavailable according to the control plane. Verdict: Yes, a routing protocol should allow destinations to avoid such links.

Defense Taxonomy: Control Plane Attack S-BGP*WhisperACR Snoop/Modify traffic -- Impersonate destination -- Black-hole traffic -- Traffic Analysis -- Traffic Degradation/DoS NA Spam (unused hijack) Note: Whisper only detects attacks, and only at a limited number of ASes.

Defense Taxonomy: Data Plane Attack S-BGP* + SSL ListenACR + SSL Snoop/Modify traffic Impersonate destination Black-hole traffic - Traffic Analysis Traffic Degradation/DoS Spam (unused hijack) NA

What should routing security achieve? It’s very hard to get guarantees about the identity of the path of data-flow. Furthermore, why would we care? If applications already use e2e security to handle these risks. As a result, they care about path quality, not path identity.

Availability Centric Routing Goals: 1)Communication in the face of control plane, data plane, and link-DoS attacks. 2)Incentivized deployment and low barriers to adoption. 3)No requirements for globally coordinated adoption.

What is done end-to-end? Assume: 1)Confidentiality, integrity and destination identity are handled end-to-end, e.g. SSL/IPSec. 2) Path quality monitoring, to decide when to change paths.

Packet “Deflections” ISPs offer users alternate paths (deflections) in addition to the normal path advertised via BGP. ABC E D F A,B,C,D,F is normal BGP path for A -> F. To avoid D, A could request that C deflects packets to E, yielding path A,B,C,E,F

Availability Providers Most path diversity comes from the densely connected tier-1 ISPs. To simplify, what if just these ASes acted as “availability providers” (APs) to offer deflections?

ACR Overview: 1) Source attempts to set-up a secure channel using default path. 2) If set-up fails, it can request alternate paths from its AP, “probing” until it finds a working path. 3) Sources monitor path performance, requesting alternate paths if the current path is inadequate.

Threats Against ACR with APs Deployment “gaps” between AP and source or destination create attack opportunities. Large number of invalid paths from AP makes probing time unrealistic. Path performance attacks

Attacks Exploiting Deployment “Gaps” If a provider ISP is duped, it is possible that a stub AS will not be reachable by any path seen by the AP. D A U M If U does not offer deflections, a malicious AS M could fool U by announce D’s prefix, making it completely unreachable by the availability provider A.

Handling Deployment Gaps Dests: Business preferences help destinations (only fellow customers can attack). Sources: Paths to a limited number of core APs are easy to manage. Local filtering can provide significant benefit. As can identifying “expected links” based on well-known core topology.

Attacking Probing Efficiency With BGP, each malicious AS can introduce one bad path to its neighbors. Total # of paths limited by an AS’s # of neighbors, (more likely peers + providers). Claim: It is non-trivial to introduce many attractive paths quickly, especially without getting noticed.

More Efficient Probing Base: Shortest AS-Path Anomaly Detection: Most paths are stable, keep with what has worked (e.g. PGBGP). Destination Hints: Let destination sign & distribute hints about its upstream connectivity. Forces attacker paths to be longer.

Monitoring for Path Performance Attacks Data serves as probes to avoid preferential treatments of probe packets. Tricky Attack: Malicious AS makes path appear valid, then black-holes or degrades performance.

Path Performance Monitoring Solutions: 1) Have traffic that is robust to “hiccups” (e.g. non-realtime) 2) Duplicate traffic over paths that are likely to be “trust disjoint” 3) Use smart probing techniques to help avoid bad control plane paths.

Deployability No requirement for address registries, cryptographic hardware, ICANN-based PKI, or new routing software. Deflections can be implemented using IP-in-IP encapsulation and MPLS over IP, which already exists in routers today. Deflections also improve performance.

Dirty Laundry CIDR and sub-prefix hijacks (Answer: Use /24’s, which approximates flat routing) Datagram communication (Answer: either run over long-term secure channel, or have data be the identifier, ala DNSSEC)

ACR Summary Secure interdomain routing proposals are heavy-weight, but still insufficient. If end-points set up secure channels, the routing infrastructure must only provide multiple paths to guarantee availability. This approach has highly attractive properties for incentivized deployment