North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: md5 for bgp tcp sessions
- From: Richard A Steenbergen
- Date: Thu Jun 23 00:15:29 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
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
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
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 <firstname.lastname@example.org> http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)