I would like to reframe the migration discussion. Manav, Scott and everyone
else, please correct me if I got it wrong.
Suppose we have a middlebox that can do useful things if it knows that the flow
is unencrypted, and only basic things if it is encrypted. A load balancer is a
good example.
We are slowly migrating all endpoints in an enterprise to be WESP-capable.
During the migration period, the middlebox sees 3 or 4 types of traffic:
1. WESP from the new nodes.
2. Depending on your view of whether we have the bit in question: encrypted ESP
from WESP-capable ("new") nodes.
3. Encrypted ESP from WESP-incapable ("old") nodes.
4. And ESP-null from old nodes.
Taking Manav's perspective, the middlebox can always use heuristics to
distinguish encrypted ESP from ESP-null. As the number of WESP-capable nodes
grows, it will see less and less ESP, so will spend ever less CPU power on
heuristics.
According to Scott, the middlebox should have a big red switch with two
settings: initially most nodes are WESP-incapable, so it should use heuristics
to analyze ESP packets. When the time comes when "almost" all endpoint are
WESP-capable, we turn the switch and now we assume all ESP is encrypted, with
no per-flow analysis. Unless we do so, we will be wasting CPU on heuristics
forever.
Are these the alternatives we are facing? And if so, what is the preferred
migration scenario?
Thanks,
Yaron
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Scott
C Moonen
Sent: Wednesday, January 06, 2010 15:38
To: Venkatesh Sriram
Cc: ipsec@ietf.org; ipsec-boun...@ietf.org
Subject: Re: [IPsec] Traffic visibility - consensus call
Venkatesh said:
> I agree that WESP should not be clipped to only support ESP-NULL; it
> should be able to carry encrypted packets as well. Without this the
> middle boxes would never know whether the ESP packet thats passing is
> encrypted or not.
Earlier, Manav said:
> Now, assume that we limit WESP for only ESP-NULL. If this is done, how
> can a middle box deterministically know that the ESP packet that it
> sees is an encrypted ESP packet or an ESP packet carrying ESP-NULL
> payload.
I don't follow the argument. Because 1) a middle box can't trust that an ESP
packet is not ESP-NULL, therefore 2) we are going to allow WESP to carry
encrypted ESP? That is either begging the question or else it is simply an
invalid argument. Allowing platform A to use WESP to carry encrypted ESP has
nothing to do with how likely it is that platform B will use WESP to carry its
ESP-NULL packets. The middle box's problem is not solved by this. That needs
to be addressed by other means (convince people to use WESP for ESP-NULL, or
mandate it). I am not saying that there is no possible case to be made for
WESP to carry encrypted packets, just that this argument does not support that.
The hidden assumption here still seems to be that WESP either is or ought to
become ESPv4. The reality is that with WESP as the alternative, ESP is not
going away and ESP-NULL is probably also not going away. I personally cannot
envision being able to justify implementing WESP even for ESP-NULL on my own
platform.
The middle boxes are dependent on end nodes if they want widespread WESP
adoption. I must say that the middle-box folks have been doing a lot less
sweet talking and receptive listening than I would have expected given this
arrangement. :) That leads me to predict a very doubtful future for WESP even
if we were to reach perfect consensus on its technical make-up.
Scott Moonen (smoo...@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen
From:
Venkatesh Sriram <vnktshsri...@gmail.com>
To:
"ipsec@ietf.org" <ipsec@ietf.org>
Date:
01/05/2010 11:16 PM
Subject:
Re: [IPsec] Traffic visibility - consensus call
________________________________________
> Would it help if WESP is renamed to something else? Since we're
> discussing the fundamental principles of the protocol, i see no reason
> why we cant change the name, if that helps. I think its the "Wrapped"
> in the WESP thats causing most heart burn, lets change that to
> something else .. something thats appeases everyone.
I agree. How about VESP - "Visible ESP" ? Its phonetically the same as WESP. :)
I agree that WESP should not be clipped to only support ESP-NULL; it
should be able to carry encrypted packets as well. Without this the
middle boxes would never know whether the ESP packet thats passing is
encrypted or not. One way could be to deprecate the use of ESP-NULL in
ESP, which would mean that if someone sees an ESP packet then it MUST
be an encrypted packet.
This is as i understand impossible, so the only option left is to let
WESP also carry encrypted packets.
Sriram
_______________________________________________
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
