Subject: RE: AH and flow label

From: "timothy enos" <[email-masked]>
Date: Fri, 8 Oct 2004 01:35:13 -0400

Good morning. Having been away from the list for a while, it's not clear
to me what (if any) the consensus (and subsequent decision) is regarding
inclusion of the IPv6 Flow Label field in the AH ICV. If consensus and a
decision were reached, what were/are they? If so, I'd like to start a
separate thread concerning how to best protect the IPv6 Flow Label. If
not, I'd like to continue the thread until consensus and a decision are
reached. 

There seems no reasonable question that protection of the IPv6 Flow
Label is needed, in light of the fact that (according to RFC 3697,
section 2) '... The Flow Label value set by the source MUST be delivered
unchanged to the destination node(s)'. 

Taken to their logical conclusions Theft-of-Service attacks can become
de facto DoS attacks. Given the ability to filter and subsequently
route/forward based upon Flow Label values (much as has been/is done
with DSCP/TOS values) it seems worthwhile to be able to include the IPv6
Flow Label within the cryptographic functions of the AH ICV. I'm also
not certain that a contention in RFC 3697 (section 5.2, regarding IPsec
tunneling) is correct: '. modification of the Flow Label by a network
node has no effect on IPsec end-to-end security, because it cannot cause
any IPsec integrity check to fail.' Presuming one of the intermediate
nodes has a policy that drops all traffic with IPv6 Flow Label value
'x', to mark such tunnel traffic (talking about the Flow Label of the
outer IPv6 header here) with value 'x' would be to mark it (thus all
that is encapsulated within it) for death. Stealing of the Flow Label
value being assigned to the legitimate tunnel traffic could also
seemingly lead to a denial of service if there is also a bandwidth
limitation applied to that type of traffic (e.g. LLQ). In either case,
it would appear that the IPsec integrity check would in fact fail due to
the modification of the Flow Label (ICV can't be checked if the traffic
cannot get to the destination in the first place). 

Again, from RFC 3697: '. since the treatment of IP headers by nodes is
typically unverified, there is no guarantee that flow labels sent by a
node are set according to the recommendations in this document.
Therefore, any assumptions made by the network about header fields such
as flow labels should be limited to the extent that the upstream nodes
are explicitly trusted.' I'm not sure a lot of explicit trust is
warranted. Whether by the AH ICV, a Hop-by-Hop option, or another
mechanism, the IPv6 Flow Label needs to be protected. 

Any feedback would be most sincerely appreciated.

Best regards,

Tim Enos
1Sam16:7

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

---

From: Francis Dupont <[email-masked]>
Date: Fri, 08 Oct 2004 15:58:26 +0200

In your previous mail you wrote:

   Good morning. Having been away from the list for a while, it's not clear
   to me what (if any) the consensus (and subsequent decision) is regarding
   inclusion of the IPv6 Flow Label field in the AH ICV. If consensus and a
   decision were reached, what were/are they?

=> a consensus was reached and its result announced by Stephen Kent
(1- keep compatibility, 2- fix the rationale).
Cf draft-ietf-ipsec-rfc2402bis-08.txt:
        (*) The flow label described in AHv1 was mutable, and in
            RFC 2460 [DH98] was potentially mutable. To retain
            compatibility with existing AH implementations, the
            flow label is not included in the ICV in AHv2.

Regards

[email-masked]