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 3-okt-2006, at 15:07, Fred Baker wrote:

So I think most operators would prefer to do a key rollover where the old key remains valid indefinitely and is removed manually rather than automatically after some time.

Somehow I can't imagine any real implementation NOT having this capability. So you set the delete timer for "next year"... You're in control of it.

That sounds good, especially if the default is "infinity".

I guess I'm making a suggestion, and if it is not reasonable then Steve and his working group have to decide that.

I don't think Steve has a working group for this.

What it sounds like you're arguing for is turning the procedure off, doing the change manually with the other operator on the phone, and taking the outage when if happens.

You mean like how things are done today?  (-:

Actually I proposed something else in my original message in this thread and also earlier in a message to Steve, on the NANOG list IIRC: have BGP speakers announce to the other side that they have a new key along with a hash over the key and when both sides have the same new key, do the rollover without delay. This means the rollover always happens when the new key is configured on the second end but only if the keys match.

In any situation where it's possible that both ends set up different keys, I believe it's important to have the resulting outage happen immediately rather than later. BGP already provides plenty of ways to shoot yourself in the foot, we should take care not to introduce new ones.

I can think of folks that change keys on a daily or weekly basis, or at least tell me they do, and are really in hope of a way to automate that in a reliable fashion.

Well, my expience is pretty much the opposite: in the commercial ISP world here in Europe, key changes are rare. Nevertheless, "reliable" is the operative word here.

If a key change is required this often, wouldn't it make more sense to protect the BGP session with IPsec? That is vastly superior to TCP- MD5 in all respects other than ease of initial setup.

_______________________________________________

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]