Subject: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility

From: Russ Housley <[email-masked]>
Date: Wed, 16 Dec 2009 14:59:45 -0800 (PST)

Discuss:
  The primary motivation for this work is to allow a middlebox to peek
  into integrity protected (but not encrypted) IPsec packets. Some
  integrity-check algorithms use an IV, a middlebox cannot alway know
  where the payload starts.  Unlike the IPsec peer that negotiated the
  algorithm in the IKE exchange, the middlebox does not know which
  integrity-check algorithm is in use, and thus doe s not know if an IV
  is present or how long it might be.

  The document allows the encapsulation of encrypted IPsec traffic.
  Why?  I cannot see the justification for the use if WESP at all if
  the IPsec traffic is encrypted.

  The document says:
  >
  > ... by preserving the body of the existing ESP packet format, a
  > compliant implementation can simply add in the new header, without
  > needing to change the body of the packet.
  >
  The figures in Section 2.2.1 and 2.2.2 show otherwise.  The ESP ICV is
  replaced by a WESP ICV.  ESP processing is changed, and I cannot see
  the justification for it.  This is explained by:
  >
  > In the diagrams below, "WESP ICV" refers to the ICV computation as 
  > modified by this specification. Namely, the ESP ICV computation is 
  > augmented to include the four octets that constitute the WESP header. 
  > Otherwise, the ICV computation is as specified by ESP [RFC4303].
  >
  So, in fact, WESP is not an optional encapsulation of ESP.  It is an
  alternative to ESP with some duplicated fields (such as Next Header)
  and pointers into the actual integrity-protected payload.

  When talking about IKEv2 negotiation, the document says:
  >
  > The notification, USE_WESP_MODE (value TBD) MAY be included in a
  > request message that also includes an SA payload requesting a
  > CHILD_SA using ESP.
  >
  USE_WESP_MODE MUST be included if one wants to use WESP, right?  The
  use of MAY here leads me to think that there are other ways to select
  the use of WESP in the IKEv2 exchange.

---

From: Jack Kohn <[email-masked]>
Date: Thu, 17 Dec 2009 05:03:14 +0530

My two bits on this and I'll let the authors/chairs explain in detail ..

>  the IPsec traffic is encrypted.

This was discussed and i think the idea was not to limit WESP for just
ESP-NULL. One does not lose anything by defining WESP for encrypted
packets (besides the additional bytes in the header). However, by
keeping provisions for this, we are free to define other extensions
which might later work for encrypted packets.

I think its a good idea to keep WESP flexible and see how it evolves
in the wild. In the worst case, no one would use it for encrypted
packets ..

Jack

---

From: Jack Kohn <[email-masked]>
Date: Thu, 17 Dec 2009 05:15:30 +0530

>  >

Actually, the name "Wrapped ESP" (WESP) is a misnomer. :)

It may have been envisaged as a wrapper over ESP, but given how it has
evolved (computing ICV, etc) , its more than just a mere wrapper and
is actually an alternative to ESP (as you rightly point out). However,
i see no issues with this. In fact, i see this as another reason why
the spec should allow WESP to be used for encryption also.

Jack

---

From: gabriel montenegro <[email-masked]>
Date: Wed, 16 Dec 2009 16:01:34 -0800 (PST)

As I recall, folks expressed that if one were to use WESP for ESP-NULL, it would be good to be able to use it for encryption as well to be able to use a consistent packet format.

This was issue 84:
http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/84

Discussed at IETF 74 and 75 as well as on the list:
http://tools.ietf.org/wg/ipsecme/minutes?item=minutes74.html
http://tools.ietf.org/wg/ipsecme/minutes?item=minutes75.html

And (just saw Jack's other message), yes "wrapped" does not correctly describe it any more
given changes to the ICV calculation.

Gabriel

----- Original Message ----
> From: Jack Kohn <[email-masked]>
> To: Russ Housley <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Sent: Wed, December 16, 2009 3:33:14 PM
> Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
> 
> On Thu, Dec 17, 2009 at 4:29 AM, Russ Housley wrote:
> > Discuss:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Dan McDonald <[email-masked]>
Date: Wed, 16 Dec 2009 21:34:58 -0500

On Wed, Dec 16, 2009 at 02:59:45PM -0800, Russ Housley wrote:

<SNIP!>

>   the IPsec traffic is encrypted.

<tin-foil-hat>
	Because THE MAN told 'em to do it!
</tin-foil-hat>

:)

Seriously though, I agree with Russ -- it makes little to no sense to expose
privacy-protected fields.  If you're worried about traffic shaping, just put
all ESP/WESP/whatever packets in the lowest priority bucket.  Any other
reason that springs to mind simply defeats the purpose of privacy-protection.

Dan

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 17 Dec 2009 08:59:43 +0200

Hi Dan

I agree with you regarding some of the proposals that have been floating around re: exposing bits and pieces of encrypted data.

I disagree though that WESP should not be used for encrypted data:

- It is simpler for implementations and architecturally cleaner for WESP to support both flavors.
- WESP provides for (secure) extensibility, which unfortunately we have not had with ESP. Indeed we should be wise about picking such extensions.

Thanks,
	Yaron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan McDonald
Sent: Thursday, December 17, 2009 4:35
To: Russ Housley
Cc: [email-masked]; [email-masked]
Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility

<SNIP!>

<tin-foil-hat>

:)

Dan

Scanned by Check Point Total Security Gateway.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 17 Dec 2009 14:03:51 +0200

Yaron Sheffer writes:
> I agree with you regarding some of the proposals that have been
> floating around re: exposing bits and pieces of encrypted data.

I am really concerned about some of those late proposals for WESP
extensions, and if someone would have mentioned any of those earlier
when we were discussing whether WESP should allow encrypted ESP also,
I would have been even more against allowing encrypted WESP. 

>   WESP to support both flavors.

It does make more complexity for the middle boxes as they need to cope
with both encrypted WESP and ESP-NULL WESP, thus they still cannot use
just the WESP protocol number to indicate this packet is clear text.
Now they also need to check the bit in the header, and if we add more
extensions to WESP, they need to start doing even more processing etc,
and quite soon WESP is more complex than what AH is now.

> - WESP provides for (secure) extensibility, which unfortunately we
>   have not had with ESP. Indeed we should be wise about picking such
>   extensions.

ESP is extensible, but it just requires out of band communication to
negotiate those extensions. We currently already have ESP extesions
like extended sequence numbers (ESN), Explicit Congestion Notification
(ECN), Traffic Flow Confidentiality (TFC), and Combined mode
algorithms.

Those were added after initial ESP was created, and they are
negotiated using IKEv2 (or some other method).

ESP does not offer extensibility that can be done without out of band
communication, and as that out of band communication is normally
encrypted (inside IKEv2) that means middle boxes cannot process it.

I do not think WESP should be used as generic extensible ESP. That was
not what the ipsecme wg was chartered to do. We were chartered to do:

- 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.
-- 
[email-masked]

---

From: "Grewal, Ken" <[email-masked]>
Date: Thu, 17 Dec 2009 10:19:15 -0700

Agreed. 

Thanks, 
Ken

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Jack Kohn
>Sent: Wednesday, December 16, 2009 3:33 PM
>To: Russ Housley

---

From: "Grewal, Ken" <[email-masked]>
Date: Thu, 17 Dec 2009 10:19:26 -0700

Some comments inline...

<snip>

>and quite soon WESP is more complex than what AH is now.

[Ken] I do not think that checking one more bit adds too much additional complexity, compared with extracting the offsets and protocol
Information from the header. It does provide compatibility for both encrypted and unencrypted traffic. 
If we add more extensions to WESP, then those need to be evaluated based on the cost / complexity Vs. benefit and that will be a separate debate. 

<snip>

>negotiate those extensions. We currently already have ESP extensions
[Ken] I think this is the whole point. All the work on ESP/IPsec this far has been considering a two party interaction (outside the multicast context!). Now there is a third party - the middle box, which would like to gain some additional information in order to provide valuable network services. The end boxes already know what is being negotiated, so just making changes to IKE to add additional capability is insufficient in certain scenarios (while perfectly sufficient in others). We need to provide additional information in the data path, hence the need for WESP.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 18 Dec 2009 10:18:49 +0200

FWIW, I would personally rather see WESP do exactly what it is supposed 
to do, reveal the packet, and not handle other kinds of functionality 
(encrypted packets etc)

Jari

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 18 Dec 2009 12:44:00 +0200

Grewal, Ken writes:
> [Ken] I do not think that checking one more bit adds too much
> additional complexity, compared with extracting the offsets and
> protocol Information from the header. It does provide compatibility
> for both encrypted and unencrypted traffic.

But without adding even more extensions there is no reason to ever use
encrypted WESP instead of ESP. WESP just adds extra header without any
benefit compared to normal encrypted ESP. 

> If we add more extensions to WESP, then those need to be evaluated
> based on the cost / complexity Vs. benefit and that will be a
> separate debate.

The question is how many extensions we have which are such that they
need to be understood by the middle boxes. Extensions for the end
hosts can be done using standard ESP. 

> [Ken] I think this is the whole point. All the work on ESP/IPsec
> this far has been considering a two party interaction (outside the
> multicast context!).

Yes, I and I think IPsec will stay that way...

For example I do not think our OEM toolkit will include WESP as I do
not really see any need for it.

> Now there is a third party - the middle box, which would like to
> gain some additional information in order to provide valuable
> network services. The end boxes already know what is being
> negotiated, so just making changes to IKE to add additional
> capability is insufficient in certain scenarios (while perfectly
> sufficient in others). We need to provide additional information in
> the data path, hence the need for WESP.

I am not sure WESP is right solution for that problem. It would be
much better to provide authenticated protocol where the middlebox
could connect to the end node and query the required parameters from
the end node and the end node can give that information out without
needing to waste extra bytes on each packet. Also that way end node
could control who gets the information and who does not. There is no
need that additional information needs to be on the data path, and in
clear text, it could also be communicated using some other out of band
method instead of WESP.

Depending on what kind of additional information needs to be
transmitted, the solutions can be quite different.
-- 
[email-masked]

---

From: Russ Housley <[email-masked]>
Date: Sat, 19 Dec 2009 12:49:06 -0500

Ken:

>multicast context!). Now there is a third party - the middle box, 
>which would like to gain some additional information in order to 
>provide valuable network services. The end boxes already know what 
>is being negotiated, so just making changes to IKE to add additional 

I do not agree with your assessment of the situation.  I agree with 
Tero's thoughts.

The IPsecME charter includes this work item:

   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.

Nothing in this description prepared me for WESP processing of ESP 
packets with a non-NULL-cipher.  It suggests making it easy for the 
middlebox to gain access to data that is already plaintext.  It does 
not suggest making information available to the middlebox that was 
previously unavailable to it.

Further, based on the discussion that has happened since I posted my 
DISCUSS position, other IPsecME WG participants are uncomfortable 
with the direction that WESP has taken.  As the discussion 
progresses, if I can see that these people and myself are in the 
rough, then I will clear.  So far, that does not seem to be the case.

Russ

---

From: Jack Kohn <[email-masked]>
Date: Mon, 21 Dec 2009 06:06:38 +0530

Hi Russ,

If we are not willing to ever extend WESP then we might as well debate
the alternative scheme that i had reviewed long time back (which was
shot down citing WESP being more extensible). I see that we are going
through the discussions that we've already had in the WG, things that
had been decided by majority consensus, approved by everyone in the
WG. With this being the case we might as well debate on whether we
really want a new protocol type for WESP (again discussed long time
back) or if we can just hijack one of the SPI values and treat all
packets with that as ESP-NULL. Alternatively, since we seem to be
having unlimited bandwidth for discussions, we might as well argue
whether we need heuristics also or not, as there are very few people
in IPSecMe WG who feel the need for it. Strangely, its that same set
of people who are against the idea of using null NULL ciphers for
WESP. Is it because by supporting encryption in WESP we make it more
generic, and thereby increasing the chances of its widespread
implementation as against the other proposal (heuristics)?

Jack

On Sat, Dec 19, 2009 at 11:19 PM, Russ Housley <[email-masked]> wrote:
> Ken:
>
>> [Ken] I think this is the whole point. All the work on ESP/IPsec this far
>> has been considering a two party interaction (outside the multicast
>> context!). Now there is a third party - the middle box, which would like to
>> gain some additional information in order to provide valuable network
>> services. The end boxes already know what is being negotiated, so just
>> making changes to IKE to add additional capability is insufficient in
>> certain scenarios (while perfectly sufficient in others). We need to provide
>> additional information in the data path, hence the need for WESP.
>
> I do not agree with your assessment of the situation.  I agree with Tero's
> thoughts.
>
> Nothing in this description prepared me for WESP processing of ESP packets
> with a non-NULL-cipher.  It suggests making it easy for the middlebox to
> gain access to data that is already plaintext.  It does not suggest making
> information available to the middlebox that was previously unavailable to
> it.
>
> Further, based on the discussion that has happened since I posted my DISCUSS
> position, other IPsecME WG participants are uncomfortable with the direction
> that WESP has taken.  As the discussion progresses, if I can see that these
> people and myself are in the rough, then I will clear.  So far, that does
> not seem to be the case.
>
> Russ

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 21 Dec 2009 13:36:05 +0200

Jack Kohn writes:
> Alternatively, since we seem to be
> in IPSecMe WG who feel the need for it.

My personal feelings is that this inspecting ESP-NULL packets is not
needed at all, as everything will be encrypted ESP anyways, so there
is even no point of trying to inspect any of that ESP-NULL traffic
(either using WESP or heuristics).

The reason I am in favor of heuristics instead of WESP, is that
heuristics requires changes only on the middleboxes, we do not need to
make new extension that will affect all the end nodes supporting
IPsec.

Also heuristics is not harmful, as it does not harm others, it is
simply internal matter inside the middlebox. I do consider WESP a bit
harmful, as it adds extra bytes to all packets, and does not offer
that much which cannot already be done by other means, but requires
all IPsec end nodes to be updated (and also every single firewall
needs to be reconfigured to allow also this new protocol number
through not just proto 50 and 51).

But those are my personal feelings, and I agreed that as rest of the
WG seemed to want to work on WESP, that is fine, but I still wanted
push the heuristics forward just as middlebox only alternative to
WESP.

> Strangely, its that same set of people who are against the idea of
> using null NULL ciphers for WESP. Is it because by supporting
> encryption in WESP we make it more generic, and thereby increasing
> the chances of its widespread implementation as against the other
> proposal (heuristics)?

Using non-NULL ciphers for WESP takes it out from its intended use,
and unless there is some more extensions done for WESP (which there
currently isn't), there is no point of doing that, as using WESP for
encrypted ESP we are just wasting bytes for extra WESP header.

Meaning that before we see any extensions that would require WESP and
encrypted ESP I do not think there is any point of sending encrypted
ESP traffic using WESP. 

And yes, making WESP more generic would mean that I would perhaps some
day need to implement it (which I do not want to) if there is too much
customer demand for it in the future.
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 21 Dec 2009 15:24:47 +0200

Hi Tero,

Allowing the more generic, encrypted WESP (as per the current I-D) would let vendors experiment with different extensions. Yes, they might play with some extensions that you and I find ugly or even insecure. But crippling WESP today would mean that any such extensions are (1) limited to IKE and (2) invisible to the middleboxes.

Thanks,
	Yaron

---

From: Brian Swander <[email-masked]>
Date: Mon, 21 Dec 2009 23:13:28 +0000

I took Russ' comments about "being in the rough" to imply that we're re-opening the consensus discussion.  I'm not sure why we're reopening this, since we already got consensus on this when it came up the first time.  Since many of our internal guys are already out for the holidays, I can't see meaningful consensus occurring until the new year.

bs

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaron Sheffer
Sent: Monday, December 21, 2009 5:25 AM
To: Tero Kivinen; Jack Kohn
Cc: [email-masked]; Russ Housley
Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility

Hi Tero,

Thanks,
	Yaron

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 22 Dec 2009 06:11:13 +0530

Tero,

> harmful, as it adds extra bytes to all packets, and does not offer

I think heuristics is a good solution, but contrary to your thinking I don't think it's a panacea to all our problems. Heuristic solution is not an exclusive alternative, but a complement to the deterministic approach in providing an interim solution using a subset of devices that are capable and willing to consume the heuristics overheads. Few of us, long time back, had done some work on the issues with heuristics and I post a summary of what we had discussed.

Claiming that heuristics requires only modification of the network entities is somewhat misleading, as the nature of the modifications is very different. Such changes would imply a radical change in architectures of devices that currently do not have the capability to run complex code with the corresponding memory requirements. Furthermore, those changes are ongoing as heuristics has to continuously change to accommodate changing traffic patterns and algorithms (e.g. leveraging new, future cryptographic algorithms for ESP, which have different IV/ICV length requirements). From the point of view of testing and compliance, such complexity is in itself an issue which compounded with the potential for incorrect determination is perhaps a deployment blocker.  

Heuristics are applicable to only some (not all) stateful devices. Even within stateful devices, not all of them are expected to be able to handle heuristics, particularly as they grow to handle 100K-400K flows.

Heuristics will NOT work for high speed, high aggregation, stateless devices. These devices provide services such as stateless statistics, QoS markings or stateless firewalls (which provide basic access control functions in filtering unwanted network traffic). Stateless devices by definition do not maintain dynamic, per-flow state (although they typically have fixed, static rules) and hence employing any heuristics-based solution would require a radical architecture change for these devices. This would be in the form of incorporating state into the device or the ability to execute the heuristics engine at line rate for every packet, which would require a pure hardware-based solution. 

Heuristics are not a good match for short-lived flows. Measurements of Enterprise traffic patterns reveal that a significant portion is represented by UDP and short-lived flows. UDP traffic has been measured at 25% of the total. The concept of "flows" which heuristics uses to amortize the initial cost of parsing and analysis is not as applicable here. Handling such cases (e.g., VoIP) via heuristics is very costly and may end up becoming the bottleneck for the services offered. The heuristics draft itself concedes that UDP checks will be more expensive, as it does not contain immutable fields (such as those available in TCP flows) that can be used as part of the heuristics algorithm to increase the probability of drawing the correct conclusions. 

Heuristics requires a proper cache flushing mechanism.  Heuristics based approach recommends executing the heuristics engine in software and subsequently caching the results in hardware by using the packet attributes (e.g. IP addresses, SPI). However, it does not provide a clean solution for cache management and specifically eviction of a given cache entry, if and when a given flow is no longer needed. The proposed approaches for cache management recommend simple Least Recently Used (LRU) type algorithms, which will unnecessarily flush legitimate cache entries for legitimate, but intermittent traffic patterns or an approach of binding TCP flow analysis with the appropriate cache entry, which may work for stateful protocols, but is ineffective for stateless protocols such as UDP. Additionally, the engine will have no idea about short and long-lived security associations and may prematurely remove cache entries, even though the SA is still active. This will require further iterations using the heuristics engine, when a subsequent packet for that security association is seen. Furthermore, the cache will likely be of a finite size and any of the above approaches will cause a 'cache trash' resulting in performance degradation, as well as unnecessary CPU consumption in re-execution of the heuristics engine. This provides a new DoS attack vector for potential adversaries by forcing cache add/remove harmonics by simply replaying packets at well-chosen intervals.

It is hard or costly to handle quick route changes via heuristics. Heuristics works best in the presence of long-lived TCP sessions. "Long-lived" must apply both to the session at the end-nodes involved as well as to how it is being routed throughout the network. Even if the former is true, constant routing changes render these sessions short-lived from the point of view of heuristics, as the new devices involved must re-run and relearn the flow based on heuristics. Route changes invalidate the amortization of building heuristic state

Heuristics can lead to more latencies in error recovery and indeterminate results. The heuristics draft discusses the possibility of several potential false positives in connection with DPI engine results. Confusing failure and garbage results can lead to slow error recovery. As pointed out by the heuristics draft, lack of explicit knowledge of the Next Protocol may require more passes, hence more latency and state to be built. 

Cheers, Manav

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 22 Dec 2009 06:16:05 +0530

+1 

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Brian Swander
> Sent: Tuesday, December 22, 2009 4.43 AM
> To: Yaron Sheffer; Tero Kivinen; Jack Kohn
> I took Russ' comments about "being in the rough" to imply 
> that we're re-opening the consensus discussion.  I'm not sure 
> why we're reopening this, since we already got consensus on 
> this when it came up the first time.  Since many of our 
> internal guys are already out for the holidays, I can't see 
> meaningful consensus occurring until the new year.
> 
> bs
> 
> 
> Allowing the more generic, encrypted WESP (as per the current 
> I-D) would let vendors experiment with different extensions. 
> Yes, they might play with some extensions that you and I find 
> ugly or even insecure. But crippling WESP today would mean 
> that any such extensions are (1) limited to IKE and (2) 
> invisible to the middleboxes.
> 
> Thanks,
> 	Yaron
>

---

From: Jack Kohn <[email-masked]>
Date: Tue, 22 Dec 2009 09:08:51 +0530

And in case there are no extensions for using WESP with encrypted
traffic, then we will continue to use WESP for ESP-NULL only.

Jack

---

From: Stephen Kent <[email-masked]>
Date: Mon, 28 Dec 2009 15:45:21 -0500

Yaron,

I hate to admit it, but I lost track of the details of WESP as it 
progressed through WG discussions and briefings at IETF meetings. 
When I read the I-D in detail, I was very surprised to see that it 
was no longer a neatly-layered wrapper, as originally proposed.  The 
fact that it now calls for the ESP ICV to be computed in a new 
fashion means that it really is replacing ESP, when used to mark 
ESP-NULL packets.

 From a protocol design perspective, the current version makes no 
sense to me. Why keep the ESP header when ESP processing is now 
changed in a significant way.  The WESP header cannot be processed 
(completely) by itself, because of the dependence on the ESP ICV. So 
it makes little or no sense to retain the ESP header in this context. 
I see no strong backward compatibility motivation for this format, 
given that ESP processing must change to accommodate WESP (as 
defined).

The issue of using WESP for marking encrypted traffic is a separate 
topic. I believe the rationale you cited was to enable WESP 
extensions, but I may have missed other arguments put forth for this. 
Since most of the WESP extension proposals discussed so far have 
proven to be questionable, I am not enthusiastic about that 
rationale.  Others have noted that using WESP with encrypted traffic 
is not consistent with the scope of the WG charter item that 
authorized work on WESP.  Unless Pasi approves a WESP extension WG 
item as part of re-chartering, I think it is inappropriate to have a 
flag to mark a WESP payload as encrypted.

Steve

---

From: Jack Kohn <[email-masked]>
Date: Tue, 29 Dec 2009 06:17:20 +0530

Are you suggesting that ESP ICV should not cover the WESP fields?

I think, and my memory could be failing me, that this was discussed in
the WG before this got added to the draft.

Jack

On Tue, Dec 29, 2009 at 2:15 AM, Stephen Kent <[email-masked]> wrote:
> Yaron,
>
> I hate to admit it, but I lost track of the details of WESP as it progressed
> through WG discussions and briefings at IETF meetings. When I read the I-D
> in detail, I was very surprised to see that it was no longer a
> neatly-layered wrapper, as originally proposed.  The fact that it now calls
> for the ESP ICV to be computed in a new fashion means that it really is
> replacing ESP, when used to mark ESP-NULL packets.
>
> From a protocol design perspective, the current version makes no sense to
> me. Why keep the ESP header when ESP processing is now changed in a
> significant way.  The WESP header cannot be processed (completely) by
> itself, because of the dependence on the ESP ICV. So it makes little or no
> sense to retain the ESP header in this context. I see no strong backward
> compatibility motivation for this format, given that ESP processing must
> change to accommodate WESP (as defined).
>
> The issue of using WESP for marking encrypted traffic is a separate topic. I
> believe the rationale you cited was to enable WESP extensions, but I may
> have missed other arguments put forth for this. Since most of the WESP
> extension proposals discussed so far have proven to be questionable, I am
> not enthusiastic about that rationale.  Others have noted that using WESP
> with encrypted traffic is not consistent with the scope of the WG charter
> item that authorized work on WESP.  Unless Pasi approves a WESP extension WG
> item as part of re-chartering, I think it is inappropriate to have a flag to
> mark a WESP payload as encrypted.
>
> Steve

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 29 Dec 2009 08:06:42 +0530

Yes, this was discussed in the WG (http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/104) and the idea was this:

We could have some malicious entity that could modify the offsets to ensure that the intermediaries don't parse a portion of the payload (which could contain malicious content) or inspect it differently than what it would have done otherwise. A way to protect against such attacks is to let the end node validate the WESP header by including this as a part of the ESP ICV. If the computed ICV does not match, the packet is dropped (usual IPSec processing).

This does not completely eliminate the vulnerability, but it does raise the bar, because now the malicious routers would have to also position themselves both before and after the middle boxes in order to have a chance to revert the packet back to its original form before the end node verifies integrity over the packet. 

We have also discussed this in the Security Considerations section of the draft.

We did informally speak to HW guys who are interested in implementing WESP, and they confirmed that increasing the integrity protection of ESP to now cover the WESP header is trivial. 

Cheers, Manav

> On Behalf Of Jack Kohn
> Sent: Tuesday, December 29, 2009 6.17 AM
> To: Stephen Kent
> Cc: [email-masked]; Russ Housley; [email-masked]; Dan McDonald

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 29 Dec 2009 13:43:52 +0200

Bhatia, Manav (Manav) writes:
> Yes, this was discussed in the WG
> (http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/104) and the idea
> was this: 
> 
> We could have some malicious entity that could modify the offsets to
> ensure that the intermediaries don't parse a portion of the payload
> (which could contain malicious content) or inspect it differently
> than what it would have done otherwise. A way to protect against
> such attacks is to let the end node validate the WESP header by
> including this as a part of the ESP ICV. If the computed ICV does
> not match, the packet is dropped (usual IPSec processing). 

As all current fields in the WESP header for ESP-NULL traffic is
already verified by the recipient to be matching their authenticated
values, there is no need to extend ESP ICV to cover WESP header.

Fo example the Next Header field in the WESP header is copy of the
Next Header field in the ESP header, and the current draft already
mandates that "The receiver MUST ensure that the Next Header field in
the WESP header and the Next Header field in the ESP trailer match
when using ESP in the Integrity only mode. The packet MUST be dropped
if the two do not match."

This same goes with HdrLen and TrailerLen etc fields.
-- 
[email-masked]

---

From: Russ Housley <[email-masked]>
Date: Tue, 29 Dec 2009 09:32:54 -0500

Manav:

I am unconvinced.  If a malicious attacker is willing to alter 
packets to fool middleboxes, this ICV does not help the middlebox and 
it harms the end system.  The middlebox cannot validate the ICV, and 
the end system does not need the WESP header information.  The end 
system does not need the pointer data in the WESP header to process 
the packet correctly; it already knows the size of the IV and other 
values associated with the algorithms in use.  Thus, the ICV 
protection imposes a requirement that the end system check the WESP 
information that it does not need, and then discard the packet if the 
attacker altered it to the potential detriment of the middlebox.

Russ

At 09:36 PM 12/28/2009, Bhatia, Manav (Manav) wrote:
>(http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/104) and the idea was this:
>
>This does not completely eliminate the vulnerability, but it does 
>raise the bar, because now the malicious routers would have to also 
>position themselves both before and after the middle boxes in order 
>to have a chance to revert the packet back to its original form 
>before the end node verifies integrity over the packet.
>
>We did informally speak to HW guys who are interested in 
>implementing WESP, and they confirmed that increasing the integrity 
>protection of ESP to now cover the WESP header is trivial.
>
>Cheers, Manav
>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 29 Dec 2009 10:47:22 -0500

>the WG before this got added to the draft.

I am suggesting that WESP should be cleanly layered, in one of two ways:

	- do not interfere with the ESP ICV computation (be 
unauthenticated, for the reasons already noted by Tero and Russ)

	- incorporate the necessary info from the ESP header and not 
replicate the ESP structure, i.e., become a full-fledged alternative 
to ESP-NULL (not for ESP when confidentiality is employed) when end 
systems are configured to expose encapsulated header info to middle 
boxes.

The current design is a hybrid that imposes undue complexity on IPsec 
implementations.

Steve