On Thu, 22 Jun 2006 13:18:35 -0400, Ron Bonica <rbonica@juniper.net> wrote:
Steve,
In Section 1 of your draft, you say:
"The proper solution involves some sort of key management protocol. Apart from the complexity of such things, RFC 2385 was not written with key changes in mind. In particular, there is no KeyID field in the option, which means that even a key management protocol would run into the same problem.
Fortunately, a heuristic permits key change despite this protocol deficiency."
Why not correct the protocol deficiency by introducing a new option that includes a KeyID? Wouldn't that approach provide a more comprehensive solution to the problem?
That's a much better long-term strategy, though the exact mechanism still has to be defined. But it's literally years before that will be usable, especially because both ends of a connection need to be upgraded before it delivers any benefits. That is especially problematic for the interISP case. We both agree that key change is (a) necessary, and (b) very difficult with 2385. The longer-term issue is where "there" his, and that's what your draft addresses; my draft is about how to get from "here" to "there". --Steven M. Bellovin, http://www.cs.columbia.edu/~smb