key change for TCP-MD5

Mon Jun 19 17:05:19 UTC 2006

On 19-jun-2006, at 16:18, Steven M. Bellovin wrote:

>>> Comments welcome.

>> I wonder how long that policy will hold.  (-:

> I'm not certain what you mean by that, but since it sounds  
> insulting to
> someone I'll ignore it.

I see that my attempts at levity (this one by referring to the  
infamous S/N ratio or the NANOG list) fell on unreachable ports. (Oh  
no! I just did it again...)

>> 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
>> 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.

> There are lots of good solutions if you're willing to change or  
> introduce
> protocols.  That takes a lot longer, both procedurally and  
> technically.
> This scheme is simple and single-ended, and can be implemented without
> co-ordination.

I'm not sure if you're referring to implementation or operation. But  
that's not important: a "good" solution can just as easily be  
implemented unilaterally, that's what all the option stuff in BGP is  
for, allowing us to still run BGP4 13 years after its inception,  
surviving IP version number changes and more.

It can't be operationally be implemented without coordination, and  
that's exactly the problem. Your solution is to agree on a time when  
the key rollover takes place and then build in a safety margin and  
optionally, allow senders to return to a previous key if the change  
is unsuccessful.

The problem with this is that the risk that something goes wrong is  
way too big: if my implementation doesn't support returning to the  
original key, or doesn't do this fast enough, then very bad things  
happen as soon as I agree with another AS to change keys at a certain  
time, and the other side doesn't add the new key to the router in time.

I really don't see how saving a little "time to market" here makes  
sense, especially since we're not talking about the lid of the cookie  
jar but about the protocol that holds the internet together, and  
because the extra effort to do things right seems very modest.

> We should indeed try for a better solution.  Until then, I'm  
> suggesting
> this -- I'm aiming at Informational -- to tide us over.

One thing I don't think many IETFers get is that EVERY change, no  
matter how small, is a HUGE deal: you need to start a project, get  
people, write the software, do testing, testing, more testing, write  
documentation and then do some REAL testing, write some more  
documentation, train people, send out the software, fix at least some  
of the bugs that have been found by now... Compared to all the effort  
that goes in to touching the code period, implementing a little more  
stuff while you're at it is of little consequence. Especially if you  
compare it with having to go back later because the extra stuff needs  
to be implemented anyway. Doing it rightaway saves you another cycle  
for all the other stuff.

On top of this general observation, I also think you're  
underestimating the amount of work required to implement your draft.  
Obviously the RFC 2385 code needs to be changed, but don't forget  
that there must be a way to specify additional keys and the times  
they become active in the configuration. That's two things that need  
to be done anyway, doing a third one by adding options to the BGP  
protocol, doesn't seem like a show stopper to me.

> The need for some
> such solution was quite clear during Bonica's talk in San Jose.

Maybe. I haven't seen/heard the talk. But I can tell you one thing:  
operators won't be in a hurry to use the mechanism you suggest for  
two reasons: even though changing keys is easier this way, it's still  
not super simple (need to talk to the other side to find out if they  
support the mechanism and coordinate a password (some people have a  
hard time grokking GPG/PGP...) and a rollover time), and, more  
importantly: the change happens at some later point when you're not  
watching. That's NOT good. No feedback except failure isn't good either.

If you really need to change a key you can always call, agree on a  
new password and count down to three and hit the return key at the  
same time...

You may want to check and see how many people use GTSM/RFC3682  
(anyone?). It suffers from the same problem as RFC 2385 and (to a  
large degree) your proposal: there is nothing wrong with the  
mechanism per se, but it has to be enabled/configured out of band  
because there is no negotiation in BGP for using / not using the  
mechanism.