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. bs -----Original Message----- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of gabriel montenegro Sent: Tuesday, January 05, 2010 1:32 PM To: Russ Housley Cc: ipsec@ietf.org Subject: Re: [IPsec] Traffic visibility - consensus call Hi Russ, Some of us believe that allowing WESP to carry encrypted packets is within the charter (there's some recent messages today to this effect). Unfortunately, there's been wording along the lines that the working group realized it was going off-charter, but no such conclusion has been arrived at (and some of us don't share it). Without this capability, there is not a complete solution for the charter item as one might still have to use heuristics which has some limitations and cost (e.g., per Manav's recent message). Additionally, allowing WESP to carry encrypted packets does not (at least in my mind) make it a general alternative for ESP. WESP has certain applicabilities, and when cooperating with intermediaries is not an issue (e.g., outside of organizational deployments) one could use encrypted ESP packets instead. thanks, Gabriel ----- Original Message ---- > From: Russ Housley <hous...@vigilsec.com> > To: gabriel montenegro <g_e_montene...@yahoo.com> > Cc: "ipsec@ietf.org" <ipsec@ietf.org> > Sent: Tue, January 5, 2010 1:11:19 PM > Subject: Re: [IPsec] Traffic visibility - consensus call > > Gabriel: > > This is being discussed to resolve the concerns that I raised in IESG > Evaluation. > > When this work was chartered, I expected as simple wrapper. The charter says: > > > - A standards-track mechanism that allows an intermediary device, such > > as a firewall or intrusion detection system, to easily and reliably > > determine whether an ESP packet is encrypted with the NULL cipher; and > > if it is, determine the location of the actual payload data inside the > > packet. The starting points for this work item are > > draft-grewal-ipsec-traffic-visibility and draft-hoffman-esp-null-protocol. > > I think the chartering discussion would have been very different had the > charter > said that the proposed WG would develop an alternative to ESP. > > Russ > > On 1/5/2010 2:08 PM, gabriel montenegro wrote: > > But I'd also like to question the process being followed. We've discussed > these points numerous times in f2f meetings, on the mailing list, at virtual > interims, etc. So I'm surprised to see the already established consensus > being > questioned all over again. > > _______________________________________________ > 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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
