Subject: Re: [IPsec] Issue #93: Next header value in tunnel mode for WESP

From: Yaron Sheffer <[email-masked]>
Date: Sun, 3 May 2009 16:52:02 +0300

Hi Ken,

It seems to me this field is more trouble than it's worth. We are assuming
that the hardware will be enforcing a very simplistic security policy (don't
care if it's Tunnel or Transport, don't care if it's a TCP SYN or not etc.)
and that the hardware is unable to perform anything more than extremely
basic packet parsing. Both assumptions may well be incorrect. And the cost
is in complicating the protocol and the endpoint implementations.

Thanks,
	Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Grewal, Ken
> Sent: Thursday, April 30, 2009 23:39
> To: [email-masked]
> Subject: [IPsec] Issue #93: Next header value in tunnel mode for WESP
> 
> All,
> As we prepare to submit the next revision of the WESP draft, we wanted to
> get some discussion / feedback on some open ticket items.
> 
> Issue #93: Next Header field to provide the value for the tunneled packet
> if
> using tunnel mode
> 
> In the current traffic visibility draft, we indicate that the next header
> value in the WESP header is equal to the next header value in the ESP
> trailer.
> Charlie Kaufman suggested that middle boxes may not want to differentiate
> between tunnel / transport mode and just get to the payload.
> i.e. consider providing the tunneled protocol value in WESP next header
> field in the
> case of tunnel mode and the WESP offset points to the tunneled payload
> 
> Pros: easier parsing for intermediary devices
> Cons: lose consistency between next header in WESP and in ESP trailer -
> any
> security concerns?
> 
> Comments / opinions appreciated...
> 
> Thanks,
> - Ken
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> Scanned by Check Point Total Security Gateway.

---

From: "Grewal, Ken" <[email-masked]>
Date: Mon, 4 May 2009 11:43:16 -0600

Hi Yaron, 
I am inclined to agree, but wanted to raise this as an option as it was
raised during conversations at the last meeting.

Are you indicating that we should set this field to be the same value as in
the ESP trailer, irrespective of tunnel / transport mode? 

Thanks, 
- Ken

>From: Yaron Sheffer [mailto:[email-masked]]
>Sent: Sunday, May 03, 2009 6:52 AM
>To: Grewal, Ken; [email-masked]
>Subject: RE: Issue #93: Next header value in tunnel mode for WESP
>
>Hi Ken,
>

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 4 May 2009 22:54:37 +0300

Actually I'm suggesting to drop it altogether.

Thanks,
	Yaron

> From: Grewal, Ken [mailto:[email-masked]]
> Sent: Monday, May 04, 2009 20:43
> To: Yaron Sheffer; [email-masked]

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 04 May 2009 15:32:47 -0700

Hi Tero,

Thanks for the detailed review.

On 4/28/09 7:35 AM, "Tero Kivinen" wrote:

> Section 3 says:
> 
>    The gateway MUST include the nonce data from the Ni payload sent by
>    the initiator in the REDIRECT payload.  This prevents certain Denial-
> 
> but the figures showing how redirect is done does not include Ni data
> in the N(REDIRECT, IP_R). Also as GW identity can also be FQDN, it is
> bit misleading to use IP_R in the payload, perhaps New_GW_ID would be
> better. I.e. it would be better to write the reply as:
> 
>                               (Initial_IP_R:500 -> IP_I:500)
>                           <-- HDR(A,0), N(REDIRECT, New_GW_ID, Ni_data)
> 
> Similar change is also needed in later sections too.
> 
> ---
> 
> In section 5 it should be:
> 
>                                <--  HDR, SK {N(REDIRECT, New_GW_ID,)}
> 
> (also changed the N[] to N() as is used normally).
> 
> ---
> 
> In section 6 it should be:
> 
>                                   (IP_R:500 -> IP_I:500)
>                               <-- HDR(A,B), SK {IDr, [CERT,] AUTH,
>                                            N(REDIRECT, New_GW_ID,)}

Fixed all of the above.
 
> (Again changed the N[] to N()). This section does not say whether the
> Ni is included in the response, but I assume it is omitted as there is
> no need for it. This section should make it clear whether it is
> included or omitted.

It is included only in the IKE_SA_INIT response. Section 7.2 says

   The 'Nonce Data' field
   is present in the REDIRECT payload only when the REDIRECT payload is
   sent in the IKE_SA_INIT response message.  It MUST NOT be included in
   the REDIRECT payload if sent in an IKE_AUTH response or in a gateway-
   initiated redirect message.

I hope this is sufficient.

> In section 6 the text:
> 
>    In such cases, the gateway should send the REDIRECT notification
>    payload in the final IKE_AUTH response message that carries the AUTH
>    payload and the traffic selectors.  The gateway MUST NOT send and the
>    client MUST NOT accept a redirect in an earlier IKE_AUTH message.
> 
> is bit confusing. First it says the gateway (lowercase) should send
> REDIRECT in final IKE_AUTH response that carries the AUTH payload and
> traffic selectors. Then it says that gateway MUST NOT send redirect in
> earlier messages.
> 
> Firstly the final IKE_AUTH response willnot include the traffic
> selectors, as they are omitted if client is redirected. Thus it is
> misleading to say "that carries the AUTH payload and traffic
> selectors".

Please see my response to Pasi's email. This text has been updated. Redirect
during the first IKE_AUTH response is always allowed even when EAP or
multiple authentication is used.
 
> Secondly, it is not clear whether the "In such cases" only refers to
> the cases wher gateway decides to do something (interact with AAA
> server/ use external authentication server), or in all cases where EAP
> or multiple authentication is used. If it is in all cases where EAP or
> multiple authentication is used, then that means gateway cannot
> redirect in first IKE_AUTH (which is fine for me, but I am not sure if
> that was meant). If it is only when gateway needs AAA/external
> authentication server, then how can client enforce the "MUST NOT
> accept redirect in an earlier IKE_AUTH message", if it does not know
> whether gateway needs to consult external authentication server or AAA
> server...
> 
> In general the text is so confusing that I am not sure what is meant.
> One easy way to solve this problem is to say things clearly, i.e.
> either add one of the following texts:
> 
>   If multiple IKE_AUTH exchanges are used the REDIRECT notification
>   payload MUST be in the IKE_AUTH response from gateway to the client,
>   which also includes the gateways AUTH payload. With EAP, there is
>   two possible places (first IKE_AUTH and last IKE_AUTH). With
>   multiple authentication support there are AUTH payload after each
>   authentication finished, thus server can redirect after each
>   authentication step is finished. REDIRECT notification MUST NOT be
>   sent or accepted in any other messages than those having AUTH
>   payload. 
> 
> or
> 
>   If multiple IKE_AUTH exchanges are used the REDIRECT notification
>   payload MUST be in the final IKE_AUTH response from the gateway to
>   the client, i.e the one that contains the AUTH payload, and that
>   would also contain the Child SA SA payload and traffic selectors,
>   if connection would not have redirected. REDIRECT notification MUST
>   NOT be sent or accepted in any of the earlier IKE_AUTH messages.

If the gateway decides to redirect after the first authentication, it would
be the same as the exchange in section 6. The second authentication would
not even happen. If the redirect is as a result of interaction with an
external authentication server, then the redirect happens in the final
IKE_AUTH message.

> In section 7.2 the first paragraph says that "The message includes the
> new responder's IP address.", but this payload can also include FQDN,
> I think it should be changed to "The message includes the
> new responder's IP address or DNS name.".

Fixed.

> In section 7.2. the GW Identity Type should be made to be IANA
> allocated registry. We have already had all kind of problems when we
> have such registries which are not clearly defined, and then someone
> wanted to add entries to there.

Creating an IANA registry is fine with me. I will add text in the IANA
considerations section.

> It would also be good to explicitly say that IPv4 address are encoded
> as 4 octects, and IPv6 addresses are encoded as 16 octets, and that
> the FQDN of the new VPN gateway is encoded as dns name without any
> terminators (e.g., NUL, CR, etc). Perhaps it would be good to
> cut & paste the similar parts from the section 3.5 of the rfc4306.

I added the following text.

  The IPv4 address, the IPv6
  address or the FQDN of the new VPN gateway MUST be encoded as
  described in section 3.5 of [RFC4306].

> ---
> 
> In section 7.3 it is not clear whether this registry used for GW Ident
> Type is same as in section 7.2 or not. As it does not have same
> values, I assume it is supposed to be separate registry. In that case
> it would be better to use some different name for it, so there is no
> confusion which registry is used (for eaxmple "Original GW Ident
> Type").
> 
> As a separate registry it also need to be set up to be IANA registry.

I think we should use the same IANA registry for both.
 
> ---
> 
> The example in section 9 about the wildcard is not good, as it is not
> mandatory to support such wildcard format. The section 4.4.3.1 or
> RFC4301 uses partial DNS names, thus it requires that omitted parts
> are separate dns labels (text from RFC4301):
> 
>            o DNS name (specific or partial)
>            o Distinguished Name (complete or sub-tree constrained)
>            o RFC 822 email address (complete or partially qualified)
>            o IPv4 address (range)
>            o IPv6 address (range)
>            o Key ID (exact match only)
> 
>    The first three name types can accommodate sub-tree matching as well
>    as exact matches.  A DNS name may be fully qualified and thus match
>    exactly one name, e.g., foo.example.com.  Alternatively, the name may
>    encompass a group of peers by being partially specified, e.g., the
>    string ".example.com" could be used to match any DNS name ending in
>    these two domain name components.
> 
> This means that the text should not use "GW*.example.com" as an
> example, but use ".sgw.example.com" instead, as that conforms to
> mimimal requirements of the RFC4301.

Good point. In addition, RFC 4301 says

   Alternatively, the name may
   encompass a group of peers by being partially specified, e.g., the
   string ".example.com" could be used to match any DNS name ending in
   these two domain name components.

So we might not have to give an example at all. Here is the new text

   In particular, the client MUST use the same Peer Authorization
   Database (PAD) and Security Policy Database (SPD) entries as it would
   have used with the original gateway.  Receiving a redirect
   notification MUST NOT result in the modification of any PAD or SPD
   entries.  In practice, this means the new gateway either has to
   either use the same responder identity (IDr) as the original gateway,
   or both should be part of a group of responders that are authorized
   by the same PAD entry.  See section 4.4.3.1 of [8] on using DNS names
   to represent a group of peers in a PAD entry.
 
> Section 10 also needs to create those two "GW Ident Type" and
> "Original GW Ident Type" registries, and specify what allocation rules
> are required for them. I.e reserver numbers 4/3 - 240 to IANA,
> allocate numbers 241-255 to private use, and add text saying that
> "Changes and additions to any of those registries are by expert
> review.".

I added the following text to the IANA section.

   This document creates a new namespace called the "Gateway Identity
   Type".  This is used to indicate the type of information regarding
   the VPN gateway that is carried in the REDIRECT Section 7.2 and
   REDIRECTED_FROM Section 7.3 Notification payloads.  The following
   values are assigned.

      1 - IPv4 address of the new VPN gateway
      2 - IPv6 address of the new VPN gateway
      3 - FQDN of the new VPN gateway

   Values '0', and 4-255 are reserved.  New values can be allocated by
   expert review.

Vijay

---

From: Satinder Singh <[email-masked]>
Date: Tue, 05 May 2009 09:45:43 +0530

The information contained in this electronic mail transmission 
may be privileged and confidential, and therefore, protected 
from disclosure. If you have received this communication in 
error, please notify us immediately by replying to this 
message and deleting it from your computer without copying 
or disclosing it.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 5 May 2009 14:51:09 +0300

> I hope this is sufficient.

I found that later, but when I was reading the protocol description in
section 6 I was wondering whether the nonce is included or not. It
might be enough to explain that in the description of the payload
itself, especially now if the N(REDIRECT, New_GW_ID,) in example
clearly indicates nonce is empty. 

> multiple authentication is used.

The text was not very clear about this. I will wait to see next
version to see if that is clearer.

> If the gateway decides to redirect after the first authentication,
> it would be the same as the exchange in section 6. The second
> authentication would not even happen.

If initiator decides to use EAP, then the exchange is not same as in
section 6, as the initiator has not proven his identity yet. The first
authentication only authenticates the identity of the server.

If Shared secret or certificates are used then both ends identities
are authenticated during the first IKE_AUTH exchange.

With multiple authentications the server can at any point decided that
it has had enough authentication and ignore the ANOTHER_AUTH_FOLLOWS
wish from client (as far as I understand the rfc4739), thus it can at
any point when authentication is finished decided to finish the whole
IKE_SA creation and send final AUTH.

I think we need bit more text there explaining how this is supposed to
work. 

> If the redirect is as a result of interaction with an external
> authentication server, then the redirect happens in the final
> IKE_AUTH message.

How is the client supposed to know whether server decides to redirect
as a result of interaction with an external authentication server, and
make sure server cannot redirect during first IKE_AUTH exchange.

The MUST in draft says that client MUST NOT accept redirect in any
earlier message.

As there is no way for client to know for this, there is no point of
putting such requirement there.

> I think we should use the same IANA registry for both.
...
>    Values '0', and 4-255 are reserved.  New values can be allocated by

So FQDN is allowed in the REDIRECTED_FROM payload too?

It is bad idea to share the registries if they can have different
values. We already had this problem in the IKEv2, as the encryption
algorithms registry was shared with both IKEv2 and ESP, and not all of
the algorithms could be used in IKEv2 (combined mode ciphers), and the
registry didn't indicate this in any way.

So either use two registries, or specify explicitly which values are
usable in which payload.
-- 
[email-masked]

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 05 May 2009 08:01:25 -0700

Hi Tero,

> putting such requirement there.

Lets discuss the multiple auth case in today's virtual meeting. I have a
slide on that.
 
> So FQDN is allowed in the REDIRECTED_FROM payload too?

No. I added text in both sections 7.2 and 7.3 that says which values are
valid in the REDIRECT and REDIRECTED_FROM payload.

> So either use two registries, or specify explicitly which values are

I did the latter.

Vijay

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 May 2009 17:12:09 -0400

> is in complicating the protocol and the endpoint implementations.

Have we received any review yet from companies/individuals that actually
build the hardware involved?  (I'm out of that business for 8 years myself).

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 12 May 2009 04:41:41 +0530

Hi,

I'd personally like to see the "Next Header" field retained in the WESP header. It becomes extremely easy for the ASICs (even off the shelf ones like Broadcom, Wintegra, etc) to look at a fixed offset in the packet for a particular byte pattern and decide on what it needs to do with that packet. By removing the "Next Header" it becomes quite difficult to do this in the fast path unless one has customized ASICs used in their Hardware. 

In our current implementation it is trivial to add a HW filter which says the following:

Drop all WESP traffic if its carrying TCP to port 8008 (we could also specify the source/dest IP)

This is possible because I know exactly where to look at in the incoming packet and decide based on that.

Is there a strong reason for doing away with the "Next Header" field in the WESP header as was suggested some time back?

Cheers, Manav 

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Michael Richardson
> Sent: Wednesday, May 06, 2009 2.42 AM
> To: [email-masked]
> Subject: Re: [IPsec] Issue #93: Next header value in tunnel 
> mode for WESP
> 
> Yaron Sheffer wrote:
> > Hi Ken,
> >

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 11 May 2009 16:27:13 -0700 (PDT)

Per my recollection, during the interim last week, Yaron clarified that even though he had made 
the suggestion to do away with the Next Header field, he did not feel strongly about it. 

His point is valid, though: if it is not found to be useful, then the field should not be included.
Your point below about Next Header being useful is specially valuable as it is from someone 
involved in developing these boxes.

Gabriel

----- Original Message ----
> From: "Bhatia, Manav (Manav)" <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Sent: Monday, May 11, 2009 4:11:41 PM
> Subject: [IPsec] Next Header field in WESP header
> 
> Hi,
> 
> I'd personally like to see the "Next Header" field retained in the WESP header. 
> It becomes extremely easy for the ASICs (even off the shelf ones like Broadcom, 
> Wintegra, etc) to look at a fixed offset in the packet for a particular byte 
> pattern and decide on what it needs to do with that packet. By removing the 
> "Next Header" it becomes quite difficult to do this in the fast path unless one 
> has customized ASICs used in their Hardware. 
>

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 12 May 2009 11:54:04 +0300

On reconsideration, I agree with Manav that the NH field will be useful for
hardware implementations. Let's keep it.

Thanks,
	Yaron

> gabriel montenegro
> Sent: Tuesday, May 12, 2009 2:27
> To: Bhatia, Manav (Manav); [email-masked]
> Subject: Re: [IPsec] Next Header field in WESP header
> 
> 
> Per my recollection, during the interim last week, Yaron clarified that
> even though he had made the suggestion to do away with the Next Header
> field, he did not feel strongly about it.
> 
> Your point below about Next Header being useful is specially valuable as
> it is from someone involved in developing these boxes.
> 
> Gabriel
> 
> 
> > It becomes extremely easy for the ASICs (even off the shelf ones like
> > Broadcom, Wintegra, etc) to look at a fixed offset in the packet for a
> > particular byte pattern and decide on what it needs to do with that
> > packet. By removing the "Next Header" it becomes quite difficult to do
> > this in the fast path unless one has customized ASICs used in their
> Hardware.
> >
> > In our current implementation it is trivial to add a HW filter which
> > says the
> > following:
> >
> > This is possible because I know exactly where to look at in the
> > incoming packet and decide based on that.
> >
> > Is there a strong reason for doing away with the "Next Header" field
> > in the WESP header as was suggested some time back?
> >
> > Cheers, Manav
> >
> > > From: [email-masked] [mailto:[email-masked]] On
> > > Behalf Of Michael Richardson
> > > Subject: Re: [IPsec] Issue #93: Next header value in tunnel mode for
> > > WESP
> > >
> > > Yaron Sheffer wrote:
> > > > Hi Ken,
> > > >
> > > Have we received any review yet from companies/individuals that
> > > actually build the hardware involved?  (I'm out of that business for
> > > 8 years myself).
> > >
> > >

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 May 2009 12:00:53 +0300

gabriel montenegro writes:
> Your point below about Next Header being useful is specially
> valuable as it is from someone involved in developing these boxes.

If the box can do IPv6 header processing (which do require similar
offset calculations) to find the WESP header in the first place, then
doing packet length - ICV length (from packet) and get byte from there
is not that complicated and hardware can most likely do that already.

And I hope nobody is designing new hardware now which cannot do IPv6
processing... 
-- 
[email-masked]

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 12 May 2009 16:17:39 +0530

There are a lot of boxes deployed in the field that cant do what you seem to be suggesting. 

If we are to pick up the "Next Header" from the ESP trailer then we need to parse the entire packet with the variability in the ICV length. This would entail storing the entire IPv4/Ipv6 packet (coming at line rate) in the silicon's buffer which would need to be really large. Not many boxes would be able to do that. However, if we specify the "Next Header" in the WESP header than most HWs capable of deep inspecting the first 128 bytes would be able to discern the packet.

Is there an issue in keeping "Next Header" in the WESP header? I see an advantage in doing so. Would like to hear arguments against it!

Cheers, Manav

> From: Tero Kivinen [mailto:[email-masked]] 
> Sent: Tuesday, May 12, 2009 2.31 PM
> To: gabriel montenegro
> Cc: Bhatia, Manav (Manav); [email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 May 2009 15:58:02 +0300

> There are a lot of boxes deployed in the field that cant do what you

Those deployed boxes will need updates anyways, as they do not support
WESP either... 

> If we are to pick up the "Next Header" from the ESP trailer then we
> need to parse the entire packet with the variability in the ICV
> length.

Note, that if you want to have port numbers, you still need to do
variable offset based on the IV length also. 

> This would entail storing the entire IPv4/Ipv6 packet
> (coming at line rate) in the silicon's buffer which would need to be
> really large.

Yes. With ethernet 1500 bytes is normally enough though. Might be
different situation if IPv6 jumbograms are used.

> Not many boxes would be able to do that.

I think most of the firewall / security processor type chips I know do
that anyways (most of those are chips doing IPsec, thus they are bit
more powerful than the very basic chips).

Can you list some (new) chips that cannot access the full packet?

> However, if we specify the "Next Header" in the WESP header than
> most HWs capable of deep inspecting the first 128 bytes would be
> able to discern the packet.

That might not be enough for IPv6, and suddenly noticing at that point
that you need more data could make HW quite complex.

> Is there an issue in keeping "Next Header" in the WESP header? I see
> an advantage in doing so. Would like to hear arguments against it! 

I think the most of the concerns were bacause then we have two Next
Header fields, and there could be security concerns because of that.

On of the options would of course then be to get rid of the Next
Header field at the end, and only have that in the WESP header. Or we
can mandate that recipient IPsec node MUST drop the packet if next
header field in the WESP header and the next header field in the end
are different.

Then there is also question what if the next header field in the WESP
header is 0, should the recipient IPsec node drop the packet if packet
was ESP-NULL and still had next header field in WESP header of 0?

I am not really strongly against the next header field in the WESP
header, I am just sure we have good reasons to duplicate data which
might cause security implications before we do that.

I am not fully convinced that the cannot get the next header field
from the end is good enough reason for adding possible security
problems and more complicated protocol.

Especially when we are talking about new HW designs coming after WESP
is specified. If old HW design can be made to understand WESP then it
most likely is already one of those more complex security processor
type things which do get full packet anyways.
-- 
[email-masked]

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 12 May 2009 19:18:19 +0530

> Those deployed boxes will need updates anyways, as they do not support

I had meant that there are boxes currently deployed in the field which would have HW capable of only looking at the fixed offsets. SW is a commodity item and can always be upgraded. If you have Next Header in the WESP header then some bit of filtering (at least at the protocol level) can still be done without upgrading the HW. 

> different situation if IPv6 jumbograms are used.

I am talking about routers and switches here. Their main job is not to deep inspect the packets but to route/switch them. Filtering is a capability added to them and most of them would not look at the entire 1500 bytes to figure out the contents of the packets (they're not even meant to do that). As I stated earlier, most would pick up the first 128 or so bytes and filter based on that.

> more powerful than the very basic chips).

That's the disconnect then. I am talking about routers/switches where we might want to deep inspect the packet for different QoS/Policy reasons.
 
> Can you list some (new) chips that cannot access the full packet?

You can look at Broadcom and Wintegra. I could be mistaken but I don't think they read the *entire* packet for content aware filtering. You can contact me offline if you want more details on the specific chipset(s) I am referring to.
 
> header field in the WESP header and the next header field in the end

This is mentioned in the draft.

> was ESP-NULL and still had next header field in WESP header of 0?

Yup, I thought we were clear on this; patently, I was mistaken ;-) 

Next Header of 0 implies that the packet uses encryption and the intermediate nodes MUST not attempt to read them. If the end node finds that this isn't true, then it MUST drop the packet.

> might cause security implications before we do that.

Point well taken.

> type things which do get full packet anyways.

Not really. Most network processors have a capability of defining user defined fields (UDFs) which the chip looks at in the incoming packet. Using that it becomes trivial to implement and support WESP without any HW change. This to me is a big reason why we must have the Next Header in the WESP header. 

A compliant implementation can trivially check the sanity of the Next Header field before accepting the packet and this doesn't really sound like a security hole to me (unless I am missing out on something!).

Cheers, Manav

---

From: Stephen Kent <[email-masked]>
Date: Tue, 12 May 2009 11:18:18 -0400

If we elect to keep the next header field, to help middle boxes 
quickly locate header fields of interest to them, then we MUST 
require the recipient of each message to do a (well-defined) 
consistency check on the packet, for the reasons I cited in  SF.

Steve

---

From: gabriel montenegro <[email-masked]>
Date: Wed, 13 May 2009 12:25:19 -0700 (PDT)

We agree, and tried to capture that in the current version at:
http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-02 

with text such as:

   Next Header, 8 bits:  If using ESP-NULL, this field MUST be
   equal to the Next Header field in the ESP trailer. If using ESP
   in encryption mode, this field MUST be set to zero..

and in the security considerations section:

   ESP is end-to-end and it will be impossible for the intermediate
   devices to verify that all the fields in the WESP header are
   correct. It is thus possible to tweak the WESP header so that
   the packet sneaks past the firewall if the fields in the WESP
   header are set to something that the firewall will allow. The
   endpoint thus must verify the sanity of the WESP header before
   accepting the packet. In an extreme case, someone colluding with
   the attacker, could change the WESP fields back to the original
   values so that the attack goes unnoticed. However, this is not a
   new problem and it already exists IPSec.

Perhaps we need more details on what exactly we mean by "the
endpoint thus must verify the sanity of the WESP header before accepting
the packet"? And the action to drop the offending packet?

----- Original Message ----
> From: Stephen Kent <[email-masked]>
> To: "Bhatia, Manav (Manav)" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>; gabriel montenegro <[email-masked]>; Tero Kivinen <[email-masked]>
> Sent: Tuesday, May 12, 2009 8:18:18 AM
> If we elect to keep the next header field, to help middle boxes quickly locate 
> header fields of interest to them, then we MUST require the recipient of each 
> message to do a (well-defined) consistency check on the packet, for the reasons 
> I cited in  SF.
> 
> Steve

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 14 May 2009 12:01:35 +0300

> the packet"? And the action to drop the offending packet?

Yes. I think we need very specific rules with MUSTs in them to say
that packet MUST be dropped if ESP-NULL packet has Next header field
in WESP header which do not match the real Next Header field in the
end. Also final recipient MUST check that the HdrLen or TrailerLen
fields in the WESP header match the negotiate SA and MUST drop the
packet if they do not match.

Next question is what values are used for HdrLen and TrailerLen if
encrypted ESP is used. If we use real values we do leak out
information, but on the other hand there is no point of giving that
information out as middle nodes cannot do anything with it.

Actually what are we trying to do if we send encrypted ESP with WESP
wrapper. If we are just making so that we can extend the WESP header
in the future, isn't the version bits enough for that? I mean if we do
not know why someone would want to use WESP encoding for encrypted ESP
now, why do we allow it?
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 14 May 2009 12:12:09 +0300

Hi Tero,

I agree that the HdrLen and TrailerLen fields MUST be 0 for encrypted WESP.
So yes, we use WESP for encrypted traffic to get:

- Extensibility (with the 8-bit Flags field).
- A single protocol that can do both cases.

Thanks,
	Yaron

> Tero Kivinen
> Sent: Thursday, May 14, 2009 12:02
> To: gabriel montenegro
> Cc: [email-masked]; Bhatia, Manav (Manav); Stephen Kent

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 14 May 2009 13:38:22 +0300

> - Extensibility (with the 8-bit Flags field).

This is future extensibility, which is needed only after we define
some future extensions using this. When we define those future
extensions we can also define that encrypted traffic can be used.

I would rather keep this for future extension, i.e. only define the
use after we find out what we want to do, as all the end nodes needs
to be updated anyways before those new extensions can be used (and the
intermediate nodes too perhaps).

The current document is not very clear what to do if reserved bits are
set. It says "On receiving a packet, these values must be checked to
ensure that they are as indicated above.". This does not specify
whether this is only for the final receiver (i.e. the node talking
IPsec), or also all intermediate nodes, or only those intermediate
nodes who actually look inside the WESP or what. It also does not
specify what needs to be done if those fields are not as specified.

I.e. we need more text for that, i.e. specific processing rules for a)
intermediate nodes who parse WESP header, b) end IPsec entity. In some
cases the dropping / passbying the packet depends on the policy. On
the other hand if flags is set or version number does not match then
that usually means that the format of the WESP header might be
different thus it might be that intermediate nodes cannot parse header
any further.

> - A single protocol that can do both cases.

By wasting extra 4 bytes and using protocol which might not be
supported by other end. I think it is better to use plan normal ESP
for encrypted traffic, but I agree that we should probably define the
WESP header so that if Next Header in WESP header is 0 then contents
is encrypted, and intermediate nodes MUST NOT try to parse it.

I would still recommend using normal ESP for encrypted traffic... 
-- 
[email-masked]

---

From: "Grewal, Ken" <[email-masked]>
Date: Thu, 14 May 2009 10:10:50 -0600

I agree in the most part. From other comments, it appears that the Next Header is providing a useful function and if we are keeping it anyway, then the Next Header value of zero also provide a useful function (i.e. payload protocol is opaque, hence data is encrypted). 

I also agree that the text for packet handling by intermediate nodes and ultimate recipients could be improved and we need explicit verbiage (with MUSTs) to describe the behavior. 

Perhaps it would be useful to get an early next rev of the draft out with these changes to ensure that we have the correct verbiage in place...

I will send out a separate summary of where we are with the open ticket items.