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.