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

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Jul 2014 07:13:32 +1200

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

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 23 Jul 2014 13:40:55 +0800

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.
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.
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?
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.
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.
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.
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.

Best Regards.

-----Original Message-----
From: v6ops [mailto:[email-masked]] 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
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 23 Jul 2014 13:35:33 +0800

Hi, Brain:

Best Regards.

-----Original Message-----
From: v6ops [mailto:[email-masked]] 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

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 27 Jul 2014 02:27:43 +1200

Hi Aijun,

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

> 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.

> 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.

> 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.

> 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.

> of this session, or else it needs two different 3-tuple, or to parse the

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.

> protect or authenticate it. It is same risk for differentiated services that

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.

> 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