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

["Aijun Wang" <[e-mail]>]

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:[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