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. 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. Regards Bora
-----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.
On 20-jun-2006, at 21:12, 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.
No time synchronization required. No BGP message required.
What if we agree to change the key on our BGP session, I add the new key on my side and start sending packets using the new key, while you don't have the new key in your configuration yet?
On 20-jun-2006, at 21:23, Randy Bush wrote:
What if we agree to change the key on our BGP session, I add the new key on my side and start sending packets using the new key, while you don't have the new key in your configuration yet?
again: try reading the draft
I've read the draft and it "solves" this problem with timing. That's insufficient because it requires that both sides do the right thing at the right time without any way to verify whether the other side is ready. What if one side didn't make the change, or entered the wrong key? I think I've sufficiently explained myself now, I'm not going to do it again.
On 6/20/2006 at 12:33 PM, Iljitsch van Beijnum <iljitsch@muada.com> wrote:
On 20-jun-2006, at 21:23, Randy Bush wrote:
What if we agree to change the key on our BGP session, I add the new key on my side and start sending packets using the new key, while you don't have the new key in your configuration yet?
again: try reading the draft
I've read the draft and it "solves" this problem with timing. That's insufficient because it requires that both sides do the right thing at the right time without any way to verify whether the other side is ready. What if one side didn't make the change, or entered the wrong key?
Uh, isn't what this, "In particular, if a key change has just been attempted but such segments are not acknowledged, it is reasonable to fall back to the previous key and issue an alert of some sort." Is for? Automated fallback if a new key doesn't work? -- Crist J. Clark crist.clark@globalstar.com Globalstar Communications (408) 933-4387 B¼information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact postmaster@globalstar.com
On Tue, 20 Jun 2006 21:16:05 +0200, Iljitsch van Beijnum said:
What if we agree to change the key on our BGP session, I add the new key on my side and start sending packets using the new key, while you don't have the new key in your configuration yet?
How is that *any* different than you sending an e-mail saying "Here's the new key we'll put into production at 3:17:04.97 GMT, hope you're NTP-synced" and not waiting for an ACK from the other end before proceeding? I'd encourage my competitors to design their procedures that way, but it only works for competitors that you aren't either peering or directly transiting with. Otherwise, you're merely handing them a loaded gun to point at your feet...
participants (5)
-
Bora Akyol -
Crist Clark -
Iljitsch van Beijnum -
Randy Bush -
Valdis.Kletnieks＠vt.edu