Routing threats and key management
This presentation is the property of its rightful owner.
Sponsored Links
1 / 13

Routing Threats and Key Management PowerPoint PPT Presentation


  • 48 Views
  • Uploaded on
  • Presentation posted in: General

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

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.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


Routing threats and key management

Routing Threats and Key Management

Sandra Murphy

[email protected]


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


  • Login