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:
> > >
Thomas, I'm happy to see a thorough review of the spec. Thanks.
> > > > 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?
>
The intent has been to specify for routers what is needed in the absence of any flow
state establishment method. It would be up to tem to define their router requirements.
> 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.)
>
This is a goal, but to a limit. It is impossible to anticipate the needs of future
FSEM specifications. We included requirements for classifiers targeting the RSVP
Wildcard-Filter reservation style requirements still in the -03 version, but these
"higher layer constructs" were to an effect obscuring the "simple flow" definition.
> 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.
>
I have suggested a clarification based on your text proposal below.
> 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?
>
The document states that flows are mapped from the three-tuple. The wording for this
has evolved through the different draft versions. In -03 we also had the following two
statements in the current section 4:
"(1) A packet is classified unambiguously to a flow on the basis of
the Flow Label, and the Source and Destination Address fields. The
flow state establishment method MUST convey this classifying
information to the IPv6 nodes that need to perform the classification.
Usage of any additional header fields for flow classification is
beyond the scope of this specification."
"(2) The flow state establishment method MAY associate multiple Flow
Label, Source Address, Destination Address triplets with the same
flow state (e.g. an SCTP connection between nodes with multiple
addresses, or a classifier with an address range, see the RSVP
Wildcard-Filter example in section 4 above)."
When faced with the comment "document too complex" from the chairs in the last
meeting, I reasoned that the (1) above is not adding anything that could not be
deduced from the other text in the document, and the issue addressed in (2) was not
absolutely necessary for this document, or at least it seemed to be too complex
concept to process by the WG at this time. I do not know if the RSVP Wildcard-Filter
style reservations will be really utilized in future, but if they are, it would be
pity if the ASIC implementation would require replication of the classifiers for all
different source addresses to support it.
> > > > 2. IPv6 Flow Label Specification
> > > >
...
> > >
> > > 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.
>
I would not want to use the "flows are defined by" language above. There are many more
aspects to the "flow definition" than the classifier. Also, the classifier might be
more than one of the tuples (or triplets), even if not further specified in this
document.
Also "that have special processing enabled" sound like it would be (only a)
configuration option (on/off), while the processing depends also on the actual flow
set-up.
So how about this:
"The 20-bit Flow Label field in the IPv6 header [IPv6] is used by a
source to label packets of a flow. Packet classifiers use the triplet
of Flow Label, Source Address, and Destination Address fields to
identify which flow a particular packet belongs to. Packets are
processed in a flow-specific manner by the nodes that have been set
up with flow-specific state. 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 out of scope for 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.
>
I think we are stating the "SHOULD label" in the section 3 ("Flow Labeling
Requirements") is sufficient? Comments?
> > > > 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).
Yes. I think so too.
> > > 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?
I don't know. It just says that if the node creates flow state out of the thin air,
the node should not assume "stability" of the flow classifier after a gap of 60
seconds. In most cases it may be that the flow is still the same flow, and could be
processed as before. In other cases it is of no significance that the flow "changed"
and the node can keep processing the packets as before (not flushing anything). It all
depends on what the node is doing.
This "must not assume" is just one side effect of the sources not re-using "flow
identities" for 60 seconds after the previous flow terminated.
>
> > 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.
>
Presumably the node can re-create the state it needs after the gap. Since there was a
long gap, there should be no reordering issues (in case the new state for example
determines a different next-hop interface).
For reference, RFC 1883 defined a lifetime value of 6 seconds.
As I said above, I do not know any use of flow-specific state without the support of a
flow state establishment method. But if we do not define a default lifetime now, it
cannot be added later. Also, it seems logical to have *some* pause before a previously
used flow label value should be re-used for a new flow.
WG chairs (collectively) insisted on the definition of the default lifetime, and there
were no opposing voices on this from the WG.
I do not think the default lifetime should have anything to do with TCP timeouts, as
long as it is long enough to not cause any reordering issues. But this is not an issue
for me, any value is fine, especially if someone could come up with good justification
for the value :-)
> > > 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.
>
No. It would still give the flow X, but it would just need to re-use the
algorithm/method/whatever to re-create the X after the gap, if it flushed the X.
It might be likely that X is not really flow-specific, but can be applied to
aggregates of flows. In this case there is no point in flushing the X (ever).
> 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...
>
Good :-)
> > > > 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.
> > >
You left the 2nd paragraph out from your quote. I think it should be considered here
as well:
"To enable applications and transport protocols to define what packets
constitute a flow, the source node MUST provide means for the
applications and transport protocols to specify the Flow Label values
to be used with their flows. The source node SHOULD be able to select
unused Flow Label values for flows not requesting a specific value to
be used."
> > > 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?
As stated in the 2nd paragraph, the stack cannot determine the application-defined
flows by itself.
The document is not aimed only at IP stack implementers. It is also aimed at
implementers of e.g. media transport "middleware" (i.e. RTP/RTSP/SIP implementers, in
their role as "applications" defining flows) and folks responsible for API definitions
(I hope that the API recommendations would be addressed in the socket API specs).
> 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.
>
It seems to me that the 2nd paragraph is saying what it needs to, if we leave API
specs out of this document.
> > > > 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.
>
The changes (1st and last sentences) seem good to 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.
>
There are at least two ways to implement this:
1) the stack implementation allows the application (or any middleware on top of the
stack) to define the lifetime, that the stack will then honor (e.g. by not assigning
that value to any new flow for the timeout value after all sockets belonging to that
flow have been closed), possibly individually for the flow, or by utilizing the
longest timeout for all flows.
2) In the absence of the interface for the non-default lifetime, the FSEM could keep
the flow "reserved" for timeout-60 seconds after the flow's traffic has finished, and
only after that release the label back to the stack (which would then keep the value
reserved for the normal 60 seconds).
> 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.
>
You are right in that the text suggests utilizing a (random) initial value and
sequential assignment for flows for which applications do not ask for a specific
value. It is a SHOULD to prevent implementations always starting from 1, for example.
But other methods of avoiding accidental re-use are possible (i.e. if the system is
able to maintain all flow-related state across reboots).
I do not think it can be deleted.
How about:
"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 select new Flow Label values in a well-
defined sequence (e.g. sequential or pseudo-random) and use a
different initial value for the sequence each time the system starts.
The initial value could be randomly generated, or computed from a
previous value stored in non-volatile memory."
> > 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.
Again, it is a matter of taste what is considered temporary. Again, the only issue
with TCP I can think of here is possible re-ordering issue, which is not an issue
after a gap of couple of seconds.
> > > > 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?
>
You might want to read the -03 draft (at
http://www.ietf.org/proceedings/02nov/I-D/draft-ietf-ipv6-flow-label-03.txt ) it had 6
requirements. Some of them were clarifying implications of the other text, but were
cut of to reduce the complexity of the document.
It would be good if you could read the -03 version to see if we dropped something that
really should not have been dropped (as you see it).
> > > > 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.
>
If the proxy is aggregating traffic so as to share a flow, then it no longer "my
bandwidth" or "your bandwidth", it is just aggregate bandwidth that the proxy is
responsible for managing, at least responsible for which traffic it is inserting to
the aggregate. From the IPv6 viewpoint the proxy is the source of the flow.
On a multi-user machine the kernel would be responsible for not allowing mixing flows
of applications belonging to different users.
> 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.
There has been nothing in this current discussion that would not have been considered.
It should be obvious that giving more resources to someone does not make sense without
compensation, but the authorization is more of an issue for the flow state
establishment methods (which are out of scope for this doc). Labeling is free as is
some aggregate based load spreading, but some authorization is required for any real
flow-specific treatment (this spec does not define any).
I agree that it would be good if the WG could come up with a more complete Security
Considerations section for this document.
Regards,
Jarno
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
