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.