-----Original Message----- From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Tuesday, September 07, 2010 9:19 PM To: 6man Subject: Flow label (im)mutability
Hi, The authors of draft-carpenter-6man-flow-update (now also including Shane Amante) are working on a new version. One fundamental issue that has come up is about the (lack of) security properties of the flow label. The most brutal expression of this is: The flow label field is always unprotected (no IP header checksum, not included in transport checksums, not included in IPsec checksum). [[WEG]] I think that this alone should be reason to update/invalidate the appropriate language in 3697, perhaps with some discussion of alternate means of carrying immutable packet header data that would otherwise end up in the flow label. It's a lot harder to dispute the technical basis behind this assertion plus the "it is futile to assert..." than it is your continuing thought about security below. It cannot be verified and can be used as a covert channel, so it will never pass a security analysis. Thus some firewalls *will* decide to clear it, whatever the IETF wants. This is inevitable, for exactly the same reason that the diffserv code point is rewriteable at domain boundaries. If this is correct, it is futile to assert that the flow label MUST be delivered unchanged to the destination, because we cannot rely on this in the real world. Are we ready to accept this analysis? [[WEG]] Yes, but as I implied above, I think the security angle is just one example of several illustrating why expecting flow label to be immutable end to end is not realistic, rather than the primary argument, and for that reason I'd like to see a little more separation between the two. Ultimately, firewall policy is a correctable (or at least containable) problem, especially if one or more end applications need flow label and are important enough to the folks on the other side of said firewall, and therefore I'm not sure you'd get consensus that it alone constitutes a deal-killer for immutable flow label. I'd rather see some additional examples - one that I'd add is general bit-error corruption by the lower-layer transport media. Since it's not covered by any checksum, it is quite possible that this field can be corrupted by a bit error and not cause the packet/frame to be discarded. Since most networks are not 100% error-free, this is a reasonable risk. Yes, it's unlikely that FL bits would be corrupted without any other impact very often, but it's worth covering when being complete about why we want to change this. This e-mail may contain Sprint Nextel proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
