North American Network Operators Group

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

Re: key change for TCP-MD5

  • From: Richard A Steenbergen
  • Date: Fri Jun 23 17:04:08 2006

On Fri, Jun 23, 2006 at 04:43:29PM -0400, Todd Underwood wrote:
> On Fri, Jun 23, 2006 at 11:49:33AM -0700, Barry Greene (bgreene) wrote:
> >
> > Yes Jared - our software does the TTL after the MD5, but the hardware
> > implementations does the check in hardware before the packet gets punted
> > to the receive path. That is exactly where you need to do the
> > classification to minimize DOS on a router - as close to the point where
> > the optical-electrical-airwaves convert to a IP packet as possible.
> i'm not that bright, so maybe i'm missing something, but i've heard
> this claim from cisco people before and never understood it.
> just to clarify:  you're saying that doing the (expensive) md5 check
> before the (almost free) ttl check makes sense because that
> *minimizes* the DOS vectors against a router?  can someone walk me
> through the logic here using small words?  i am obviously not able to
> follow this due to my distance from the
> "optical-electrical-airwaves". 

As I parsed Barry's post, he was saying that Cisco currently does the 
wrong thing today, but that some day when they actually support doing the 
check in hardware, that will be the right place to do it. (aka "duh" :P)

Obviously in a perfect world, you don't want to do the expensive MD5 check 
anywhere sooner than the last possible moment before you declare the data 
valid and add it to the socket buffer. I assume that the reason they can't 
do the check sooner in software is they lack a mechanism to tell the IP or 
even TCP input code "we want to discard these packets if they are less 
than TTL x". They probably can't make that decision until the packet gets 
validated by TCP and makes it all the way to BGP code.

But, they should still be able to do all of the TCP layer checks which 
don't require outside information, such as matching the segment to a 
proper TCB by ip/port/seq #, before doing the MD5 calculation. This makes 
DoS against MD5 where you don't know the full L4 port #'s and the seq # 
pretty impossible on its own, without needing to involve the TTL hack.

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