Subject: [IPsec] WESP - Roadmap Ahead

From: Jack Kohn <[email-masked]>
Date: Wed, 11 Nov 2009 21:35:55 +0530

Hi,

>From operational perspective if we are supporting both v4 and v6 (and we
will) then having different protocols ESP and AH is and will be a
nightmare.  Common denominator is ESP-Null. However, there were issues with
ESP-Null as it couldnt be deep inspected which has now been solved with
WESP.

In short, the argument that "Oh, but we can inspect AH packets" is not
relevant anymore.

Given this, should we still have AH as a MAY for IPSEC - Cant we deprecate
it?

WESP is ESP++, and it offers everthing that ESP offers plus more. What is
our stance for ESP moving forward?

Also, I see that a lot of work done in other WGs is still using ESP
(primarily for data integrity). Shouldn’t they be moving to WESP, as WESP
offers more flexibility?

Jack

---

From: Stephen Kent <[email-masked]>
Date: Wed, 11 Nov 2009 15:56:39 -0500

Jack,

I would have no problem deprecating AH in the context of the IPsec 
architecture document, if others agree. It is less efficient  than 
ESP-NULL. However, other WGs have cited AH as the IPsec protocol of 
choice for integrity/authentication in their environments, so there 
will be a need to coordinate with them, and it may be unacceptable to 
kill AH as a standalone protocol for them.

I am not comfortable with the notion of ESP with WESP.  WESP adds 
more per-packet overhead than ESP, and some users are very sensitive 
to this aspect of IPsec use. Also, other WG rely on ESP and we would 
need to convince them that the packet inspection features of WESP 
merit making changes to their standards, which might be a tough sell. 
So, I cannot support this suggestion.

Steve

---

From: Scott C Moonen <[email-masked]>
Date: Wed, 11 Nov 2009 16:06:34 -0500

Jack, I'm not sure it's clear yet whether WESP will be widely adopted. 
There's disagreement between end-node and middle-node folks as to whether 
WESP or heuristics are the best approach for inspection of ESP-NULL 
traffic.  I think that end-node vendors will be very reluctant to adopt 
WESP widely until there is broad customer demand for it, and I'm not sure 
that this demand will ever materialize.

This is all my personal opinion, of course.  But it seems to me that 
heuristics will have to be adopted by competitive middle-node vendors, and 
therefore (barring any extensions to WESP that make it attractive for 
other reasons) the use of heuristics will probably always be more 
widespread and will dampen the demand for WESP.  Additionally, ESP-NULL 
itself has rather narrow applicability in an environment where end-to-end 
encryption is increasingly common, which further limits the cases where 
there will be an absolute need for WESP.  Furthermore, there will always 
be valid reasons to use AH (reduced overhead compared to WESP).

For reasons like these, I believe it's premature to call for deprecation 
of AH and even more premature to start preferring WESP to ESP.

What status will the WESP RFC have?  Experimental, informational, 
standards track, etc.?

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

From:
Jack Kohn <[email-masked]>
To:
[email-masked]
Date:
11/11/2009 11:06 AM
Subject:
[IPsec] WESP - Roadmap Ahead

Hi,

From operational perspective if we are supporting both v4 and v6 (and we 
will) then having different protocols ESP and AH is and will be a 
nightmare.  Common denominator is ESP-Null. However, there were issues 
with ESP-Null as it couldnt be deep inspected which has now been solved 
with WESP.

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

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 12 Nov 2009 01:56:52 +0200

> that this demand will ever materialize.

I agree on that... 

> be valid reasons to use AH (reduced overhead compared to WESP).

And wider protection, i.e. IP addresses and options... 

> of AH and even more premature to start preferring WESP to ESP.

Agree on that too. 

> What status will the WESP RFC have?  Experimental, informational, 

It is aimed for proposed standard, altough I would be happier if would
be aimed for experimental. 
-- 
[email-masked]

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 12 Nov 2009 07:32:18 +0530

Scott,

> From: [email-masked] On Behalf Of Scott C Moonen
> Sent: Thursday, November 12, 2009 2.37 AM
> To: Jack Kohn
> Cc: [email-masked]; [email-masked]
> Subject: Re: [IPsec] WESP - Roadmap Ahead
>	
> WESP or heuristics are the best approach for inspection of ESP-NULL traffic.  
> I think that end-node vendors will be very reluctant to adopt 

I cant comment on the interest of the end-node vendors, but i can certainly say that this will be of interest to the router vendors. There are currently a lot of applications (routing/signaling for instance) where we use ESP-NULL for integrity protection (confidentiality is not an issue there) and it will be really good if there are ways to deep inspect these packets for proper QoS treatment.

> WESP widely until there is broad customer demand for it, and I'm not 
> sure that this demand will ever materialize. 
>	
> This is all my personal opinion, of course.  But it seems to me that heuristics 
> will have to be adopted by competitive middle-node vendors, and 
> therefore (barring any extensions to WESP that make it attractive 
> for other reasons) the use of heuristics will probably always be more 
> widespread and will dampen the demand for WESP.  Additionally, 

There you go:

http://tools.ietf.org/html/draft-montenegro-ipsecme-wesp-extensions-00

> ESP-NULL itself has rather narrow applicability in an environment where 
> end-to-end encryption is increasingly common, which further limits 

Most routing, signaling protocols use ESP-NULL (it's a MUST, while support for AH is a MAY) and I can see benefits of moving to WESP from the QoS perspective. I am not saying that we cannot do QoS with ESP, but it just becomes a tad more flexible/easier with WESP.

> the cases where there will be an absolute need for WESP.  Furthermore, 
> there will always be valid reasons to use AH (reduced overhead compared to WESP). 
>	

I agree.

>
> What status will the WESP RFC have?  Experimental, informational, standards track, etc.? 

Standards Track

Cheers, Manav

> http://www.linkedin.com/in/smoonen <http://www.linkedin.com/in/smoonen>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 12 Nov 2009 07:44:55 +0530

Steve,

> kill AH as a standalone protocol for them.

I agree that it is a trifle too early to start deprecating AH, though I wouldn't mind doing so. OTOH, don't most WGs already suggest AH as a MAY, and ESP-NULL as a MUST?  In any case what should be the stand for the newer work that comes out of these WGs. Should they spell out support for AH, or should they just be talking about ESP (or ESP-NULL or WESP)?

If we want to deprecate AH, or at least discourage its use in the context of the IPSec architecture in the near future then shouldn't we be working on this?

> merit making changes to their standards, which might be a tough sell. 

I agree. However, we should start socializing WESP in other WGs so that folks are at least aware of it. 

Cheers, Manav

---

From: Stephen Kent <[email-masked]>
Date: Wed, 11 Nov 2009 22:28:25 -0500

At 7:44 AM +0530 11/12/09, Bhatia, Manav (Manav) wrote:
>I agree that it is a trifle too early to start deprecating AH, 
>though I wouldn't mind doing so. OTOH, don't most WGs already 
>suggest AH as a MAY, and ESP-NULL as a MUST?

Not always. For example, I believe that OSPF security makes use of 
AH, outside the IPsec context.

>In any case what should be the stand for the newer work that comes 
>out of these WGs. Should they spell out support for AH, or should 
>they just be talking about ESP (or ESP-NULL or WESP)?

I'd recommend ESP-NULL, unless the context on which the operate might 
require inspection by an intermediate system.

>If we want to deprecate AH, or at least discourage its use in the 
>context of the IPSec architecture in the near future then shouldn't 
>we be working on this?

Part of the problem is that some WGs want to make use of IPsec 
protocols outside of the IPsec architecture.

>that folks are at least aware of it.

Agree.

---

From: Merike Kaeo <[email-masked]>
Date: Wed, 11 Nov 2009 19:49:29 -0800

All of the standards I've seen that explicitly define how IPsec is to  
be used for authentication (including RFC 4552 - Authentication/ 
Confidentiality for OSPFv3) say that for authentication ESP-Null MUST  
be used and AH MAY.

Which RFCs specify AH specifically as a MUST for authentication/ 
integrity?

Now on the flip side, in practical implementations, most vendors I  
know of started off with AH being used for OSPFv3 and I doubt in  
practice people are using ESP-Null.  Would love to be wrong here :)

- merike

On Nov 11, 2009, at 7:28 PM, Stephen Kent wrote:

> I'd recommend ESP-NULL, unless the context on which the operate  
> might require inspection by an intermediate system.
>
>> context of the IPSec architecture in the near future then  
>> shouldn't we be working on this?
>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 12 Nov 2009 09:30:00 +0530

> Confidentiality for OSPFv3) say that for authentication 

Yes, this is correct.

The latest PIM-SM authentication document (http://tools.ietf.org/html/draft-ietf-pim-sm-linklocal-08) uses IPSec to authenticate link-local messages in PIM-SM. It too says that ESP is a MUST while use of AH is optional.
 
> Which RFCs specify AH specifically as a MUST for authentication/ 

I am not aware of any that do that.

> practice people are using ESP-Null.  Would love to be wrong here :)

I don't think this is really true. I know of at least two major vendors that use ESP-NULL and one of them doesn't even support AH.

Cheers, Manav

> >> I agree. However, we should start socializing WESP in 
> other WGs so  
> >> that folks are at least aware of it.
> >
> > Agree.
> >

---

From: Stephen Kent <[email-masked]>
Date: Wed, 11 Nov 2009 23:07:56 -0500

At 7:49 PM -0800 11/11/09, Merike Kaeo wrote:
>All of the standards I've seen that explicitly define how IPsec is 
>to be used for authentication (including RFC 4552 - 
>Authentication/Confidentiality for OSPFv3) say that for 
>authentication ESP-Null MUST be used and AH MAY.
>
>Which RFCs specify AH specifically as a MUST for authentication/integrity?
>

Whoops, I was wrong. I looked at 4552 and they do cite ESP-NULL 
(although they never refer to it that way) as a MUST, and AH as a MAY.

I probably was confused because the authors did not understand the 
IPsec model as per RFC 4301, when I sat down and talked with them 
over 3 years ago, with Sam Hartman in his SEC AD role. I am amazed 
that, in the final analysis, they did try to adhere to the 4301 model 
(see section 11)!

I don't know if any other apps have done what I thought (erroneously) 
had been done here.

Steve

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 12 Nov 2009 09:39:23 +0530

> Confidentiality for OSPFv3) say that for authentication 

In fact there was some discussion of using IPSec for OSPFv2 authentication, and that proposal too uses ESP as a MUST and AH as a MAY.

http://tools.ietf.org/html/draft-gupta-ospf-ospfv2-sec-01

Cheers, Manav

---

From: Jack Kohn <[email-masked]>
Date: Thu, 12 Nov 2009 10:00:11 +0530

>
> Whoops, I was wrong. I looked at 4552 and they do cite ESP-NULL (although
> they never refer to it that way) as a MUST, and AH as a MAY.

Ok, so can we work on deprecating AH? This way new standards defined
in other WGs dont have to provide support for AH.

Jack

>
> I probably was confused because the authors did not understand the IPsec
> model as per RFC 4301, when I sat down and talked with them over 3 years
> ago, with Sam Hartman in his SEC AD role. I am amazed that, in the final
> analysis, they did try to adhere to the 4301 model (see section 11)!
>
> I don't know if any other apps have done what I thought (erroneously) had
> been done here.
>
> Steve
>
>

---

From: Daniel Migault <[email-masked]>
Date: Thu, 12 Nov 2009 06:44:27 +0100

> in other WGs dont have to provide support for AH.
AH is a security feature we need to keep for header authentication. Other WG
may chose not to deal with AH and only consider ESP. I don't see what's
wrong with that?

 Regards

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

---

From: Steven Bellovin <[email-masked]>
Date: Thu, 12 Nov 2009 09:54:43 -0500

On Nov 11, 2009, at 3:56 PM, Stephen Kent wrote:

> Jack,
> 
> I would have no problem deprecating AH in the context of the IPsec architecture document, if others agree. It is less efficient  than ESP-NULL. However, other WGs have cited AH as the IPsec protocol of choice for integrity/authentication in their environments, so there will be a need to coordinate with them, and it may be unacceptable to kill AH as a standalone protocol for them.

I believe that most such uses date from the "just use IPsec" era of security design.  I further suspect that it is very rarely used or even implemented in practice, and that in many cases it wouldn't in fact have been usable.

Yes, as a matter of due diligence someone needs to check if it's still mandated for anything, and if so figure out what to do.  But I'd be very happy if AH were to go awa; I concluded in 1995 that it was pretty useless.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 13 Nov 2009 06:48:13 +0530

Daniel,

> AH is a security feature we need to keep for header authentication
 
Am really not sure about the value that AH adds even in case of header authentication.
 
So what fields does AH protect:
 
Version, Payload length, Next Header, Source IP and dest IP
 
The only field worth modifying is the source and the dest IP. Now note that an IPSec SA is established between a pair of source IP and dest IP. Upon receipt of a packet containing an AH header, the receiver determines the appropriate (unidirectional) SA, based on the dest IP, security protocol (AH), and the SPI (it could also include the source IP). If the attacker modifies (or spoofs) either of the source or the dest IP, the SA lookup will fail and the receiver will regardless discard the packet. So what are we gaining by AH "header authentication"?

AH can only add value over ESP-NULL if there are instances where despite address spoofing we erroneously process the IPSec packet. I don't see that happening, so is this really an issue?

Cheers, Manav
________________________________

	From: Daniel Migault [mailto:[email-masked]] 
	Sent: Thursday, November 12, 2009 11.14 AM
	To: Jack Kohn
	Cc: Stephen Kent; [email-masked]; Bhatia, Manav (Manav); Merike Kaeo
	Subject: Re: [IPsec] WESP - Roadmap Ahead

	AH is a security feature we need to keep for header authentication. Other WG may chose not to deal with AH and only consider ESP. I don't see what's wrong with that?
	
	 Regards
	
	Daniel
	-- 
	Daniel Migault
	Orange Labs -- Security
	+33 6 70 72 69 58

---

From: Richard Graveman <[email-masked]>
Date: Thu, 12 Nov 2009 20:37:25 -0500

I think this argument implicitly assumes unicast.

Rich Graveman

On Thu, Nov 12, 2009 at 8:18 PM, Bhatia, Manav (Manav)
<[email-masked]> wrote:
>                >
>                > Whoops, I was wrong. I looked at 4552 and they do cite ESP-NULL (although
>                > they never refer to it that way) as a MUST, and AH as a MAY.
>

---

From: Stephen Kent <[email-masked]>
Date: Thu, 12 Nov 2009 20:33:11 -0500

>Version, Payload length, Next Header, Source IP and dest IP

you forgot IPv4 and IPv6  options that have predictable values at the 
destination

Steve

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 13 Nov 2009 10:12:47 +0530

> you forgot IPv4 and IPv6  options that have predictable values at the 

Lets start with the IPv6 Type 0 Route Header (aka "Source Routing" in v4 parlance), which is a mutable but a predictable extension header. It has been discovered and is widely known that these functionalities can be exploited in order to perform remote network discovery, can be used to bypass firewalls and can be used for DoS attacks. RFC 5095 has more details on this. This has been deprecated and nobody is really using this.

Hop-by-Hop Options and Destination Extension Headers

These options contain a bit that indicates whether the option might change (unpredictably) during transit.  For any option for which contents may change en-route, the entire "Option Data" field must be treated as zero-valued octets when computing or verifying the ICV.  The Option Type and Opt Data Len are included in the ICV calculation. All options for which the bit indicates immutability are included in the ICV calculation.  

If we were to use ESP-NULL instead then there is no way to validate whether the Option Type and Opt Data Len is valid or not till the processing is done at the receiving end.

So, what kind of attack can be possibly done by changing these values? What is the real risk involved here?

Fragmentation Header

Fragmentation occurs after AH processing and the reassembly, before AH processing on the other end. So, there is really no gain there too.

Cheers, Manav

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 13 Nov 2009 10:24:27 +0530

Yup, that's correct I had not considered multicast.

SSM groups would use a 3-tuple SA identifier composed of an SPI, a dest mcast address, and the source IP. An Any-Source Multicast group SA would only require an SPI and a dest mcast identifier. If either of the IPs change, wouldn't the SAD lookup fail?

Cheers, Manav

> -----Original Message-----
> From: Richard Graveman [mailto:[email-masked]] 
> Sent: Friday, November 13, 2009 7.07 AM
> To: Bhatia, Manav (Manav)
> Cc: Daniel Migault; [email-masked]; Stephen Kent; Kaeo; 
> [email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Fri, 13 Nov 2009 00:16:21 -0500

My message pointed out that there was no mention of options,  Your 
reply picked a couple of option examples and argued that they were 
either not used or did not pose a security problem.

The right way to generate a god answer is to construct a table of all 
the options, and provide a rationale for why each one is not covered, 
deprecated, or not secruity relevant.

Also, note that IPSO and CIPSO are examples of options that were 
discussed at the IPSECME meeting this week, where there is a need to 
bind the options to the payload.  I observed that using tunnel mode 
(ESP) addresses this concern, but one could also note that using AH 
would do the same, with lower per-packet bandwidth overhead.

Steve

---

From: Steven Bellovin <[email-masked]>
Date: Fri, 13 Nov 2009 12:47:03 -0500

On Nov 13, 2009, at 12:16 AM, Stephen Kent wrote:

> My message pointed out that there was no mention of options,  Your reply picked a couple of option examples and argued that they were either not used or did not pose a security problem.
> 
> The right way to generate a god answer is to construct a table of all the options, and provide a rationale for why each one is not covered, deprecated, or not secruity relevant.

Divine guidance is, I suppose, one way to do protocol design, but it could lead to *real* religious wars....
> 
> Also, note that IPSO and CIPSO are examples of options that were discussed at the IPSECME meeting this week, where there is a need to bind the options to the payload.  I observed that using tunnel mode (ESP) addresses this concern, but one could also note that using AH would do the same, with lower per-packet bandwidth overhead.

Or put the labels in the SA, since especially for IPSO you probably want cryptographic separation of different security levels.

I did go through the analysis you suggest for IPv4 and concluded that nothing was both protectable and useful.  I also noted the following issue:

	Furthermore, the AH spec says that we can't
	enumerate the v4 options, and hence whether or not they should
	be included or not -- but RFC1122 says that unknown IP options
	MUST be silently ignored.  So an implementation can receive an
	option that it doesn't recognize, doesn't know if it changes
	en route, must be ignored anyway -- but may or may not be included
	in the AH calculation, and the receiver doesn't know.

Note, of course, that that was from 1995; I have not repeated the analysis for newer AH or IPv6 specs.

---

From: Tero Kivinen <[email-masked]>
Date: Sun, 15 Nov 2009 17:46:26 +0200

> ESP-Null as it couldnt be deep inspected which has now been solved with

ESP-NULL and AH will still have different properties. AH will also
protect data which is not protected by the ESP-NULL, i.e. IP-header
including IP-addresses (unless ESP-NULL is used with tunnel mode). 

> In short, the argument that "Oh, but we can inspect AH packets" is not

I do not think it was never really relevant... AH was not used because
it offers ability to inspect packets, it was used when encryption was
not necessarely and where protection of the IP header was needed. 

> Given this, should we still have AH as a MAY for IPSEC - Cant we deprecate

I do not see any reason why it should be deprecated. It is already MAY
which means it does not need to be implemented unless your environment
or use scenario needs it. I was earlier in favor of changing it to
MAY, but I do not think we need to move it further than that. 

> our stance for ESP moving forward?

I am very sceptical for the WESP getting lots of implementations
quickly, so I do not really consider WESP as competitor for ESP. Also
I do not see any reason to wasting bytes for extra WESP header for
encrypted traffic, so I assume WESP will be used (if it will be used)
for ESP-NULL traffic not for encrypted traffic. 

> (primarily for data integrity). Shouldn’t they be moving to WESP, as WESP

It will take several years before implementations start to implement
WESP, and even more years before hardware chips support WESP. Most of
the IPsec users are still using IKEv1, even when we published IKEv2
2005, i.e. 4 years ago. And IKEv2 draft was finished and publication
was requested at end of 2003.

So stable draft which could be used to implement IKEv2 was ready 6
years ago, and while there are several implementations out, people are
still using IKEv1. Also before WESP can be used people would first
need to move to IKEv2 anyways... 
-- 
[email-masked]

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Mon, 16 Nov 2009 11:48:48 +0530

> need to move to IKEv2 anyways... 

Not all applications of WESP (or AH and ESP for that matter) would require an IKEv2 negotiation. You could use WESP as a protocol for routing protocol authentication without an IKEv2 extension.

And the reason why you might want to use WESP is to prioritize certain protocol packets over the others, as is normally done for v4 control packets (e.g. OSPFv3 HELLOs and ACKs over other OSPFv3 packets)

Cheers, Manav

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 16 Nov 2009 15:09:04 +0200

Bhatia, Manav (Manav) writes:
> And the reason why you might want to use WESP is to prioritize
> certain protocol packets over the others, as is normally done for v4
> control packets (e.g. OSPFv3 HELLOs and ACKs over other OSPFv3
> packets) 

You cannot do that, as if the packets get reordered more than what is
the replay window size of the responder, then older packets will get
dropped. If you want to do QoS you need to use multiple IPsec SAs each
carrying only one traffic for one QoS level.

See RFC4301 section 4.1.
-- 
[email-masked]

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Mon, 16 Nov 2009 19:50:31 +0530

This is an implementation specific optimization that has already been solved in multiple implementations.

Cheers, Manav

> From: Tero Kivinen [mailto:[email-masked]] 
> Sent: Monday, November 16, 2009 6.39 PM
> Cc: [email-masked]
> Subject: RE: [IPsec] WESP - Roadmap Ahead
>

---

From: Stephen Kent <[email-masked]>
Date: Mon, 16 Nov 2009 11:18:52 -0500

>been solved in multiple implementations.

Is the phrase "implementation specific" a euphemism for non-standard?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 16 Nov 2009 11:39:30 -0500

>...

an appropriate caution given my typo :-).

>>discussed at the IPSECME meeting this week, where there is a need 
>>to bind the options to the payload.  I observed that using tunnel 
>>mode (ESP) addresses this concern, but one could also note that 
>>using AH would do the same, with lower per-packet bandwidth 
>>overhead.
>
>Or put the labels in the SA, since especially for IPSO you probably 
>want cryptographic separation of different security levels.

There are various options here. I know of devices that have opted to 
use ESP in tunnel mode to ensure the binding, and that is what I 
noted during the IPSECME WG session. I may know of an instance or two 
where AH has been used to do this, because if introduced less 
(bandwidth) overhead than tunnel mode. Implementations that make use 
of IPSO or CIPSO should negotiate the labels as part of the SA. The 
label should be part of the SPD, and be checked based on SAD entry 
data cached form the SPD. (Can you tell that I've been through al of 
this?) We had a presentation by Joy (remotely) on adding label 
support, as a new work item, which would explore these issues in more 
detail, if we choose to adopt this as a new Wg item.

>I did go through the analysis you suggest for IPv4 and concluded 
>that nothing was both protectable and useful.  I also noted the 
>following issue:
>

I am not suggesting that any aspect of your analysis is flawed. I am 
suggesting that before the WG chooses to further deprecate AH, it 
needs to document the analysis supporting this decision, not just 
cite a couple of examples and make general statements in support of 
such an action.

Steve

---

From: Dan McDonald <[email-masked]>
Date: Mon, 16 Nov 2009 11:52:48 -0500

On Mon, Nov 16, 2009 at 11:39:30AM -0500, Stephen Kent wrote:

<SNIP!>

> detail, if we choose to adopt this as a new Wg item.

If the WG takes on labeling, please make sure we don't concentrate on just
one platform (SELinux).  Besides Joy's work, there's now also SA-implicit
labeling on another platform:

	http://hub.opensolaris.org/bin/view/Project+txipsec/

Once build 128 hits the servers, you can play with it!

FYI,
Dan

---

From: Jack Kohn <[email-masked]>
Date: Tue, 17 Nov 2009 05:49:13 +0530

There multiple "implementation specific" optimizations available. One
such optimization that is currently in use in multiple platforms is:

Do the seq number check, and then place the packets in different
priority queues/paths based on the kind of packet it is. Proprietary
ASICs on the routers can easily do this and its one of those things
that differentiate one vendor from the other.

Jack

---

From: Venkatesh Sriram <[email-masked]>
Date: Tue, 17 Nov 2009 09:51:17 +0530

Tero,

> carrying only one traffic for one QoS level.

Since processing of the sequence number fields is at the discretion of
the receiver, it can always elect not to enable the anti-replay
service for a specific SA for which it needs to prioritize certain
packets.

Also if the keys have been manually distributed, which would most
probably happen if WESP is being used as a standalone protocol then
compliant implementations SHOULD NOT provide anti-replay service.

In addition to this, we are discussing a multi-sender SA in which case
replay protection is anyways NOT recommended.

Sriram

---

From: Gregory Lebovitz <[email-masked]>
Date: Tue, 17 Nov 2009 11:03:04 -0800

inline...

> Is the phrase "implementation specific" a euphemism for non-standard?

GML>  Or perhaps, a local security policy decision to ease up on the size of
the enforcement window -- aka ease security requirements -- in order to get
more QoS enforcement capability -- aka convenience -- ??

GML> Gregory

-- 
----
IETF related email from
Gregory M. Lebovitz
Juniper Networks

---

From: Gregory Lebovitz <[email-masked]>
Date: Tue, 17 Nov 2009 11:19:36 -0800

inline...

On Mon, Nov 16, 2009 at 8:39 AM, Stephen Kent <[email-masked]> wrote:

--snip--

> suggesting that before the WG chooses to further deprecate AH, it needs to
> document the analysis supporting this decision, not just cite a couple of
> examples and make general statements in support of such an action.
>

WESP implementations need to occur, be deployed, and have some time in
operational networks. It would benefit the standards process to get some
feedback from the operational community once this has happened. Whether or
not we call it "experimental", we need to try out the WESP mechanism, in
parallel with the heuristics method, in the wild and see what comes of
them.

We need not be shy about WESP's existence and benefits. I agree we ought to
go on a bit of an intra-IETF "road show" and get the word to other Areas and
WG's about WESP as compared to AH, and see what feedback we get. This can
only help the standards process. In this context, Steve's suggestion for a
an analysis document would be very helpful. Much of the arguments made in
this thread would be excellently housed in said document.

After some time in the wild, If we observe signs that WESP is operationally
replacing AH, then we could seriously discuss deprecating AH.

HTH,
Gregory.

-- 
----
IETF related email from
Gregory M. Lebovitz
Juniper Networks

---

From: Jack Kohn <[email-masked]>
Date: Wed, 18 Nov 2009 05:43:28 +0530

Gregory,

Do you see how WESP can be used in KARP?

Jack

---

From: Stephen Kent <[email-masked]>
Date: Sat, 21 Nov 2009 08:03:02 -0500

At 11:03 AM -0800 11/17/09, Gregory Lebovitz wrote:
>inline...
>
>On Mon, Nov 16, 2009 at 8:18 AM, Stephen Kent 
><<mailto:[email-masked]>[email-masked]> wrote:
>
>GML>  Or perhaps, a local security policy decision to ease up on the 
>size of the enforcement window -- aka ease security requirements -- 
>in order to get more QoS enforcement capability -- aka convenience 
>-- ??

4301 contains We have explicit directions on how to use multiple SAs 
when the peers know that they want to send traffic with different QoS 
parameters. This appears to be an instance where the middle boxes are 
to examining traffic, and putting in into different QoS queues. That 
raises the question of how a receiver would know that this is 
happening, so that a bigger enforcement window is needed.

ESP and AH already allow a receiving peer to select any size window 
that it wants, bigger than the specified minimum. So that is not an 
issue.

Steve

---

From: Jack Kohn <[email-masked]>
Date: Sat, 21 Nov 2009 23:09:35 +0530

Steve,

>
> 4301 contains We have explicit directions on how to use multiple SAs when
> the peers know that they want to send traffic with different QoS parameters.
> This appears to be an instance where the middle boxes are to examining
> traffic, and putting in into different QoS queues. That raises the question

You got it all wrong. The sender is sending packets with the same QoS
parameters; its the receiver thats trying to prioritize some packets
over the others. One would typically do this for the Hellos/KeepAlives
that are associated with a protocol, so that the  adjacency/peering
session are not timed out.

Jack

---

From: Stephen Kent <[email-masked]>
Date: Sun, 22 Nov 2009 09:25:47 -0500

Jack,

Maybe I got it "all wrong" because the explanation provided in the 
messages was, at best, ambiguous :-).

Your description above is only marginally better:

	- it fails to characterize the range of protocols for which 
you believe this argument applies,

	-it fails to explain how WESP is relevant, since a receiver 
has the ability to process encrypted packets. WESP is a protocol that 
has been promoted as designed to aid middle boxes, not end systems

Steve

---

From: Jack Kohn <[email-masked]>
Date: Mon, 23 Nov 2009 04:47:42 +0530

> Maybe I got it "all wrong" because the explanation provided in the messages
> was, at best, ambiguous :-).
>
>        - it fails to characterize the range of protocols for which you
> believe this argument applies,

http://www.ietf.org/mail-archive/web/ipsec/current/msg05070.html

This is one example, we could think of some more.

>
>        -it fails to explain how WESP is relevant, since a receiver has the

This has already been discussed in this email thread earlier.

> ability to process encrypted packets. WESP is a protocol that has been
> promoted as designed to aid middle boxes, not end systems

Border Gateway Protocol (BGP) (http://www.ietf.org/rfc/rfc4271.txt)
was originally designed to work as an Exterior Gateway Protocol (EGP).
Today besides working as an EGP it is used in myriad other
applications, from discovering nodes in a VPN to distributing advisory
messages to remote network operators. So, i dont see a reason why we
should restrict ourselves to the applications for which a protocol can
be used ..

Jack

---

From: Stephen Kent <[email-masked]>
Date: Tue, 24 Nov 2009 11:40:01 -0500

>This is one example, we could think of some more.

This is only one example, and I think it is not "mainstream", so more 
examples would be helpful.

>This has already been discussed in this email thread earlier.

Not a very specific reference :-(.

>should restrict ourselves to the applications for which a protocol can

I would NEVER use BGP as a good example of a protocol that has been 
extended to cover a broader range of contexts, if security is the 
focus of the discussion.

Let me try to recapitulate the context of our discussion, since I 
have had trouble following the thread:

	- the principle example offered is OSPFv3 use of IPsec
	- OSPFv3 relies on both unicast and multicast SAs
	- in either case, a router receiving IPsec-protected OSPFv3 traffic
	  will have an SAD entry for the traffic, which means that the
	  router will know that the traffic will be protected via AH
	  or ESP. if ESP is employed, a router receiving traffic will know
	  ESP-NULL is used.
	- RFC 4552 mandates support for using different SAs for DSCP-marked
	  traffic
	- RFC 4552 calls for manual keying for both unicast and multicast SAs,
	  and states that a receiver is not checking sequence numbers.

In a given OSPF context (e.g., an AS), all the routers are operated 
by the same administrative entity (based on the definition of an AS). 
If the AS in which OSPF is being employed chooses to use ESP-NULL, 
all the routers can be configured to require this, as part of local 
SPD management.

Why do we need to use WESP in this context? The current argument you 
provided was that this was an issue for a router receiving OSPF 
traffic, not a middlebox issue. But the router knows that the traffic 
will be ESP-NULL, and knows the algorithm employed, so it should be 
able to examine this traffic easily. If the router wants to process 
traffic out-of-order, after examination, that too is easy, since 
there is no receiver sequence number checking, so processing the rest 
of the traffic (potentially with gaps) will not be a problem from an 
IPsec perspective.

I went back and analyzed the thread to see how we got to this point.

>control packets (e.g. OSPFv3 HELLOs and ACKs over other OSPFv3 

Tero question this assertion, citing packet ordering concerns, and 

>been solved in multiple implementations.

That caused me to ask what "implementation specific" optimizations meant, which
resulted in your response (11/17)

>that differentiate one vendor from the other.

This response seems confusing, since it discusses a sequence number 
check being performed in a context (OSPFv3) that calls for no such 
checks. Sriram noted that in a manual keying context (not just 
OSPFv3) sequence checking is not performed,
which reaffirmed the notion that this thread went awry.

>in order to get more QoS enforcement capability -- aka convenience 

Which prompted my reply (10/21) noting that 4301 mandates QoS support 
via use of multiple SAs (which, as noted above, is also called for by 
4552) and that
using larger receive windows is always a local matter, not an 
implementation specific optimization.

It was this response that you labelled as "all wrong" and said:

>... The sender is sending packets with the same QoS

So, it does not appear that the context has changed since Manav cited 
OSPFv3 a week ago, yet all the arguments about sequence number 
checking (by IPsec) are irrelevant in this context. I have seen no 
good arguments about why WESP is needed here, i.e., what benefits it 
offers for a router receiving OSPF traffic, some of which may need to 
be processed out-of-order.

Steve

---

From: Jack Kohn <[email-masked]>
Date: Wed, 25 Nov 2009 09:05:46 +0530

> In a given OSPF context (e.g., an AS), all the routers are operated by the
> same administrative entity (based on the definition of an AS). If the AS in
> which OSPF is being employed chooses to use ESP-NULL, all the routers can be
> configured to require this, as part of local SPD management.
>
> provided was that this was an issue for a router receiving OSPF traffic, not
> a middlebox issue. But the router knows that the traffic will be ESP-NULL,
> and knows the algorithm employed, so it should be able to examine this
> traffic easily. If the router wants to process traffic out-of-order, after
> examination, that too is easy, since there is no receiver sequence number
> checking, so processing the rest of the traffic (potentially with gaps) will
> not be a problem from an IPsec perspective.

Assume we dont have WESP.

The end router having scores of OSPF adjacencies will have following
rules in its database for *each* adjacency:

Incoming Pkt carries SPI X, then look at the nth bit and if its a OSPF
HELLO, put it in Ospfv3HighPrioQueue.
Incoming Pkt carries SPI X, then look at the mth bit and if its a OSPF
ACK, put it in Ospfv3HighPrioQueue.

This is assuming that SPI X corresponds to ESP-NULL and one can
disambiguate OSPF Hellos/ACKs from other OSPF packets by looking at
the nth bit and the mth bit (Please note that n could also be equal to
m).

Now, if this router has N adjacencies then the # of rules required =  2 x N = 2N

Thus the # of filter entries scales up linearly with the # of adjacencies.

Now, assume that we were using WESP.

You would need just two rules in your filter database saying the following:

Incoming Pkt is WESP integrity Protected, then look at the nth bit and
if its a OSPF HELLO, put it in Ospfv3HighPrioQueue.
Incoming Pkt is WESP integrity Protected, then look at the mth bit and
if its a OSPF ACK, put it in Ospfv3HighPrioQueue.

Thus one now needs only 2 rules in the HW to prioritize packets for
*all* OSPF adjacencies.

This becomes a huge advantage when we start scaling up the OSPF adjacencies.

Jack.

---

From: Daniel Migault <[email-masked]>
Date: Wed, 25 Nov 2009 12:11:09 +0100

Hi Manav,

I agree that for an already negotiated SA, the SPD lookup detects IP source
address spoofing. So in that case ESP detects the address spoofing during
the SPD check whereas AH would detect it while checking the signature check.

However SAD lookup is done with the longest match rule, and section 4.1 of
RFC4301 specifies :

      "3. Search the SAD for a match on only SPI if the receiver has
         chosen to maintain a single SPI space for AH and ESP, and on
         both SPI and protocol, otherwise."

This seems to enable a ESP or AH datagram with spoofed IP addresses to match
the SAD and SPD. If we consider a middleboxe that changes the IP address,
then using ESP will not detect the IP address spoof. On the other hand using
AH the spoofing attack will be detected.

There are some cases you want to protect the IP address header with IP
addresses and options. The example I have in mind is when you are a mobile
or a multihomed node, you are changing you IP address and want to notify
your peer with a IPsec protected signalling message.
      - MIPv6 [RFC3776] uses ESP to protects the BU message. The information
to be carried is the new CoA. Since ESP does not protects the IP header, the
BU datagram carries the IP address in its Payload, thus carrying twice this
information. It seems that AH would avoid repeating information.
      - MOBIKE [RFC4555] MOBIKE does not protect the new IP value which is
taken from the IP header. In some cases this can lead to traffic redirecting
attacks. The main purpose of this attack seems to be DoS.

Thus I would not consider AH as ESP_NULL equivalent, and thus feel AH should
not be removed. Nevertheless, AH has a major drawback which is NAT. For now
we can only hope IPv6 will bring an end-to-end connectivity. At least AH
would take considerable advantage of this statement!

IMO, rather then removing AH I would see if future use of the Internet make
it "historical" or not. For now it might be too soon to take such a
decision. Furthermore, AH does not cause "problems" with other protocols,
since they can chose not to use it.

Regards,

Daniel

Regards,

Daniel

On Fri, Nov 13, 2009 at 2:18 AM, Bhatia, Manav (Manav) <
[email-masked]> wrote:

> The only field worth modifying is the source and the dest IP. Now note that
> an IPSec SA is established between a pair of source IP and dest IP. Upon
> receipt of a packet containing an AH header, the receiver determines the
> appropriate (unidirectional) SA, based on the dest IP, security protocol
> (AH), and the SPI (it could also include the source IP). If the attacker
> modifies (or spoofs) either of the source or the dest IP, the SA lookup will
> fail and the receiver will regardless discard the packet. So what are we
> gaining by AH "header authentication"?
>
> AH can only add value over ESP-NULL if there are instances where despite
> address spoofing we erroneously process the IPSec packet. I don't see that
> happening, so is this really an issue?
>
> Cheers, Manav
>        AH is a security feature we need to keep for header authentication.
> Other WG may chose not to deal with AH and only consider ESP. I don't see
> what's wrong with that?
>
>         Regards
>
>        Daniel
>        --
>        Daniel Migault
>        Orange Labs -- Security
>        +33 6 70 72 69 58
>
>
>

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

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 25 Nov 2009 15:44:37 +0200

> Assume we dont have WESP.

I would like to, but unfortunately I lost :-)

> ACK, put it in Ospfv3HighPrioQueue.

As all of those IPsec connections is created by node, it actually
knows which algorithms are allowed, so it can very quickly do simple
run partial heuristics on the packet to know it is ESP-NULL.

Or actually it can also make so that if SPI number bit x is set then
the IPsec SA is using ESP-NULL for ospf, otherwise it is normal
encrypted traffic or something else. As SPI allocation is local
matter for this node, it can do this kind of things.

Middle boxes (where wesp and heuristics are really intended for)
cannot do this kind of things, but end-boxes can.

So for end boxes there is even more efficient methods than using WESP
to do the same thing. Splitting SPI range to indicate algorithms is
more efficient than WESP, as then you do waste extra bytes for extra
header. 

> This becomes a huge advantage when we start scaling up the OSPF

If you start using IPsec protected OSPF then you most likely will
require hardware support for IPsec also, and SPI lookup to find out
the algorithms etc is very fast first step done in there. After that
you know the parameters for the SA and you can then do this kind of
prioritizing before forwarding packet to the actual crypto engines. On
the other hand it might be better to just put few extra dollars for
the hardware and get fast enough crypto chips so you can do this
prioritizing using AUTHENTICATED data from the packet, i.e. after
IPsec processing as that will protect against attackers flooding the
Ospfv3HighPrioQueue by sending packets matching your bits.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 25 Nov 2009 15:59:58 +0200

Daniel Migault writes:
> address spoofing.

Not quite true, as you point out yourself. 

> So in that case ESP detects the address spoofing during
> the SAD and SPD.

Yes, and this is very important to get NAT-T and MOBIKE to work as
there the source address might change (either because NAT box rebooted
or otherwise forgot the mapping, and gave new IP address for the IPsec
connection, or because host moved around using MOBIKE).

> If we consider a middleboxe that changes the IP address,

Yes. 

> would take considerable advantage of this statement!

To reiterate for others, the major drawback in AH is that it actually
detects changes in the source / destination IP addresses, thus it
breaks if there is evil attackers (called NATs) in the middle who try
to modify source and/or destination addresses...

I agree.
-- 
[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Wed, 25 Nov 2009 09:31:52 -0500

>the nth bit and the mth bit (Please note that n could also be equal to

These packets are arriving on a multicast SA, so the preferred way to 
do the lookup, to make certain that the packet is from a relevant 
router is to perform
the lookup as described in section 4.1 (pages 12+13) of RFC 4301. 
That means that these SAs generally are uniquely identified based on 
both the SPI value and the source and/or destination addresses.  So, 
you would need to refine the matching algorithm described above based 
on the rules from 4301.

>Thus the # of filter entries scales up linearly with the # of adjacencies.

I've always found the 4552 discussion of SA use a bit confusing, but 
my recollection is that it called for reusing SAs in a way to avoid 
this problem (see Figure 3, section 7, page 7). But I am not 
completely confident about this, based on the wording in that RFC.

>if its a OSPF ACK, put it in Ospfv3HighPrioQueue.

This is much simpler, but also potentially inaccurate. Specifically, 
because it pays no attention to the SAD info, it would grab ANY 
packet that passes through the router, uses WESP, and that matches 
the bits that one uses to decide of a packet is an OSPF HELLO or ACK.

>Thus one now needs only 2 rules in the HW to prioritize packets for

Unless you used some other rules to narrow down the set of packets 
subject to these quick checks, other packets may be grabbed.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 25 Nov 2009 09:40:00 -0500

At 12:11 PM +0100 11/25/09, Daniel Migault wrote:
>Hi Manav,
>
>I agree that for an already negotiated SA, the SPD lookup detects IP 
>source address spoofing. So in that case ESP detects the address 
>spoofing during the SPD check whereas AH would detect it while 
>checking the signature check.
>
>However SAD lookup is done with the longest match rule, and section 
>4.1 of RFC4301 specifies :
>This seems to enable a ESP or AH datagram with spoofed IP addresses 
>to match the SAD and SPD.

I'm confused at this juncture.  The 4301 inbound processing algorithm 
(section 5.2 in RFC 4310) refers to SAD entries for processing 
IPsec-protected packets; the SPD inbound cache (SPD-I) is used only 
for bypass and discard traffic. So there should be no reference to 
the SPD in the sentence immediately above, right?

Also, you should remind folks that this rule applies only to 
multicast SAs. That's relevant to the OSPFv3 discussion we are 
having, but it seems inconsistent with the comment below of a 
middlebox that changes addresses, i.e., does one really expect to 
encounter a NAT on a link between two routers running OSPF?

I am not criticizing your later comments about AH vs. ESP 
applicability in mobile environments, just trying to keep the various 
arguments straight.

Steve

---

From: Jack Kohn <[email-masked]>
Date: Thu, 26 Nov 2009 05:47:33 +0530

> This is much simpler, but also potentially inaccurate. Specifically, because
> it pays no attention to the SAD info, it would grab ANY packet that passes
> through the router, uses WESP, and that matches the bits that one uses to
> decide of a packet is an OSPF HELLO or ACK.

Obviously the following rules would only be applied if the IP packet
was addressed to the router that was doing these checks. This way it
will not trap the other packets passing through this router.

> Unless you used some other rules to narrow down the set of packets subject
> to these quick checks, other packets may be grabbed.

Same as above. It is trivial to find out if the packet is locally
bound, or needs to be routed.

Jack

---

From: Stephen Kent <[email-masked]>
Date: Sun, 29 Nov 2009 19:48:43 -0500

Jack,

Thanks for describing the additional selection criteria that must be 
employed to avoid the problem I cited.

Given this more complete description of the selection criteria, I am 
not convinced that that is a significant benefit for using WESP in 
this context.

	- Whether using WESP or just ESP-NULL, the router needs to 
determine that the packet is addressed to it.  This means looking for 
either a unicast address (per interface?) or a multicast address. I 
thought that the traffic of interest would arrive on a multicast 
address. If so, then this is a very easy check.

	- Traffic other than OSPF can be addressed to the router, but 
I'm not sure what other traffic would be multicast. For unicast 
traffic addressed to the router, if some of that is protected using 
ESP with confidentiality, then the address check might have to be 
extended to include a source address as well.

	- There is an assumption that the OPSFv3 traffic is 
(ultimately)  protected using ESP-NULL. The next check that you 
described, i.e., looking for a few bits that indicate whether the 
payload is OSPF and appears to be a HELLO or ACK, is the real focus 
of this thread.  There appears to be a couple of cases:

	- If all multicast traffic directed to the router and 
protected using ESP is ESP-NULL, then WESP seems to help ONLY if 
there are algorithms being used for different SAs, AND if those 
algorithms result in different offsets for the start of the ESP-NULL 
payload. It's not clear that this is a realistic case. But, in this 
case, using WESP could avoid the need to check the SPI in the packet. 
What's not clear is whether checking for WESP and extracting the 
offset info is faster than matching against a set of SPIs.

	- if some multicast traffic directed to the router is 
protected with ESP with confidentiality, in addition to the ESP-NULL 
OSPF traffic, then one would need to check SPI values to 
differentiate between these two classes of traffic.

So, the question of whether we have one multicast SA for this 
traffic, or potentially a lot of these SAs is potentially relevant. 
As I mentioned in my previous message, this is not completely clear 
to me from 4552. You didn't respond to that part of my message, so I 
don't know if that means you find the RFC unclear on this point as 
well, or if you didn't think it mattered to this discussion. Well, if 
appears to matter, if one believes that the number is substantial.

So, the bottom line appears to be that WESP might be better than just 
using ESP-NULL, depending on the number of multicast SAs that 
terminate at the router, that make use of ESP, and maybe whether the 
ones that use ESP make use of different integrity algorithms that 
result in different offsets.  That is a lot of IFs for which we have 
yet to get an answer.

In any case, as I noted earlier, because of the use of manual keying 
in this context, selecting a subset of packets for out-of-order 
processing does not impose any burden on the IPsec for the remaining 
packets, so all of the comments about that issue were red herrings.

Steve