Brian, the middle box could never "assume that ESP always means ESP-NULL" because the down-level nodes (as well as any up-level node talking to them) will use ESP for encrypted traffic as well.
Moreover, this is a soft sort of begging the question because it is assuming that WESP will be widely adopted in order to argue for it to be even more widely used. I remain unconvinced of that assumption, and I am definitely unconvinced that there is zero cost to happily assuming the up-level nodes can always and freely use WESP for encrypted traffic. All this does nothing to encourage those down-level nodes to get with the WESP program, and I think that is your real challenge. Again, I'm not saying that there is no conceivable value to encrypted WESP, just that if this is your concern then encrypted WESP is not the answer. Finally, if WESP really is going to be that widely used, then we really need to scrap it and talk about whether there is warrant to do a real ESPv4 instead of backdooring it like this. WESP is not a suitable ESPv4. And if WESP is going to be that quickly and widely adopted then there should be no trouble getting consensus to do ESPv4. ;) Scott Moonen (smoo...@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Brian Swander <bria...@microsoft.com> To: Stephen Kent <k...@bbn.com> Cc: "ipsec@ietf.org" <ipsec@ietf.org>, Russ Housley <hous...@vigilsec.com>, gabriel montenegro <g_e_montene...@yahoo.com> Date: 01/06/2010 12:42 PM Subject: Re: [IPsec] Traffic visibility - consensus call The uplevel machines can't use ESP to send the encrypted traffic in this scenario. Remember, that we need to look at the holistic scenario of how to deploy this in an environment where we have legacy machines that don't do WESP. And we need to satisfy the goal of deterministic intermediary visibility. Hence, the best method I see is what I describe below. The non-WESP machines MUST do ESP-NULL to allow visibility. That means uplevel machines cannot use ESP to send encrypted, since otherwise intermediaries would see both ESP-NULL, and ESP, and be forced back to heuristics. Intermediaries would be configured (in this scenario) to assume that ESP always means ESP-NULL. bs -----Original Message----- From: Stephen Kent [mailto:k...@bbn.com] Sent: Wednesday, January 06, 2010 7:07 AM To: Brian Swander Cc: gabriel montenegro; Russ Housley; ipsec@ietf.org Subject: Re: [IPsec] Traffic visibility - consensus call At 10:10 PM +0000 1/5/10, Brian Swander wrote: >I'll resend my message from earlier today that gives a concrete >scenario for why the WESP encryption bit is in charter. > >To satisfy the existing charter item, we need a deployable solution, >which entails working with legacy systems that don't support this >functionality yet. > >Here's an explicit scenario that requires the encrypted bit for >WESP, fully within the current charter of enabling ESP-NULL >inspection. > >Transport policies for within an organization that want to enable >intermediary inspection of ESP-NULL non-heurisitically. >Organization has a mix of version of systems. > >Sample policy: >When talking to/from non-WESP capable machines: must do ESP-NULL only >When both peers are WESP capable: do WESP/ESP-NULL most places. >However, where policy requires encryption, do WESP/ESP. This is where I have a problem with the analysis. If the policy were that WESP-capable hosts did ESP when then needed to send encrypted traffic, the flag inn question would not be needed, right? I don't think we can justify the inclusion of this flag based on the scenario you described above, because that scenario adopts a particular local policy that it not required. Steve _______________________________________________ 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
