Routing Threats and Key Management

1
Routing Threats and Key Management

• Sandra Murphy
• sandy_at_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 2000s
• 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 ATTs 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 ATT, XO and Bell South (12/8,
  64/8, 65/8) misdirected to Bolivia the next day,
  Germany prompting ATT 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 Its Not So Bad

• Response is now under an hour
• but this is no ones 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 arent exploitable deterministically
  and remotely

6
Threat Sources (Attackers)

• Outsiders
• Not a routers 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 doesnt 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 dont forget the compromises to the routing
  infrastructure itself (fixing at end hosts isnt
  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 doesnt)

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
• Dont have to pre-communicate with neighbor

13
Requirements for Automated Key Management

• Cant be too demanding on the router performance
• This is crypto for routing so key management
  cant assume routing to be working
• Neighbor discovery depends on crypto
• When the link is flakey, key management cant add
  to problem
• Multiple rapid attempts at key establishment
  cant 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