[v6ops] Comments on draft-wang-v6ops-flow-label-refelction-01

[Brian E Carpenter <[e-mail]>]

There wasn't time for me to line up at the microphone, so
here are my comments. I think the idea is quite interesting,
but a little optimistic.

What are the effects of some sessions supporting reflection
and others not? We know very well that even the basic RFC 6437
flow label is not supported yet in the real world, so widespread
use of reflection is years in the future.

There's no discussion of flow label rewriting by firewalls,
which we know from the 6man discussions before RFC 6437 is
a real issue. If the scope is strictly limited to a single
administrative domain, that's OK, but the general end-to-end
case probably fails.

Actually, the draft doesn't clarify exactly what is a session
for flow label purposes. As noted in the meeting, is a "stateless"
session (UDP request/reply) a session for this purpose? What
about multiple HTTP connections from the same client?

The uniqueness rule for flow labels is that a flow is identified
by the 3-tuple {Flow Label, Source Addr, Destination Addr}. The
flow label value itself might not be unique in the intermediate
nodes, so any state must be keyed by the 3-tuple, with the two
addresses either way round.

The mechanism seems very exposed to on-path attacks, since an
attacker could forge a reverse packet with the correct label,
even before the first TCP ACK. So nobody should rely on the flow
label alone for anything important. (I don't think there is any
new risk for off-path attacks.)

Finally I think the document would have more chance of success
if it was made Informational, without that SHOULD. Just describe
this as a use case for the flow label - it is completely consistent
with RFC 6437. If the original label is pseudo-random, it will
do fine as a reflected label from the other node.

Regards
   Brian