Re: Last Call: 'Key Change Strategies for TCP-MD5' to Informational RFC (draft-bellovin-keyroll2385)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 4-okt-2006, at 16:30, Steven M. Bellovin wrote:

Having read the draft, I do have similar concerns with "double-ended"
operations.  The draft mentions that the new key should only be used
when it's "at a point where it is reasonably certain that the other
side would have it installed, too".  This is not very exact language,
and I wonder how implementations would handle this.

My intention, actually, was that operators would do that.  "Attention
customers: we will be installing the 2007 BGP key on January 15. Please install the new key on your end before then." -- and then you actually do
your end on Jan 20 or thereabouts.

My perspective:

First of all, you NEVER want to bother a customer with requiring some kind of change from them. It sucks up unbelievable amounts of time and effort that are better spent elsewhere. Second, in this case, when the customer connection is reset or redirected by an attacker, that's the customer's problem, not the service provider's problem. So it's the customer who should decide if and when key changes need to happen, not the service provider. Third, you never want to say to a customer "we are going to make a change, as of this date you can do such-and-such". What you want to do is make the change on your end BEFORE informing the customer (in cases where both ends must change and one end can change without problems first, such as in this example). Then, the customer can make the change at their end immediately when they get your message. Last but not least, if you say you're going to remove the old situation so that they'll be down if they haven't made the change at their end at that point, you do this on the date that you announce, so that they can correlate any problems with the announcement. (All of this assumes that you have a reliable and secure way to communicate with the right people in the customer organization by the way, which isn't always the case.)

As a customer, I would want to be the one that sees the change happen when I'm logged in to the router, so I'd probably say to the service provider that I want to change keys and please let an engineer call me when she or he is ready to make the change so I can monitor from my side. But I'd probably install the new key beforehand so that if they don't call me and make the change anyway, the session stays up.

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]