Subject: [IPsec] Traffic visibility - consensus call

From: Yaron Sheffer <[email-masked]>
Date: Tue, 5 Jan 2010 00:27:26 +0200

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: Yoav Nir <[email-masked]>
Date: Tue, 5 Jan 2010 09:55:18 +0200

> - 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 extensi…

Yes to both.

Regardless of what the original work item specified, WESP as it is now is an alternative to ESP. In the long run it makes no sense to have them both, so one will get obsoleted (just as AH is getting there).

I see no benefit in crippling WESP to either keep the old ESP unchanged or to keep some functionality (like encryption) as ESP-only.

---

From: Scott C Moonen <[email-masked]>
Date: Tue, 5 Jan 2010 07:28:41 -0500

> > Do you support [the decision to include the WESP header in the ICV
> > calculation]?
> > . . .
> > Do you support [the decision to allow the use of WESP for encrypted
> > ESP flows]?
> 
> Yes to both.
> 
> Regardless of what the original work item specified, WESP as it is now
> is an alternative to ESP. In the long run it makes no sense to have
> them both, so one will get obsoleted (just as AH is getting there).
> 
> I see no benefit in crippling WESP to either keep the old ESP
> unchanged or to keep some functionality (like encryption) as ESP-only.

No to both, considering the initial scope of what this was trying to do. I 
don't think we have warrant for inventing a complete replacement to ESP 
and I haven't yet seen any hypothetical proposals for the use of WESP that 
convince me there is a strong case for scuttling and replacing ESP.

However, if the ayes have it, then I think two things are advisable. 
First, it would be wise to rewind the clock a bit and think about 
designing a cleaner WESP.  WESP would look different if it had started out 
as a complete replacement for ESP.  (For example, we've missed the 
opportunity to move the encrypted protocol byte up to the front.)  Second, 
because there is a deep divide over whether a full-featured WESP has value 
or will be embraced, it may be wise to change this from a standards-track 
document to an individual draft or to experimental.  Alternatively, we 
could really rewind the clock and try to establish real warrant and 
consensus for a complete replacement to ESP.

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

From:
Yoav Nir <[email-masked]>
To:
Yaron Sheffer <[email-masked]>
Cc:
"[email-masked]" <[email-masked]>
Date:
01/05/2010 02:56 AM
Subject:
Re: [IPsec] Traffic visibility - consensus call

On Jan 5, 2010, at 12:27 AM, Yaron Sheffer wrote:

> 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?

Yes to both.

Regardless of what the original work item specified, WESP as it is now is 
an alternative to ESP. In the long run it makes no sense to have them 
both, so one will get obsoleted (just as AH is getting there).

I see no benefit in crippling WESP to either keep the old ESP unchanged or 
to keep some functionality (like encryption) as ESP-only.

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

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 5 Jan 2010 14:52:55 +0200

Yaron Sheffer writes:
> - 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?

No.

> - 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?

No.

If we really want to make WESP as specified in the charter, it would
be much better to make it so it can be added incrementally to the ESP
processing, i.e. just like UDP encapsulation for NAT-traversal can be
do. This would mean that the WESP processing could be applied after
the normal ESP processing, and WESP would simply add extra header to
the beginning, and nothing else. The current draft already makes sure
all the fields in the WESP header are verified by the IPsec recipient
thus there is really no need to add ICV to cover them (if extensions
are added then ICV needs cover them, which makes it impossible to
implement WESP as incremental change to ESP).

On the other hand if WESP is going be ESPv4, then it would be better
to modify the ESP directly, i.e make the required modifications to the
ESP header itself.

Now WESP has bad attributes from both. It cannot be implemented as
extra step after normal ESP processing, but it does not benefit from
the fact that it could be modifying ESP header.

I myself has always not cared that much of WESP, as I always planned
NOT to implement it ever, but just refer people who want it to my
heuristics draft, and say that there is no need for WESP. Now if
people really start to talk WESP as a new ESPv4, and talking about
obsoleting old ESP so that only WESP would stay, then the situation is
quite different. If that would have been clear from the beginning I
myself would have concentrated much more on the WESP work. I assume
there are other people who feel the same.

Thats why I think it is inappropriate to even consider WESP as
something that would be replacing ESP ever. If that is wanted, then
much more discussion is needed. 
-- 
[email-masked]

---

From: Dan McDonald <[email-masked]>
Date: Tue, 5 Jan 2010 10:27:47 -0500

On Tue, Jan 05, 2010 at 02:52:55PM +0200, Tero Kivinen wrote:
<SNIP!>

> implement WESP as incremental change to ESP).

Yes -- this would allow WESP to be an attribute one adds to an ESP SA.  Not
unlike NAT-Traversal, it could be negotiated by IKE.

Dan

---

From: Stephen Kent <[email-masked]>
Date: Tue, 5 Jan 2010 13:06:05 -0500

At 12:27 AM +0200 1/5/10, Yaron Sheffer wrote:
>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 
>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?

My previous message describing why I think the current design is 
seriously flawed provided the rationale for my NO response to this 
question. WESP as a modular, separate, nested protocol would be 
preferable.

>extensibility offered by WESP. But arguably, it positions WESP as an 
>alternative to ESP. Do you support this design decision?

I am concerned about the wording of the penultimate sentence above. 
Several folks argued against applying WESP to encrypted traffic and 
they cited various reasons for why this might be inappropriate.  You 
did not choose to cite those reasons, which I think may bias 
responses.  I think the two major issues cited re the extension of 
WESP to encrypted traffic are:
	- it is formally outside the charter
	- no good WESP extensions have been proposed for encrypted traffic

Even if WESP is approved for use with encrypted traffic, that does 
not mean that it will supplant ESP.  ESP still has a smaller header 
than WESP, so for environments where there is no intent to 
accommodate middlebox snooping, ESP is still preferable.

So, NO to this question as well.

Steve

---

From: "Grewal, Ken" <[email-masked]>
Date: Tue, 5 Jan 2010 11:14:43 -0700

Yes to both, based on arguments already discussed numerous times in the WG via presentations, 12 iterations of the draft and multiple WG last calls + AD reviews!

The main motivation for extending the ICV was to counter some of the issues originally raised by Steve Kent - malicious entities modifying portions of the WESP header to bypass legitimate parsing of the packet by Trusted Intermediary (TI) devices such as IDS/IPS/etc. This can be addressed by the recipient explicitly validating the WESP header before accepting the packet or implicitly by including the WESP header as part of the ICV check. 

The motivation for allowing WESP to be used for encrypted data was brought up as a consistency argument and also allows for future extensibility in a uniform manner. I agree that this was not part of the original charter, as shown in the earlier revisions of the WESP drafts. 
BUT, this was discussed numerous times within the WG (including an open ticket on scope) and it was agreed that this would be a useful bit to include in the flags, hence introduced in the latter revisions of the draft. Note that this does not mandate using WESP for encrypted traffic, but allows it as optional and can be dictated as part of the session setup based on local policy. Another benefit may be that in running mixed mode environments (encrypted + ESP_NULL traffic), it allows for an explicit distinction from the packet that certain traffic is encrypted and other traffic is not. Otherwise, one would use ESP and WESP in these mixed mode environments and to be absolutely sure if ESP traffic is encrypted or not, would need to fall back to heuristics, which somewhat defeats the object of having this spec.  

I am certainly not a fan of heuristics, as it is complex, non-deterministic, will require updates for new algorithms added into ESP, as well as other arguments already cited numerous times, so would like to see a consistent deterministic way to identify the traffic.  

Thanks, 
- Ken

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Yaron Sheffer
>Sent: Monday, January 04, 2010 2:27 PM
>To: [email-masked]
>Subject: [IPsec] Traffic visibility - consensus call
>
>Hi,
>
>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
>encrypted flows can benefit from the future extensibility offered by
>WESP. But arguably, it positions WESP as an alternative to ESP. Do you

---

From: gabriel montenegro <[email-masked]>
Date: Tue, 5 Jan 2010 11:08:34 -0800 (PST)

Yes to both questions.
 
But I'd also like to question the process being followed. We've discussed these points numerous times
in f2f meetings, on the mailing list, at virtual interims, etc. So I'm surprised to see the already
established consensus being questioned all over again. Some of the arguments claim lack of
attention, whereas they have been intense and prolific discussions on WESP, and thankfully so 
(e.g., including but not limited to spawning of Tero's heuristics draft and 
the motivation for the modified ICV coverage to address Steve's comment). 
 
But even if folks had not paid attention, that is no excuse for derailing the process.
 
I disagree that WESP encryption is out of scope. It certainly is.
 
There is a need per the charter for a mechanism to
"easily and reliably" determine the type of traffic. Within an organization, it would be much easier to use
WESP encryption as an alternative to ESP. If one sees ESP packets, then one would have to run heuristics
with all the pertaining issues as explained in Manav's recent message, and higher cost associated
(particularly, in stateless high aggregation points). WESP with encryption support would allow an 
organization to simplify rules and inspection devices. Sure, the WESP header adds more bytes, but the
tradeoff is that there is no need for costly heuristics throughout the network. Without WESP encryption,
the charter item does not have a complete solution.
 
Just to be clear: I'm not saying that WESP is a general replacement for ESP. As Steve Kent points out,
where there are no trusted intermediary inspection devices (i.e., outside of medium to large organizations)
there is no need for end-nodes to collaborate with the inspecting infrastructure, hence no need for 
WESP. ESP is fine. Perhaps this is the disconnect that is happening: traditionally, the focus of the IPsec
WG has been on such external applications (VPN), whereas WESP and future potential
extensibility is more valuable within organizations. Such value may not be as obvious to VPN folks.
 
Gabriel

----- Original Message ----
> From: "Grewal, Ken" <[email-masked]>
> To: Yaron Sheffer <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Tue, January 5, 2010 10:14:43 AM
> Subject: Re: [IPsec] Traffic visibility - consensus call
> 
> Yes to both, based on arguments already discussed numerous times in the WG via 
> presentations, 12 iterations of the draft and multiple WG last calls + AD 
> reviews!
> 
> The main motivation for extending the ICV was to counter some of the issues 
> originally raised by Steve Kent - malicious entities modifying portions of the 
> WESP header to bypass legitimate parsing of the packet by Trusted Intermediary 
> (TI) devices such as IDS/IPS/etc. This can be addressed by the recipient 
> explicitly validating the WESP header before accepting the packet or implicitly 
> by including the WESP header as part of the ICV check. 
> 
> The motivation for allowing WESP to be used for encrypted data was brought up as 
> a consistency argument and also allows for future extensibility in a uniform 
> manner. I agree that this was not part of the original charter, as shown in the 
> earlier revisions of the WESP drafts. 
> BUT, this was discussed numerous times within the WG (including an open ticket 
> on scope) and it was agreed that this would be a useful bit to include in the 
> flags, hence introduced in the latter revisions of the draft. Note that this 
> does not mandate using WESP for encrypted traffic, but allows it as optional and 
> can be dictated as part of the session setup based on local policy. Another 
> benefit may be that in running mixed mode environments (encrypted + ESP_NULL 
> traffic), it allows for an explicit distinction from the packet that certain 
> traffic is encrypted and other traffic is not. Otherwise, one would use ESP and 
> WESP in these mixed mode environments and to be absolutely sure if ESP traffic 
> is encrypted or not, would need to fall back to heuristics, which somewhat 
> defeats the object of having this spec.  
> 
> I am certainly not a fan of heuristics, as it is complex, non-deterministic, 
> will require updates for new algorithms added into ESP, as well as other 
> arguments already cited numerous times, so would like to see a consistent 
> deterministic way to identify the traffic.  
> 
> Thanks, 
> - Ken
> 
>

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Jan 2010 11:14:36 -0800

At 11:08 AM -0800 1/5/10, gabriel montenegro wrote:
>But I'd also like to question the process being followed.

And I would like to answer. In short: the IESG is responsible for the output of the IETF. This is one such output. The IESG chartered the WG for a particular item, and there is a question about whether what we produced matches that charter, and if it doesn't, is it still OK.

>We've discussed these points numerous times
>established consensus being questioned all over again.

The IESG was not part of those discussions; they are reviewing the work that this WG sent to them.

>But even if folks had not paid attention, that is no excuse for derailing the process.

A consensus call is not "derailing the process": it is just the opposite.

--Paul Hoffman, Director
--VPN Consortium

---

From: gabriel montenegro <[email-masked]>
Date: Tue, 5 Jan 2010 11:25:31 -0800 (PST)

I fully agree that a consensus call is an integral part of the IETF process. 

But what we're seeing here is not one but a plurality of consensus calls.

I would have expected the response to the IESG to be: yes, this was the consensus arrived
in the WG at time X, here are further details, etc.

What we're seeing is: oh, ok, let's do it all over again. 

----- Original Message ----
> From: Paul Hoffman <[email-masked]>
> To: gabriel montenegro <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Tue, January 5, 2010 11:14:36 AM
> And I would like to answer. In short: the IESG is responsible for the output of 
> the IETF. This is one such output. The IESG chartered the WG for a particular 
> item, and there is a question about whether what we produced matches that 
> charter, and if it doesn't, is it still OK.
>

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Jan 2010 11:41:07 -0800

>But what we're seeing here is not one but a plurality of consensus calls.

The two questions that Yaron asked are related to the questions from the IESG.

>in the WG at time X, here are further details, etc.

The IESG fully understands that there was rough consensus; that's not what they are asking. They want to know if there was a strong consensus, and did we see that we were straying from the charter.

>What we're seeing is: oh, ok, let's do it all over again.

That is one possibility; another is "OK, that's fine". But it is the IESG that gets to make that determination, not the WG.

--Paul Hoffman, Director
--VPN Consortium

---

From: Brian Swander <[email-masked]>
Date: Tue, 5 Jan 2010 19:49:33 +0000

Yes to both.

To elaborate on what Ken said, here's an explicit scenario that requires the encrypted bit for WESP, fully within the current charter of enabling ESP-NULL inspection.

Transport policies for within an organization that want to enable intermediary inspection of ESP-NULL non-heurisitically.  Organization has a mix of version of systems.

Sample policy:
When talking to/from non-WESP capable machines:  must do ESP-NULL only
When both peers are WESP capable: do WESP/ESP-NULL most places.  However, where policy requires encryption, do WESP/ESP.

Only with the WESP encrypt bit can intermediaries distinguish what is going on here, and still enable the uplevel systems to do full encryption where needed.  I.e. if they see ESP, it must be ESP-NULL.  If they see WESP, then they must leverage the encrypt bit to see what to do.

Hence we need to keep the encrypted bit to satisfy the current WESP charter item.

bs

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaron Sheffer
Sent: Monday, January 04, 2010 2:27 PM
To: [email-masked]
Subject: [IPsec] Traffic visibility - consensus call

Hi,

Thanks,
     Yaron

---

From: Russ Housley <[email-masked]>
Date: Tue, 05 Jan 2010 16:11:19 -0500

Gabriel:

This is being discussed to resolve the concerns that I raised in IESG 
Evaluation.

When this work was chartered, I expected as simple wrapper.  The charter 
says:

 > - A standards-track mechanism that allows an intermediary device, such
 > as a firewall or intrusion detection system, to easily and reliably
 > determine whether an ESP packet is encrypted with the NULL cipher; and
 > if it is, determine the location of the actual payload data inside the
 > packet. The starting points for this work item are
 > draft-grewal-ipsec-traffic-visibility and 
draft-hoffman-esp-null-protocol.

I think the chartering discussion would have been very different had the 
charter said that the proposed WG would develop an alternative to ESP.

Russ

On 1/5/2010 2:08 PM, gabriel montenegro wrote:
> But I'd also like to question the process being followed. We've discussed these points numerous times in f2f meetings, on the mailing list, at virtual interims, etc. So I'm surprised to see the already established consensus being questioned all over again.

---

From: gabriel montenegro <[email-masked]>
Date: Tue, 5 Jan 2010 13:32:18 -0800 (PST)

Hi Russ,

Some of us believe that allowing WESP to carry encrypted packets is within the charter
(there's some recent messages today to this effect). Unfortunately, there's been wording along the lines
that the working group realized it was going off-charter, but no such conclusion has been
arrived at (and some of us don't share it). 

Without this capability, there is not a complete solution for the charter item as one might still have to use 
heuristics which has some limitations and cost (e.g., per Manav's recent message).

Additionally, allowing WESP to carry encrypted packets does not (at least in my mind)
make it a general alternative for ESP. WESP has certain applicabilities, and when
cooperating with intermediaries is not an issue (e.g., outside of organizational deployments) 
one could use encrypted ESP packets instead.

thanks,

Gabriel

----- Original Message ----
> From: Russ Housley <[email-masked]>
> To: gabriel montenegro <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Sent: Tue, January 5, 2010 1:11:19 PM
> When this work was chartered, I expected as simple wrapper.  The charter says:
> 
> > draft-grewal-ipsec-traffic-visibility and draft-hoffman-esp-null-protocol.
> 
> I think the chartering discussion would have been very different had the charter 
> said that the proposed WG would develop an alternative to ESP.
> 
> Russ
> 
> > But I'd also like to question the process being followed. We've discussed 
> these points numerous times in f2f meetings, on the mailing list, at virtual 
> interims, etc. So I'm surprised to see the already established consensus being 
> questioned all over again.
>

---

From: Brian Swander <[email-masked]>
Date: Tue, 5 Jan 2010 22:10:28 +0000

I'll resend my message from earlier today that gives a concrete scenario for why the WESP encryption bit is in charter.   

To satisfy the existing charter item, we need a deployable solution, which entails working with legacy systems that don't support this functionality yet.  

Here's an explicit scenario that requires the encrypted bit for WESP, fully within the current charter of enabling ESP-NULL inspection.

Sample policy:

bs

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of gabriel montenegro
Sent: Tuesday, January 05, 2010 1:32 PM
To: Russ Housley
Cc: [email-masked]
Subject: Re: [IPsec] Traffic visibility - consensus call

Hi Russ,

thanks,

Gabriel

---

From: Russ Housley <[email-masked]>
Date: Tue, 05 Jan 2010 17:52:24 -0500

> arrived at (and some of us don't share it).

I see the discussion, but so far, I am not convinced by it.  I'm still 
listening ...

> one could use encrypted ESP packets instead.

It is a replacement (as opposed to a wrapper) if the portions of the 
packet that are covered by the ICV are different.

Russ

---

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

Yaron,

On Tue, Jan 5, 2010 at 3:57 AM, Yaron Sheffer <[email-masked]> wrote:
> - 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?

I had brought this up on the mailing list some time back that WESP now
is not a mere "wrapper" over the ESP and is almost like a new
protocol, which it anyways was designed to be. I dont see an issue
with that. I dont hold a very strong opinion on whether we should
include the WESP protocol header inside the ESP calculation or not and
am also fine with the end nodes just doing a sanity check to ensure
that things look alright when they receive the WESP protocol packets.

>
> - 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.

And i strongly agree with this. It would be severely limiting to see
WESP being only used for ESP-NULL cases. I see absolutely no harm in
using WESP for encrypted traffic too. I agree with others on the list
that by having WESP do encryption we provide the middle boxes with an
easy/deterministic way to discriminate between integrity protected and
encrypted packets, which is what we were chartered to do. I am not a
big fan of flow based devices as these get really too hot to handle in
scaled up networks and heuristics seems like a juvenile attempt at
solving the problem. There have been various mails in the past about
the issues in that scheme and i dont intend to rehash them here, so
i'll this here.

> But arguably, it positions WESP as an alternative to ESP.
>

It does not.

ESP still has its own place and i dont see how having WESP ship ESP
encrypted packets makes it a substitute of ESP. WESP will be required
in the environments wherever we require deep inspection while ESP will
continue where its not.

> Do you support this design decision?

Yes, i do.

Jack

---

From: "Joseph Tardo" <[email-masked]>
Date: Tue, 5 Jan 2010 15:32:59 -0800

Gabriel Montenegro wrote:

> Just to be clear: I'm not saying that WESP is a general replacement for ESP. 
> As Steve Kent points out, where there are no trusted intermediary inspection 
> devices (i.e., outside of medium to large organizations) there is no need
> for  end-nodes to collaborate with the inspecting infrastructure, hence no
> need for WESP. ESP is fine. Perhaps this is the disconnect that is happening: 
> traditionally, the focus of the IPsec WG has been on such external applications
> (VPN), whereas WESP and future potential extensibility is more valuable within 
> organizations. Such value may not be as obvious to VPN folks.
 
This sounds like an argument for being able to strip off the internal network WESP header at a perimeter intermediate system. That same perimeter box can apply Tero's heuristics and then add the header for so the intermediate systems don't need to. Voila, instant upgrade value for the VPN folks.

Which, of course, would not be possible with the ICV over the WESP header.

On the other hand, I don't really buy the 'slippery slope' arguments. I have read the charter for this work item over a couple of times and WESP with encryption still looks consistent to me.

So, here's my opinion:

- YES on allowing use of WESP when using ESP with encryption

- NO on including the WESP header in the ICV calculation, the endpoints have to deal with attacks in any case.

By the way, WESP extension drafts that propose arbitrary new mutable fields for use with ESP just reinforce that NO. 

Thanks,
--Joe

---

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

> Even if WESP is approved for use with encrypted traffic, that does not mean
> that it will supplant ESP.  ESP still has a smaller header than WESP, so for
> environments where there is no intent to accommodate middlebox snooping, ESP
> is still preferable.

I agree with Steve here that extending WESP to support encryption does
not mean that it will be replacing ESP. The latter would still get
used, as i noted in my earlier email, in environments where there is
no need for deep packet inspection.

Jack

---

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

> the charter item does not have a complete solution.

I agree.

I, like others, and unlike the authors of heuristics, would never like
to see heuristics implemented in a network, because it is not going to
work. Period.

It requires too much from the devices to do, and its simply not
practical (refer to past mails in the WG list). One can clearly gauge
the interest in heuristics vis-a-vis WESP by the amount of mails and
the review comments that have been sent/exchanged.

WESP provides a simple, clean, deterministic way to disambiguate
between encrypted and unencrypted traffic and i would like to see it
this way.

> WESP. ESP is fine.

I agree and would like to stress that WESP is not a replacement for
ESP. I repeat for the benefit of others that extending WESP to carry
encrypted packets does not mean that it is replacing ESP.

Jack

---

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

Russ,

>
> It is a replacement (as opposed to a wrapper) if the portions of the packet
> that are covered by the ICV are different.

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.

Jack

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 6 Jan 2010 07:26:43 +0530

Hi Russ,
 
> charter said that the proposed WG would develop an alternative to ESP.

I don't think WESP is in any sense an alternative to ESP and I believe we did stick to the charter, which was to provide a *deterministic* way to disambiguate different ESP packets.

I understand that the word "deterministic" is missing from the charter text, but it was obvious to everyone working in IPSec that WESP was to be a *deterministic* solution.

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. The middleboxes will now be forced to apply heuristics just to be sure that the packet is indeed an encrypted ESP packet. This would defeat the purpose of having WESP in the network.

So, when including the encryption bit in the WESP header we never thought that it was out of the charter (as others have also noted in the mailing list) as it was really being used to provide a deterministic answer to whether the packet was encrypted or not.

We really don't have a complete solution if we don't include the encryption bit in the WESP header.

Cheers, Manav

---

From: gabriel montenegro <[email-masked]>
Date: Tue, 5 Jan 2010 18:15:20 -0800 (PST)

Russ,

I think we agree here: the end nodes need to validate the WESP header info.

As I noted before, one could do this by modifying the ICV or by explicitly checking those 
WESP fields at the end nodes. I think there has been enough feedback to the effect that
modifying the ICV is overkill and has some down sides. 

So, ok, I think in the next rev of the draft we should go back to *not* modifying the ICV (i.e., not 
including the WESP header fields in the ICV). This would leave WESP as a wrapper (as it started).

The other threads and messages are hopefully addressing your other concerns.

thanks,

Gabriel

----- Original Message ----
> Sent: Tue, January 5, 2010 2:52:24 PM
> I see the discussion, but so far, I am not convinced by it.  I'm still listening 
> ...
> 
> It is a replacement (as opposed to a wrapper) if the portions of the packet that 
> are covered by the ICV are different.
> 
> Russ

---

From: Zhen Cao <[email-masked]>
Date: Wed, 6 Jan 2010 10:19:35 +0800

Yes to both.

Zhen
China Mobile

On Tue, Jan 5, 2010 at 6:27 AM, Yaron Sheffer <[email-masked]> wrote:

> 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 (
> longer a simple wrapper around ESP - ESP itself is modified. Do you support
> this design decision?
>

Yes, we need to protect the message integrity while offering traffic
visibility.

> But arguably, it positions WESP as an alternative to ESP. Do you support

Yes, future extensibility is a feature that will benefit traffic control for
operators and other entities.

---

From: Venkatesh Sriram <[email-masked]>
Date: Wed, 6 Jan 2010 09:45:49 +0530

> 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

---

From: Scott C Moonen <[email-masked]>
Date: Wed, 6 Jan 2010 08:37:54 -0500

Venkatesh said:
> 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.

From:
Venkatesh Sriram <[email-masked]>
To:
"[email-masked]" <[email-masked]>
Date:
01/05/2010 11:16 PM
Subject:
Re: [IPsec] Traffic visibility - consensus call

> something else .. something thats appeases everyone.

I agree. How about VESP - "Visible ESP" ? Its phonetically the same as 
WESP. :)

Sriram

---

From: Stephen Kent <[email-masked]>
Date: Wed, 6 Jan 2010 09:28:30 -0500

At 11:14 AM -0700 1/5/10, Grewal, Ken wrote:
>Yes to both, based on arguments already discussed numerous times in 
>the WG via presentations, 12 iterations of the draft and multiple WG 
>last calls + AD reviews!
>
>The main motivation for extending the ICV was to counter some of the 
>issues originally raised by Steve Kent - malicious entities 
>modifying portions of the WESP header to bypass legitimate parsing 
>of the packet by Trusted Intermediary (TI) devices such as 
>IDS/IPS/etc. This can be addressed by the recipient explicitly 
>validating the WESP header before accepting the packet or implicitly 

My recollection is that I identified a vulnerability that arose 
because of the potential for a mismatch between what a TI checked and 
what the receiver acted upon, irrespective of how that mismatch 
arose.  I think I suggested that this vulnerability might be remedied 
by requiring the receiver to verify that the WESP header info was 
consistent with what the receiver was acting upon, as part of WESP 
processing. The current I-D calls for this check to be performed by 
the recipient. Above you state that:

"This can be addressed by the recipient explicitly validating the 
WESP header before accepting the packet or implicitly by including 
the WESP header as part of the ICV check."

I disagree with the "or" in this sentence, for two reasons. First, 
the I-D calls for the receiver to perform the consistency check, so 
it's not an "or." Second,
it would not suffice to perform JUST the ICV check you described, 
since that would not address the possibility that the sender created 
the misleading WESP header.

>The motivation for allowing WESP to be used for encrypted data was 
>brought up as a consistency argument and also allows for future 
>extensibility in a uniform manner. I agree that this was not part of 
>the original charter, as shown in the earlier revisions of the WESP 
>drafts.

It appears that we agree that it was out of scope (although others do 
not), and that the principle motivation cited was to allow for 
extensions. The phrase :in a uniform manner" is, I believe, shorthand 
for extensions that apply to encrypted traffic, right?

>BUT, this was discussed numerous times within the WG (including an 
>open ticket on scope) and it was agreed that this would be a useful 
>bit to include in the flags, hence introduced in the latter 
>revisions of the draft.

I have already admitted that I lost track of this aspect of the 
discussion, among all of the ticket items that the WG has processed. 
(BTW, I congratulate Paul and Yaron for doing a very good job of 
managing such a large number of issues in a detailed fashion.  The 
fact that I, and maybe a few other folks, lost track of the details 
on one of the many items being worked is not a reflection on the 
management style that have employed.)

When I re-read the I-D during IETF last call, I was surprised to 
learn that ESP  processing had been changed, so cause the ICV to 
cover non-ESP fields.  This seems to be unnecessary and it is a bad 
design, in my opinion.

>Note that this does not mandate using WESP for encrypted traffic, 
>but allows it as optional and can be dictated as part of the session 
>setup based on local policy. Another benefit may be that in running 
>mixed mode environments (encrypted + ESP_NULL traffic), it allows 
>for an explicit distinction from the packet that certain traffic is 
>encrypted and other traffic is not. Otherwise, one would use ESP and 
>WESP in these mixed mode environments and to be absolutely sure if 
>ESP traffic is encrypted or not, would need to fall back to 
>heuristics, which somewhat defeats the object of having this spec.

If local policy can be used to dictate whether WESP is or is not used 
for encrypted traffic, then that policy also can dictate that ESP is 
used only for encrypted traffic. Even in an environment where some 
but not all hosts support WESP, I don't see the need for this flag. A 
host that is WESP capable need not use WESP for encrypted traffic; it 
can use ESP. if so, then ITs see three classes of traffic:
	- encrypted using ESP
	- integrity-protected using WESP
	- integrity-protected using ESP

The third class of traffic poses a problem for the ITs, but adding 
the encrypted flag to WESP does not seem to address that problem.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 6 Jan 2010 10:06:37 -0500

At 10:10 PM +0000 1/5/10, Brian Swander wrote:
>I'll resend my message from earlier today that gives a concrete 
>scenario for why the WESP encryption bit is in charter.  
>
>To satisfy the existing charter item, we need a deployable solution, 
>which entails working with legacy systems that don't support this 
>functionality yet. 
>
>Here's an explicit scenario that requires the encrypted bit for 
>WESP, fully within the current charter of enabling ESP-NULL 
>inspection.
>
>Transport policies for within an organization that want to enable 
>intermediary inspection of ESP-NULL non-heurisitically. 
>Organization has a mix of version of systems.
>
>Sample policy:
>When both peers are WESP capable: do WESP/ESP-NULL most places. 
>However, where policy requires encryption, do WESP/ESP.

This is where I have a problem with the analysis. If the policy were 
that WESP-capable hosts did ESP when then needed to send encrypted 
traffic, the flag inn question would not be needed, right?

I don't think we can justify the inclusion of this flag based on the 
scenario you described above, because that scenario adopts a 
particular local policy that it not required.

Steve

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 6 Jan 2010 17:19:20 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf Of Scott C Moonen
Sent: Wednesday, January 06, 2010 15:38
To: Venkatesh Sriram
Cc: [email-masked]; [email-masked]
Subject: Re: [IPsec] Traffic visibility - consensus call

> sees is an encrypted ESP packet or an ESP packet carrying ESP-NULL 

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. 

From: 

________________________________________

Sriram

---

From: Russ Housley <[email-masked]>
Date: Wed, 06 Jan 2010 11:36:36 -0500

Jack:

The name sets incorrect expectations, but that is not on my list of 
concerns.

Russ

---

From: Stephen Kent <[email-masked]>
Date: Wed, 6 Jan 2010 11:43:46 -0500

At 9:45 AM +0530 1/6/10, Venkatesh Sriram wrote:
>I agree that WESP should not be clipped to only support ESP-NULL;

WESP was not initially proposed as a protocol that would encapsulate 
encrypted traffic, so the term "clipped" is approproprioate only 
relative to what WESP has mutated to become :-).

>it

This is a local policy decision that avoid the need to have a flag in 
the WESP header to indicate encrypted content.  It need not be a 
standards track action, as you suggest above.

>WESP also carry encrypted packets.

It certainly is not impossible as a local policy.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 6 Jan 2010 12:10:19 -0500

At 5:19 PM +0200 1/6/10, Yaron Sheffer 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:
>
>2. Depending on your view of whether we have the bit in question: 
>encrypted ESP from WESP-capable ("new") 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.

It's not clear why nodes sending encrypted traffic would need to use 
WESP (vs. native ESP), even if there is a WESP flag that indicates an 
encrypted payload. Thus I don't agree with the conclusion that over 
time there would be less ESP over all. If you said there would be 
less use of ESP-NULL (w/o a WES header), I would agree. To suggest 
otherwise is to pre-suppose that replacing ESP with WESP in general 
is a goal, and I certainly don't think the WG has indicated that (nor 
is it in scope at this time).

Steve

---

From: Brian Swander <[email-masked]>
Date: Wed, 6 Jan 2010 17:35:46 +0000

Take a look at the policy sketch I sent our yesterday for how to roll this out in a mixed mode environment.   That should clarify all your questions.

bs

From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott C Moonen
Sent: Wednesday, January 06, 2010 5:38 AM
To: Venkatesh Sriram
Cc: [email-masked]; [email-masked]
Subject: Re: [IPsec] Traffic visibility - consensus call

From:

To:

Date:

01/05/2010 11:16 PM

Subject:

________________________________

Sriram

---

From: Brian Swander <[email-masked]>
Date: Wed, 6 Jan 2010 17:42:23 +0000

The uplevel machines can't use ESP to send the encrypted traffic in this scenario.  Remember, that we need to look at the holistic scenario of how to deploy this in an environment where we have legacy machines that don't do WESP.  And we need to satisfy the goal of deterministic intermediary visibility.

Hence, the best method I see is what I describe below.  The non-WESP machines MUST do ESP-NULL to allow visibility.  That means uplevel machines cannot use ESP to send encrypted, since otherwise intermediaries would see both ESP-NULL, and ESP, and be forced back to heuristics.   Intermediaries would be configured (in this scenario) to assume that ESP always means ESP-NULL.

bs

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Wednesday, January 06, 2010 7:07 AM
To: Brian Swander
Cc: gabriel montenegro; Russ Housley; [email-masked]
Subject: Re: [IPsec] Traffic visibility - consensus call

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 6 Jan 2010 09:49:33 -0800

Not wearing any hat:

>Hence we need to keep the encrypted bit to satisfy the current WESP charter item.

That policy makes sense if you assume that WESP covers encrypted ESP. If WESP only covers unencrypted ESP, the policy would be:

When talking to/from non-WESP capable machines:  must do ESP-NULL only.
When both peers are WESP capable: do WESP/ESP-NULL.

This is exactly what was envisioned when the WG chartered the work item. That is, the presence of WESP does not affect policy about encryption.

--Paul Hoffman, Director
--VPN Consortium

---

From: Brian Swander <[email-masked]>
Date: Wed, 6 Jan 2010 17:56:47 +0000

But that doesn't give us any path to actually do encryption (in environments with legacy systems) - hence the proposal is untenable. 

I'd argue it therefore doesn't satisfy the charter item.   The charter item is a deployable mechanism that lets intermediaries inspect ESP-NULL when present.  This charter item surely shouldn't mandate that we can now no longer use encrypted ESP at all.

Clearly we need a solution that also lets us use encrypted traffic where needed, but not break inspection of integrity only traffic.  How do we meet that with your proposal below?

We must make sure that we have a solution that is deployable and useful in the real world.

bs

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Wednesday, January 06, 2010 9:50 AM
To: Brian Swander; gabriel montenegro; Russ Housley
Cc: [email-masked]
Subject: Re: [IPsec] Traffic visibility - consensus call

Not wearing any hat:

--Paul Hoffman, Director
--VPN Consortium

---

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

On Wed, Jan 6, 2010 at 8:49 PM, Yaron Sheffer <[email-masked]> wrote:
> 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.
>

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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 6 Jan 2010 10:21:05 -0800

No hat.

>But that doesn't give us any path to actually do encryption (in environments with legacy systems) - hence the proposal is untenable.

That doesn't make sense: it is *exactly* the same path as we have today. WESP-as-envisioned gives us one extra capability; WESP-as-it-is-today gives us two. The "path to actually do encryption (in environments with legacy systems)" is to use ESP exactly as it is being done today by dozens of vendors, including you.

>I'd argue it therefore doesn't satisfy the charter item.   The charter item is a deployable mechanism that lets intermediaries inspect ESP-NULL when present.  This charter item surely shouldn't mand…

Please don't reduce this to absurd straw men. The charter item is quite clear:

A standards-track mechanism that allows an intermediary device, such
as a firewall or intrusion detection system, to easily and reliably
determine whether an ESP packet is encrypted with the NULL cipher; and
if it is, determine the location of the actual payload data inside the
packet.

WESP-over-ESP-NULL-only fulfills that charter item. WESP-as-it-is-today does it as well, but adds additional features and extensibility. The question in this thread is whether to back down to WESP-over-ESP-NULL-only.

>Clearly we need a solution that also lets us use encrypted traffic where needed, but not break inspection of integrity only traffic.  How do we meet that with your proposal below?

As it is done today, and adding in WESP-over-ESP-NULL-only.

>We must make sure that we have a solution that is deployable and useful in the real world.

Really, you think so? :-)

--Paul Hoffman, Director
--VPN Consortium

---

From: Stephen Kent <[email-masked]>
Date: Wed, 6 Jan 2010 13:37:05 -0500

At 5:42 PM +0000 1/6/10, Brian Swander wrote:
>The uplevel machines can't use ESP to send the encrypted traffic in 
>this scenario.  Remember, that we need to look at the holistic 
>scenario of how to deploy this in an environment where we have 
>legacy machines that don't do WESP.  And we need to satisfy the goal 
>of deterministic intermediary visibility.
>
>Hence, the best method I see is what I describe below.  The non-WESP 
>machines MUST do ESP-NULL to allow visibility.  That means uplevel 
>machines cannot use ESP to send encrypted, since otherwise 
>intermediaries would see both ESP-NULL, and ESP, and be forced back 
>to heuristics.   Intermediaries would be configured (in this 
>scenario) to assume that ESP always means ESP-NULL.
>
>bs

Sorry, Brian, I still don't understand the scenario.  Let's see if a 
detailed analysis can help.

In a mixed environment, there are two classes of machines: 
WESP-capable and not.  That yields 3 types of connections, and 6 
types of flows.  Let's label end systems (nodes) as W (for 
WESP-capable) and N (for not WESP-capable), and label traffic as I 
(integrity protected, but not encrypted) and E (for encrypted). 
Finally, label the protocols as W (WESP), W* (WESP with the encrypted 
content flag set), EE (ESP-encrypted) and EN (ESP-NULL).  The 
following table shows the flows and protocols that could result in 2 
scenarios: Scenario 1 is WESP as originally proposed and Scenario 2 
is with super-WESP.

Case	Nodes	Flow	S 1	S 2
1	N-N	I	EN	EN
2	N-N	E	EE	EE
3	W-W	I	W	W
4	W-W	E	EE	W*
5	W-N	I	EN	EN
6	W-N	E	EE	EE

The only place W* can be used is in case 4 (in Scenario 2), where 
both nodes are WESP-capable and the traffic is encrypted. But, in 
both scenarios, an intermediate device will encounter ESP traffic 
that may or may not be encrypted, in cases 1, 2, 5, and 6. So, it 
appears to me that the intermediate device needs to use heuristics 
until there are NO non-WESP nodes. At that time, we are dealing only 
with cases 3 & 4. But, in either scenario, these two cases present an 
intermediate device with unambiguous info for deciding whether a 
packet can be inspected.

This analysis suggests that there is no need for the flag when all 
nodes are WESP-capable, and no benefit when there are a mix of 
WESP-capable and legacy nodes.

Steve

---

From: Dan McDonald <[email-masked]>
Date: Wed, 6 Jan 2010 13:44:45 -0500

<SNIP!>

> intermediary inspection of ESP-NULL non-heurisitically.  Organization has a
> mix of version of systems.

At this point I need more details.  Specifically, why does an organization
need to inspect ESP-NULL packets?  I can think of two good reasons off the
top of my head:

	* To appropriately schedule or forward a packet according to latency,
          or any other number of diffserv properties.

	- Deep-packet inspection for content or other beyond-the-headers
          processing.

I've marked the first item with *, and the second with -.

Items marked with * merely requires flow classification.  In IPv6 we have a
flow id already, and there are rumblings of a hop-by-hop IPv4 option to do
the same thing here:

	http://tools.ietf.org/html/draft-dreibholz-ipv4-flowlabel-11

(Heck, it's even 20 bits!)

Items marked with - require that the payload be in the clear, or (by some
miracle) the inspecting entity has the cryptographic keys.

Items marked with * can use flow labels.  Yes it's a host software change,
but quite frankly so is WESP.  WESP doesn't do anything in this case an
alternate mechanism cannot do.

Items marked with - will benefit greatly from WESP IF (and only if) you
believe heuristics to be untenable, but encrypted WESP support won't help
here at all.  Furthemore, a working flow label deployment and flow labelling
policy could make what were heuristics into completely deterministic
processing.

There's vague talk about deployability and future directions.  Please show me
some concrete examples supporting WESP with encrypted packet support.  I
suspect such examples will most likely either require the whole packet text
(i.e. marked with -) or just enough data to identify a flow (i.e. marked with
*).

Thanks,
Dan

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 6 Jan 2010 10:48:31 -0800 (PST)

Hi,

  No and no.

  I'm a little alarmed at the assumption by some that ESP would be
deprecated (albeit "not for a long time"). AH does not really solve
the problem supposedly solved by WESP because it doesn't work through
a NAT. So if we're going to have a new protocol that needs to be
implemented by end points why not just make a NAT-friendly version
of AH and forget the whole idea of "wrapping" ESP packets. That would
be architecturally cleaner, in my opinion. If you want to provide
traffic visibility then negotiate <new protocol> for the traffic that
is being protected, if you don't then negotiate ESP. And if ESP-NULL
poses a problem for you then prohibit it by policy.

  Dan.

On Mon, January 4, 2010 2:27 pm, Yaron Sheffer wrote:
> 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

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 6 Jan 2010 20:56:38 +0200

Hi Steve,

Please reread my text. I was (in that paragraph) taking Manav's side, i.e. assuming there's value in deterministic distinction between encrypted and unencrypted ESP, and hence, gradually moving the endpoints to WESP so that middleboxes have an easier time.

As we know, this opinion is not shared by everyone.

Thanks,
	Yaron

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Wednesday, January 06, 2010 19:10
To: Yaron Sheffer
Cc: Scott C Moonen; Venkatesh Sriram; [email-masked]; [email-masked]
Subject: Re: [IPsec] Traffic visibility - consensus call

Steve

Scanned by Check Point Total Security Gateway.

---

From: Scott C Moonen <[email-masked]>
Date: Wed, 6 Jan 2010 14:00:12 -0500

Brian, the middle box could never "assume that ESP always means ESP-NULL" 
because the down-level nodes (as well as any up-level node talking to 
them) will use ESP for encrypted traffic as well.

Moreover, this is a soft sort of begging the question because it is 
assuming that WESP will be widely adopted in order to argue for it to be 
even more widely used.  I remain unconvinced of that assumption, and I am 
definitely unconvinced that there is zero cost to happily assuming the 
up-level nodes can always and freely use WESP for encrypted traffic.  All 
this does nothing to encourage those down-level nodes to get with the WESP 
program, and I think that is your real challenge.  Again, I'm not saying 
that there is no conceivable value to encrypted WESP, just that if this is 
your concern then encrypted WESP is not the answer.

Finally, if WESP really is going to be that widely used, then we really 
need to scrap it and talk about whether there is warrant to do a real 
ESPv4 instead of backdooring it like this.  WESP is not a suitable ESPv4. 
And if WESP is going to be that quickly and widely adopted then there 
should be no trouble getting consensus to do ESPv4.  ;)

From:
Brian Swander <[email-masked]>
To:
Stephen Kent <[email-masked]>
Cc:
"[email-masked]" <[email-masked]>, Russ Housley <[email-masked]>, 
gabriel montenegro <[email-masked]>
Date:
01/06/2010 12:42 PM
Subject:
Re: [IPsec] Traffic visibility - consensus call

The uplevel machines can't use ESP to send the encrypted traffic in this 
scenario.  Remember, that we need to look at the holistic scenario of how 
to deploy this in an environment where we have legacy machines that don't 
do WESP.  And we need to satisfy the goal of deterministic intermediary 
visibility.

Hence, the best method I see is what I describe below.  The non-WESP 
machines MUST do ESP-NULL to allow visibility.  That means uplevel 
machines cannot use ESP to send encrypted, since otherwise intermediaries 
would see both ESP-NULL, and ESP, and be forced back to heuristics. 
Intermediaries would be configured (in this scenario) to assume that ESP 
always means ESP-NULL.

bs

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Wednesday, January 06, 2010 7:07 AM
To: Brian Swander
Cc: gabriel montenegro; Russ Housley; [email-masked]
Subject: Re: [IPsec] Traffic visibility - consensus call

Steve

---

From: Brian Swander <[email-masked]>
Date: Wed, 6 Jan 2010 19:06:42 +0000

Remember, the goal isn't necessarily to provide the full cross product of all possible permutations, which is what you've done.  The goal is to satisfy the customer scenarios.   Only if the customer really needs all the cross product permutations, do they come into play.

My argument is that a very good deployment strategy that will meet many customer scenarios is precisely to prune your matrix to make things deterministic to the intermediaries.

In terms of your chart, that means that the only allowed combinations (of this scenario) are:

Case    Nodes   Flow    S 1     S 2
1       N-N     I       EN      EN
3     W-W     I       W       W
4      W-W     E       EE      W*
5     W-N     I       EN      EN

Hence any (legitimate) ESP traffic that the intermediary sees must be ESP-NULL, and the encypt flag is critical, as it is the mechanism to enable encryption between uplevel machines.

The main point of WESP is to remove heuristics from intermediary processing.    Hence we need to focus on the scenarios that actually allow us to do that, and enable as many of them as possible.

bs

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Wednesday, January 06, 2010 10:37 AM
To: Brian Swander
Cc: [email-masked]; Russ Housley; gabriel montenegro
Subject: Re: [IPsec] Traffic visibility - consensus call

bs

Sorry, Brian, I still don't understand the scenario.  Let's see if a detailed analysis can help.

In a mixed environment, there are two classes of machines: WESP-capable and not.  That yields 3 types of connections, and 6 types of flows.  Let's label end systems (nodes) as W (for WESP-capable) and N (for not WESP-capable), and label traffic as I (integrity protected, but not encrypted) and E (for encrypted). Finally, label the protocols as W (WESP), W* (WESP with the encrypted content flag set), EE (ESP-encrypted) and EN (ESP-NULL).  The following table shows the flows and protocols that could result in 2 scenarios: Scenario 1 is WESP as originally proposed and Scenario 2 is with super-WESP.

Case    Nodes   Flow    S 1     S 2
1       N-N     I       EN      EN
2     N-N     E       EE      EE
3     W-W     I       W       W
4      W-W     E       EE      W*
5     W-N     I       EN      EN
6       W-N     E       EE      EE

The only place W* can be used is in case 4 (in Scenario 2), where both nodes are WESP-capable and the traffic is encrypted. But, in both scenarios, an intermediate device will encounter ESP traffic that may or may not be encrypted, in cases 1, 2, 5, and 6. So, it appears to me that the intermediate device needs to use heuristics until there are NO non-WESP nodes. At that time, we are dealing only with cases 3 & 4. But, in either scenario, these two cases present an intermediate device with unambiguous info for deciding whether a packet can be inspected.

This analysis suggests that there is no need for the flag when all nodes are WESP-capable, and no benefit when there are a mix of WESP-capable and legacy nodes.

Steve

---

From: Brian Swander <[email-masked]>
Date: Wed, 6 Jan 2010 19:08:00 +0000

See my response to Stephen Kent, and let me know if that doesn't clarify adequately.

bs

From: Scott C Moonen [mailto:[email-masked]]
Sent: Wednesday, January 06, 2010 11:00 AM
To: Brian Swander
Cc: gabriel montenegro; Russ Housley; [email-masked]; [email-masked]; Stephen Kent
Subject: Re: [IPsec] Traffic visibility - consensus call

Brian, the middle box could never "assume that ESP always means ESP-NULL" because the down-level nodes (as well as any up-level node talking to them) will use ESP for encrypted traffic as well.

Moreover, this is a soft sort of begging the question because it is assuming that WESP will be widely adopted in order to argue for it to be even more widely used.  I remain unconvinced of that assumption, and I am definitely unconvinced that there is zero cost to happily assuming the up-level nodes can always and freely use WESP for encrypted traffic.  All this does nothing to encourage those down-level nodes to get with the WESP program, and I think that is your real challenge.  Again, I'm not saying that there is no conceivable value to encrypted WESP, just that if this is your concern then encrypted WESP is not the answer.

Finally, if WESP really is going to be that widely used, then we really need to scrap it and talk about whether there is warrant to do a real ESPv4 instead of backdooring it like this.  WESP is not a suitable ESPv4.  And if WESP is going to be that quickly and widely adopted then there should be no trouble getting consensus to do ESPv4.  ;)

From:

To:

Cc:

"[email-masked]" <[email-masked]>, Russ Housley <[email-masked]>, gabriel montenegro <[email-masked]>

Date:

01/06/2010 12:42 PM

Subject:

bs

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Wednesday, January 06, 2010 7:07 AM
To: Brian Swander
Cc: gabriel montenegro; Russ Housley; [email-masked]
Subject: Re: [IPsec] Traffic visibility - consensus call

Steve

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 6 Jan 2010 21:21:22 +0200

Hi Brian,

[no hat on]

I think your reasoning about the different scenarios actually demonstrates that "super-WESP" is useful. But I have to strongly disagree with the statement below. Yes we should support all possible permutations. There's no reason why WESP should suddenly cause traffic that used to require encryption to not require it any more.

So I would put it differently: the WESP encrypt flag is what enables intermediaries to be implemented *efficiently* in a mixed environment, with old and new endpoints, encrypted and integrity-protected traffic.

Thanks,
                Yaron

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Swander
Sent: Wednesday, January 06, 2010 21:07
To: Stephen Kent
Cc: [email-masked]; Russ Housley; gabriel montenegro
Subject: Re: [IPsec] Traffic visibility - consensus call

Case    Nodes   Flow    S 1     S 2
1       N-N     I       EN      EN
3     W-W     I       W       W
4      W-W     E       EE      W*
5     W-N     I       EN      EN

bs

bs

Case    Nodes   Flow    S 1     S 2
1       N-N     I       EN      EN
2     N-N     E       EE      EE
3     W-W     I       W       W
4      W-W     E       EE      W*
5     W-N     I       EN      EN
6       W-N     E       EE      EE

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 6 Jan 2010 14:27:55 -0500

At 8:56 PM +0200 1/6/10, Yaron Sheffer wrote:
>Hi Steve,
>
>Please reread my text. I was (in that paragraph) taking Manav's 
>side, i.e. assuming there's value in deterministic distinction 
>between encrypted and unencrypted ESP, and hence, gradually moving 
>the endpoints to WESP so that middleboxes have an easier time.
>

Yaron,

Sorry. I missed that element of the context that you were assuming.

Nonetheless, the analysis I just sent in response to Brian's message 
suggests that determinism is not possible if we consider the general 
case of WESP-capable and legacy devices and a mix of encrypted and 
integrity-only flows.  That motivated my response. That analysis is 
not an opinion :-). But, in fairness, I had not yet generated the 
analysis when I sent my message, so ...

Steve

---

From: Brian Swander <[email-masked]>
Date: Wed, 6 Jan 2010 19:28:18 +0000

I'd like to understand your policies for deploying your proposal below that meets the charter item.

Here are the customer scenario requirements:
Legacy systems that don't support WESP (lots of them)
Requirements to do encryption between some machines.  Willing to upgrade pockets of machines to accomplish this.
Routing infrastructure that doesn't do heuristics
Requires intermediaries that can do full ESP-NULL parsing.

bs

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: Wednesday, January 06, 2010 10:21 AM
To: Brian Swander; gabriel montenegro; Russ Housley
Cc: [email-masked]
Subject: RE: [IPsec] Traffic visibility - consensus call

No hat.

--Paul Hoffman, Director
--VPN Consortium

---

From: Brian Swander <[email-masked]>
Date: Wed, 6 Jan 2010 19:33:53 +0000

I never meant to imply WESP would reduce encryption requirements.   If the customer traffic has to be encrypted, then it will be or the scenario isn't satisfied.    In the below, to meet that customer requirement, the customer would need to upgrade the machines that require encryption to the latest version (in this proposal).  However, all the other machines can remain untouched.

Yes we need to support all possible permutations in the product.  I was talking about a specific scenario.   If intermediaries have good heuristic support, etc, then more permutations open up.   But we can't assume intermediaries must implement heuristics.

bs

From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaron Sheffer
Sent: Wednesday, January 06, 2010 11:21 AM
To: Brian Swander; Stephen Kent
Cc: [email-masked]; Russ Housley; gabriel montenegro
Subject: Re: [IPsec] Traffic visibility - consensus call

Hi Brian,

[no hat on]

Thanks,
                Yaron

Case    Nodes   Flow    S 1     S 2
1       N-N     I       EN      EN
3     W-W     I       W       W
4      W-W     E       EE      W*
5     W-N     I       EN      EN

bs

bs

Case    Nodes   Flow    S 1     S 2
1       N-N     I       EN      EN
2     N-N     E       EE      EE
3     W-W     I       W       W
4      W-W     E       EE      W*
5     W-N     I       EN      EN
6       W-N     E       EE      EE

Steve

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 6 Jan 2010 21:34:19 +0200

Hi Steve,

[No hat.]

Thanks for the analysis, I hope this'll help the discussion to converge.

You are taking an either-or approach in the last paragraph below. But assuming that WESP is useful (bear with me...), there will be a gradual deployment within any given network. I agree that heuristics will still be needed, until the last endpoint is WESP-enabled (i.e., forever). But if we adopt W*, during the migration less and less heuristic processing will be needed. Much of this discussion is about performance, so quantitative arguments are also useful.

Thanks,
                Yaron

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Wednesday, January 06, 2010 20:37
To: Brian Swander
Cc: [email-masked]; Russ Housley; gabriel montenegro
Subject: Re: [IPsec] Traffic visibility - consensus call

bs

Case    Nodes   Flow    S 1     S 2
1       N-N     I       EN      EN
2     N-N     E       EE      EE
3     W-W     I       W       W
4      W-W     E       EE      W*
5     W-N     I       EN      EN
6       W-N     E       EE      EE

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 6 Jan 2010 14:45:14 -0500

At 7:06 PM +0000 1/6/10, Brian Swander wrote:
>Remember, the goal isn't necessarily to provide the full cross 
>product of all possible permutations, which is what you've done. 
>The goal is to satisfy the customer scenarios.   Only if the 
>customer really needs all the cross product permutations, do they 
>come into play.

I don't recall the WG having agreed upon a subset of cases that were 
deemed to be the only ones of interest. But, I admit to having missed 
some details of WESP as it evolved too, so maybe I missed this too. 
Can you refresh my memory on this point?

>  My argument is that a very good deployment strategy that will meet 
>many customer scenarios is precisely to prune your matrix to make 
>things deterministic to the intermediaries.

This seems a lot like saying that we can convince customers that they 
need only a subset of the possible cases because these are the ones 
that we can address well!

>combinations (of this scenario) are:

I don't understand how one arrives at this subset. Why are legacy 
nodes prohibited form sending encrypted traffic in this context? Is 
the idea that this limitation will motivate deployment of 
WESP-enabled nodes? I don't think the rationale here has been clearly 
articulated.

>  Hence any (legitimate) ESP traffic that the intermediary sees must 
>be ESP-NULL, and the encypt flag is critical, as it is the mechanism 
>to enable encryption between uplevel machines.

This seems to relate to my questions above.

>The main point of WESP is to remove heuristics from intermediary 
>processing.   Hence we need to focus on the scenarios that actually 
>allow us to do that, and enable as many of them as possible.

I don't think it is reasonable to consider only those cases where the 
encrypted content flag will make things better, unless we have a very 
good, and agreed-upon, rationale for discarding the other cases.

Steve

---

From: "Grewal, Ken" <[email-masked]>
Date: Wed, 6 Jan 2010 12:48:20 -0700

Steve, 
The either-or on using an ICV or explicitly checking the WESP header on the recipient was based on the assumption that the threat does not come from the sender and only from some other malicious entity after the packet has been sent. 
This was the reason for simplifying the header check by using the ICV, instead of explicitly checking every field. 

If the sender is malicious, then an encrypted (covert) channel is all that is needed to bypass any intermediate checking and furthermore, any explicit checking of each WESP field on the recipient does not help, as the payload can contain whatever is intended by the malicious sender!

We did debate this a number of times and extending the integrity appears as early as May of last year in version 3 of the draft (at version 12 now), so it should not have been a surprise at last call. 

In either case, as Gabriel indicates in a separate email, if it makes sense to go back to not integrity protecting the WESP header, I am fine with that. This was the original position and aligns with your other email on WESP acting as a wrapper to ESP, and should also address other comments indicating that the name Wrapped ESP is a misnomer! 

Thanks, 
- Ken

>Sent: Wednesday, January 06, 2010 6:28 AM
>To: Grewal, Ken
>Cc: Yaron Sheffer; [email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 6 Jan 2010 21:54:27 +0200

Hi Brian,

[No hat]

If your intermediary is something like a load balancer, and you don't care that some portion of your traffic is not balanced well, then fine - you don't need heuristics.

But if the intermediary is a security device, then I would only buy one that implemented heuristics, even if only on the "slow path". An intermediary shouldn't rely on the entire network being tuned to its needs.

Thanks,
                Yaron

From: Brian Swander [mailto:[email-masked]]
Sent: Wednesday, January 06, 2010 21:34
To: Yaron Sheffer; Stephen Kent
Cc: [email-masked]; Russ Housley; gabriel montenegro
Subject: RE: [IPsec] Traffic visibility - consensus call

bs

Hi Brian,

[no hat on]

Thanks,
                Yaron

Case    Nodes   Flow    S 1     S 2
1       N-N     I       EN      EN
3     W-W     I       W       W
4      W-W     E       EE      W*
5     W-N     I       EN      EN

bs

bs

Case    Nodes   Flow    S 1     S 2
1       N-N     I       EN      EN
2     N-N     E       EE      EE
3     W-W     I       W       W
4      W-W     E       EE      W*
5     W-N     I       EN      EN
6       W-N     E       EE      EE

Steve

---

From: Brian Swander <[email-masked]>
Date: Wed, 6 Jan 2010 19:55:45 +0000

I trust my clarification (to Yaron) addressed these questions.  Let me know if there are any outstanding.

bs

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Wednesday, January 06, 2010 11:45 AM
To: Brian Swander
Cc: [email-masked]; Russ Housley; gabriel montenegro
Subject: Re: [IPsec] Traffic visibility - consensus call

I don't recall the WG having agreed upon a subset of cases that were deemed to be the only ones of interest. But, I admit to having missed some details of WESP as it evolved too, so maybe I missed this too. Can you refresh my memory on this point?

This seems a lot like saying that we can convince customers that they need only a subset of the possible cases because these are the ones that we can address well!

Case    Nodes   Flow    S 1     S 2
1       N-N     I       EN      EN
3     W-W     I       W       W
4      W-W     E       EE      W*
5     W-N     I       EN      EN

I don't understand how one arrives at this subset. Why are legacy nodes prohibited form sending encrypted traffic in this context? Is the idea that this limitation will motivate deployment of WESP-enabled nodes? I don't think the rationale here has been clearly articulated.

I don't think it is reasonable to consider only those cases where the encrypted content flag will make things better, unless we have a very good, and agreed-upon, rationale for discarding the other cases.

Steve

---

From: Brian Swander <[email-masked]>
Date: Wed, 6 Jan 2010 20:02:52 +0000

That's a cost/benefit business decision for the intermediary.    Some intermediaries may welcome the option to not support heuristics at all.  They'll need to do the market research, etc on the various scenarios.

But it is my goal to understand exactly what scenarios require heuristics, and enable as many as possible that don't require them.   We've had overwhelming support on the list here from intermediary vendors saying heuristics are hard/bad etc.   (Note, I'm not maligning heuristics.  If they are present in the infrastructure, then ideally the scenarios can leverage them, too).

bs

Sent: Wednesday, January 06, 2010 11:54 AM

Hi Brian,

[No hat]

Thanks,
                Yaron

bs

Hi Brian,

[no hat on]

Thanks,
                Yaron

Case    Nodes   Flow    S 1     S 2
1       N-N     I       EN      EN
3     W-W     I       W       W
4      W-W     E       EE      W*
5     W-N     I       EN      EN

bs

bs

Case    Nodes   Flow    S 1     S 2
1       N-N     I       EN      EN
2     N-N     E       EE      EE
3     W-W     I       W       W
4      W-W     E       EE      W*
5     W-N     I       EN      EN
6       W-N     E       EE      EE

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 6 Jan 2010 15:19:04 -0500

At 9:34 PM +0200 1/6/10, Yaron Sheffer wrote:
>You are taking an either-or approach in the last 
>paragraph below. But assuming that WESP is 
>useful (bear with meŠ), there will be a gradual 
>deployment within any given network. I agree 
>that heuristics will still be needed, until the 
>last endpoint is WESP-enabled (i.e., forever). 
>But if we adopt W*, during the migration less 
>and less heuristic processing will be needed. 
>Much of this discussion is about performance, so 
>quantitative arguments are also useful.
>
>Thanks,
>                 Yaron
>

Yaron,

So, is the argument that use of W* would reduce 
the quantity of traffic that requires heuristic 
processing at some stages in the deployment 
process, because as the number of WESP-capable 
nodes increases, cases 3 & 4 predominate? if this 
is the argument, why did it take this long to get 
a clear articulation of the argument (and why was 
I the one who had to do the analysis to support 
it :-))?

That argument makes sense, but only in the 
context of other assumptions about deployment 
(which have yet to be articulated).

For example, if an enterprise deploys an 
intermediate system that can perform packet 
inspection on IPsec traffic before most of the 
nodes are WESP-capable, then that system will 
have to use heuristics to deal with the vast 
majority of traffic initially. Such a system 
could continue to use those heuristics until 
WESP-deployment is complete. So that scenario 
does not motivate use of W*.

However, if the traffic load grows a lot during 
deployment, it might exceed the capacity of the 
intermediate system before WESP deployment was 
complete. In that case use of W* would help, if 
encrypted traffic were a lot more common than 
integrity-protected traffic.

Or, one might argue that use of W* would allow 
deployment of an intermediate system that uses 
WESP, but still incorporates heuristic support, 
at an earlier stage in WESP-deployment, though 
not initially. Of course the (earlier) point at 
which such deployment could take place is very 
context-specific.

These could be reasonable arguments, but I've not 
seen them articulated clearly. Nor have I seen 
any rough estimates of ratios of traffic types 
and the processing burden of heuristics to 
provide some quantitative basis for arguments of 
this sort.  So, I think the WG needs to do more 
homework on this if we're going to make such 
arguments.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 6 Jan 2010 15:40:07 -0500

At 12:48 PM -0700 1/6/10, Grewal, Ken wrote:
>Steve,
>The either-or on using an ICV or explicitly checking the WESP header 
>on the recipient was based on the assumption that the threat does 
>not come from the sender and only from some other malicious entity 
>after the packet has been sent.
>This was the reason for simplifying the header check by using the 
>ICV, instead of explicitly checking every field.

You cited my comments about a vulnerability as the rationale for 
pursuing this design. I noted that my comments did not specify the 
source of the mismatch between header data that IPsec acts upon (for 
access control) vs. what WESP caused an intermediate system to 
examine. You chose to focus on one possible source of manipulation, 
i.e., a MITM attack.  That's fine, but it does not necessitate 
changing the ESP ICV computation, i.e., checking by the recipient 
suffices. Also, the I-D calls for consistency checking, so I was 
(justifiably) confused by the either-or statement you made.

>If the sender is malicious, then an encrypted (covert) channel is 
>all that is needed to bypass any intermediate checking and 
>furthermore, any explicit checking of each WESP field on the 
>recipient does not help, as the payload can contain whatever is 
>intended by the malicious sender!

I see we have a miscommunication about the nature of the 
vulnerability that I cited. It is what I noted above, i.e., "a 
mismatch between header data that IPsec acts upon (for access 
control) vs. what WESP caused an intermediate system to examine." 
This is an old security concern, dating from the mid/late 1970s, when 
it was discovered that one could make a call to an OS with one set of 
parameters, and then change the parameters after an access control 
check was performed but before the OS acted upon the call. The fix 
for this sort of attavck was to copy the parameters into 
OS-controlled address space, out of user-space. An encrypted covert 
channel was not what motivated my comments,  because IPsec makes its 
access control decisions based on the 5-tuples from the IP and 
transport layer headers.

>We did debate this a number of times and extending the integrity 
>appears as early as May of last year in version 3 of the draft (at 
>version 12 now), so it should not have been a surprise at last call.

I have already apologized for not closely tracking the changes to 
WESP.  However, during IETF last call everyone is free to raise 
questions of this sort, so we ought not devote too much time and 
energy to this aspect of the discussion.

>In either case, as Gabriel indicates in a separate email, if it 
>makes sense to go back to not integrity protecting the WESP header, 
>I am fine with that. This was the original position and aligns with 
>your other email on WESP acting as a wrapper to ESP, and should also 
>address other comments indicating that the name Wrapped ESP is a 
>misnomer!

That works for me too, but I would feel better if we were all in 
agreement about the nature of the vulnerability that I cited, which 
motivated this in the first place.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 6 Jan 2010 16:01:21 -0500

>me know if there are any outstanding.

I understood the first two lines about lots of legacy systems, only a 
few of which need to perform encryption." The next two lines were too 
terse for me:

"Routing infrastructure that doesn't do heuristics
Requires intermediaries that can do full ESP-NULL parsing"

if the intermediaries are part of the routing infrastructure, why use 
different terms in these two lines?

Also within an enterprise context, one might well be able to 
configure the intermediaries with the addresses of the few machines 
that perform encryption, and which therefore are allowed to 
communicate with one another w/o benefit of packet inspection.

So I would not say that your response addresses my questions in the 
lager context.

Steve

---

From: "Paul Koning" <[email-masked]>
Date: Wed, 6 Jan 2010 16:43:06 -0500

I've been watching a long stream of messages about WESP flying by and I
must admit to being rather confused.  What follows is based on my best
understanding of what's going on, so please apply grains of salt as
needed. 

It's likely that I'm in the same corner as Tero. 

It sounds to me like WESP was chartered to do something very specific,
having to do with ESP-NULL and intermediate systems looking at traffic.
And now we have discussions about ESP-nonNULL with WESP, and maybe WESP
as an alternative to ESP, or a replacement to ESP.

How is this possible?  It's nice to talk about the benefits of greater
generality and all that, but it isn't proper to have a WG chartered to
do a narrow thing and then end up doing something much bigger.  

Why not?

Answer: the purpose of a charter is (a) to tell the WG what it should be
doing, (b) to tell observers whether the work of the WG is something
they need to track -- or do NOT need to track.

If a WG goes well outside its charter, that's not fair to those who
would have participated if the charter had said this, but ended up not
participating because the charter told them they did not need to.  From
what I understand from Tero's comments, that situation applies to him,
and I think it applies to me as well.

It may well be a good idea to expand or modify or generalize or replace
ESP, but if such a project is to be done, it should be done by a WG
chartered for that purpose, so that all interested parties are on notice
that this work is about to happen.

Meanwhile, as to the consensus call: if this is out of charter as it
appears to be, then, independent of its technical merit, my vote is NO.

	paul koning

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 06 Jan 2010 14:08:36 -0800

On Tue, 2010-01-05 at 00:27 +0200, Yaron Sheffer wrote:
> 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?

no.

> - 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?

no.

---

From: Brian Swander <[email-masked]>
Date: Wed, 6 Jan 2010 22:17:34 +0000

I trust that this is a question on the sample set of requirements for the scenario I sent to Paul.

I use infrastructure and intermediaries terms interchangeably.

The scenario I had in mind is:

No heuristic support from any network infrastructure.

Only limited number of legacy clients that require encryption, hence they are capable of upgrading.
Vast majority of legacy are ok with ESP-NULL.

Potentially many uplevel clients that require encryption.   As on the previous thread, we want to enable as many capabilities in the cross product matrix as possible.  Hence it is extremely desirable for uplevel to do encryption or integrity without forcing extra infrastructure config.   I.e. I'd assume that managing ip addresses on all uplevel machines that want to do encryption is prohibitive.

bs

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Wednesday, January 06, 2010 1:01 PM
To: Brian Swander
Cc: [email-masked]; Russ Housley; gabriel montenegro; Stephen Kent
Subject: RE: [IPsec] Traffic visibility - consensus call

Steve

---

From: "Grewal, Ken" <[email-masked]>
Date: Wed, 6 Jan 2010 15:42:09 -0700

Paul, 

<Firstly, Thanks for the blank slate to respond...way too many messages on this topic! :-)>

My 2 cents...

Some people have jumped to conclusions that because we want to differentiate between encrypted and non-encrypted traffic by explicitly signaling in the packet, that WESP is now a replacement for ESP.

THIS IS NOT THE CASE AND IT WAS NEVER THE INTENT! 

One item that may have led to this conclusion was the expanded ICV over WESP, but this was introduced as a mitigation for certain threats highlighted in the WG. Subsequent discussions have determined that it would be better to mitigate these treats in an alternative manner, so we can fall back to WESP being a wrapper for ESP, without the expanded ICV. Wrapped ESP provides a wrapper for ESP!

The other item for discussion is whether WESP needs to explicitly differentiate between the payload being encrypted or NULL - I think this is a valid point to discuss. 

Numerous threads have talked about policy based deployments, mixed mode environments, migration paths, using/not using heuristics, etc...

The bottom line is that in order for a network appliance (Trusted Intermediary) to offer critical network services (IDS/IPS/DPI/Access Control) in IPsec environments, it needs to know if a given IPsec packet is encrypted or not in a deterministic manner and this is within scope. 
WESP is offering this determination on a per packet basis. 

I think we all agree that the traffic patterns will not fall into one single category (NULL OR Encrypted) within an Enterprise environment. i.e. There will be some traffic that is encrypted and some using NULL encryption. 

Some argue that we should use WESP for NULL traffic, mandating ESP for encrypted traffic...AND ensure that ESP is NEVER used for NULL encryption within a given domain / environment. How does an intermediate device know that this policy is being enforced? What if ESP is still being used for ESP-NULL and encrypted traffic? If this is the case, we are back to where we were/are today - no way to tell if ESP payload is encrypted or not. 

Having the encrypted flag within WESP allows clear and explicit distinction that certain traffic is encrypted whereas other traffic is not. This preserves the network based services we rely on and also allows other access control policies to be enforced. E.g. I want to ensure that my finance data flowing in the network is encrypted and NOT using ESP-NULL. If I rely on ESP for encrypted data and it can still use NULL encryption, I cannot enforce such a policy from an access control tool.  

Bottom line is that having this 'encryption' flag in WESP provides the capability to deterministically provide and preserve critical network services in IPsec environments, as well as apply access control policies. Without it, we are back to half-baked solutions.

As others have quoted the charter, here it is again...

"A standards-track mechanism that allows an intermediary device, such
as a firewall or intrusion detection system, to easily and reliably
determine whether an ESP packet is encrypted with the NULL cipher; and
if it is, determine the location of the actual payload data inside the
packet."

If we say that WESP is ONLY used to carry ESP-NULL (and ESP is used to carry encrypted traffic, but based on the ESP spec and legacy, it may also carry ESP-NULL), then we have not completed what we set out to do, as we have failed to *reliably* determine if the ESP traffic is encrypted or not!

Again, WESP does not replace ESP. It offers what it set out to do - an easy and reliable way to tell if an IPsec packet has a NULL payload or if it is encrypted.

Thanks, 
- Ken

>Of Paul Koning
>Sent: Wednesday, January 06, 2010 1:43 PM
>To: Stephen Kent
>Cc: [email-masked]

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 6 Jan 2010 16:04:19 -0800 (PST)

Hi Ken,

  No one responded to my suggestion so I'll suggest it again below.

On Wed, January 6, 2010 2:42 pm, Grewal, Ken wrote:
[snip]
> The bottom line is that in order for a network appliance (Trusted
> Intermediary) to offer critical network services (IDS/IPS/DPI/Access
> Control) in IPsec environments, it needs to know if a given IPsec packet
> is encrypted or not in a deterministic manner and this is within scope.

  That is a clear definition of the problem: a TI must be able to
determine whether a given IPsec packet is encrypted or not.

[snip]
> Some argue that we should use WESP for NULL traffic, mandating ESP for
> encrypted traffic...AND ensure that ESP is NEVER used for NULL encryption
> within a given domain / environment. How does an intermediate device know
> that this policy is being enforced? What if ESP is still being used for
> ESP-NULL and encrypted traffic? If this is the case, we are back to where
> we were/are today - no way to tell if ESP payload is encrypted or not.

  The intermediate device knows this because it is under the same
policy domain as the endpoints that have agreed to do WESP. If he's not
in the same policy domain then he has no assurance that the endpoints
will do WESP anyway. Maybe they'll do ESP and maybe even use the NULL
cipher, so this box in the cloud is out-of-luck again and WESP doesn't
help. Unless, of course, WESP is really a trojan horse to deprecate ESP
and force everyone to use WESP always but you have said that's not the
case.

  So now my suggestion again. If you're going to specify a new protocol
and require endpoints to implement it then why not just make a new
IPsec protocol that is a NAT-friendly way of doing per-packet integrity
protection? Don't try to "wrap" ESP packets. That way the middlebox knows
that when it sees this new protocol that it is not encrypted and when it
sees ESP it knows it is encrypted (it knows that ESP is not using NULL
encryption because policy has disallowed that). We could even think about
deprecating ESP-NULL in favor of this new protocol. This would be an
architecturally cleaner way of solving the problem you clearly described
above. IKE can negotiate the new protocol, in transport- or tunnel-mode,
negotiate an algorithm to use to provide integrity protection, and
establish an authenticated and shared key to use with the algorithm. So
what's the problem with this suggestion?

  regards,

  Dan.

---

From: Joy Latten <[email-masked]>
Date: Wed, 06 Jan 2010 18:16:01 -0600

> Having the encrypted flag within WESP allows clear and explicit distinction that certain traffic is encrypted whereas other traffic is not. This preserves the network based services we rely on and…
Ok. Thanks, for the clarity. I had read the latest draft and had been
following the thread but wasn't clear on the justification of needing
the encryption flag in WESP.

So for my own understanding... the use of the "USE_WESP_MODE" for IKEv2
as indicated in the draft guarantees that WESP-capable nodes only use
ESP for encryption and WESP for ESP-NULL. My thinking is, the SA created
will somehow indicate this "USE-WESP-MODE" and thus guarantee that the
packets on the SA enforce this policy, right? However, this is on the
end node, not the intermediate device. And it is the intermediate device
we want to give the guarantee to... especially in a mixed-environment...
And the WESP header, with an encryption flag indicating encrypted or
not, supplies this guarantee to the device. Am I understanding this
correctly or missing something or not even in the ballpark?

If I have understood correctly, then in reference to Yaron's email, I

>>you support this design decision?

No. Go back to WESP as a wrapper for ESP.

>>you support this design decision?

Yes.

regards,
Joy

---

From: Jack Kohn <[email-masked]>
Date: Thu, 7 Jan 2010 06:12:05 +0530

>> we were/are today - no way to tell if ESP payload is encrypted or not.

Thats the whole idea of using WESP with encryption. During the initial
phase there will be less number of nodes supporting WESP, and the
majority would be using ESP-NULL. However, as time passes, more and
more nodes would move to WESP, because load
balancers/firewalls/inspection devices will work properly only with
WESP traffic. This would provide the end nodes with a motivation to
upgrade to WESP. I dont think heuristics have a place here. Manav had
sent an excellent detailed mail on the issues with heuristics and why
its not as easy to implement as the authors and its proponents claim.

Given that heuristics cannot be done, what alternative are we left
with for middle boxes to deterministically differentiate between the
two classes of traffic?

The vision, and its not shared by everyone, is that after some time we
will have lot of end nodes moving to WESP, as its only then that their
packets can get prioritized, load balanced, etc. All other
unrecognized traffic by the middle boxes will not follow the optimized
path.

> what's the problem with this suggestion?

How different is your new protocol from WESP? Would it work if we were
to call this new protocol XXXX instead of WESP.

The idea behind this design is that it requires only an incremental
implementation effort as its only a wrapper over an existing widely
deployed implementation. Once we do away with WESP inside ESP ICV
computation its really just a wrapper over ESP.

Jack

---

From: "Grewal, Ken" <[email-masked]>
Date: Wed, 6 Jan 2010 17:41:57 -0700

Hi Dan, 
I think the main motivation for using ESP and providing a wrapper was so we do not have to reinvent the wheel / redo all the work that has been done already.
Starting off from scratch on a new protocol would have meant a larger workload and this item was meant to be a simple wrapper to provide the desired functionality. 

I do recall that someone else had brought up modifying AH earlier also, but as ESP already provided everything we needed, including NAT-T support, and we had two existing I-Ds as a starting point, we selected this route. 

Thanks, 
- Ken

>Of Dan Harkins
>Sent: Wednesday, January 06, 2010 4:04 PM
>To: Grewal, Ken
>Cc: [email-masked]; Paul Koning; Stephen Kent

---

From: "Grewal, Ken" <[email-masked]>
Date: Wed, 6 Jan 2010 17:48:54 -0700

Joy, 
Yes, your understanding is correct - WESP with the encryption flag allows intermediaries to determine if the payload is encrypted or NULL-encrypted and act accordingly. 

Thanks, 
- Ken

>From: Joy Latten [mailto:[email-masked]]
>Sent: Wednesday, January 06, 2010 4:16 PM
>To: Grewal, Ken
>Cc: [email-masked]
>> Some people have jumped to conclusions that because we want to
>differentiate between encrypted and non-encrypted traffic by explicitly
>signaling in the packet, that WESP is now a replacement for ESP.
>>
>> One item that may have led to this conclusion was the expanded ICV
>over WESP, but this was introduced as a mitigation for certain threats
>highlighted in the WG. Subsequent discussions have determined that it
>would be better to mitigate these treats in an alternative manner, so we
>can fall back to WESP being a wrapper for ESP, without the expanded ICV.
>Wrapped ESP provides a wrapper for ESP!
>>
>> The other item for discussion is whether WESP needs to explicitly
>differentiate between the payload being encrypted or NULL - I think this
>is a valid point to discuss.
>>
>> Numerous threads have talked about policy based deployments, mixed
>mode environments, migration paths, using/not using heuristics, etc...
>>
>> I think we all agree that the traffic patterns will not fall into one
>single category (NULL OR Encrypted) within an Enterprise environment.
>i.e. There will be some traffic that is encrypted and some using NULL
>encryption.
>>
>encrypted traffic...AND ensure that ESP is NEVER used for NULL
>encryption within a given domain / environment. How does an intermediate
>device know that this policy is being enforced? What if ESP is still
>being used for ESP-NULL and encrypted traffic? If this is the case, we
>are back to where we were/are today - no way to tell if ESP payload is
>encrypted or not.
>>
>> Having the encrypted flag within WESP allows clear and explicit
>distinction that certain traffic is encrypted whereas other traffic is
>not. This preserves the network based services we rely on and also
>allows other access control policies to be enforced. E.g. I want to
>ensure that my finance data flowing in the network is encrypted and NOT
>using ESP-NULL. If I rely on ESP for encrypted data and it can still use
>NULL encryption, I cannot enforce such a policy from an access control
>tool.
>>
>> Bottom line is that having this 'encryption' flag in WESP provides the
>capability to deterministically provide and preserve critical network
>services in IPsec environments, as well as apply access control
>policies. Without it, we are back to half-baked solutions.
>>
>> If we say that WESP is ONLY used to carry ESP-NULL (and ESP is used to
>carry encrypted traffic, but based on the ESP spec and legacy, it may
>also carry ESP-NULL), then we have not completed what we set out to do,
>as we have failed to *reliably* determine if the ESP traffic is
>encrypted or not!
>>
>> Again, WESP does not replace ESP. It offers what it set out to do - an
>easy and reliable way to tell if an IPsec packet has a NULL payload or
>if it is encrypted.
>>
>> Thanks,
>> - Ken
>>
>>

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 6 Jan 2010 17:16:13 -0800 (PST)

Hi Jack,

  My suggestion in not just a semantic one. The protocol would be
different because it would not wrap an existing, ESP-encapsulated
packet. There would be no "additional attributes", no "next header"
duplication, no processing overhead to check whether data is the
same in two places, and none of the issues currently being discussed
here, like the encrypted data bit.

  It would be just like AH but NAT-friendly. It would be simple to
implement and more clean architecturally. You could probably even
cut-and-paste large portions of AH to make a draft too.

  I am somewhat sympathetic to your point about the implementation
effort but hacks always _appear_ easier than doing it right (which is
why they're done in the first place) and this seems alot like a hack.
Heck, if implementation simplicity is a concern you could probably
cut-and-paste large portions of your AH implementation to do this type
of a protocol and in that sense it might actually even be easier than
an ESP wrapper.

  Dan.

On Wed, January 6, 2010 4:42 pm, Jack Kohn wrote:
>>> encryption

---

From: Charlie Kaufman <[email-masked]>
Date: Thu, 7 Jan 2010 07:14:16 +0000

Oh sigh!! What is it about IPsec that makes people go down this same path every time:

1) Someone proposes an utterly simple and useful piece of functionality (in this case, some way to indicate where the encapsulated data begins in the case where ESP is carrying unencrypted data.
2) The proposal is a little more complex than we might have hoped because we have to deal with forward migration (in this case, we can't add a new field to the ESP header - it was not extensible in this way - so we have to invent some new alternate header or a wrapper for the existing one).
3) Hoards of people propose minor improvements in the form of extensibility "infection sites" where future stuff can be added in a way that (if we're lucky) won't cause as much migration pain in the future if some similar extension is needed in the future. (In this case, we might want more information than the offset to the beginning of the plaintext data. Let's add a variable length header extension whose content is specified later. Oh, and the decision to put the "next protocol" field at the end of the ESP format instead of the front in order to maintain someone's idea of alignment turns out to be trouble, so let's put a copy at the front. Oh, and some of those fields we might want to specify someday might be security sensitive so let's change the integrity check to cover them. Oh, and we might want those extra fields we might want to specify someday to be added even for encrypted packets, so let's make the functionality that got this whole ball rolling optional!)
4) The resulting protocol is complex and misunderstood, and as a result it is incorrectly implemented by enough high profile vendors that any future extensibility based on the unused options will break them and in practice have to be done in some new and more horrible way.

We're on step 3, debating whether to push on with something ugly or spend another year trying to make the thing simpler. Can anyone think of an example of where taking another year to make things simpler actually worked? And for those who think simplifying this will only slow it down by a few weeks, post the prediction to the list and I'll forward this note to you in a year and ask how things are going.

Responding to Yaron's questions:

[Yaron:] - 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?

[CWK: ] If and only if it causes the process to complete faster. If we're going to have the option to add new options later, it makes sense to be able to integrity protect them. But it might make this a little harder to implement for some vendors. Neither of these arguments is important; I'd vote for whatever makes the debate end sooner.

[Yaron: ] - 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?

[CWK: ] If and only if it causes the process to complete faster. If we're going to have the option to add new options later, it makes sense to be able to apply those options to encrypted flows. But it makes the check in a middle-box for whether there is plaintext data in the packet more complex and implementations more complex (neither by very much). Neither of these arguments is important; I'd vote for whatever makes the debate end sooner.

[CWK:] Unfortunately, I don't know what will make the debate end sooner. If history is any guide, neither decision will and we're just doomed.

[CWK:] PROVE ME WRONG!!  PLEASE!!

	--Charlie

---

From: Yoav Nir <[email-masked]>
Date: Thu, 7 Jan 2010 09:26:50 +0200

> Oh sigh!! What is it about IPsec that makes people go down this same path every time:

<snip/>

IPsec?

So I guess you haven't been following the TLS mailing list these past couple of months.

I don't think anyone's described a practical attack on WESP without extending the ICV protected data, but I'm afraid that if we don't extend it, someday somebody will, and then we'll really have a situation like they have, retrofitting "new ICV" into "old WESP", using "extensions" that many did not implement correctly.

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 7 Jan 2010 14:08:08 +0200

Hi Joy,

Sorry but this is not the case. Quoting your text below: "The use of the "USE_WESP_MODE" for IKEv2 as indicated in the draft guarantees that WESP-capable nodes only use ESP for encryption and WESP for ESP-NULL."

This is incorrect: proponents of the encryption flag would have the WESP-capable devices use WESP for *both* encrypted and ESP-null traffic.

And as you say, intermediaries would then be able to distinguish both kinds of traffic using the encryption flag in the WEPS header.

Thanks,
	Yaron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joy Latten
Sent: Thursday, January 07, 2010 2:16
To: Grewal, Ken
Cc: [email-masked]
Subject: Re: [IPsec] Traffic visibility - consensus call

Yes.

regards,
Joy

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 7 Jan 2010 14:19:42 +0200

Hi Dan,

There are multiple good ways to indicate ESP-null traffic. We just chose one option.

But (assuming you strongly dislike heuristics, which some of us do) the big question is how to indicate *encrypted* ESP. Deprecating ESP-null is a non-starter: it is "changing ESP" just like changing the header format, and even more so, because it is a practically invisible change.

Thanks,
	Yaron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan Harkins
Sent: Thursday, January 07, 2010 2:04
To: Grewal, Ken
Cc: [email-masked]; Paul Koning; Stephen Kent
Subject: Re: [IPsec] Traffic visibility - consensus call

  Hi Ken,

[snip]

  regards,

  Dan.

---

From: Daniel Migault <[email-masked]>
Date: Thu, 7 Jan 2010 17:00:01 +0100

Hi,

> longer a simple wrapper around ESP - ESP itself is modified. Do you support

Motivations for including the WESP header in the ICV calculation were to
counter WESP header modifications. An alternative is to explicitly check
WESP header fields. On my opinion both are fine. Checking WESP's header
values makes WESP to be a Wrapper that do not change ESP. If this design
issue makes implementation easier, that's even better. I may not understand
all discussions on transition from ESP to WESP, and still consider WESP and
ESP as two distinct protocols designed for different purposes.  So my answer
is YES I support this design decision.

> But arguably, it positions WESP as an alternative to ESP. Do you support

As mentioned above WESP and ESP have been designed for two different
purposes. ESP has been designed for end-to-end communications, WESP is based
on ESP but has been designed to provide traffic visibility to middle boxes.
One scenario considers bypassing ESP_NULL traffic and discarding -or having
different policies -- for encrypted and/or unspecified traffic. This means
that targeted traffic is ESP_NULL. Traffic management may also target
NON_NULL_ESP traffic. If a node has multiple interfaces it can choose to
forward NON_NULL_ESP traffic on a non-protected network, and has different
policies for the rest of the traffic.
We (Orange) do request, for traffic management purpose, that flows can
explicitly specify whether they are encrypted or not-encrypted. The WESP
header seems to me the proper place for that specification.
We are not considering WESP as ESPv4, but we think that WESP (resp. ESP)
will be used because WESP (resp. ESP) traffic will have better QoS then ESP.
This will mainly depend on security and traffic management policies.
So here again my answer is YES I support this design decision.

Regards,
Daniel

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Stephen Kent <[email-masked]>
Date: Thu, 7 Jan 2010 11:10:12 -0500

At 10:17 PM +0000 1/6/10, Brian Swander wrote:
>Potentially many uplevel clients that require encryption.   As on 
>the previous thread, we want to enable as many capabilities in the 
>cross product matrix as possible.  Hence it is extremely desirable 
>for uplevel to do encryption or integrity without forcing extra 
>infrastructure config.
>
>  I.e. I'd assume that managing ip addresses on all uplevel machines 
>that want to do encryption is prohibitive.

Color me confused.

It appears that the high level policy is:

	- pairs of "uplevel" (WESP-capable) machines are allowed to 
send data via encrypted SAs, and thus bypass the packet inspection 
that the intermediate systems would otherwise perform

	-  if either machine in a communicating pair is not "uplevel" 
then any SAs between them must be subject to inspection by the 
intermediate systems, and hence they are restricted to using ESP-NULL 
(or no IPsec at all).

What confuses me is how the intermediate systems will know which 
policy applies to any given traffic flow? If the intermediate systems 
have a list of IP addresses of the hosts that fall into the category 
of "allowed to encrypt traffic" that would work, but that approach 
relies on doing what you said would be prohibitive to manage. Even if 
one needs only to configure one of the addresses or authorized pairs, 
that is the same as what would be needed in my proposal, and thus is 
also viewed as too hard to manage. But what other means of informing 
the intermediate systems how to decide to treat these two different 
classes of traffic do you envision?

I hope that you're not suggesting that the answer is to rely on each 
node to behave properly and to use only the type of SA for which it 
is authorized. If we had sufficient confidence in these nodes to do 
that, we probably wouldn't need intermediate systems to perform 
packet inspection, right?

Steve

---

From: "Grewal, Ken" <[email-masked]>
Date: Thu, 7 Jan 2010 10:09:34 -0700

Thanks for the clarification Yaron.
My answer was incomplete, as I had just picked up on the last statement.

Thanks, 
- Ken

>From: Yaron Sheffer [mailto:[email-masked]]
>Sent: Thursday, January 07, 2010 4:08 AM
>To: [email-masked]; Grewal, Ken
>Cc: [email-masked]
>Sorry but this is not the case. Quoting your text below: "The use of the
>"USE_WESP_MODE" for IKEv2 as indicated in the draft guarantees that
>WESP-capable nodes only use ESP for encryption and WESP for ESP-NULL."
>
>This is incorrect: proponents of the encryption flag would have the
>WESP-capable devices use WESP for *both* encrypted and ESP-null traffic.
>
>And as you say, intermediaries would then be able to distinguish both
>kinds of traffic using the encryption flag in the WEPS header.
>
>Thanks,
>	Yaron
>
>Of Joy Latten

---

From: Brian Swander <[email-masked]>
Date: Thu, 7 Jan 2010 17:13:51 +0000

In this scenario, the sum of functionality is greater than the parts - end hosts and intermediaries working together can achieve better overall security than either working in isolation and in complete distrust of the other.

It'll be up to the individual customer on where to dial the knobs, and we should enable the options and make them as deployable as possible.  I.e. if customers really want to manage full IP address policies for who can do encrypted ESP, than that option should be available.   If they want good intermediary audit trails with a simpler intermediary config, that option needs to be available.  If they want best effort load balancing/WAN optimization, that option needs to be available.

This is no longer an either-or adversarial situation between end systems and intermediaries, and the intermediaries in play are not relegated to security intermediaries - although clearly security intermediaries are important here, too.

bs

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Thursday, January 07, 2010 8:10 AM
To: Brian Swander
Cc: [email-masked]; Russ Housley; gabriel montenegro
Subject: Re: [IPsec] Traffic visibility - consensus call

Color me confused.

Steve

---

From: Brian Swander <[email-masked]>
Date: Thu, 7 Jan 2010 17:17:38 +0000

Slight rewording of the first sentence for more clarity:

In this scenario, the sum of functionality is greater than the parts - end hosts and intermediaries working together can better satisfy the customer's holistic deployment requirements (security, load balancing, auditing, etc) than either working in isolation and in complete distrust of the other.

-----Original Message-----
From: Brian Swander 
Sent: Thursday, January 07, 2010 9:14 AM
To: 'Stephen Kent'
Cc: [email-masked]; Russ Housley; gabriel montenegro
Subject: RE: [IPsec] Traffic visibility - consensus call

bs

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Thursday, January 07, 2010 8:10 AM
To: Brian Swander
Cc: [email-masked]; Russ Housley; gabriel montenegro
Subject: Re: [IPsec] Traffic visibility - consensus call

Color me confused.

Steve

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 7 Jan 2010 09:56:57 -0800 (PST)

Hi Yaron,

  Yes, one way was chosen but it has morphed into something much more
than simply indicating ESP-null traffic. What I'm suggesting is that if
the goal is simply a good way to indicate ESP-null traffic then doing
just that is possible with a NAT-friendly version of AH. It's much
cleaner than WESP.

  How do I indicate encrypted ESP? Well, as I mentioned, it is the only
traffic using ESP in the network for which traffic visibility is required.
The middleboxes looking into these packets must be in the same policy
domain as the end systems that are producing the protected traffic. That
being the case you just disallow ESP-null _by policy_ on that network.
Then any traffic on the network that is ESP is encrypted and the
protected-but-inspectable traffic is the NAT-friendly version of AH.
Voila! We can now distinguish between encrypted and non-encrypted traffic
and we can inspect traffic that is merely integrity protected.

  Dan.

P.S. ESP is a protocol which has the ability to use or not use any number
of ciphers. I don't think deprecating a cipher (even the NULL cipher) is
a "change" to ESP. It doesn't change the protocol the way changing a
header format or redefining ICV calculations changes the protocol. But
I'm not proposing deprecating ESP-null and that really has nothing to do
with the topic of a NAT-friendly version of AH as a solution to the
problem that WESP claims it is solving.

On Thu, January 7, 2010 4:19 am, Yaron Sheffer wrote:
> But (assuming you strongly dislike heuristics, which some of us do) the
> big question is how to indicate *encrypted* ESP. Deprecating ESP-null is a
> non-starter: it is "changing ESP" just like changing the header format,
> and even more so, because it is a practically invisible change.
>
> Thanks,
> 	Yaron
>

---

From: Stephen Kent <[email-masked]>
Date: Thu, 7 Jan 2010 14:09:01 -0500

At 5:13 PM +0000 1/7/10, Brian Swander wrote:
>In this scenario, the sum of functionality is 
>greater than the parts - end hosts and 
>intermediaries working together can achieve 
>better overall security than either working in 
>isolation and in complete distrust of the other.
>
>It'll be up to the individual customer on where 
>to dial the knobs, and we should enable the 
>options and make them as deployable as possible. 
>I.e. if customers really want to manage full IP 
>address policies for who can do encrypted ESP, 
>than that option should be available.   If they 
>want good intermediary audit trails with a 
>simpler intermediary config, that option needs 
>to be available.  If they want best effort load 
>balancing/WAN optimization, that option needs to 
>be available.
>
>This is no longer an either-or adversarial 
>situation between end systems and 
>intermediaries, and the intermediaries in play 
>are not relegated to security intermediaries - 
>although clearly security intermediaries are 
>important here, too.
>
>bs

Brian,

I was really hoping for a simple answer to the 
questions I posed in my message. Instead IO got a 
message with words like "holistic" and phrases 
like "the sum of functionality is greater than 
the partsŠ" which is a bit too new age for me :.

  I'm guessing that hints to the answer I was 
looking for are lurking in your second paragraph:

>It'll be up to the individual customer on where 
>to dial the knobs, and we should enable the 
>options and make them as deployable as possible. 
>I.e. if customers really want to manage full IP 
>address policies for who can do encrypted ESP, 
>than that option should be available. If they 
>want good intermediary audit trails with a 
>simpler intermediary config, that option needs 
>to be available.  If they want best effort load 
>balancing/WAN optimization, that option needs to 
>be available.

In interpret this to mean that yes, you realize 
that an intermediate system that wants to enforce 
the sort of policies you previously described 
would, in fact, have to be configured with IP 
address info (or its moral equivalent) in order 
to enforce such policies.  In this case your 
argument against my suggested approach to dealing 
with incremental deployment of WESP disappears 
(which may be why you chose to not make this 
statement directly :)).

You seem to offer an alternative, i.e., to give 
customers the ability to have intermediaries 
inspect or not inspect traffic based solely on 
what the traffic labels indicate. This amounts 
trusting the hosts to label traffic properly, 
which is the alternative answer I postulated and 
criticized. Again, you chose not to answer this 
directly, but instead alluded (in your last 
paragraph) to the need to think of end systems 
and intermediaries as no longer operating in an 
adversarial environment. Historically, the 
principle motivations for security intermediaries 
include countering (security relevant) 
misconfiguration of hosts, an inability to manage 
the (security relevant) configurations of hosts, 
dealing with compromise of hosts, etc. These are 
all instances where the intermediaries do not 
trust the end systems. Please elaborate on why 
you believe that these are now outmoded reasons 
for how security intermediaries should relate to 
hosts.

You describe allowing intermediaries to generate 
audit trails (presumably capturing some info 
about the encrypted traffic that they were unable 
to inspect, but you didn't say specifically) as 
an alternative to policy enforcement. There may 
be some merit to this in some contexts, but I 
think the WG needs to have a clear picture of 
what is being proposed and the associated 
rationale.  I searched the IPSECME archives and 
found only one set of messages inn 2009 that 
include the word "audit" in the context of this 
discussion. These messages were a thread 
involving Ken and Tero, and appeared in the 
2/4-11 timeframe. The messages focused on the 
performance and cost issues associated with 
implementing stateful vs. stateless 
intermediaries, as part of the larger debate on 
heuristics vs. explicit packet labeling. This 
thread did not raise the issue you did above, 
i.e., that a major motivation for WESP is to 
enable users to "audit" encrypted traffic flows 
as an alternative to using access control info to 
permit/deny such flows.

I don't think the WG should make major design 
decisions without a clear picture of the various 
use cases that are being cited, but which lack 
detailed descriptions and thoroughly-articulated 
assumptions.  I think the WG needs such 
descriptions and associated analysis to guide its 
decisions. 

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 7 Jan 2010 13:43:39 -0500

Folks,

In discussing how intermediaries can perform packet inspection in the 
context of mixed deployments (WESP-capabale and legacy hosts) there 
seems to be a lack of detail re assumptions.  This came to light in 
my questions to Brian this morning.  So, just to clarify the 
discussion, I'd like to hear from folks what information about hosts 
they presume an intermediary has available, and how that affects how 
the intermediary operates. It probably will help if we distinguish 
among different types of intermediaries, e.g., firewall-like devices, 
IDS-style devices, load balancing devices, etc. My goal is to ensure 
that we all are using the same set of underlying assumptions when we 
discuss how things operate, and thus why different approaches to 
labelling packets are more or less desirable.

Thanks,

Steve

---

From: Brian Swander <[email-masked]>
Date: Thu, 7 Jan 2010 20:06:20 +0000

I'm going by what my real customers are asking for. 

Our real customers are asking for exactly what I'm describing below.   I didn't ask them why their stance to intermediaries has changed, if it even has.  That is academic.  The key question here is what do real customers want to deploy, and how can we enable them to do it.

bs

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Thursday, January 07, 2010 11:09 AM
To: Brian Swander
Cc: [email-masked]; Russ Housley
Subject: RE: [IPsec] Traffic visibility - consensus call

Brian,

Steve

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 7 Jan 2010 23:24:44 +0200

Hi Dan,

[No hat. This is getting cold!]

When I hear that "the network enforces a policy" I immediately think of the exceptions: unmanaged machines (in the enterprise sense of the word), machines with weird operating systems (that's "non Windows" to some of our participants), outdated versions, machines that failed to be provisioned etc.

So it is difficult to assume that *all* ESP is encrypted in any given network. This may be OK, if you're willing to accept false positives (e.g. in a load balancer). Or it may not be OK, if you have security decisions that depend on this distinction.

And this is why a smooth migration is so important. Over time you get a larger and larger portion of the network to play by the rules.

Thanks,
	Yaron

-----Original Message-----
From: Dan Harkins [mailto:[email-masked]] 
Sent: Thursday, January 07, 2010 19:57
To: Yaron Sheffer
Cc: [email-masked]
Subject: RE: [IPsec] Traffic visibility - consensus call

  Hi Yaron,

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 7 Jan 2010 13:51:00 -0800 (PST)

Hi Yaron,

  [wearing a baseball cap from the "Working Man's Triathlon"!]

  These same "unmanaged machines" will cause problems for this new
mutated form of WESP (wrapping both encrypted and unencrypted ESP).
There is no way to assure that they will use WESP. Maybe they'll
use ESP-null without WESP and then these middleboxes relying on
WESP wrapped ESP to do their job are out-of-luck. So yes, these
machines do pose a problem, but WESP doesn't fix that problem.

  Over time a larger and larger portion of the network will "play by
the rules", as you say, but those rules could be: 1) use WESP to wrap
all your ESP traffic, both encrypted and not encrypted; or 2) use
ESP for encrypted traffic and <NAT-friendly-AH-protocol> for your
unencrypted traffic.

  Aside from architectural cleanliness, another benefit of a NAT-friendly
AH would be that the temptation for extensions and the consequential
creep of new "requirements" (what WESP seems to be suffering from right
now) would go away. We had a problem and the solution has morphed and
succumed to temptation. That's the sign of a bad solution.

  Dan.

On Thu, January 7, 2010 1:24 pm, Yaron Sheffer wrote:
> When I hear that "the network enforces a policy" I immediately think of
> the exceptions: unmanaged machines (in the enterprise sense of the word),
> machines with weird operating systems (that's "non Windows" to some of our
> participants), outdated versions, machines that failed to be provisioned
> etc.
>
> So it is difficult to assume that *all* ESP is encrypted in any given
> network. This may be OK, if you're willing to accept false positives (e.g.
> in a load balancer). Or it may not be OK, if you have security decisions
> that depend on this distinction.
>
> And this is why a smooth migration is so important. Over time you get a
> larger and larger portion of the network to play by the rules.
>
> Thanks,
> 	Yaron
>
>> Of
>> Dan Harkins

---

From: Stephen Kent <[email-masked]>
Date: Thu, 7 Jan 2010 18:41:11 -0500

At 8:06 PM +0000 1/7/10, Brian Swander wrote:
>Our real customers are asking for exactly what I'm describing below. 
>I didn't ask them why their stance to intermediaries has changed, if 
>it even has.  That is academic.  The key question here is what do 
>real customers want to deploy, and how can we enable them to do it.
>
>bs

Brian,

I don't know how IPSECME will choose to proceed, but in the WG I 
chair folks expect WG participants to provide technically defensible 
rationales for designs that they advocate. Relaying what customers 
purportedly have requested doesn't  cut it.

Also, the IETF does not assume that "the customer is always right" 
when making protocol design decisions. If we did, and if we made such 
decisions in 1990, we'd be using ATM, CLNP, X.400, and other 
protocols that many big clients said were what they wanted in that 
time frame :-).

Steve

---

From: Jack Kohn <[email-masked]>
Date: Fri, 8 Jan 2010 05:24:21 +0530

Dan,

As Yaron has already stated, there are multiple ways of detecting
ESP-NULL packets and the WG chose one out of those. I remember an
initial proposal (by Manav or Paul? not sure)  where the author was
using a reserved SPI value in the ESP to indicate all ESP-NULL
packets. This was shot down by the WG citing extensibility reasons,
and i agreed with them. I agreed, that if we do that then we will be
able to differentiate between ESP-NULL and other ESP packets, but
that'll be the end of the road, and there can be no further extensions
done.

Then WESP came along, which was patently extensible and people happily
lapped it up. Now, folks are getting cold feet, saying that its too
extensible and probably we shouldnt be having such a loose protocol
thats so easily extensible. Lets leave it at marking ESP-NULL only and
lets not have this do anything else.

Similarly, as Charlie says, you might be proposing AH-lite, but by the
time it reaches IESG it would have morphed into something much more
complex than the AH-lite that you have in your mind right now! :)

YMMV but I dont see WESP as a hack at all, and i think its a very good
solution to a problem that we're all trying very hard to fix.

Jack

---

From: Brian Swander <[email-masked]>
Date: Thu, 7 Jan 2010 23:59:30 +0000

Take 3 simple ones.   

1.  Intermediaries can audit traffic flowing thru them.  Netflows work for all integrity protected traffic as if it were cleartext.

2.  Intermediaries can effectively perform QOS markings on packets.  Integrity-only packets get more accurate markings (as if they were cleartext).  

3.  Intermediaries can enforce stateless router ACLs on all integrity traffic.  This is used in conjunction with end system audits, and intermediary audits, etc.   This only increases the security of the overall system.  The alternative is that the stateless router ACLs just permits all ESP (null or otherwise).

All of these allow rolling out transport IPSec without compromising the functionality of the given intermediaries.   All are in scope for WESP.  

I'm curious what the goal of this line of enquiry is.  I.e. how can we ever be done with this thread?
What sort of justification is needed to progress here? 

bs

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Thursday, January 07, 2010 3:41 PM
To: Brian Swander
Cc: [email-masked]; Russ Housley
Subject: Re: [IPsec] Traffic visibility - consensus call

Brian,

Steve

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 7 Jan 2010 18:10:10 -0600

On Tue, Jan 05, 2010 at 12:27:26AM +0200, Yaron Sheffer wrote:
> draft. To help resolve them, we would like to reopen the following two

No.

> you support this design decision?

I don't fully understand why we actually need this, but I think the
above is instantly objectionable, while this may be less so.  (Just
thinking in terms of what changes would be required to existing IPsec
implementations.)

Nico
--

---

From: "Joseph Tardo" <[email-masked]>
Date: Thu, 7 Jan 2010 17:47:32 -0800

Steve,

Let me add 2 more simple ones, mirroring based on L4 dest port and policy based routing.

An important point here is that not all intermediate nodes that need to examine packets are necessarily "trusted" intermediaries (in the security appliance sense), many (such as Netflow probes) have perfectly legitimate purposes that ESP-NULL would break. For these, and I'm not the first to say this, heuristics will never work. WESP is a simple enough approach to include in many of these kind of devices.

I agree with Brian and Charlie here, what do we need to close this off?

Thanks,
--Joe

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Swander
Sent: Thursday, January 07, 2010 3:59 PM
To: Stephen Kent
Cc: [email-masked]; Russ Housley
Subject: Re: [IPsec] Traffic visibility - consensus call

Take 3 simple ones.   

bs

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Thursday, January 07, 2010 3:41 PM
To: Brian Swander
Cc: [email-masked]; Russ Housley
Subject: Re: [IPsec] Traffic visibility - consensus call

Brian,

Steve

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 8 Jan 2010 13:58:16 +0200

[I finally managed to catch up all the tons of emails to the
ipsec-list, so now I can finally reply to few of them.]

> allow us to do that, and enable as many of them as possible. 

Note, that every time you have ESP-NULL traffic without WESP, you need
heuristics. I.e. the cases 1 and 5 still need heuristics regardless
whether you like that fact or not. If you try to inspect plain
ESP-NULL traffic you need heuristics to find out the algorithm
parameters for those ESP-NULL connections, i.e. what is the ICV length
and whether there is IV (and its length).

If you allow ESP traffic at all on the network you need to deal with
it, meaning you either use heuristics to inspect it or you simply
allow it go through or drop it (regradless whether it is encrypted ESP
or ESP-NULL).

If your use of ESP/WESP is such that it is beneficial for the users to
use WESP instead of ESP-NULL then they will move to it (i.e. if WESP
provides better QoS properties than ESP-NULL, then it will get used).

If it is critical for security that all traffic is inspected then you
cannot allow encrypted ESP at all (regardless whether it is marked in
WESP or not). 

If it is "nice to have feature" (for example network statistics) to be
able to see inside ESP-NULL packets (regardless whether they use WESP
or ESP-NULL) then you either use heuristics for ESP-NULL packets, or
just notice that the amount of ESP-NULL traffic is so small that it is
no longer needed for network statistcs use (i.e. when WESP is
widespread enough in your network, you can stop trying to inspect ESP
packets to account that last 0.00001% of traffic still using ESP-NULL
instead of WESP).

I cannot really see any scenario above where it would really be needed
to put encrypted packets inside WESP. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 8 Jan 2010 15:24:09 +0200

Grewal, Ken writes:
> differentiate between encrypted and non-encrypted traffic by
> explicitly signaling in the packet, that WESP is now a replacement
> for ESP. 
>

That is true, it was never intented for that, but some of the comments
in the list (and in the last IETF meeting) started discussions which
started to lead that way.

This includes most of the WESP extension discussion. That discussion
was the thing that woke me up, and then I started to notice that the
WESP is very far from where it started.

Even when most of the intermediate steps were justifiable, that does not
mean the end result will be ok.

> over WESP, but this was introduced as a mitigation for certain
> threats highlighted in the WG. Subsequent discussions have
> determined that it would be better to mitigate these treats in an
> alternative manner, so we can fall back to WESP being a wrapper for
> ESP, without the expanded ICV. Wrapped ESP provides a wrapper for
> ESP!

The current draft still requires both checks, i.e. both ICV to cover
the WESP header, AND checking all fields in the WESP header against
other sources. I think the checking and ICV expansion happeneded about
in the same time, and one of the reasons the checking of the fields is
needed REGARDLESS whether ICV covers WESP header or not, is to protect
against attacks where the end node puts wrong values to the WESP
header to fool intermediate devices.

ICV cannot protect against that. ICV will only protect against the
attacks happening in transit, but checking all fields protects both
for attacks happening in transit, and attacks done by the end node. 

> Some argue that we should use WESP for NULL traffic, mandating ESP
> for encrypted traffic...AND ensure that ESP is NEVER used for NULL
> encryption within a given domain / environment. How does an
> intermediate device know that this policy is being enforced?

It cannot, but on the other hand how can intermediate device know that
the traffic which must be sent using ESP-NULL is not encrypted?

Only way to do either of those, is to mandate them by policy, which do
require co-operation from end point(s). 

> distinction that certain traffic is encrypted whereas other traffic
> is not. This preserves the network based services we rely on and
> also allows other access control policies to be enforced. E.g. I
> want to ensure that my finance data flowing in the network is
> encrypted and NOT using ESP-NULL. If I rely on ESP for encrypted
> data and it can still use NULL encryption, I cannot enforce such a
> policy from an access control tool.

If you mandate that ESP is only for encrypted data, then you make
policy which says that ESP is only for encrypted data, and thats it.

If you cannot rely your end nodes to select correct policy between
WESP-NULL and encrypted ESP, how can you rely them selecting correct
policy for WESP-NULL vs encrypted-WESP traffic?

I.e. your node can still use WESP-NULL for financial data or it can
use encrypted WESP for traffic which should have been been using NULL
cipher.

> If we say that WESP is ONLY used to carry ESP-NULL (and ESP is used
> to carry encrypted traffic, but based on the ESP spec and legacy, it
> may also carry ESP-NULL), then we have not completed what we set out
> to do, as we have failed to *reliably* determine if the ESP traffic
> is encrypted or not!

You can still use heuristics in that case, if you cannot update all
your hosts which use NULL cipher to use WESP. Heuristics can also
provide *reliable* way to determine whether traffic is encrypted ESP
or not. That is why we have both heuristics and WESP. Heuristics are
meant to be used in the mean time when not all traffic cannot be made
to use WESP-NULL. After the whole network supports WESP-NULL you can
forbid ESP-NULL by policy and drop heuristics.
-- 
[email-masked]

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 8 Jan 2010 09:55:28 -0600

> thinking in terms of what changes would be required to existing IPsec

I believe I understand the issues now, and I believe this extension is
not needed, therefore: No.

Nico
--

---

From: Brian Swander <[email-masked]>
Date: Fri, 8 Jan 2010 17:06:31 +0000

In the absolutely most generic case, yes.  And heuristics absolutely have their place.  However, my proposal clearly allows for eliminating all heuristics with policy constraints. 

As you well know, you can eliminate the heuristics you describe by choosing the same algorithm so intermediaries don't need to guess ICV lengths.

Hence in this scenario, all ESP traffic would be ESP-NULL of a known algorithm.  This is possible since you just choose an algo that all the legacy clients also support.    

So my scenario gives a very real deployment that can eliminate the need for heuristics entirely during migration.  So carrying encrypted traffic in WESP is very valuable (and in charter).

bs

---

From: <[email-masked]>
Date: Mon, 11 Jan 2010 09:28:38 +0100

> ICV, instead of explicitly checking every field.

Note that the current draft *does* explicitly check ever field.
Are you proposing removing those checks?
 
Best regards,
Pasi
(not wearing any hats)

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Mon, 11 Jan 2010 14:32:55 +0530

I believe Ken is alluding to removing the WESP header from the ICV calculation, and relying on explicitly checking the WESP header at the endnodes.

Cheers, Manav

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of [email-masked]
> Sent: Monday, January 11, 2010 1.59 PM
> To: [email-masked]
> Cc: [email-masked]

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 11 Jan 2010 01:23:48 -0800 (PST)

Manav,

  So let's say the normal (removed WESP header) ICV calculations by
ESP are correct but something doesn't match between the (now unprotected)
WESP header and the rest of the packet. Why should the recipient care?
WESP is for middleboxes. The end node has an assurance that the
_meaningful_ portion of the frame was sent by the claimed sender and
was not modified in transit. Any decisions made by a middlebox that
might've involved an improperly modified WESP header are over and done
with. He doesn't care if the packet was properly handled by middleboxes
or not, he got it and it's correct.

  You trust the end nodes to negotiate WESP and encapsulate their ESP
packets in WESP but you don't trust the content they put into those
packets. Is that the trust model you're operating on?

  The more I think of this problem the more worthless WESP becomes.

  Dan.

On Mon, January 11, 2010 1:02 am, Bhatia, Manav (Manav) wrote:
> I believe Ken is alluding to removing the WESP header from the ICV
> calculation, and relying on explicitly checking the WESP header at the
> endnodes.
>
> Cheers, Manav
>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Mon, 11 Jan 2010 15:02:03 +0530

Dan,

No.

We trust the end nodes to put the right information in the WESP header. But, we don't trust the intermediaries, that could have mangled the packet so that it goes through the firewall/deep inspection device.

If that happens, then the packet should not be consumed, which would make the attack by a malicious middle box worthless.

Hope this helps.

Manav

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 11 Jan 2010 02:00:20 -0800 (PST)

Manav,

On Mon, January 11, 2010 1:32 am, Bhatia, Manav (Manav) wrote:
> We trust the end nodes to put the right information in the WESP header.
> But, we don't trust the intermediaries, that could have mangled the packet
> so that it goes through the firewall/deep inspection device.

  The fact that you require deep inspection of a packet sent by an end
node means you don't trust the end node to put good bits into the packet.
Yet you trust the end node to negotiate WESP and properly encapsulate ESP
with WESP and do the checking of the (now unprotected) WESP header and
normal ESP header. That's weird.

  If (the WESP header of) a packet was modified such that it avoided deep
packet inspection but still passes a source and (non-WESP header) data
integrity check why would you want to drop that packet?

  End-to-end protection (via ESP) means that you don't have to trust the
intermediaries. And you don't. Great. So what exactly is the threat?

  Dan.

---

From: "Grewal, Ken" <[email-masked]>
Date: Mon, 11 Jan 2010 09:15:13 -0700

Hi Pasi, 
The text for explicitly checking the fields was added in and this was followed by adding the ICV check for simplification, without removing the aforementioned text, hence we ended up with both 'checks'!

Based on subsequent discussions, the WG appears to be in favor of removing the extended ICV and keeping the explicit checks, so we will incorporate the appropriate modifications for this and other items raised when the next rev of the document is generated. 

Thanks, 
- Ken

>From: [email-masked] [mailto:[email-masked]]
>Sent: Monday, January 11, 2010 12:29 AM
>To: Grewal, Ken
>Cc: [email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Wed, 13 Jan 2010 13:53:25 -0500

At 3:02 PM +0530 1/11/10, Bhatia, Manav (Manav) wrote:
>We trust the end nodes to put the right information in the WESP 
>header. But, we don't trust the intermediaries, that could have 
>mangled the packet so that it goes through the firewall/deep 
>inspection device.
>
>If that happens, then the packet should not be consumed, which would 
>make the attack by a malicious middle box worthless.
>
>Hope this helps.
>
>Manav

I don' know about anyone else, but it didn't clarify the threat model 
for me :-).

In some messages the phrase "trusted intermediaries" is used, which 
does not seem to fit your text above.  If you are alluding to a MITM, 
say so.

Steve