Thomas,
Thanks for the careful review. Comments inserted...
Thomas Narten wrote:
>
> I reviewed the revised document today. Speaking as an individual, here
> is my reaction:
>
> > Abstract
> >
> > This document specifies the IPv6 Flow Label field, the requirements
> > for IPv6 source nodes labeling flows, and the requirements for flow
> > state establishment methods.
>
> Note: what I would expect this draft to describe is:
>
> 1) what arbitrary source nodes should do with the flow label.
> 2) what routers should do with the flow label.
>
> The document appears to do 1), but 2) is omitted from the document. Is
> this OK?
IMHO, it's not only OK, it is essential at this stage. There are a number
of use cases for the flow label - if I even enumerated them here, they
are controversial enough to start a flame war. The draft has been very
carefully limited to *avoid* assuming any particular use case. It serves
two purposes, in my view:
-- setting globally applicable boundary conditions on what a sending
host may and may not do;
-- making it clear that intermediate systems may use the flow label
for packet classification purposes (which means, in particular,
that ASIC and network processor designers know that they should
include the flow label in the fields potentially used by
classifiers).
Going beyond this point would take us back into the controversy we
had on this list a year or so ago. So, to repeat, it would *not*
be OK to attempt to specify what routers should do with the flow
label.
> I.e., I thought the main reason to specify the flow label is
> so that current implementations can do something sensible with the
> flow label. Is there enough guidance for router implementors (e.g.,
> those doing hardware) to add useful support for the flow label? I'm
> not sure, but would like to hear from such implementors.
As I said, there are multiple use cases and IMHO we should get this
document out and then let the QOS community (not the IPv6 community)
work on those use cases. Time will tell which ones succeed.
>
> > 2. IPv6 Flow Label Specification
> >
> > The 20-bit Flow Label field in the IPv6 header [IPv6] SHOULD be used
> > by a source to label packets of a flow. A non-zero Flow Label
>
> Note: I don't think the SHOULD/MUST usage in this document is always
> helpful or even correct. It would make sense to go read the defintions
> in RFC 2119 as cited.
This does mean SHOULD in the 2119 sense - hosts need a valid reason for not
doing it.
>
> This document defines a flow as the three tuple. No "SHOULD" about
> it. If a source wants to label a flow, it does so by setting the flow
> label. A better wording would be something like:
>
> Flows in IPv6 identified by the tuple of the 20-bit Flow Label,
> the IP source address, and the IP destination address in the IPv6
> header.
No. We want to say that hosts SHOULD label flows. (Rationale: it's
only by this becoming the norm that the flow label can become an effective
tool. If only 1% of traffic is labelled, there is no benefit.)
>
> > The packet MAY be given some flow-specific treatment based on the
> > flow state established on a set of IPv6 nodes. The nature of the
>
> MAY here seems odd too. Again, read the definition of MAY. It suggests
> that an implementation may decide it makes sense to do something in
> certain circumstances. But what I think the document is trying to say
> here is that flow-specific processing is done by entities that have
> been directed to do so. This is not an implementation choice in the
> "MAY" sense. It has more to do whether a device implements flows and
> then whether there is appropriate flow-state. Suggested reword:
>
> The packet will be processed in a flow-specific manner by those
> nodes that have special processing enabled for packets belonging
> to a particular flow.
Agreed, or simply use lower case "may".
>
> Actually, the entire paragraph might be better as:
>
> IPv6 flows are defined by the tuple of the 20-bit Flow Label, the
> IP source address, and the IP destination address in the IPv6
> header. Packet classifiers use the tuple to identify which flow a
> particular packet belongs to. Packets will be processed in a
> flow-specific manner by those nodes that have special processing
> enabled for packets belonging to a particular flow. A Flow Label
> of zero indicates an unlabelled packet that is given no special
> treatment. The nature of the specific treatment and the methods
> for the flow state establishment are beyond the scope of this
> specification.
Well, I think we want the SHOULD in there. We mean it.
>
> > The Flow Label value set by the source MUST be delivered unchanged to
> > the destination node(s).
>
> Question: What is the above intended to mean? That the flow label must
> be delivered to the destination unchanged from what it was set to by
> the originator? Or that the flow label MUST NOT be modified by any
> node along the path? (the two are different, and the words seem to say
> the former.) It would be good to be clear.
I prefer the "MUST NOT be modified" formulation if my co-authors agree.
>
> > IPv6 nodes MUST NOT assume any mathematical or other properties of
> > the Flow Label values assigned by source nodes. Router performance
> > SHOULD NOT be dependent on the distribution of the Flow Label values.
> > Especially, the Flow Label bits alone make poor material for a hash
> > key.
>
> I wonder if the above wording is even needed. Can this section just be
> dropped? If not, suggested reword:
>
> Some early proposals for use of the IPv6 Flow Label suggested that
> routers might use the Flow Label as a hash key for doing lookups as
> an optimization. However, this technique assumed that Flow Label
> values would make good material for a hash key in order that the
> resultant hashes would be sufficiently distributed. In practice,
> this cannot be relied upon, and would open up implementations to
> potential denial-of-service attacks from attackers that
> intentionally violate such an assumption. Consequently, IPv6 nodes
> MUST NOT assume any mathematical or other properties of the Flow
> Label values assigned by source nodes.
Good
>
> > Nodes keeping dynamic flow state MUST NOT assume packets arriving 60
> > seconds or more after the previous packet of a flow still belong to
> > the same flow, unless a flow state establishment method in use
> > defines a longer flow state lifetime or the flow state has been
> > explicitly refreshed within the lifetime duration.
>
> I'm not entirely comfortable with the above wording. It seems to me,
> that any node making assumptions about flow values *needs* a flow
> setup mechanism to go along with it. But if there is such a mechanism,
> that mechanism can communicate appropriate timer values for timing out
> state (and the above words are not needed). If there is no such
> mechanism, what sort of flow-specific processing should assume that a
> gap of 60 seconds implies a reset in the flow?
We don't know, and 60 seconds is a compromise value anyway. But there
seemed to be WG consensus that a default timeout is needed, since
otherwise we are licensing implementors to create hard state. The authors
have been round and round this many times, and this was the best we
could come up with. (more comment on this below)
>
> What problem is the above wording intended to address?
Use cases that nobody has thought of yet.
>
> > If an IPv6 node is not providing flow-specific treatment, it MUST
> > ignore the field when receiving or forwarding a packet.
>
> Such a node is presumably not implementing this spec, in which case
> the words seem superfluous... Delete?
You're too logical :-) But I think this forbids attempts to abuse
the label as a covert signalling channel, or otherwise use it for
an unintended purpose. So I'd vote for keeping the sentence, but
I don't feel strongly.
>
> > 3. Flow Labeling Requirements
> >
> > To enable Flow Label based classification, sources SHOULD assign each
> > unrelated transport connection and application data stream to a new
> > flow. The source MAY also take part in flow state establishment
> > methods that result in assigning certain packets to specific flows. A
> > source which does not assign traffic to flows MUST set the Flow Label
> > to zero.
>
> I find the above a bit muddled and incomplete. Here is an attempt at
> clarifying:
I object. Your text starts to hint at use cases. I think we should
absolutely avoid that, and restrict ourselves strictly to setting
boundary conditions on senders. Also, we agreed earlier to take out
all the stuff on APIs and picking flow label values. That was part
of the Grand Simplification of the draft. So I don't agree that the
paragraph is incomplete with respect to the goals of this document.
Let me try a slight rewrite.
To enable Flow Label based classification, sources SHOULD assign each
unrelated transport connection and application data stream to a new
flow and assign a new label value to that flow. The source may also
take part in flow state establishment methods that result in assigning
certain packets to specific flows to which label values have been
assigned. A source which does not assign certain packets to flows
MUST set the Flow Label to zero in those packets.
>
> A source enables flow-specific processing by assigning a non-zero
> value to the Flow Label on outgoing packets. Because identifying
> individual flows may only be possible with the direct help of
> individual applications, there is no one rule for how and when to
> label outgoing packets. In the absence of more-explicit
> information (e.g, from an application), sources SHOULD assign each
> new transport connection to a new flow.
>
> Applications should also be provided sufficient control over how
> to set the Flow Label. Such indications should support:
>
> - use a specific value for the flow label (e.g., if the
> application is participating in a flow setup protocol)
>
> - Let the system pick a value, but provide a way for the
> application to specify that a previously-assigned value be
> used when sending packets. This is to support applications
> that have multiple flows, transported over what the system
> might view as a single "connection" or "socket".
>
> ... [there are a bunch of things here that it probably makes
> sense to at least indicate may be necessary. I don't think
> this document should include the API, but it would be good
> to itemize the types of operations that will need to be
> supported.]
>
> A source that does not desire flow-specific processing sets the
> Flow Label value to 0. However, this document requires that
> implementations not set the value to 0 by default, in order to
> enable the support load spreading.
>
> > A source node MUST keep track of the Flow Label values it is
> > currently using or has recently used.
>
> Mumble. the above comes across as a restrictive requirement rather
> than focusing on the key requirement to fulfill.
Yes, we can replace MUST by "needs to".
>
> > Flow Label values previously
> > used with a specific pair of source and destination addresses MUST
> > NOT be assigned to new flows with the same address pair within 60
> > seconds of the termination of the previous flow. If the previous flow
> > had a lifetime longer than the default 60 seconds, a quarantine
> > period of at least the length of the lifetime MUST be observed.
>
> As mentioned above, I'm not sure about the 60 second value. Also, the
> wording could be better.
As noted, 60 seconds is a compromise. We looked at values anywhere between
10 and 600 seconds. There is no right answer, but 60 seems as good as
we could get. (10 seemed too short for a slow TCP stream, and 600 seemed
far too long, despite being the TCP timeout.)
Wording suggestions?
>
> > The requirement of not reusing a Flow Label value for a new flow with
> > the same pair of source and destination addresses extends across
> > source node crashes and reboots. To avoid accidental Flow Label value
> > reuse, the source node SHOULD use a different initial value for Flow
> > Label assignments after a reboot. The initial value could be randomly
> > generated, or computed from a previous value stored in non-volatile
> > memory.
>
> Suggested rewording:
>
> A source node should not reuse a particular Flow Label for a
> different flow until it is sure that any flow-specific state on
> other nodes has timed out or been appropriately updated. In
> particular, if a node reboots, it may lose track of which Flow
> Label values it has used recently, and pick the same
> ones. Implementations MUST ensure that they don't reuse Flow Labels
> too quickly. The problem here is analagous to picking initial
> sequence numbers when opening TCP connections after a
> restart. There are number of ways to avoid reuse. One approach is
> to have new Flow Label values be chosen in some well-defined order
> (e.g., sequentially, a pseudo-random sequence, etc.). Upon a system
> restart, the initial value could be randomly generated, or computed
> from a previous value stored in non-volatile memory.
Again, we removed some such text in the recent simplification of
the document. Do you really think we should start re-complicating?
>
> > 4. Flow State Establishment Requirements
> >
> > To enable flow-specific treatment, flow state needs to be established
> > on all or a subset of the IPv6 nodes on the path from the source to
> > the destination(s). The methods for the state establishment, as well
> > as the models for flow-specific treatment will be defined in separate
> > specifications.
> >
> > To enable co-existence of different methods in IPv6 nodes, the
> > methods MUST meet the following basic requirements:
> >
> > (1) The method MUST provide the means for flow state clean-up from
> > the IPv6 nodes providing the flow-specific treatment. Signaling
> > based methods where the source node is involved are free to
> > specify flow state lifetimes longer than the default 60 seconds.
> >
> > (2) Flow state establishment methods MUST be able to recover from
> > the case where the requested flow state cannot be supported.
>
> I'm not sure what purpose the above provides. I guess its mostly
> harmless, but it strikes me as being pretty obvious, and I wonder if
> these are the only real issues to think about. I.e., is this section
> complete? If not, do we need it?
It stops here, once again, to avoid getting into specific use cases. But
we did feel these were necessary to avoid future flow-state mechanisms
interfering with each other. Does that make sense?
>
> > Security Considerations
> >
> > The use of the Flow Label field enables flow classification also in
> > the presence of encryption of IPv6 payloads. This allows the
> > transport header values to remain confidential, which may lessen the
> > possibilities for some forms of traffic analysis. However, the
> > labeling of flows defined in this specification may reveal some
> > structure of communications otherwise concealed by transport mode
>
> Seems like more could be said here. If use of the flow label allows
> special treatment of traffic, aren't there possible theft of service
> issues? Or DOS issues, if someone generates traffic trying to
> overwhelm a particular flow? What about authorization? Can anyone set
> up flows? Are there requirements or issues here that should be
> mentioned in Section 4? This section seems a bit incomplete.
Since flow labels are not protected by IPSEC-AH, they can be forged.
We should probably state this. However, since the flow is actually
identified by the {srce, dest, label} triplet, the theft of service
or DOS problem actually requires address spoofing as well as label
spoofing (and is prevented by ingress filtering). We should probably say
this.
Authorization is a local issue in the sending host. I could argue that
since it is not a wire-protocol issue, we don't need to mention it.
However, I think it is worth stating that multi-user hosts may require
an authorization mechanism for individual applications to use QOS services
including the flow label.
Brian
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
