> I don't know; it depends on what you're trying > to accomplish. Is there a reason that you must > choose one? I agree that dynamic addresses makes > manual keying problematic, but I'm not sure that > it follows that you need to pick one keying > scheme. Even with IKE, there's room for > interoperability issues (some might say far > too much room, but I digress).
I think we can agree on wanting to change <keyword> IKE to <keyword> IKEv2 as soon as that is possible. > My personal feeling is that the ng working > group has the consensus about right. We need > a base level set of mechanisms for protecting > IP packets. Since this is normally kernel > level work, having a strong statement here > is useful. And while I think there's pretty good > consensus that IPsec (eg, not IKE) is a > a stable and mature, there's equally good > consensus that IKE is not. Given KINK and > JFK/IKEv2 -- not to mention how widespread > transport mode keying really gets deployed -- > I'm not sure that I'd want to choose any one > at this point. I personally think that the > Kerberos based keying is well suited to > high fan out kinds of applications like > telephony, but I wouldn't claim that it is > the only way (or The Way) to approach the > problem of keying. Yes... this is not a bad approach. However, I still feel that it is sort of an underspecification. For instance, if we say that MUST ESP and leave key management in the air, then distribute 100,000,000 devices with no key management, 100,000,000 devices with IKE, 100,000,000 devices with IKEv2, 100,000,000 devices with KINK, and 100,000,000 devices with a weird app layer keying scheme that isn't documented anywhere, we aren't going to get interoperability! We couldn't make a server for all of these devices to connect to, and they certainly couldn't contact each other. I do understand your comments about kernels and so on, but I feel that I should perhaps explain more about the deployment aspects of handing out very large numbers of devices to grandmothers and truck drivers: they expect their device to work, and they aren't going to install isakmpd after finding out that their device doesn't work with their friend's device -- like you and I would. The device is a box that either works or doesn't work. Therefore, I'm not very happy with a half-way MUST particularly on a device where it may not make much sense to talk about kernels and application processes. (This is also in part why I'm worried about putting in extra features just in case, and why we wanted an all-or-nothing approach: either you really are using IPsec or TLS or you're not going to need to do some part of them.) Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
