Brian E Carpenter <[EMAIL PROTECTED]> writes:
> 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.
We may be more in agreement than appears. I agree that usage scenarios
should be left out. What I want to be sure about though is that router
implementors have a clear understanding of what they need to
implement, in order to be able to support flows once specific usages
are defined. (Or, please correct me if this is this not a goal here.)
I.e., folks doing hardware today want to know what they are supposed
to do with the Flow Label. They don't want to find themselves later
down the road saying "oops" our hardware can't support that because we
didn't know that's how flows were defined.
It may well be that all that needs to be said is that a flow is
defined by the three tuple, and that implementations need to classify
based on the tuple. What is done to packets that belong to a
particular flow is future work. But the definition of how the
classification is to be done seems important to nail down now. IMO,
the current wording about this could be more clear. But if hardware
folk feel like the current words are sufficiently clear on this, I'm
OK too.
My assumption is that this document is trying to say that classifiers
need to map the three-tuple into a "flow". Or am I wrong? Is the
document not even wanting to go this far?
> > 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.
If the point is that how packets of a specific flow are to be
processed needs to be defered to future work, I agree. But if this
also relates to the definition of which packets belong to which flow,
I wonder whether this document achieves anything useful in practice.
> > > 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.)
Pekka said exactly what I would say here.
> > > 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".
agreed too.
> >
> > 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.
Make the "SHOULD implement" a separate point from the definition
itself then. And have it refer specifically (for hosts) that they
SHOULD label outgoing packets. That is what I think we are aiming for.
> > > 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)
Well, I have a basic problem with a default timeout of 60
seconds. Heck, a temporary routing glitch can cause a loss of traffic
for 60 seconds, yet the TCP sesssion doesn't go away that quickly. So
60 seconds seem like a rather odd compromise value. Seems too short to
me.
> > What problem is the above wording intended to address?
> Use cases that nobody has thought of yet.
I don't understand this answer. If a router does something
flow-specfic for flow X, but then sees no traffic for 60 seconds, the
implication now is that it shouldn't give flow X the same treatement
it was just giving it just 60 seconds ago.
I do remember some discussion on this in the past. But I still don't
feel like I understand the rational. Can someone please summarize or
point me back to a previous thread?
> > > 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.
Not a show stopper to leave in...
> > > 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.
Part of my concern with the current text is it says hosts SHOULD set
the flow-label for each Application-level stream. I assume, however,
that this document is aimed at the IP stack, not at individual
applications. I.e., how will someone who implements the stack be able
to use different flow labels for different application stream without
help from the application? Seems like some sort of wording about this
would be good. I'm not saying it even needs to be normative (it
probably shouldn't be). But maybe some guidance. The existing wording
seems a bit incomplete and the issues here seem more complex.
> > > 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".
ok. But that alone doesn't fix the issue. Just saying it "needs to
keep track of" doesn't focus on the "why". I think the document would
be better off saying what fundamental principal an implementation
needs to be sure to not violate. In this case, it's not reusing the
same flow label too quickly, including across reboots. I agree that
mandating how an implementation does is beyond the scope of the
document.
Note: an implementation doesn't need to keep track of which flow IDs
it has recently used (as the current words say). It simply needs to
ensure that it doesn't reuse any that have been reused recently. There
is a subtle difference. I.e., one doesn't need to keep track of *each*
flow one has recently used. One can aggregate that information.
Here's a slightly less delta-ish proposal relative to the current
text:
A source node MUST ensure that it does not reuse Flow Label values
it is currently using or has recently used when creating new
flows. 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 before reusing that Flow Label.
Note: this last sentence seems hard to achieve. it suggests that if a
future flow establishment method uses longer lifetimes, the stack will
have to be retrofitted to figure out somehow not to reuse those flow
label values for the longer period. I suspect that future uses of the
flow label (i.e., the signalling partz) may well be implemented
separately from the base IP stack Flow Label support, and it may not
be possible for the signalling to ensure the quarantine behavior.
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.
Text OK up to here.
but, for the rest:
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.
I think the above text is not really good enough. It makes some
unstated assumptions about how things are implemented. It either needs
more text, or should just be deleted. I guess my attempt at
replacement wasn't successful.
> 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?
Again, it seems like it should be at least as long as TCP timeouts. I
don't think you want the flow state to be reclaimed just because of
temporary network outages.
> > > 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?
The document should be absolutely clear on what the requirement is. It
also seems reasonable to provide some guidance on how to achieve the
requirement, though in a non-normative fashion. This is because folks
will wonder how one can implement the requirement if they have no
stable storage or a very small footprint. I think it was Rob who
pointed out a long while back that there were similarities here with
generating TCP initial sequence numbers across reboots.
> > > 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?
I can live with the text.
> > > 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.
My application, when running between the same pair of machines as
yours, might be able to steal bandwidth from your application. This
might be a real issue where one has proxies and other aggregating
devices talking to each other.
My basic point thought when reading the current text, however, was
that from the few words it wasn't clear that a whole lot of thought
had gone into any possible security issues. The writeup seems a bit
superficial.
Thomas
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
