Subject: Re: [IPsec] Traffic visibility - consensus call

From: Mark Vondemkamp <[email-masked]>
Date: Tue, 5 Jan 2010 12:47:50 -0800

Yes and Yes.

We see a lot of value in taking advantage of the extensibility of the protocol as it stands in the WESP today. Allowing WESP to not be simply a wrapper, and enabling encryption support are both fundamental for the future extensibilities. So we express our support of the these design decisions.

Mark

-----Original Message-----
Date: Tue, 5 Jan 2010 00:27:26 +0200
From: Yaron Sheffer <[email-masked]>
Subject: [IPsec] Traffic visibility - consensus call
To: "[email-masked]" <[email-masked]>

Hi,

We have had a few "discusses" during the IESG review of the WESP draft. To help resolve them, we would like to reopen the following two questions to WG discussion. Well reasoned answers are certainly appreciated. But plain "yes" or "no" would also be useful in judging the group's consensus.

- The current draft (http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11) defines the ESP trailer's ICV calculation to include the WESP header. This has been done to counter certain attacks, but it means that WESP is no longer a simple wrapper around ESP - ESP itself is modified. Do you support this design decision?

- The current draft allows WESP to be applied to encrypted ESP flows, in addition to the originally specified ESP-null. This was intended so that encrypted flows can benefit from the future extensibility offered by WESP. But arguably, it positions WESP as an alternative to ESP. Do you support this design decision?

Thanks,
     Yaron

---

From: "Dragan Grebovich" <[email-masked]>
Date: Tue, 5 Jan 2010 16:22:23 -0500

Yes and Yes.

I supported WESP from the beginning, because it allows intermediate
systems to perform DPI on ESP-NULL packets.  I was not in favor of
heuristics - not because it is a bad solution (on the contrary) - but
because many products we have/make today could not be upgraded to
support it.  Manav gave an excellent summary the other day.

I also view that the extensibility of the protocol as it stands in the
WESP today allows a smooth evolution path for fixing an obvious problem
and allowing support of new services.  I would not deprecate ESP for a
long time because there is a wide customer base that cannot be ripped
out.  I would work within the present charter, if possible.  If it takes
a new charter to codify ESPv4, I am fine with that too, and let's use
WESP as a base.  

There is always going to be equipment mix of multiple vintages and
capabilities.  Systems capable of supporting  (extensible) WESP should
be able to take advantage of that.  Some systems may not be able to
support encrypted WESP and would work with ESP-NULL only.  Legacy
systems (non-WESP capable) must be able to perform as they do today
(ignoring WESP packets and forwarding them uninspected).  

Dragan

-----Original Message-----
Date: Tue, 5 Jan 2010 00:27:26 +0200
From: Yaron Sheffer <[email-masked]>
Subject: [IPsec] Traffic visibility - consensus call
To: "[email-masked]" <[email-masked]>

Hi,

We have had a few "discusses" during the IESG review of the WESP draft.
To help resolve them, we would like to reopen the following two
questions to WG discussion. Well reasoned answers are certainly
appreciated. But plain "yes" or "no" would also be useful in judging the
group's consensus.

- The current draft
(http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11)
defines the ESP trailer's ICV calculation to include the WESP header.
This has been done to counter certain attacks, but it means that WESP is
no longer a simple wrapper around ESP - ESP itself is modified. Do you
support this design decision?

- The current draft allows WESP to be applied to encrypted ESP flows, in
addition to the originally specified ESP-null. This was intended so that
encrypted flows can benefit from the future extensibility offered by
WESP. But arguably, it positions WESP as an alternative to ESP. Do you
support this design decision?

Thanks,
     Yaron

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Jack Kohn <[email-masked]>
Date: Wed, 6 Jan 2010 23:44:05 +0530

> support it.  Manav gave an excellent summary the other day.

The more that i think about this, the more convinced i get, that we
(IPSecME WG) do not have a solution, any solution for traffic
visibility, if we do not let WESP carry encrypted traffic, because
heuristics is for most boxes unimplementable (i.e. if at all it can
work) and all models proposed so far rely on all boxes doing some bit
of heuristics along with WESP for proper identification of encrypted
and unencrypted packets.

> a new charter to codify ESPv4, I am fine with that too, and let's use

Either this, or we come out with a short draft that deprecates
ESP-NULL usage with ESP.

> (ignoring WESP packets and forwarding them uninspected).

I agree.

Jack

---

From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
Date: Thu, 7 Jan 2010 00:03:18 +0000

Responding to Yaron's request for group input on two questions pertaining to WESP draft

On question #1 (ICV calculation): I don't agree with design decision to include WESP header in ESP trailer's ICV.  I see it as unnecessary contamination of ESP protocol.  

On question #2 (Allowing WESP as alternative to ESP):  I support this design choice. On the whole I feel that the functionality described for WESP, even when perceived as an alternative to ESP,  is a step in the right direction for supporting several key use cases for us.  

Cheers,
MS

-------------------------------------------- 
Mauricio Sanchez
Chief Security Architect

HP ProCurve Networking
Hewlett-Packard
8000 Foothills Blvd.
M/S 5541
Roseville, CA 95747
tel: 916.785.1910
fax: 916.785.1749
[email-masked]
 
--------------------------------------------

----------------------------------------------------------------------

Message: 1
Message-ID:
	<[email-masked]>
	
Content-Type: text/plain; charset="us-ascii"

Hi,

Thanks,
     Yaron

------------------------------