Happy to see the WG Last Call finally announced :-)
Bob Hinden wrote:
> The IPv6 w.g. chairs believe there are some important open
> issues that they
> would like to see the working group discuss as part of the
> working group
> last call on the "IPv6 Flow Label Specification"
> <draft-ietf-ipv6-flow-label-03.txt>.
>
> The current draft allows flow labels to be used in ways that go beyond the
> consensus that was reached when the working group agreed to make this
> document a working group document.
The draft is where the WG consensus should be documented, as it has
been continuously revised based on the comments received in both the
meetings and on the list. At least I have not been aware of any other
documentation of the WG consensus on this topic.
Naturally the draft will be further revised based on the comments and
consensus on this list during the WG Last Call period.
> This consensus was that the flow label would be set by a source node
> to label a set of packets (with same source and destination addresses)
> that the source wanted to be treated as a flow.
> The flow label in this definition did not have any defined
> structure.
> The main application for this was to make it easier for other
> nodes to recognize flows without having to search to one or more headers to
> find the transport port numbers.
I may be too careful here, and am sorry if the following is unwarranted.
"Recognize" is clearly out of the consensus, if it means anything else
that "classify". Also it has been long standing consensus that there
should be no requirement to have 1:1 mapping between transport
connections and IPv6 flows, with the explicit meaning that the flow
label is not mandated to be a transformation of the transport header
information. What this means is that classifying on the traditional
5-tuple (addresses, transport protocol, port numbers) and the 3-tuple
of (flow label, addresses) WILL in some cases result to different
results.
So the main and only application of the flow label field is to enable
efficient flow classification independently of the upper headers. The
source node defines what constitutes a flow by labeling the packets.
It is free to put multiple transport connections to the same flow, or
to split a single transport connection between multiple flows.
One possible interpretation for "recognizing flows without having to
search ... the transport port numbers" is that the flow label based
classification would be expected to map 1:1 with port number based
classification, even so that the flow label based flows would be
"recognized" by first classifying on the port numbers, creating flow
state out of that based on the flow label that happened to be in the
same packet, and then later classifying on the addresses and flow label
only, with the expectation that the classification results be the same
as would have been for port based classification.
If the chairs have the intention to drive the solution to the direction
described above, it would be fair to say so, so that the necessary
discussion can take place on the list as part of the Last Call process.
The first time I saw the above kind of scenario being proposed on the
list was a couple of months ago, roughly half a year after the decision
to make our draft a WG work item.
I'm sorry if I indeed was just too paranoid about this, and this is
really a non-issue for all of us.
> The current draft has a number of
> features that go beyond this model and permit many other modes. Examples
> include:
>
Some earlier attempts to specify the flow label usage have failed due to
trying to narrow down the usage scenarios resulting to endless
discussions of issues secondary to the flow label specification itself.
To enable building consensus on the specification, the authors have
aimed at minimal requirements that enable the intended uses of the flow
label. Our intention has not been to prohibit any other (maybe unknown)
modes/models.
I still believe the specification should specify the absolutely needed
minimal requirements, and additional helpful guidance where necessary.
> - Allowing for other standard specifications to define
> properties and/or
> structure of the flow label field.
This is referring to the sentence:
"IPv6 nodes MUST NOT assume mathematical or other non-standardized
properties of the Flow Label values assigned by source nodes."
Currently, no such standardized properties exist. Any such standard
would necessarily need to be approved by the IPv6 WG and IESG in
future. But if this is seen as an issue, I would be happy to change the
referred sentence to (rest of the paragraph shown for context):
"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."
> - A strong focus on the assignment of flow label via
> signaling protocols.
I do not see this. There is strong focus on distribution of the flow
state via flow state establishment methods, that may be signaling
methods, manual configuration, etc. References to signaling methods like
RSVP and SDP are there to provide helpful guidance to work being
conducted in NSIS, for example.
In section 4. there is the highest precedence rule for assigning packets
to flows, that is specifying a signaling method with a MAY. The
motivation for the precedence ordering in that section is that there
should be default behavior of the TCP/IP stack (4), that should be
overridden by applications having more knowledge of their flows (2),
that should be overridden by any specific configuration on the source
host (3), and that should finally be overridden by signaling based
methods, since they provide the most "current" or "timely" knowledge of
what packets should belong to which flow. This order represents the
understanding of the authors on how the assignment of packets to flows
"works". However, we are open for any comments on this area as well.
I should also note that the assignment of a specific flow label value to
the flow is somewhat orthogonal to the above ("assignment of packets to
flows"). Also in (1) the source will most likely pick a value that is
then used part of the classifier, that is then configured in the
relevant nodes.
> - Allowing a specific flow label value to be assigned via
> a signaling
> protocol to identify flows with different source and destination
> addresses.
>
As long as applications are allowed to specify what flow label values
should be used with specific flows, the above is allowed as well (the
signaling protocol being utilized by the application in this case).
To not allow the above necessarily means to only use random (at least
from the viewpoint of the application) flow label values for each new
flow.
We should not make random assignment mandatory just to prevent upper
layers to build higher-layer constructs based on flows, especially when
at least some of those constructs can be seen to be beneficial. The RSVP
Wildcard-Filter reservation style is the example of this we have in the
draft currently (2nd to last paragraph on section 4, on page 5).
> The draft may be trying to accommodate uses of the flow label
> that were not
> agreed to by the working group.
>
It is my opinion that it would be futile to even try to agree on the all
possible uses of the flow label field in the working group, at least
now. For example, the non-mutability requirement would allow people to
build end-to-end protocols with application multiplexing without using
any transport headers by using the flow label as the multiplexer. While
there may be many reasons why such a thing would be a Bad Idea, the only
real consensus possible for this WG is "so what, we don't care". The
only way to really prohibit the end-to-end usage would be to make the
field explicitly mutable, which I do not think we can do without harming
the usage as a well defined classifier.
What I mean with the above that we should not worry what uses someone
may come up with as long as they do not interfere with the use as a flow
classifier. (It could also be added that if none of the flow endpoints
wants to have the flow classified, there shouldn't be any reason to not
allow even weirder usages between consenting hosts.)
> There are a number of other areas in the draft that need additional
> discussion and/or clarification. These include:
>
> - No default time out for the life time for specific flow
> label values.
The requirement (5) (section 5) is in there to mandate flow state clean-
up. If flow state establishment method requires a time out, then it
would be up to that method to define the time out. Some, e.g.
configuration based methods, may not require a specific time out value
at all.
> - No requirement that signaling mechanisms must include a lifetime
> when providing flow label setup information.
This could be added. Currently it states that (for methods in general)
both soft- and hard-state methods are possible. This could be refined so
that dynamic methods (including signaling based methods, algorithmic
methods) would need to specify a time-out, while static methods (e.g.
configuration based) should not.
> - No default mechanisms if flow label values requested via
> a signaling
> mechanisms conflict with existing flow label values.
It would be the function of the signaling mechanism itself to define the
error response mechanism (currently a SHOULD in (6) of section 5). Maybe
that should be a MUST instead? I don't see what a default mechanism
could add here? It could be hard to coordinate the implementations
between a signaling mechanism (e.g. in the user space) and a separate
default error response mechanism (possibly in the kernel).
> - Security considerations need to discuss the impact of
> labeling flows
> of encrypted traffic.
That is already done to some extent. Currently all we have is:
"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."
Also, in the -02 version we had the following sentence in the beginning
of the Security Considerations:
"Anything that facilitates flow classification also increases the
vulnerability to traffic analysis."
That was removed based on the feedback received. Should we move that
back in? Is there something else the chairs see missing?
>
> The chairs would like to see these issues discussed by the
> working group in
> the last call.
>
> Bob Hinden, Steve Deering, Margaret Wasserman
>
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]
--------------------------------------------------------------------
