Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

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

Re: key change for TCP-MD5

  • From: Jared Mauch
  • Date: Mon Jun 19 10:01:48 2006

On Mon, Jun 19, 2006 at 03:40:50PM +0200, Iljitsch van Beijnum wrote:
> 
> On 19-jun-2006, at 14:32, Steven M. Bellovin wrote:
> 
> >I just submitted an I-D on TCP-MD5 key change.  Until it shows up  
> >in the
> >official repository, see
> >http://www.cs.columbia.edu/~smb/papers/draft-bellovin- 
> >keyroll2385-00.txt
> >Here's the abstract:
> 
> >                The TCP-MD5 option is most commonly used to secure
> >                BGP sessions between routers.  However, changing
> >                the long-term key is difficult, since the change
> >                needs to be synchronized between different
> >                organizations.
> >                We describe single-ended strategies that will permit
> >                (mostly) unsynchronized key changes.
> 
> >Comments welcome.
> 
> I wonder how long that policy will hold.  (-:
> 
> Ok:
> 
> First of all, I applaud this effort.
> 
> There doesn't really seem to be a way to introduce a new key other  
> than to just to agree on a time. I'm not sure this is good enough.

	I think there is a challenge in making sure the clocks are
synced.

> Wouldn't it be better to exchange some kind of "time to change keys"  
> message? This could simply be a new type of BGP message that hold a  

	I think there is a challenge in getting the kernel to change
keys after getting an underlying message, and the effect this has
on your config.  Why would you trust their message?  Preconfigured
keys seem to be the best way.  Allowing the kernel to check against
a few different keys, or knowing when to 'switch' seems to be the
best method IMHO.  Ideally it'd use a set of keys in all cases,
including the overlap time period +/- a few seconds to avoid dropping
the TCP session.

> key ID. Obviously the capability to send and receive these messages  
> must be negotiated when the session is created, but still, I think  
> the extra complexity is worth it because it allows for much more  
> robust operation.

	sure, i agree as well.

	- jared

-- 
Jared Mauch  | pgp key available via finger from jared@puck.nether.net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.




Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.