North American Network Operators Group

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

RE: key change for TCP-MD5

  • From: Barry Greene (bgreene)
  • Date: Sat Jun 24 06:00:23 2006
  • Authentication-results:; [email protected]; dkim=pass (sig from verified; );
  • Dkim-signature: a=rsa-sha1; q=dns; l=2964; t=1151142718; x=1152006718;c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;; [email protected]; z=From:=22Barry=20Greene=20\(bgreene\)=22=20<[email protected]>|Subject:RE=3A=20key=20change=20for=20TCP-MD5;; b=pmZ+Xb7mCnyNR+iOnmaawl1XTzYdMbK58irUqQMmbfV3+bq872plCDNnZTNOre+2HAQuCBUyAtgbe54Ocr+YU40CdYjyHkuMBw7oJbAv+jmZAbCp+SWEoAgfqrybROc7;

Walk through the code with the current MD5 spec. You need to terminate
the TCP session, check the MD5, then do the next checks. That is why
we're doing TTL check for GTSM and other classifying/queuing before the
TCP session termination. In the big equipment that ranges from
specialized ASIC checks, to raw queue classifiers, to ACLs .... All
before the packet gets punted out of the forwarding chip to the Route
Processor. In other equipment you do the check on the Line Card's CPU
after the punt - compartmentizing the impact of an attack. There is even
code in the 'coding queue' to do the check on CPU routers before you
terminate (still get the CPU clock cycle hit for dropping the packet). 

Granted, you need to put this in context of how vendors should be
building security into their devices - layered - with a combination of
classification (i.e. ACLs), queuing (containing the impact), and systems

So go back to the instigating presentation:

Also check on one vendor's roadmap:

So lets keep focused on the right issue - can you TTL filter before the
TCP session terminates vs worrying over the order of the multitude of
checks which take up processing the TCP packet.


> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of Todd Underwood
> Sent: Friday, June 23, 2006 1:43 PM
> To: [email protected]
> Subject: Re: key change for TCP-MD5
> 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". 
> t.
> --
> _____________________________________________________________________
> todd underwood                                 +1 603 643 9300 x101
> renesys corporation                            chief of 
> operations & security 
> [email protected]