Bert and Francis are correct that there is no plan to change AH for this.
> Seems to me that even RFC 3697 allows for the Flow Spec to be > changed in transit, as long as it's returned to its original > state before arriving at the destination.
The authors of 3697 were fairly careful about that, since we know that some people have use cases in mind for the flow label where it would be twiddled en route. But the basic model is that it is an e2e field.
Brian
Manfredi, Albert E wrote:
I believe I had the last word on this thread until today.ly 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).
The original version of AH, RFC 2402, has the Flow Spec value as being mutable.
RFC 2460, IPv6 spec, has the Flow Spec value potentially mutable.
Diffserv, RFC 2475, has the DS codepoint as being potentially mutable.
Seems to me that even RFC 3697 allows for the Flow Spec to be changed in transit, as long as it's returned to its original state before arriving at the destination.
I had suggested that the Flow Spec not be included in AH bis, and to use the above older references as reason. That is to say, existing AH algorithms could break if this was changed. In addition, I had also suggested that perhaps the best way to protect a flow where the Flow Spec value really matters is to use ESP and send the critical traffic through a tunnel.
Bert
-----Original Message----- From: timothy enos [mailto:[EMAIL PROTECTED] Sent: Friday, October 08, 2004 12:35 AM To: [EMAIL PROTECTED] Subject: RE: AH and flow label
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 seeming
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 PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
