nanog mailing list archives
Re: key change for TCP-MD5
From: Richard A Steenbergen <ras () e-gerbil net>
Date: Fri, 23 Jun 2006 17:01:00 -0400
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 <ras () e-gerbil net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Current thread:
- RE: key change for TCP-MD5, (continued)
- RE: key change for TCP-MD5 Randy Bush (Jun 21)
- Re: key change for TCP-MD5 Iljitsch van Beijnum (Jun 21)
- Re: key change for TCP-MD5 Niels Bakker (Jun 25)
- Re: key change for TCP-MD5 Iljitsch van Beijnum (Jun 26)
- RE: key change for TCP-MD5 Bora Akyol (Jun 21)
- RE: key change for TCP-MD5 Randy Bush (Jun 21)
- Re: key change for TCP-MD5 Richard A Steenbergen (Jun 21)
- backbone threats [Re: key change for TCP-MD5] Pekka Savola (Jun 26)
- RE: key change for TCP-MD5 Randy Bush (Jun 21)
- Re: key change for TCP-MD5 Todd Underwood (Jun 23)
- Re: key change for TCP-MD5 Richard A Steenbergen (Jun 23)
- Re: key change for TCP-MD5 Richard A Steenbergen (Jun 23)
- Re: key change for TCP-MD5 Iljitsch van Beijnum (Jun 23)
- Re: key change for TCP-MD5 Patrick W. Gilmore (Jun 23)
- Re: key change for TCP-MD5 Iljitsch van Beijnum (Jun 24)
- Re: key change for TCP-MD5 Valdis . Kletnieks (Jun 23)
- Re: key change for TCP-MD5 Roland Dobbins (Jun 23)