Thanks for the comments. Extracting: On 2010-04-15 22:14, Alexandru Petrescu wrote: ... >> 1. If and only if the flow label in an IPv6 packet has the default >> value of zero, then a router MAY set it to a value between between 1 >> and 0xFFFFF. This option modifies the rule that the flow label must >> be delivered unchanged, by allowing exactly one router to set it if >> the source host did not set it. > > I believe this may pose problems. The case is when the sending Host1 > does not set the Flow Label and the receiving Host2 knows somehow (e.g. > the app protocol is older than new Flow Labels) that H1 doesn't > implement Flow Labels and so expects "0" zero from it. When H2 sees a > flow label set then it deduces something is wrong, because it knows H1 > couldn't set it.
Indeed, I think we should make it clear that receiving hosts MUST NOT rely on the flow label for any kind of upper layer behaviour. That is a missing rule in RFC3697, I think. > In RPL there's talk proposing "restoration" of the Flow Label at the > exit point, but I don't agree with that either. That is *required* by the existing rules of RFC3697. >> packets leaving the local domain may contain flow label values that >> are not pseudo-random > > For some reason I have difficulty understanding "not pseudo-radom": does > it mean actually "random", interpreted as a double negation? Does it > mean "not random but can't talk random because true random doesn't > exist"? The implications of this clarification are wide I believe. OK, good point. What is intended by "not pseudo-random" is that it's either assigned systematically (e.g. 1, 2, 3...) or that the bits are encoded with some special meanings. I don't like to write plain "random" because most network nodes don't contain random number devices. > >> The flow label is not protected in any way and can be forged by an >> on-path attacker. On the other hand, a pseudo-random flow label >> cannot be readily guessed by an off-path attacker. > > That "OTOH" makes think that because pseudo-random flow labels cannot be > guessed then the Flow Label is protected against on-path attackers. I What? Not at all. On-path attackers can observe and/or forge any flow label. But as draft-blake-ipv6-flow-label-nonce shows, they can have value for making off-path attacks harder. > don't think much protection is afforded by the use of visible be them > random numbers. Were it public-private-keys then yes but here we don't > talk Flow Labels as security keys, at least because of the obvious > performance requirements. Indeed not. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
