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@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)