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.
=> That's because you are assuming that the flow label can only be used for QoS related applications. Even if we go with this assumption, if a real time app gets treated as a best effort app then effectively there is no real time communication. =>BTW, if someone is able to modify the header and wants to deny all communication for a node, I have another way to do it, change either address in the header! You don't need the flow label to do that... Hesham 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 =========================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. =========================================================== -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
