Routing Threats and Key Management

1. Routing Threats and Key Management Sandra Murphy sandy@sparta.com

2. History of Routing Outages • ARPANET/MILNET outages • 1971 - Black Hole • Harvard IMP said it was 0 hops to everywhere • 1973 – Masquerade • Aberdeen IMP said it was UCLA • 1973/80/88 - Routing Storms • Router overload -- random advertisements; cyclic sequence numbers caused protocol churn • 1986 - Crossed Nets • Two nets connected – multiple routers with same ID

3. History of Routing Outages • Commercial Internet: systemic problems • RFC 1918 bogon announcements • DoS attacks on BGP in early 2000’s • Announcements of unallocated space (spammers)

4. History of Routing Outages Commercial Internet -: specific network outages • Apr 1997 – AS 7007 announced direct connections to all the Internet • Deaggregation; mis-origination; overload • Apr 1998 – AS 8584 mis-announced 100K routes • Dec 1999 –AT&T’s server network announced by another ISP – misdirecting their traffic (made the Wall Street Journal) • May 2000 – Sprint addresses announced by another ISP • Apr 2001 – AS 15412 mis-announced 5K routes • Dec 24, 2004 – thousands of networks misdirected to Turkey (AS9121 – TTNET) • Feb 10, 2005: Estonian ISP announced a part of Merit address space • Sep 9, 2005 – AT&T, XO and Bell South (12/8, 64/8, 65/8) misdirected to Bolivia [the next day, Germany – prompting AT&T to deaggregate] • Jan 22, 2006 – Many networks, including PANIX and Walrus Internet, misdirected to NY ISP (Con Edison (AS27506)) • Feb 26, 2006 - Sprint and Verio briefly passed along TTNET (AS9121 again?) announcements that it was the origin AS for 4/8, 8/8, and 12/8 • Feb 24, 2008 –Pakistan Telecom announces /24 from YouTube

5. So Maybe It’s Not So Bad … • Response is now under an hour • but this is no one’s idea of reliable networking • damage to applications and to the Internet itself in terms of churn and routing table size • These are human mistakes, not attacks • but anything possible through human error can be done by human intent • deliberate attacks would be repeatable at will • There are bigger outages due to hardware and software failures • but those aren’t exploitable deterministically and remotely

6. Threat Sources (Attackers) • Outsiders • Not a router’s legitimate peer in the protocol • Could be anywhere in protocol scope (Mars?) • Authentication prevents this • Insider • Legitimate peer in the protocol • Has context and access to do considerable damage • Authentication doesn’t help here; need authorization • Insider as outsider • A legitimate participant masquerading as another • Has context and access and can avoid audit/trouble-shooting • Separate category because authentication prevents this

7. Threat Consequences • People tend to concentrate on compromises to the data traffic: • Starvation • Eavesdrop • Cut • Delay • Looping • But don’t forget the compromises to the routing infrastructure itself (fixing at end hosts isn’t enough): • Blackhole • Network Congestion • Partition • Churn • Instability • Overcontrol • Clog

8. Basic Routing Functions • Transport channel • Can be link, IP, UDP, TCP, … • Control layer • Neighbor Discovery and Control • E.g., OSPF Hellos, BGP TCP Open/Listen • Database Control • E.g., explicit OSPF database synchronization • Data layer – routing information exchange • OSPF LSA, BGP Update, ISIS LSP, etc.

9. Basic Function Vulnerabilities • Underlying transport • Jamming, ARP spoofing, IP flooding, TCP port flooding, TCP Syn Flooding, TCP RST, ... • Neighbor Discovery and Control • Break a link between neighbors • Masquerade as a neighbor • Database Exchange • Interfere with exchange, replay, etc. • Routing Information • Inject bogus data, remove valid data, rapidly change data, etc.

10. BGP Vulnerabilities MIS-CONSTRUCTION of PATH e.g., AS_PATH POISONING ROUTING INFO ATTACKS: MIS-ORIGINATION AS 123 AS 345 AS 567 AS_PATH =123 NLRI= 7/8 AS_PATH =345,789,123 NLRI= 7/8 Net 2.0.0.0 BGP BGP BGP TCP TCP TCP IP IP IP TCP SPOOF BGP PORT FLOODING TRANSPORT ATTACKS: TCP SYN FLOODING IP FLOODING

11. Solutions? • Authenticate the neighbors to prevent masquerade • Already built into some protocols • OSPF/ISIS/RIP/RSVP/TCP MD5 use a keyed MD5 based on a (group) shared key • Difficulties • Hard to scale to large numbers of neighbors • Varying and limited support for agility (key rollover, algorithm or parameter change, etc.) • Must know the neighbors (manet doesn’t)

12. Improve the Crypto? • Use more sophisticated, agile mechanisms? • Already underway in many cases (OSPF, ISIS, TCP-AO) • Automate the key management? • Advantage • Makes key rollover and algorithm/parameter change easier • Scales better to large numbers of neighbors • Don’t have to pre-communicate with neighbor

13. Requirements for Automated Key Management • Can’t be too demanding on the router performance • This is crypto for routing – so key management can’t assume routing to be working • Neighbor discovery depends on crypto • When the link is flakey, key management can’t add to problem • Multiple rapid attempts at key establishment can’t exhaust some resource • Routers have limited resources • Key management has to be easy to compute • Router operators have limited time and patience • Has to be easy to configure