1 / 13

Routing Threats and Key Management

Explore the history of routing outages, including the reasons behind them and their consequences. Learn about common threats and vulnerabilities in routing systems, and the potential solutions to prevent these incidents.

alvinmorris
Download Presentation

Routing Threats and Key Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related