In the context of RFC 3697, it seems to me that there can only be one AH-related difference if the flow label is included in the ICV:
If the flow label is included in the ICV, then a theft of service attack will result in a complete loss of communication between source and destination(s). If the flow label is not included in the ICV, then a theft of service attack will result in possibly lower QoS (in a benign situation), but not necessarily complete loss of communications, unless the theft of service attack becomes a denial of service attack. As the RFC states, anyone capable of spoofing the flow label can also spoof the addresses (which are definitely included in the ICV), so it's not entirely clear to me whether inclusion of the flow label in the ICV computation is desirable or not, in AH. Maybe it's a toss-up? Non-inclusion of the flow label in the ICV computation allows for a sort of higher granularity theft of service attack. Rather than all or nothing, it allows an attacker to tweak the QoS, potentially. To actually protect an e2e flow with QoS, you would probably need to use ESP to protect some or all of the hop by hop routing options. That would drive the protected QoS packets along a specified, protected route that a hacker would presumably not know, and therefore would have a harder time hacking. Bert > -----Original Message----- > From: Soliman, Hesham [mailto:[EMAIL PROTECTED] > > Ok, please see RFC 3697 for the latest document on the > flow label. This reflects current concensus. > > Hesham > > -----Original Message----- > From: Manfredi, Albert E [mailto:[EMAIL PROTECTED] > > > -----Original Message----- > > From: Soliman, Hesham [mailto:[EMAIL PROTECTED] > > > BTW, a lot of people on this thread (not including Brian's > > email above) seem to implicitly > > imply that the flow label will be modified without > > being put back to its original value. I wonder if > > the intention here is to break existing specs or are people > > forgetting that we already mandate that such scenario is not > > allowed? > > Perhaps this happens because RFC 2402 says that the IPv6 flow > label is mutable (in para. 3.3.3.1.2.1). But RFC 2460 seems > to disagree in terms of current use (as of 1998), in Appendix > A, even though in Section 6 the words allow for any sort of > change in the future use of this field ("subject to change"). > > However, if this flow label is to be included in the ICV, as > long as the flow label is returned to its original value > before header verification at the destination side (be it > tunnel or transport mode), all should be fine. > > Unless the wg has resolved that the flow label is absolutely > *not* still "subject to change," what's the urgency to get it > included in the ICV? Are we lacking for fields included in > the ICV? Do we just need words to justify its non-inclusion? > > Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
