routing threats and key management
Download
Skip this Video
Download Presentation
Routing Threats and Key Management

Loading in 2 Seconds...

play fullscreen
1 / 13

Routing Threats and Key Management - PowerPoint PPT Presentation


  • 86 Views
  • Uploaded on

Routing Threats and Key Management. Sandra Murphy [email protected] 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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Routing Threats and Key Management' - charissa-britt


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
history of routing outages
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
history of routing outages1
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)
history of routing outages2
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
so maybe it s not so bad
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
threat sources attackers
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
threat consequences
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
basic routing functions
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.
basic function vulnerabilities
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.
bgp vulnerabilities
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

solutions
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)
improve the crypto
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
requirements for automated key management
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
ad