North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: md5 for bgp tcp sessions

  • From: Richard A Steenbergen
  • Date: Thu Jun 23 13:05:22 2005

On Thu, Jun 23, 2005 at 05:57:05AM -0400, Todd Underwood wrote:
> 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 TTL hack itself (this is the one where your neighbor sets their 
outbound TTL to 255 and then you can drop the packet if it has a TTL less 
than 254, in case anyone wasn't paying attention) can be implemented on 
the data plane in the receive/loopback hardware based filters before any 
TCP processing happens or the packet ever gets near the management cpu, 
since it is an IP-specific check. The only thing that the TTL hack 
guarantees is that the packet hasn't traveled over any routed network to 
get to you, so for example you could still get hit by directly connected 
networks (across a public exchange with malicious or compromised 
participants, for example). This is different from the issue of whether 
the sequence number is checked before the MD5 signature.

Remember the entire point of this attack was that some bright person 
"realized" that with most people having a default TCP window size of 16384 
(btw I'm told that this isn't necessarily the case, and that at least some 
vendors are lowering their socket buffers on the BGP specific sockets for 
other unrelated reasons) or 2^14 you only need to try 2^18 combinations 
per ephemeral port and bgp port pair instead of 2^32, times the number of 
ephemeral ports you must test, times 2 to handle BGP collision detection 
which may set the session up in either direction. You still have to throw 
a couple billion packets at the victim and hope for a match, and only 
after you get this match do you need to proceed to the next step of 
validation on the one packet that managed to get through. If you are doing 
MD5 validation on every packet that comes in before you check the other 
criteria like sequence number, you are opening yourself up to a very easy 
DoS by anyone who wants to throw junk MD5 signed packets at you.

> 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.  

This wasn't the first or last time the vendors have told us we must 
upgrade immediately to some buggy new code because of some secret reason 
they can't disclose without killing us afterwards, only to find out it was 
a dud issue we wouldn't have cared about if we had been given technical 
details beforehand. While I suppose this is slightly better than them 
putting out a press release 24 hours after the discovery with everything 
but some example exploit code that compiles on linux, I think the point 
that we're all trying to make is that we'd like the vendors to find the 
happy middle ground between stupidity and paranoia.

Richard A Steenbergen <[email protected]>
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)