|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: key change for TCP-MD5
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 toI 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 introduceI'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 suggestingOne 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. 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.The need for some such solution was quite clear during Bonica's talk in San Jose. 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.
|