And in case there are no extensions for using WESP with encrypted traffic, then we will continue to use WESP for ESP-NULL only.
Jack On Mon, Dec 21, 2009 at 6:54 PM, Yaron Sheffer <yar...@checkpoint.com> wrote: > 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
