Below... On 2010-09-08 14:44, Christopher Morrow wrote: > On Tue, Sep 7, 2010 at 9:18 PM, Brian E Carpenter > <brian.e.carpen...@gmail.com> wrote: >> 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? > > what's the threat if it changes in flight? multiple times even?
That presumably depends on the use case. The idea is that someone figures out what flow label values will screw you, and sets such values. Let's assume you're using it for ECMP or LAG. You're hashing the flow label as part of the ECMP/LAG hash. Someone figures out how to compute a flow label for each packet arriving on your 10GB line that will bias your hash, and therefore defeat the load sharing. Note, I'm not saying it will happen, just that it might, and that seems to be how some security people think. We can choose to not worry about this, but that's why I want to discuss it. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
