md5 for bgp tcp sessions

Thu Jun 23 04:14:12 UTC 2005

On Wed, Jun 22, 2005 at 10:04:09PM -0400, Todd Underwood wrote:
> 
> the md5 password hack to protect tcp sessions is rapidly falling out
> of favor for a number of reasons.  among them:
> 
> 1) it protects against a very limited "vulnerability".  for operating
> systems that stay up for reasonable periods of time, that generate
> sufficiently random ISNs and that check for in-windowness of syns and
> rsts, there is a very limited exposure.

Well, it isn't really as bad as all that (and I don't think I've ever been 
accused of being a BGP MD5 lover).

Yes, everyone who knows how TCP works knows that the "vulnerability" that 
was "discovered" is precisely how TCP was meant to work, and if you ever 
thought it worked otherwise you were really confused and/or misinformed. 
But out of all the hoopla, we've ended up widely deploying a fairly nifty 
hack that helps prevent this type of attack at the protocol level, across 
a wide variety of routers and systems. While it didn't actually stop any 
attacks in the wild (because there were never any to begin with), it never 
hurts to harden your protocol implementation if there is no tradeoff.

> 2) the cure is worse than the disease:
> 	
> 	a) many (all?) implementations of md5 protection of tcp expose
> new, easy-to-exploit vulnerabilities in host OSes.  md5 verification
> is slow and done on a main processor of most routers.  md5
> verification typically takes places *before* the sequence number,
> ports, and ip are checked to see whether they apply to a valid
> session.  as a result, you've exposed a trivial processor DOS to your
> box.  

Well, I think they've finally fixed this one by now, at least everyone 
that I'm aware of has done so. Immediately following the whining to start 
deploying MD5 is was certainly the case that many implementations did 
stupid stuff like process MD5 before running other validity checks like 
sequence numbers which are far less computationally intensive, and there 
were a few MSS bugs that popped up, but they should have all been worked 
out by now. I don't think that anyone running modern code is suffering any 
more attack potential because of this.

> 	b) coordination problems cause downtime.  password
> coordination problems are reported to be a major cause of downtime
> among peers that i interact with.  this downtime is costly and is much
> greater than the downtime caused by the (theoretical and not actively
> exploited) tcp "vulnerability"
> 
> i would encourage everyone to seriously rethink the routine use of MD5
> passwords to protect BGP tcp sessions.

This one is really the heart of the problem, which has far more to do with 
those silly humans behind the keyboards than it does with any protocols. 
If you were working with intelligent, responsive, organized folks, 
deploying MD5 probably wasn't difficult to do at all. If however you were 
working with the clueless, paranoid, unresponsive, disorganized folks that 
most of us were dealing with, you probably did a lot of swearing that 
week.

Before this incident, it was much more difficult to explain, pick, share, 
and configure the MD5 keys with all of your idiot peers, so just the fire 
drill effect probably did help organize people a little bit. As long as 
you don't get carried away with it, deploying MD5 everywhere is probably 
not going to hurt anything, and has become the new path of least 
resistance.

Just please realize that this is a trivial layer of security, an extra 
little bit of insurance to make it harder to alter the packets in flight 
or screw with the delivery protocol, and as such the key is not a state 
secret. I am going to seriously hurt the next person who wants to exchange 
phone numbers via pgp encrypted email so that we can have a conference 
call to set up a meeting where we can whisper MD5 keys to each other in 
pig latin while standing under the god damned cone of silence and then 
shoot the engineers who configured it on the router afterwards.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)