below...
Thomas Narten wrote:
>
> 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.
Rather, they need to be *capable* of classifying based on the
3tuple. I'd be happy to see this added.
> ...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?
That's the implication, given the definition of a flow at the
beginning of the document. My personal preference is not to say this,
since it's a direct implication and I prefer fewer words, but it's
for the WG to say.
>
> > > 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.
Well, it's my assertion that the definition of exactly what belongs
to a flow *is* use-case dependent, and that we can't say more
than the -04 draft says. This is after all a network layer WG and
flows are a transport layer (or above) concept.
>
> > > > 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.
Agreed
>
> > > > 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.
See below
>
> > > 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.
If we say N seconds instead of 60, that is exactly the implication -
in other words flow state should be soft state. Are you objecting to
that, or to the choice N=60?
>
> 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?
I don't recall whether this was email or f2f discussion, but I agree
we've been round this before. Not sure there was any conclusion.
>
> > > > 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...
Or to remove, for me.
>
> > > > 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.
Yes, and I think that is the same point as needing to mention
authorization issues under security. Who has the right to QOS is an
authzn issue and this is just a subset of that problem.
>
> > > > 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.
OK, we could certainly add a sentence about that (assuming we agree
that the basic model is soft-state).
>
> 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.
OK by me
>
> 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.
Well, at the least it would require the quarantine time to be a
parameter in some API. But we don't really want to go there in
this document.
>
> 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.
I'd be happy to delete it, and leave it as an exercise for the
implementor.
>
> > 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.
My original suggestion was 600s. The objection is that this means that
after a crash/reboot, no flow labels can be allocated for 10 minutes,
if you are logical and use the same timeout everywhere. That's where
the suggested compromise on a shorter time came from. I think there
is no right answer here, unfortunately. At least, I'm wedged on it.
>
> > > > 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.
Absolutely, with same issues for low-end devices. Again, there seems
to be no right answer. (BTW I don't have any problems with your text,
but we need guidance from the WG about whether to add it.)
>
> > > > 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.
Yes, hence the need for authorization mechanisms in multiuser hosts,
and this definitely needs to be stated.
>
> 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.
Well, my view is that the issues are quite similar to those with
diffserv code points, where we have never found much to write either.
Once you accept that the label (like the DSCP) is forgeable, there
isn't much more to say, unfortunately. (There is text in both
RFC 2474 and 2475, and maybe some if it applies here too.) Theft of
QOS certainly deserves work, but the problem is very general and
probably not for this document.
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]
--------------------------------------------------------------------
