nanog mailing list archives
RE: key change for TCP-MD5
From: Ross Callon <rcallon () juniper net>
Date: Tue, 20 Jun 2006 17:06:27 -0400
At 12:12 PM 6/20/2006 -0700, Bora Akyol wrote:
The draft allows you to have a set of keys in your keychain and the implementation tries all of them before declaring the segment as invalid.
DoS against routers is of course a major concern. Using encryption has the potential of making DoS worse, in the sense that the amount of processing that a bogus packet can cause is increased by the amount of processing needed to check the authentication. If the router needs to check multiple keys in the keychain before declaring the segment as invalid, then this multiplies the effect of the DOS by the number of keys that need to be checked.
No time synchronization required. No BGP message required. The added cost for CPU-bound systems is that they have to try (potentially) multiple keys before getting the **right** key but in real life this can be easily mitigated by having a rating system on the key based on the frequency of success.
This mitigates the effect of authenticating valid packets. However, this does not appear to help at all in terms of minimizing the DOS effect of an intentional DoS attack that uses authenticated packets (with the processing time required to check the keys the intended damage of the attack). Ross
> -----Original Message----- > From: owner-nanog () merit edu [mailto:owner-nanog () merit edu] On > Behalf Of Iljitsch van Beijnum > Sent: Monday, June 19, 2006 10:22 AM > To: Randy Bush > Cc: NANOG list > Subject: Re: key change for TCP-MD5 > > > On 19-jun-2006, at 19:10, Randy Bush wrote: > > >>> try reading more carefully > > >> Didn't help... > > > how sad, as the whole document is about how to usefully be able to > > introduce and roll to new keys without agreeing on a narrow time. > > Well, as you can tell from my message just now, I don't think > going from agreeing on a narrow time to agreeing on a wider > time is worth the trouble, especially since by adding a BGP > message it would be possible to roll over if and as soon as > both sides are ready, removing the "wait for some time and > then see whether the other end really installed the new key" > part from the proceedings. > >
Current thread:
- Re: key change for TCP-MD5, (continued)
- Message not available
- Re: key change for TCP-MD5 Steven M. Bellovin (Jun 22)
- Re: key change for TCP-MD5 Iljitsch van Beijnum (Jun 22)
- RE: key change for TCP-MD5 David Schwartz (Jun 22)
- Message not available
- Re: key change for TCP-MD5 Iljitsch van Beijnum (Jun 20)
- Re: key change for TCP-MD5 Randy Bush (Jun 20)
- Re: key change for TCP-MD5 Iljitsch van Beijnum (Jun 20)
- Re: key change for TCP-MD5 Crist Clark (Jun 20)
- Re: key change for TCP-MD5 Richard A Steenbergen (Jun 20)
- Re: key change for TCP-MD5 Warren Kumari (Jun 20)
- Re: key change for TCP-MD5 Randy Bush (Jun 20)
- Re: key change for TCP-MD5 Ross Callon (Jun 21)
- Re: key change for TCP-MD5 David Barak (Jun 21)
- Re: key change for TCP-MD5 Jared Mauch (Jun 21)
- Re: key change for TCP-MD5 Randy Bush (Jun 21)