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
