[90899] in North American Network Operators' Group
RE: key change for TCP-MD5
daemon@ATHENA.MIT.EDU (Bora Akyol)
Tue Jun 20 15:13:11 2006
Date: Tue, 20 Jun 2006 12:12:31 -0700
From: "Bora Akyol" <bora@broadcom.com>
To: "Iljitsch van Beijnum" <iljitsch@muada.com>,
"Randy Bush" <randy@psg.com>
Cc: "NANOG list" <nanog@merit.edu>
Errors-To: owner-nanog@merit.edu
The draft allows you to have a set of keys in your keychain and=20
the implementation tries all of them before declaring the segment
as invalid.
No time synchronization required. No BGP message required.
The added cost for CPU-bound systems is that they have to try=20
(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.
Regards
Bora
> -----Original Message-----
> From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On=20
> 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
>=20
>=20
> On 19-jun-2006, at 19:10, Randy Bush wrote:
>=20
> >>> try reading more carefully
>=20
> >> Didn't help...
>=20
> > how sad, as the whole document is about how to usefully be able to=20
> > introduce and roll to new keys without agreeing on a narrow time.
>=20
> Well, as you can tell from my message just now, I don't think=20
> going from agreeing on a narrow time to agreeing on a wider=20
> time is worth the trouble, especially since by adding a BGP=20
> message it would be possible to roll over if and as soon as=20
> both sides are ready, removing the "wait for some time and=20
> then see whether the other end really installed the new key"=20
> part from the proceedings.
>=20
>=20
