On Wed, Jan 6, 2010 at 8:49 PM, Yaron Sheffer <yar...@checkpoint.com> wrote:
> 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?
I think it will always be the first one, where we see less and less of
ESP so that boxes have to spend minimal CPU on heuristics. I am also
fine with the other model if we can come out with another
standard-track RFC along with the WESP which says that we MUST not use
ESP-NULL with ESP, so that we dont see unencrypted ESP pkts in the
wild. Can we do this? If not, then lets go ahead with the first model,
as proposed by Manav.
Jack
>
> Thanks,
> Yaron
>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
