But that doesn't give us any path to actually do encryption (in environments with legacy systems) - hence the proposal is untenable.
I'd argue it therefore doesn't satisfy the charter item. The charter item is a deployable mechanism that lets intermediaries inspect ESP-NULL when present. This charter item surely shouldn't mandate that we can now no longer use encrypted ESP at all. Clearly we need a solution that also lets us use encrypted traffic where needed, but not break inspection of integrity only traffic. How do we meet that with your proposal below? We must make sure that we have a solution that is deployable and useful in the real world. bs -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Paul Hoffman Sent: Wednesday, January 06, 2010 9:50 AM To: Brian Swander; gabriel montenegro; Russ Housley Cc: [email protected] Subject: Re: [IPsec] Traffic visibility - consensus call Not wearing any hat: 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. > >Only with the WESP encrypt bit can intermediaries distinguish what is going on >here, and still enable the uplevel systems to do full encryption where needed. > I.e. if they see ESP, it must be ESP-NULL. If they see WESP, then they must >leverage the encrypt bit to see what to do. > >Hence we need to keep the encrypted bit to satisfy the current WESP charter >item. That policy makes sense if you assume that WESP covers encrypted ESP. If WESP only covers unencrypted ESP, the policy would be: When talking to/from non-WESP capable machines: must do ESP-NULL only. When both peers are WESP capable: do WESP/ESP-NULL. This is exactly what was envisioned when the WG chartered the work item. That is, the presence of WESP does not affect policy about encryption. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
