Le 8 sept. 2010 à 03:18, Brian E Carpenter a écrit : > 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). 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?
IMHO,yes. The consequence could be that a FL: - SHOULD be set by the packet source to a value that generally differs from a flow to another (e.g. a 5-tuple hash) - MAY be reset to zero in intermediate nodes, but only for security reasons - MAY be reset to a non-zero value in intermediate nodes, provided this value generally differs from a flow to another. An intermediate node that can identify 3-tuples but not 5-tuples SHOUL NOT reset FLs to non-zero values. RD > > -- > Regards > Brian Carpenter > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
