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

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

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