Subject: RE: AH and flow label

From: "Bound, Jim" <[email-masked]>
Date: Fri, 10 Sep 2004 14:56:46 -0400

OK I am worried now.  Is there a security hole and potentially serious
problem by not including the Flowlabel in the ICV?  We do need to ask
this question and should not ignore it.  Then the trade offs can be
determined.  But that data and what problem it solves should be fairly
compelling to go tell product implementors to add it.  

Thanks
/jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Francis Dupont
> Sent: Friday, September 10, 2004 11:06 AM
> To: Brian Haberman
> Cc: [email-masked]
> Subject: Re: AH and flow label 
> 
>  In your previous mail you wrote:
> 
>    Speaking as an IPv6 wg member, I am not comfortable with 
> the flow label 
>    being unprotected.  As an immutable field, it should be 
> included in the
>    ICV calculation.
> 
> => this is the argument which has triggered the question.
> 
>    I have seen several projects started that intend on taking
>    advantage of RFC 3697.
> 
> => note the RFC 3697 explains why the protection of the flow 
> label is not in fact useful. Can you give more details, for 
> instance are flow labels used by the destination?
> 
>    My main question is how much of an impact would such a 
> change have on
>    the existing IPv6 implementations.
>    
> => 100% incompatibility for IPv6/IPsec implementations which 
> support AH and put a non-zero flow label in packets (i.e., 
> all conformant implementations :-).
> 
>    Can anyone speak to their IPv6/IPSec implementations on this issue?
>    
> => I strongly object to change the current choice (not 
> protecting the flow label despite it is immutable) for two reasons:
>  - a change will be incompatible with current implementations
>  - the protection doesn't work on transit routers, i.e., where
>    the flow label is used.
> 
> Regards
> 
> [email-masked]
> 
> PS: status quo is compatible with RFC 3697, or with other 
> words, nobody asked when we discussed about the document 
> which became the RFC 3697 for an IPsec protection of the field.
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Sat, 11 Sep 2004 02:35:17 +0200

We are not talking about changing AH v1; we are discussing AH v2. To 
   correctly implement AH v2, one already has to be able to accommodate 
   64 bit sequence numbers, vs. the 32 bit sequence numbers in v1. AH v2 
   is still an I-D, not an RFC. So, while a change in whether to include 
   the flow label in the ICV would make v2 not backward compatible with 
   v1, v2 is already not backward compatible with v1 due to the required 
   sequence number support difference.
   
=> Steve, your numbering is not compatible with the usual one, i.e.,
we are talking about v3... (proof by the name of the ESP v3 draft)
And the ESN (extended (64) sequence number) is an option which is
negociated at the SA establishment, so it is not true to say the v3
is always not backward compatible with v2 (v1 is still supported
by some implementations but seems to be no more used). But one can
say we have an indirect way to distinguish v2 and v3 using the ESN
feature...

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Sat, 11 Sep 2004 11:53:25 +0200

OK I am worried now.  Is there a security hole and potentially serious
   problem by not including the Flowlabel in the ICV?

=> according to RFC 3697 there is fortunately none. More, all attacks
on flow labels can't be mitigated by including the flow label in the ICV
because intermediate nodes can't check the ICV.

   We do need to ask this question and should not ignore it. Then
   the trade offs can be determined.  But that data and what problem
   it solves should be fairly compelling to go tell product implementors
   to add it.  
   
=> I agree: this shows all the symptoms of a gratuitous change (i.e.,
without clear benefits). And if we can imagine end-to-end usages of
the flow label which need protection, we can imagine cases where we
should make the flow label mutable...

Thanks

---

From: Stephen Kent <[email-masked]>
Date: Fri, 10 Sep 2004 16:07:53 -0400

>compelling to go tell product implementors to add it. 

Jim,

Based on your comments in this message, I think there is some misunderstanding.

Does this help?

Steve

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Mon, 13 Sep 2004 17:04:20 +0900 (JST)

> sequence number support difference.

	i want a clarification:
	are you suggesting that AHv2 (and ESPv3) will have a different protocol
	number from the current AH/ESP?  otherwise we cannot distinguish
	between AHv2/ESPv3 traffic and old AH/ESP traffic.

itojun

---

From: Jari Arkko <[email-masked]>
Date: Mon, 13 Sep 2004 12:39:05 +0300

Steve,

> sequence number support difference.

I think the word "compatible" is inadequate to describe the
situation completely.

It is true that AHv2 defines 64 bit sequence numbers, but the
last time I looked at the draft, the extended sequence number
space was an option that was only used when peers agreed to
use it. So AHv2 still supports the old 32 bit sequence numbers
too. The use of the 64 bit range is negotiated in IKE, and
it is not used if either side wants to avoid it. I think
this applies to the other changes of AHv2 as well.

This leads me to believe that AHv2 is an *extension* of
AHv1, and an AHv1 implementation can still work well together
with an AHv2 implementation. To put it in another way,
an AHv1 implementation may not fullfill all the requirements
of AHv2, but an AHv2 implementation will fulfill all the
requirements of AHv1. Correct?

If so, the change of the flow label ICV calculation rules
would break this compatibility between AHv1 and AHv2.
I think we need to be careful when making such changes.
Is it really necessary? Will AHv2 use a different protocol
number as Itojun suggested, or will the use of the new
ICV calculation rules be signalled in IKE? Otherwise it
is not possible to have interoperability. OTOH, assuming
we need to allocate new protocol numbers or add yet another
negotiation parameter, are the benefits of the change
worth the cost?

--Jari

---

From: Stephen Kent <[email-masked]>
Date: Mon, 13 Sep 2004 10:48:48 -0400

>	between AHv2/ESPv3 traffic and old AH/ESP traffic.

The same protocol number is used in the old and new versions.  You 
can tell, based on IKE negotiation, whether the larger sequence 
number space is to be used, but that is the only way to distinguish 
the old vs. the new versions.  Presumably if one manually configures 
SAs, then one has to coordinate the versions as well as all the other 
parameters.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 13 Sep 2004 10:43:11 -0400

>[email-masked]

Francis,

You are right that my numbering was off.  I tend to ignore the first 
set of ESp & AH specs. They were rushed to publication before they 
had a chance to be thoroughly developed, and as a result they were 
not widely adopted.  But, you are right, we are talking about v3 at 
this point.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 13 Sep 2004 18:06:27 -0400

At 12:39 PM +0300 9/13/04, Jari Arkko wrote:
>Steve,
>
>>We are not talking about changing AH v1; we are discussing AH v2. 
>>To correctly implement AH v2, one already has to be able to 
>>accommodate 64 bit sequence numbers, vs. the 32 bit sequence 
>>numbers in v1. AH v2 is still an I-D, not an RFC. So, while a 
>>change in whether to include the flow label in the ICV would make 
>>v2 not backward compatible with v1, v2 is already not backward 
>>compatible with v1 due to the required sequence number support 
>>difference.
>

Note that the 64 bit sequence number option is the default for IKEv2. 
We have no other way to signal use of the newest versions of these 
protocols, so the sequence number option really acts as a signal, at 
least for AH. It is not clear  that there are any backwards 
compatibility problem re the current and next versions of AH, if we 
don't make this change.  ESP might be an issue, depending on how 
folks react to receipt of the "no next protocol" header, etc.

>requirements of AHv1. Correct?

see above comments

>negotiation parameter, are the benefits of the change

same protocol number, unless someone says something very soon!

Yes, the question is whether it is worth whatever cost (new protocol 
number or lack of backwards compatibility) we incur.  I'm not sure it 
is. I just want to make sure that the IPsec and IPv6 WGs have a 
chance to explore the issues before we declare AH done.  Note that 
the current text MUST be changed, as it gives the wrong reason for 
not including the flow label under the ICV. So, we either change the 
rationale provided, or we change how we handle the field. All I was 
asking was which of these would folks prefer.

Steve

Steve