nanog mailing list archives
TCP/BGP vulnerability - easier than you think
From: "David Luyer" <david () luyer net>
Date: Wed, 21 Apr 2004 13:09:31 +1000
You missed the "(assuming the attacker can accurately guess both ports)" part. This is BY NO MEANS a given. In fact, it is pretty much guaranteed to not be a given on any router which has not recently been rebooted. (Or at least that the attacker doesn't know has been recently rebooted. :)
A significant number of BGP sessions will be with a source port of 11000, 11001 or 11002; BGP sessions are generally quite stable and Cisco routers start the source port at 11000. So attackers could cause enough disruption just targeting these three source ports. The other thing the attacker has to guess is which router established the BGP session. As to IPs which sessions exist on, they can guess from traceroute each inter-provider hop. Answering another poster's concern about DoS risk... TCP MD5 is not a significant DoS risk as you only MD5 once the source, destination, sequence, etc are valid - ie. you only MD5 a packet which would already have broken your BGP session! [*] Worse than breaking the session, I'm told by people who have tested in labs that they could typically break BGP sessions in under half an hour, which then caused flapping and dampening of the routes if the attack was repeated. So the risk is not just the occasional BGP session flap, it's a frequent enough flap that your routes can be dampened. So, you're best to implement TCP MD5 on your BGP sessions. With an up to date IOS, if you both implement the password within about a second, the BGP session doesn't even flap to implement the password. Older IOS (12.1) resets the BGP session as a password is set. Other vendors vary. David. [*] in any reasonable implementation. it is possible some old implementation does this wrong, though.
Current thread:
- Re: TCP vulnerability, (continued)
- Re: TCP vulnerability Aviva Garrett (Apr 20)
- Re: TCP vulnerability Joe Abley (Apr 20)
- Re: TCP vulnerability Randy Bush (Apr 20)
- Re: TCP vulnerability Joe Abley (Apr 20)
- Re: TCP vulnerability Stephen Stuart (Apr 20)
- Re: TCP vulnerability Tom (UnitedLayer) (Apr 20)
- Re: TCP vulnerability Joe Abley (Apr 20)
- Re: TCP vulnerability Aviva Garrett (Apr 20)
- Massive stupidity (Was: Re: TCP vulnerability) Richard A Steenbergen (Apr 20)
- Re: Massive stupidity (Was: Re: TCP vulnerability) Sean Donelan (Apr 20)
- Re: Massive stupidity (Was: Re: TCP vulnerability) Mike Tancsa (Apr 20)
- Re: Massive stupidity (Was: Re: TCP vulnerability) Patrick W . Gilmore (Apr 20)
- TCP/BGP vulnerability - easier than you think David Luyer (Apr 20)
- Re: TCP/BGP vulnerability - easier than you think Patrick W . Gilmore (Apr 20)
- Re: TCP/BGP vulnerability - easier than you think Rob Thomas (Apr 20)
- Re: TCP/BGP vulnerability - easier than you think Joe Abley (Apr 20)
- RE: TCP/BGP vulnerability - easier than you think David Luyer (Apr 20)
- Re: TCP/BGP vulnerability - easier than you think Adam Rothschild (Apr 21)
- Re: TCP/BGP vulnerability - easier than you think E.B. Dreger (Apr 21)
- Re: TCP/BGP vulnerability - easier than you think E.B. Dreger (Apr 22)
- Re: TCP/BGP vulnerability - easier than you think Iljitsch van Beijnum (Apr 21)
- Re: TCP/BGP vulnerability - easier than you think Daniel Roesen (Apr 21)
- Re: TCP/BGP vulnerability - easier than you think Iljitsch van Beijnum (Apr 21)