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

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