Transcript TCP SPOOF ROUTING INFO ATTACKS

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
• Router overload -- random advertisements; cyclic sequence
numbers caused protocol churn
– 1986 - Crossed Nets
• Two nets connected – multiple routers with same ID
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 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 …
• 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)
• 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
• 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
• 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
• 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
MIS-CONSTRUCTION of PATH
MIS-ORIGINATION e.g., AS_PATH POISONING
ROUTING
INFO
ATTACKS:
AS 123
Net
2.0.0.0
BGP
AS_PATH
=123
NLRI= 7/8
AS 345
BGP
AS_PATH
=345,789,123
NLRI= 7/8
AS 567
BGP
TCP
TCP
TCP
IP
IP
IP
TCP SPOOF
BGP PORT FLOODING
TRANSPORT
TCP SYN FLOODING
ATTACKS: IP FLOODING
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?
• 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
• 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