Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-flow-3697bis-02.txt>

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 May 2011 09:34:26 +1200

On 2011-04-06 05:40, Thomas Narten wrote:
> Here are my detailed comments on the document. I did chat with Brian
> directly in Prague about these points as well. Overall, I support this
> document. But I think the wording in places needs another round of
> revision.
> 
>    A flow is a sequence of packets sent from a particular source to a
>    particular unicast, anycast, or multicast destination that a node
>    desires to label as a flow.  A flow could consist of all packets in a
> 
> This is a circular definition. 

Somewhat intentionally: a flow is whatever the source chooses to label
as a flow. We'll take Bob's reply as cancelling your comment out, except
for a small clarification in the text.

> I think it would be useful to give two
> definitions, something like the following:
> 
>     A Flow is a sequence of packets originating from a particular
>     application that should be treated "the same" by the network as
>     they are forwarded along to their ultimate destination. Packets
>     within a flow should not be reordered, should not be given
>     dissimilar QOS treatment, etc. What constitutes a Flow can only be
>     defined by the application itself.
> 
>     At the network level, routers need to be able to identify packets
>     belonging to the same Flow in order to process them
>     consistently. At the same time, it may be beneficial to process
>     packets between the same src/destination pairs (but from different
>     application flows) differently, e.g., to support ECMP or other
>     types of load splitting.
> 
> Then:    
> 
>     Traditionally, flow classifiers have been based on the 5-tuple of the
>     source and destination addresses, ports, and the transport
>     protocol
> 
> add "flow classifiers at the network layer"

Well, using the transport information makes it a layer violation. Do
we really want to open that discussion?

> 
>    The 20-bit Flow Label field in the IPv6 header [RFC2460] is used by a
>    node to label packets of a flow.  A Flow Label of zero is used to
>    indicate packets not part of any flow.  Packet classifiers can use
> 
> reword to say "that have not been labeled" (Packets will almost always
> be part of some Flow).

OK

> 
>    specification.  However, any node that sets flow label values
>    according to a stateful scheme MUST ensure that packets conform to
>    Section 3 of the present specification if they are sent outside the
>    network domain using the stateful scheme.
> 
> The above wording regarding "sent outside the network domain" is
> problematic. It hints that maybe you can do things with the Flow Label
> within a domain so long as you don't send such packets outside the
> domain. We shouldn't even hint that that is acceptable. I'd suggest
> removing all references to the "stateful" flow label scheme to one
> section. And that section could be very short.

We agree that this all belongs together in one short paragraph (see
below). But we don't agree to remove the "MUST ensure...". We believe
this is a mandatory constraint on all hypothetical stateful schemes.

>  
>    1.  Implementers are advised that forwarding nodes, especially those
>        acting as domain border devices, might nevertheless be configured
>        to change the flow label value in packets.  This is undetectable,
>        unless some future version of IPsec authentication [RFC4302]
>        protects the flow label value.
> 
> Remove this. Again, the Flow Label is  not allowed to be modified
> accept when zero. That is all that needs to be said.

We've been assured several times that firewalls will do this. However,
we think this belongs in the security considerations. The phrase about
IPsec also needed rephrasing - as you pointed out in Prague, there is
no likelihood of a future version of IPsec authentication.

> 
>        if the packet will leave their domain.  If it is known to a
>        border router that flow labels originated within the domain are
>        not uniformly distributed, it will need to set outgoing flow
>        labels in the same manner as described for forwarding nodes in
>        Section 3.
> 
> Remove this. It agains suggests border routers will be resetting Flow
> Label values.

In fact we took the whole paragraph out, but retained some of it in
the rationale document in a different form. We certainly don't want to
enourage this.

> 
>    o  Implementers should be aware that the flow label is an unprotected
>       field that could have been accidentally or intentionally changed
>       en route.  Implementations MUST take appropriate steps to protect
>       themselves from being vulnerable to denial of service and other
>       types of attack that could result (see Section 6.1).
> 
> Can we just move this advice to the Security Considerations section?
> IMO, we are giving it too much weight by having it in the main text.

OK

> 
>    o  Forwarding nodes such as routers and load balancers MUST NOT
>       depend only on Flow Label values being uniformly distributed.  In
>       any usage such as a hash key for load distribution, the Flow Label
>       bits MUST be combined at least with bits from other sources within
>       the packet, so as to produce a constant hash value for each flow
>       and a suitable distribution of hash values across flows.
> 
> 
> Can't we just come out and say that routers should:
> 
> 1) use the src/dest/flow/port numbers? this is the most prefered.
> 
> 2) if you can't use the port numbers, hash on the 3 tuple.
> 
> 3) you could also say hash on teh src/dest alone as a last resort, but
> why the Flow Label RFC would suggest that isn't immediately obvious to
> me. :-)

Indeed. We added a succinct version of the above (referring to the 5-tuple).

> 
>    The use of the Flow Label field does not necessarily signal any
>    requirement on packet reordering.  Especially, the zero label does
>    not imply that significant reordering is acceptable.
> 
> The first sentence above isn't right. One SHOULD NOT reorder packets
> from the same flow. Period. 

Agreed, rewritten.

> 
>    An IPv6 node that does not set the flow label to a non-zero value, or
>    make use of it in any way, MUST ignore it when receiving or
>    forwarding a packet.
> 
> I don't understand why this wording is in here. For the stateless
> case, nodes should simply ignore the received Flow Label value. We
> should probably just say that.

We concluded that the sentence is a no-op and deleted it.

> 
>    It is desirable that flow label values should be uniformly
>    distributed to assist load distribution.  It is therefore RECOMMENDED
>    that source hosts support the flow label by setting the flow label
>    field for all packets of a given flow to the same uniformly
>    distributed pseudo-random value.  Both stateful and stateless methods
>    of assigning a pseudo-random value could be used, but it is outside
>    the scope of this specification to mandate an algorithm.  In a
>    stateless mechanism, the algorithm SHOULD ensure that the resulting
>    flow label values are unique with high probability.
> 
> I think we need to specify some recommended algorithms. They can be
> SHOULDs (rather than MUST), but saying nothing leaves things too
> unclear. In particular, if we think just doing a simple hash based on
> the port numbers (or something) is good enough, we should recommend
> that.

We're reluctant to use a normative SHOULD in fact - in the end it's an
implementation choice - but yes, we should give clear suggestions -
see new text.

> 
> Also, this document should not be requiring (or  even use SHOULD) to
> say pseudo randomness is necessary. This document has not made the
> case for that.

We need to be clearer that *variability* of the values is necessary.
We've added unguessability as a requirement, which explains why sequential
flow values are a bad idea. There are quite a lot of resulting text changes.

In fact tidying this up (here and in the rationale document) led us to
look into the formal definition, both in statistics texts and at:
http://en.wikipedia.org/wiki/Discrete_uniform_distribution

> 
>    An OPTIONAL algorithm for generating such a pseudo-random value is
>    described in [I-D.gont-6man-flowlabel-security].
> 
>    [[ NOTE TO RFC EDITOR: The preceding sentence should be deleted, and
>    the reference should be changed to Informative, if the cited draft is
>    not on the standards track at the time of publication. ]]
> 
> I'd prefer that this document provide a suggested algorithm.

The reference is gone anyway because that draft isn't moving.
> 
>    A source node which does not otherwise set the flow label MUST set
>    its value to zero.
> 
> Better: just say that the default value should be zero, unless set
> explicitely.

Er, isn't that exactly what the sentence says?

> 
>    A node that forwards a flow whose flow label value in arriving
>    packets is zero MAY set the flow label value.  In that case, it is
> 
> s/MAY set/MAY change/

OK

>    A node that sets the flow label MAY also take part in a flow state
>    establishment method that results in assigning specific treatments to
>    specific flows, possibly including signaling.  Any such method MUST
>    NOT disturb nodes taking part in the stateless model just described.
>    Further details are not discussed in this document.
> 
> I don't understand what does this is really intended to mean. IMO,
> just say the first sentence, and then say the details of stateful are
> out of scope for this document.

This is where we want to relocate the "MUST ensure..." sentence mentioned
above. It means that stateful mechanisms mustn't mess up the stateless model,
and we don't care and don't say how they achieve that.

> 
>    would cause a stateful mechanism to behave incorrectly.  For this
>    reason, stateless mechanisms should not use the flow label alone to
>    control load distribution, and stateful mechanisms should include
> 
> s/stateless mechanisms/stateless classifiers/

OK

   Brian, for the authors

---

From: Thomas Narten <[email-masked]>
Date: Tue, 03 May 2011 10:01:19 -0400

Hi Brian.

Changes look mostly good. Some specific comments.

> we really want to open that discussion?

What, we can't be honest about what people really are doing and have
been doing forever? I don't see why this has to result in some big
philosophical discussion...

> this is a mandatory constraint on all hypothetical stateful schemes.

A requirement saying you cannot modify the Flow Label (unless it is
zero) seems awfully clear to me. Why we then also have to say the
above is what I don't understand. State the requirement clearly,
unambiguously, and once. That should be sufficient.

The part that I object to "if they are sent outside the network
domain", as it implies that it must be OK to change it within a
network domain. If this spec is trying to say that, I object and would
like to know why.

> implementation choice - but yes, we should give clear suggestions -

I'm not calling for a SHOULD. But I do think it would be helpful to
give one or more example algorithms that could be used. The revised
version of the document still doesn't give one.

> Er, isn't that exactly what the sentence says?

Not to me... How can a sender "not otherwise set" a value? It has to
set it to something, even if it is just a random value because it
doesn't conciously set it... But may that's just me. 

Below are some additional comments on the revised document itself.

Thomas

2011-05-03 Review of -03

   Flow label values should be chosen such that their bits exhibit a
   high degree of variability, making them suitable for use as part of
   the input to a hash function used in a load distribution scheme.  At
   the same time, third parties should be unlikely to be able to guess
   the next value that a source of flow labels will choose.

s/guess the next value/guess values/

   An implementation in which flow labels are assigned sequentially is
   NOT RECOMMENDED, as it would then be simple for third parties to
   guess the next value.

This then means the examples in gont-security cannot be used? (They
generate sequential values....). I think the above is not right, and
needs to be more nuanced.

I think it would be useful to change "third parties" to "off-path
attackers". Those on path will be able to see the values in use, so
you are stuck with that.

And the algorithm in gont-security presumably are fine to protect
against off path attackers. Right?

(Thus, I think the above needs tweaking).

   A node that forwards a flow whose flow label value in arriving
   packets is zero MAY change the flow label value.  

reword:

   A node that forwards a packet whose received flow label value is
   zero MAY change the flow label value.  

> 4.  Flow State Establishment Requirements
> 
>    Thus, any node that sets flow label values according to a stateful
>    scheme MUST ensure that packets conform to Section 3 of the present
>    specification if they are sent outside the network domain using the
>    stateful scheme.  Further details are not discussed in this document.

The above is a little  awkward in places. Suggest the following:

   A node that sets the flow label MAY also take part in a flow state
   establishment method that results in assigning specific treatments
   to specific flows. Such state establishment approaches may include
   signaling to establish state in routers along the path to the
   destination.  In order to avoid interference with nodes
   implementing the stateless model described in this document, the
   assignment of label values MUST satisfy the properties described in
   Section 3. Further details of stateful Flow State establishment are
   outside the scope of this document.

>    This specification defines the flow label as immutable once it has
>    been set to a non-zero value.  However, implementers are advised that
>    forwarding nodes, especially those acting as domain border devices,
>    might nevertheless be configured to change the flow label value in
>    packets.  This is undetectable.

Again, I object to the above as stated. Getting to Ran's point, if we
think that border routers will zero out the Flow Label, let's be
honest and state that directly and also *why* (and maybe provide some
context about whether that is good/bad/etc.). The above IMO is trying
to have it both ways, in a way that no one will understand and will
easily be misinterpreted.

> 9.  Acknowledgements

Would be good to more clearly identify the text that applies to this
version of the document vs. previous versions.