Hello Authors of draft-carpenter-6man-flow-update-02 at
http://tools.ietf.org/html/draft-carpenter-6man-flow-update-02
I have some comments.
"a. "The Flow Label value set by the source MUST be delivered
unchanged...
b. "IPv6 nodes MUST NOT assume any mathematical or other
properties...
c. "Router performance SHOULD NOT be dependent on the distribution
of the Flow Label values...
The second two rules appear to forbid a usage in which... However,
both before and after these rules were laid down, a considerable
number of proposals for use of the flow label have been published...
Examples... These authors propose use cases in which some combination
of the following options apply: o The flow label may be changed by
intermediate systems..."
Er? The logic sounds flawed. You seem to be saying that earlier
Authors complained about "b" and "c". But then you say they suggested a
solution where "a" is addressed too. So actually they complained about
"a" too? Not sure I understand what they wanted.
The purpose of the proposed change is that the flow label should be
available for domain-specific use, with locally defined semantics,
without preventing uses that are compatible with RFC 3697.
Ok, but then make sure one considers coherently a Host being _in_ xor
_out_ of that domain. Sometimes these usages can be mixed. If we say a
Host _within_ the domain will _not_ set the Flow Label then we can't say
that the intermediary Routers within that domain will change it: because
it's hard to imagine a Router is not a Host at the same time.
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.
In RPL there's talk proposing "restoration" of the Flow Label at the
exit point, but I don't agree with that either.
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.
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
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.
Alex
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
