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

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

Hi Aijun,

Sorry not to reply more quickly but I was quite busy this week ;-)

On 23/07/2014 17:40, Aijun Wang wrote:
> Hi, Brain:
> 
> Thanks for your comments. Below is my opinion to your concern points.
> 1. If some session support reflection, and others not, then the unsupported
> session will be less likely recognized and controlled, there is no other
> side-effect. Packets in bi-direction will be load balanced according to the
> RFC6438, regardless whether the IPv6 flow label is reflected or not.

I agree (and of course packets with zero flow labels must still
be balanced by traditional methods). I think this needs to be
explained in the draft; otherwise everybody will ask the same
question.

> 2.The reason that the IPv6 flow label is not supported in the real world is
> that we have not find some killer-application that can exploit this field.
> The mechanism of IPv6 flow label reflection can increase the opportunities
> of such killer-application be hatched, not the contrary.

Well, I am not certain about that. There are already a few systems that
set the flow label, because even under the original RFC 2460 rules
or the old RFC 3697 rules, it was possible to do the right thing.

However, I hope you are correct.

> 3. For mechanism of IPv6 flow label reflection, we strongly recommend this
> value be manipulated only at the IPv6 packet endpoints, not the in-path
> device. What is the motion for firewalls to rewrite this value?

As far as I could tell when we developed RFC 6437, in cases where this
is done, it is because of suspicion of a "covert channel" risk, where
a user sends encrypted messages in the flow label. In some high security
environments this is not an acceptable risk. It may be unusual in
a consumer environment but significant in an enterprise or government
environment. See section 6.1 of RFC 6437. There is not much the IETF
can do about this; firewalls do what they want to do.

The other case of course is where the source host does not set
the label but a router on the path does so. In that case the
router really acts as a flow-label proxy. In a one-way case
that's fine; in the reflection case it seems complicated.

RFC 6437 precisely defines this case:

   A node that forwards a flow whose flow label value in arriving
   packets is zero MAY change the flow label value.  In that case, it is
   RECOMMENDED that the forwarding node sets the flow label field for a
   flow to a uniformly distributed value as just described for source
   nodes.

For the reflection case, you would have to specify the behaviour
of this router in some detail, as an alternative to this RECOMMENDED
behaviour.

> 4.The session for flow label can be UDP request/reply or TCP request/reply.
> If one same client have multiple Http connections, there will be multiple
> distinctive IPv6 Flow label. That is to say, this value is unique in the
> local host for every TCP/UDP session.

And that's a problem for correct load balancing, if a single application
layer session is using multiple transport sessions. For other aspects
of this, please see the expired draft:
http://tools.ietf.org/html/draft-tarreau-extend-flow-label-balancing-01

If you really want to improve the problem of flow label persistence,
then multi-flow sessions, possibly with different client addresses,
need to be covered.

> 5.For In-path device, it needs actually 3-tuple {Flow Label, Source Addr,
> Destination Addr} to identify the unique session. If the flow label be
> reflected, then the same 3-tuple can used to identify bi-direction traffic
> of this session, or else it needs two different 3-tuple, or to parse the
> extend IPv6 header.

Yes, the same 3-tuple except that source and destination may be swapped.
That's an implementation choice. It's much better to avoid parsing
the whole header if possible.

> 6. Considering on-path attack, I think we can view this value as one magic
> number, which is widely used in various application protocol. This magic
> number/IPv6 flow label will be used only to coordinate the bi-direction
> traffic of one session. If it is changed by some on-path attacker, it only
> influence the recognition accuracy and control of the session. For
> differentiated service based on this value, we need other mechanism to
> protect or authenticate it. It is same risk for differentiated services that
> based on DSCP value.

Yes, but your draft needs to explain this. I assume that the worst case
is degradation of QoS, which may be considered an acceptable risk.

> 7. The IPv6 flow label field is unique in IPv6 packet, we should propose to
> exploit its potential value actively. From the viewpoint of application
> developer, there is no more differences between IPv6 packet and IPv4 packet
> except this field and the length of IP address. The little change of host
> operation system will be more influence to the IPv6 application and the
> service that based on IPv6. This change can be deployed incrementally.

That's true. Personally I hope that once operators become familiar with
IPv6 as the normal protocol, there will be more interest in exploiting
its features. Do please remember my comment that you can describe this
as a use case for the flow label, consistent with RFC 6437. It isn't
necessary for it to be on the standards track.

Regards
    Brian

> Best Regards.
> 
> -----Original Message-----
> From: v6ops [mailto:[e-mail]] On Behalf Of Brian E Carpenter
> Sent: Wednesday, July 23, 2014 3:14 AM
> To: IPv6 Operations
> Subject: [v6ops] Comments on draft-wang-v6ops-flow-label-refelction-01
> 
> 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
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> 
> 
> 
>