nanog mailing list archives

Re: md5 for bgp tcp sessions


From: Todd Underwood <todd () renesys com>
Date: Thu, 23 Jun 2005 05:57:05 -0400


ras, all,

On Thu, Jun 23, 2005 at 12:14:12AM -0400, Richard A Steenbergen wrote:
On Wed, Jun 22, 2005 at 10:04:09PM -0400, Todd Underwood wrote:

    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.

my understanding is that md5 is still checked before the ttl-hack
check takes place on cisco (and perhaps most router platforms).  new
attack vector for less security than you had before.  oh well.  ras:
can you confirm that it is possible to implement ttl-hack and have it
check *before* md5 signature checks?

the chaos (and crappy quality of the implementations) during the panic
demonstrates two other things:  rolling out magic code because your
vendor tells you to is a bad idea;  slapping together a hack on top of 
a well-designed protocol without careful thought and testing is a
terrible idea.  

t.

-- 
_____________________________________________________________________
todd underwood
director of operations & security
renesys - interdomain intelligence
todd () renesys com   www.renesys.com


Current thread: