I took Russ' comments about "being in the rough" to imply that we're re-opening the consensus discussion. I'm not sure why we're reopening this, since we already got consensus on this when it came up the first time. Since many of our internal guys are already out for the holidays, I can't see meaningful consensus occurring until the new year.
bs -----Original Message----- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yaron Sheffer Sent: Monday, December 21, 2009 5:25 AM To: Tero Kivinen; Jack Kohn Cc: ipsec@ietf.org; Russ Housley Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility Hi Tero, Allowing the more generic, encrypted WESP (as per the current I-D) would let vendors experiment with different extensions. Yes, they might play with some extensions that you and I find ugly or even insecure. But crippling WESP today would mean that any such extensions are (1) limited to IKE and (2) invisible to the middleboxes. Thanks, Yaron -----Original Message----- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Tero Kivinen Sent: Monday, December 21, 2009 13:36 To: Jack Kohn Cc: ipsec@ietf.org; Russ Housley Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility Jack Kohn writes: > Alternatively, since we seem to be > having unlimited bandwidth for discussions, we might as well argue > whether we need heuristics also or not, as there are very few people > in IPSecMe WG who feel the need for it. My personal feelings is that this inspecting ESP-NULL packets is not needed at all, as everything will be encrypted ESP anyways, so there is even no point of trying to inspect any of that ESP-NULL traffic (either using WESP or heuristics). The reason I am in favor of heuristics instead of WESP, is that heuristics requires changes only on the middleboxes, we do not need to make new extension that will affect all the end nodes supporting IPsec. Also heuristics is not harmful, as it does not harm others, it is simply internal matter inside the middlebox. I do consider WESP a bit harmful, as it adds extra bytes to all packets, and does not offer that much which cannot already be done by other means, but requires all IPsec end nodes to be updated (and also every single firewall needs to be reconfigured to allow also this new protocol number through not just proto 50 and 51). But those are my personal feelings, and I agreed that as rest of the WG seemed to want to work on WESP, that is fine, but I still wanted push the heuristics forward just as middlebox only alternative to WESP. > Strangely, its that same set of people who are against the idea of > using null NULL ciphers for WESP. Is it because by supporting > encryption in WESP we make it more generic, and thereby increasing > the chances of its widespread implementation as against the other > proposal (heuristics)? Using non-NULL ciphers for WESP takes it out from its intended use, and unless there is some more extensions done for WESP (which there currently isn't), there is no point of doing that, as using WESP for encrypted ESP we are just wasting bytes for extra WESP header. Meaning that before we see any extensions that would require WESP and encrypted ESP I do not think there is any point of sending encrypted ESP traffic using WESP. And yes, making WESP more generic would mean that I would perhaps some day need to implement it (which I do not want to) if there is too much customer demand for it in the future. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. _______________________________________________ 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