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
