Subject: Re: [IPsec] Proposed work item: WESP extensibility - YES

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 3 Dec 2009 07:56:42 +0530

[mail snipped]

> - If this proposal is accepted as a WG work item, 
> are you committing to review multiple versions of the draft?
Yes
> - Are you willing to contribute text to the draft?
Yes
> - Would you like to co-author it?
Yes

I believe the OAM extension described in the draft is useful and I would like to see this discussed further in the WG.

Cheers, Manav

---

From: Brian Swander <[email-masked]>
Date: Thu, 3 Dec 2009 17:16:25 +0000

(Apologies if this is a dupe.  I sent it out yesterday, but it still hasn't shown up on the list yet, so I figured I better resend from a different account).

Here is another WESP extension that we are interested in.

Packet Contents Option

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type (PC)    |    Length     |  ContentType  |Data (variable)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Data(variable)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Type: PacketContents (PC) option identifier (value TBD)
  Length: 2 octets
  ContentType:  type of the packet contents description
  Data: depends on the ContentType

The purpose of this option is to exchange information about the contents of the
payload data to intermediaries (network infrastructure).  This can be used both
with full payload encryption or with just integrity.   When the entire
payload data is encrypted, some intermediaries, for instance packet filterers
and deep content inspectors, lose the ability to perform their function.
With this extension, the end host can append the PacketContents option to
describe the contents of the packet for the benefit of intermediary devices.

There are many possible uses for this.  For instance, the endhost could have
a classification scheme that maps HTTP to 1, LDAP to 2, SMB to this class of
server to 3, SMB to another class of server to 4, etc.   Hence there needn't
be direct information disclosure of the encrypted data types to an attacker
who didn't have access to the policy.

Another possible use would be to expose the full URL for the request by duplicating
it into the option.

An example of a use for this with integrity only encapsulation is to flag things that are difficult to deduce by an intermediary.  For instance, RPC commonly runs on dynamic ports.  So we can flag the RPC packets with a specific tag.

Clearly this puts trust in the end-system to apply the correct markings.  But in a fully encrypted end-to-end environment, the intermediaries must trust the end systems somewhat anyway. And for integrity-only mode, these markings could be treated as hints to aid parsing.

brian

From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaron Sheffer
Sent: Sunday, November 29, 2009 9:21 AM
To: [email-masked]
Subject: [IPsec] Proposed work item: WESP extensibility

This draft proposes an extensibility framework for WESP, as well as several specific extensions.

Proposed starting point: http://tools.ietf.org/id/draft-montenegro-ipsecme-wesp-extensions-00.txt.

Please reply to the list:

- If this proposal is accepted as a WG work item, are you committing to review multiple versions of the draft?

Please also reply to the list if:

- You believe this is NOT a reasonable activity for the WG to spend time on.

If this is the case, please explain your position. Do not explore the fine technical details (which will change anyway, once the WG gets hold of the draft); instead explain why this is uninteresting for the WG or for the industry at large. Also, please mark the title clearly (e.g. "DES40-export in IPsec - NO!").

---

From: Jack Kohn <[email-masked]>
Date: Fri, 4 Dec 2009 07:50:00 +0530

I will be interested in reviewing this and might also contribute some
text to the draft.

Jack

On Sun, Nov 29, 2009 at 10:50 PM, Yaron Sheffer <[email-masked]> wrote:
> Proposed starting point:
> http://tools.ietf.org/id/draft-montenegro-ipsecme-wesp-extensions-00.txt.
>
>
>
> If this is the case, please explain your position. Do not explore the fine
> technical details (which will change anyway, once the WG gets hold of the
> draft); instead explain why this is uninteresting for the WG or for the
> industry at large. Also, please mark the title clearly (e.g. "DES40-export
> in IPsec - NO!").
>
>
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Dec 2009 22:17:33 -0500

> http://tools.ietf.org/id/draft-montenegro-ipsecme-wesp-extensions-00.txt.

I am not interested in any further extensions to WESP.
In particular, I think we are creating mechanisms in advance of problems.

---

From: Daniel Migault <[email-masked]>
Date: Fri, 4 Dec 2009 15:44:01 +0100

I am interested in WESP Extension and would like to co-author it. Our
interest in WESP extensions are to ease IPsec deployment within Intranet
security AND Middle Boxes. We expect WESP would be able to provide Network
administrators information related on IPsec and Middleboxes interactions.

Regards,
Daniel

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

---

From: Brian Swander <[email-masked]>
Date: Mon, 7 Dec 2009 17:23:04 +0000

I am interested in WESP extensibility proceeding as a chartered work item.

I will commit to reviewing the draft, and providing text.   I don't need to be a co-author.

bs

---

From: Stephen Kent <[email-masked]>
Date: Mon, 7 Dec 2009 10:45:48 -0500

Brian,

I wasn't sure, form your brief description, whether you envisioned 
any crypto protection for this version of WESP. If not, then this 
added info is not protected and might be modified en route. This 
seems like a possibly dangerous feature, as it says that we are 
causing an intermediate system (e.g., a firewall) to make decisions 
on passing packets based on unauthenticated info. If the WESP data 
were protected it would raise questions about how we effect key 
distribution, and why this form of SA nesting is more attractive than 
the nested SA support that was pulled from IPsec as we went from 2401 
to 4301.

Steve

---

From: Brian Swander <[email-masked]>
Date: Mon, 7 Dec 2009 18:24:48 +0000

0 - option data does not change en-route. This option is
   included in the WESP ICV computation.

We'll be using this flag, so this option will always be integrity protected.

I'm not sure what you mean by effecting key distribution.   

In the integrity only case, the intermediaries can still see into the packet.  In the fully encrypted ESP case, only the WESP extension will be visible, and the intermediaries will have to trust the end systems to do the correct marking.   If that is not acceptable to a given deployment, the customer always has the policy option to disable this, and just have the end systems send fully encrypted packets thru the now totally blind intermediaries like we have today.

bs

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Monday, December 07, 2009 7:46 AM
To: Brian Swander
Cc: [email-masked]
Subject: Re: [IPsec] Proposed work item: WESP extensibility

Brian,

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 7 Dec 2009 14:43:07 -0500

>We'll be using this flag, so this option will always be integrity protected.

integrity protected for checking by the end system, but not 
verifiable by the intermediate system.

>I'm not sure what you mean by effecting key distribution.

what I meant was that the intermediate system cannot verify the WESP data.

>    In the integrity only case, the intermediaries can still see into 
>the packet.  In the fully encrypted ESP case, only the WESP 
>extension will be visible, and the intermediaries will have to trust 
>the end systems to do the correct marking.

And the end system will have to check another set of data, which may 
be complex. A while ago I noted a vulnerability in a prior version of 
WESP.  Specifically, the (ultimate) recipient of the WESP packet has 
to verify that the Next Header and the HdrLen fields are consistent 
with the encapsulated content that it is processing.  Othwewise, an 
attacker could change these fields to make the packet acceptable to 
an intermediate system but be different from what the recipient 
processes.

This proposed extension would require that the recipient MUST also 
verify that the data being made available to intermediaries for 
packet inspection is consistent with the data being delivered as 
IPsec output. At the current level of specification, this additional 
processing is arbitrary. If I were a hardware IPsec vendor I would 
worry about the possible implications of this sort of facility.

Steve

---

From: Brian Swander <[email-masked]>
Date: Mon, 7 Dec 2009 19:50:42 +0000

In case it wasn't clear for the earlier WESP discussions, we need this to also work with simple transport mode: i.e. not just transport mode inside tunnels terminating at various infrastructure, and not just in tunnel mode.  

The transport nesting from 2401 doesn't give us what this extension proposal does.

bs

-----Original Message-----
From: Brian Swander 
Sent: Monday, December 07, 2009 10:25 AM
To: 'Stephen Kent'
Cc: [email-masked]
Subject: RE: [IPsec] Proposed work item: WESP extensibility

bs

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Monday, December 07, 2009 7:46 AM
To: Brian Swander
Cc: [email-masked]
Subject: Re: [IPsec] Proposed work item: WESP extensibility

Brian,

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 7 Dec 2009 16:42:43 -0500

At 7:50 PM +0000 12/7/09, Brian Swander wrote:
>In case it wasn't clear for the earlier WESP discussions, we need 
>this to also work with simple transport mode: i.e. not just 
>transport mode inside tunnels terminating at various infrastructure, 
>and not just in tunnel mode. 
>

Understood.  And I agree that transport mode inside of a tunnel does 
not provide comparable functionality.

Steve

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 8 Dec 2009 13:25:47 +0200

> We'll be using this flag, so this option will always be integrity

One of the things that disturb me here is that AH was not acceptable
because of the complexity and because it didn't go through NATs, and
now we are thinking of adding lots of complexity to the WESP (perhaps
even more than what AH had by looking at some of the discussion).

Perhaps it would be better to go back and say use AH instead, at least
for that we would have some implementations and even when there is
perhaps much less testing done on the AH than to ESP, it has still
lots of more testing and experience than what we have from WESP...

I still think that extending WESP in any ways is very bad idea, and if
it is to be done, we need to first start from the exact scenarios
where those extensions are needed, not make any generic framework
or protocol document before we know what problems we are solving.

This same thing was problematic for WESP. I am still not sure what
problem we are solving, even when I am author of the another draft
solving same "problems" than WESP. Every time someone starts
discussing about the problems, it seems the problem is completely
different...
-- 
[email-masked]

---

From: Brian Swander <[email-masked]>
Date: Wed, 9 Dec 2009 17:20:55 +0000

AH alone isn't good enough.  We need solutions that also work with end-to-end encryption.

bs

---

From: Stephen Kent <[email-masked]>
Date: Wed, 9 Dec 2009 16:19:43 -0500

>AH alone isn't good enough.  We need solutions that also work with 
I think you are saying that it is a goal of those who are proposing 
the WESP extension work item to move beyond the original, stated 
goals of WESP, and provide middleboxes the ability to examine 
purported contents of encrypted packets.  I will observe that this 
notion suggests copying portions of plaintext that is being encrypted 
into a WESP extension header, which is close to the partial 
encryption proposals that the IPSEC Wg rejected on multiple 
occasions, for secruity reasons.

I also note that my last two e-mail exchanges with Jack Kohn did not 
elicit a clarification of the one vs. many SAs issue that was raised 
in the context of OSPFv3 use of IPsec, as part of the justification 
for using WESP there.  Absent a definitive statement that this 
context requires a lot of SAs, the arguments put forth about the need 
for ESP in that context are moot.

Steve

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 10 Dec 2009 11:29:24 +0200

> AH alone isn't good enough.  We need solutions that also work with

Then we are not talking about ESP-NULL traffic anymore, thus it falls
outside the scope of our WESP charter:

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

WESP is not meant to be used for encrypted traffic, it was designed to
be used to detect encrypted ESP packets from ESP-NULL packets. 
-- 
[email-masked]