Take a look at the policy sketch I sent our yesterday for how to roll this out in a mixed mode environment. That should clarify all your questions.
bs From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Scott C Moonen Sent: Wednesday, January 06, 2010 5:38 AM To: Venkatesh Sriram Cc: ipsec@ietf.org; ipsec-boun...@ietf.org Subject: Re: [IPsec] Traffic visibility - consensus call Venkatesh said: > I agree that WESP should not be clipped to only support ESP-NULL; it > should be able to carry encrypted packets as well. Without this the > middle boxes would never know whether the ESP packet thats passing is > encrypted or not. Earlier, Manav said: > Now, assume that we limit WESP for only ESP-NULL. If this is done, how > can a middle box deterministically know that the ESP packet that it > sees is an encrypted ESP packet or an ESP packet carrying ESP-NULL > payload. I don't follow the argument. Because 1) a middle box can't trust that an ESP packet is not ESP-NULL, therefore 2) we are going to allow WESP to carry encrypted ESP? That is either begging the question or else it is simply an invalid argument. Allowing platform A to use WESP to carry encrypted ESP has nothing to do with how likely it is that platform B will use WESP to carry its ESP-NULL packets. The middle box's problem is not solved by this. That needs to be addressed by other means (convince people to use WESP for ESP-NULL, or mandate it). I am not saying that there is no possible case to be made for WESP to carry encrypted packets, just that this argument does not support that. The hidden assumption here still seems to be that WESP either is or ought to become ESPv4. The reality is that with WESP as the alternative, ESP is not going away and ESP-NULL is probably also not going away. I personally cannot envision being able to justify implementing WESP even for ESP-NULL on my own platform. The middle boxes are dependent on end nodes if they want widespread WESP adoption. I must say that the middle-box folks have been doing a lot less sweet talking and receptive listening than I would have expected given this arrangement. :) That leads me to predict a very doubtful future for WESP even if we were to reach perfect consensus on its technical make-up. Scott Moonen (smoo...@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Venkatesh Sriram <vnktshsri...@gmail.com> To: "ipsec@ietf.org" <ipsec@ietf.org> Date: 01/05/2010 11:16 PM Subject: Re: [IPsec] Traffic visibility - consensus call ________________________________ > Would it help if WESP is renamed to something else? Since we're > discussing the fundamental principles of the protocol, i see no reason > why we cant change the name, if that helps. I think its the "Wrapped" > in the WESP thats causing most heart burn, lets change that to > something else .. something thats appeases everyone. I agree. How about VESP - "Visible ESP" ? Its phonetically the same as WESP. :) I agree that WESP should not be clipped to only support ESP-NULL; it should be able to carry encrypted packets as well. Without this the middle boxes would never know whether the ESP packet thats passing is encrypted or not. One way could be to deprecate the use of ESP-NULL in ESP, which would mean that if someone sees an ESP packet then it MUST be an encrypted packet. This is as i understand impossible, so the only option left is to let WESP also carry encrypted packets. Sriram _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
