Thanks for all the discussion. Just commenting on a few points: On 2010-09-09 08:51, Iljitsch van Beijnum wrote: ... > Remember, the flow label is an optimization, use it if it's > helpful, ignore it otherwise.
I wonder if we all agree on this? I do, but people who want to encode specific semantics in the label clearly don't. If we do agree on this, it's very helpful, because it guides all further decisions. For example, it allows us to see that the label is immutable on a best effort basis, rather than mathematically immutable. So we ccould say both that forwarding nodes MUST NOT change the label, *and* that downstream nodes MUST NOT rely on the value being unchanged. On 2010-09-08 20:44, Iljitsch van Beijnum wrote: ... > There is currently no writeup of how to use the flow label > for ECMP. And as far as I can tell there are no > implementations of this either. Which is a real shame. There is work in progress, but IMHO we need to resolve the issues in RFC 3697 before this can be completed. > > There is work going on on creating "multipath TCP" where a > TCP flow is split into subflows which take different paths. > (See the MPTCP wg.) Currently, it is assumed that the paths > are defined by the source/destination address pairs, but > there are many paths that can't be selected this way. A > different way to do this would be to have a path selector > value in packets which the MPTCP (or other multipath > transport) can use to tell routers to use different paths for > different subflows. The flow label would be a very good > choice for this, it would then bascially be a "subflow > label". Actually, that is not forbidden by RFC 3697 (therefore it's allowed). Read carefully the definition of a flow in Section 1: "A flow is a sequence of packets ... that the source desires to label as a flow." (etc.) > > Considering the above, in my opinion: > > - we shouldn't lock down the flow label such that only one > flow label per flow is allowed because this would impede > future innovation Since it's the source that decides what a flow is, this has been the case since 2004. > - zero flow labels are still created by many systems, but > these would hamper a flow label based ECMP. Rewriting zero > flow labels into a real flow label somewhere in the network > would therefore be a useful function > > - arbitrarily changing flow labels could break stuff like > flow label based multipath and flow label based ECMP > > In other words: the flow label wouldn't be immutable, but > non-zero values SHOULD NOT be rewritten. I agree. Except for the firewall problem, that is. On 2010-09-09 06:08, Thomas Narten wrote: >>> > > 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. > > And exactly how is this is different that what we have today, where > the same can be done by setting values for the src/dest addresses and > ports? Well, rewriting the addresses or ports will misdirect a packet. We don't actually know what rewriting the flow label would do, since we don't know what it's being used for. So it is a bit different, but I agree that it's the same class of risk. As Fernando and Steve have pointed out, the argument is the other way round for off-path attacks - a randomised flow label will be even harder to guess than a randomised port. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
