Subject: AH and flow label

From: Francis Dupont <[email-masked]>
Date: Fri, 10 Sep 2004 10:49:58 +0200

Here is a message from Steve Kent who is updating the RFC 2402
"IP Authentication Header (AH)" about the flow label status.
I have put it in this list for people interested by IPsec but
who have no enough time to read the mailing list...
To summary the question is:

Is the [ipsec] WG comfortable with the status quo, i.e., NOT including the 
flow label in the ICV [integrity check value], despite the fact that it
is immutable?

[email-masked]

PS: of course my opinion is we have to keep the status quo and
the decision is in the scope (i.e., hands?) of the ipv6 WG.

Subject: Re: [Ipsec] draft-ietf-ipsec-rfc2402bis-07.txt ... Suggest moving the "Flow Label" IPv6 base header field to "immutable" and protecting with AH
From: Stephen Kent <[email-masked]>
To: Francis Dupont <[email-masked]>
Cc: [email-masked]
Date: Thu, 9 Sep 2004 14:58:36 -0400

Francis,

I looked at RFC 3697.  It does state that AH does not protect flow 
labels, which is consistent with the old AH spec (RFC 2402). So, if 
we were to change this in the new AH spec, there would be a conflict. 
Also, the security analysis in 3697 argues that since there is no 
protection of the flow spec value, intermediate systems cannot rely 
on it and an end IPsec implementation cannot rely on it in transport 
mode.  I agree that it is unlikely that we would be able to manage 
key distribution for intermediate systems to be able to check the AH 
ICV, which supports your argument that it is not worth including it 
in the ICV computation.
However, if we choose to maintain backward compatibility with 2402, 
we need to clarify in 2402bis that this is the reason for not 
including the value in the ICV computation, as opposed to the 
current, erroneous rationale.

Is the WG comfortable with the status quo, i.e., NOT including the 
flow label in the ICV, despite the fact that it is immutable?

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

---

From: Brian Haberman <[email-masked]>
Date: Fri, 10 Sep 2004 06:50:08 -0400

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.
I have seen several projects started that intend on taking advantage of 
RFC 3697.
My main question is how much of an impact would such a change have on
the existing IPv6 implementations.

Can anyone speak to their IPv6/IPSec implementations on this issue?

Regards,
Brian

On Sep 10, 2004, at 4:49, Francis Dupont wrote:

> Date: September 9, 2004 14:58:36 EDT
> Subject: Re: [Ipsec] draft-ietf-ipsec-rfc2402bis-07.txt ... Suggest 
> moving the "Flow Label" IPv6 base header field to "immutable" and 
> protecting with AH
>
>
> Francis,
>
> labels, which is consistent with the old AH spec (RFC 2402). So, if we 
> were to change this in the new AH spec, there would be a conflict. 
> protection of the flow spec value, intermediate systems cannot rely on 
> it and an end IPsec implementation cannot rely on it in transport 
> mode.  I agree that it is unlikely that we would be able to manage key 
> distribution for intermediate systems to be able to check the AH ICV, 
> which supports your argument that it is not worth including it in the 
> ICV computation.
> However, if we choose to maintain backward compatibility with 2402, we 
> need to clarify in 2402bis that this is the reason for not including 
> the value in the ICV computation, as opposed to the current, erroneous 
> rationale.
>

---

From: Francis Dupont <[email-masked]>
Date: Fri, 10 Sep 2004 17:06:08 +0200

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?

=> 100% incompatibility for IPv6/IPsec implementations which support AH
and put a non-zero flow label in packets (i.e., all conformant
implementations :-).

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

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.

---

From: Brian Haberman <[email-masked]>
Date: Fri, 10 Sep 2004 11:28:11 -0400

> labels used by the destination?

Yes, most of these projects expect to use the flow label at the 
destination.
And one of these projects is using it in conjunction with 
source-routing.

> and put a non-zero flow label in packets (i.e., all conformant

Right.  My question was an attempt to see how many implementations
support IPSec AH today.

>  - a change will be incompatible with current implementations

Agreed.  I don't want to break a lot of implementations.  However, my
question above on who supports AH today is germane.

>  - the protection doesn't work on transit routers, i.e., where

For the transit use, I agree.  Destination use is something new.

> for an IPsec protection of the field.

Good point.  I think it is still worthwhile to have this discussion 
even if it leads
to staying with the status quo.

Regards,
Brian

---

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

=> and they expect to use AH end-to-end too?

=> source-routing doesn't change the argument that the intermediate nodes
can't check the ICV.

   
=> all IPv6/IPsec implementations I know (BSDs, Linux 2.6, last Windows,
etc).

   

=> it should be good to get more infos because AH itself is subject
to calls for deprecation based on the facts ESP can be used in place
of it in most cases and AH is not very used...

Thanks

PS: note there is a possible ugly compromise: protect flow labels
only when ESNs (extended sequence numbers, option of the new version
of AH) are enabled. This solves the compatibility issue but we should
have stronger arguments than "it is prettier to protect flow labels".

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 13 Sep 2004 14:52:32 +0200

Having read the whole thread, I can't see any convincing reason
to include the flow label in AH.

Apart from the arguments already expressed, what do we do if
AH fails because of a changed flow label? We discard the packet
instead of delivering it. Does that improve QOS? I don't *think*
so. On the contrary, it creates a trivial new DoS attack.

     Brian

Francis Dupont wrote:
> ------------------------------------------------------------------------
>

---

From: "James Kempf" <[email-masked]>
Date: Mon, 13 Sep 2004 08:36:59 -0700

> of it in most cases and AH is not very used...

If AH is not heavily used today (or used at all), then why is there a
backward compatibility issue with modifying it to protect the flow label?
And, if AH may potentially be deprecated in the near future, then what is
the point of discussing whether to add protection for the flow label in the
first place?

One of the original applications for AH was security for RFC 2461, but,
after trying that, SEND found out it didn't work and a different solution
was adopted. Current applications for ESP are easy to identify, example:
VPNs. Future applications are also, example: Mobile IPv6. What are the
compelling current and future applications for AH? Note that I am not trying
to disparage AH, but rather I'm looking for some practical justification for
this thread.

            jak

---

From: Francis Dupont <[email-masked]>
Date: Mon, 13 Sep 2004 19:29:40 +0200

I'm looking for some practical justification for this thread.
   
=> quoting Brian Haberman, the main justification of this thread is itself...

---

From: Jari Arkko <[email-masked]>
Date: Mon, 13 Sep 2004 21:55:53 +0300

> the point of discussing whether to add protection for the flow label in the

(I dislike making even a small deployed base incompatible.)

> to disparage AH, but rather I'm looking for some practical justification for

You have a really good point about future use of AH. I also have
trouble seeing why we should spend any effort on it. In fact, I'd
rather simplify the whole architecture by dropping AH from RFC 2401bis-
world; I realize that there are people who want to use AH for certain
very specific applications. Those people can continue to use RFC 2402
if they want to. And all the people who would use AH would still be
compatible with each other.

And I do believe the SEND experience was not exceptional; future
IP "control protocol" protection requirements are likely to have
similar requirements that make an AH-like function insufficient.
There's been talk about creating a new general purpose security
tool, to give IP control protocols what TLS has given for applications.
But its not clear if that's feasible. In any case, AHv2 is unlikely
(IMHO) the answer.

--Jari