On Tuesday, March 04, 2003, Pekka Savola wrote:
> On Tue, 4 Mar 2003, Bob Hinden & Margaret Wasserman wrote:
> > This is a one week IPv6 working group last call for
> comments on advancing
> > the following document as a Proposed Standard:
> >
> > Title : IPv6 Flow Label Specification
> > Author(s) : J. Rajahalme, A. Conta, B. Carpenter,
> S. Deering
> > Filename : draft-ietf-ipv6-flow-label-05.txt
> > Pages : 8
> > Date : 2003-3-3
> >
...
> substantial:
> ------------
>
> The 3-tuple of the Flow Label and the Source and
> Destination Address
> fields enables efficient IPv6 flow classification, where only IPv6
> main header fields in fixed positions are used.
>
> ==> this might require some extra analysis somewhere (not in that
> particular place, I think). In particular, this seems to say
> that once
> this is published people can happily move to using the three-tuple
> classification. The reality is probably quite different, and
> one must
> also consider the big portion of nodes which do not mark the flows.
>
Maybe the text is too lean. The meaning should be that this spec enables
the flows to be labeled, and when labeled, efficient classification is
possible. It is also said in the beginning of section 4 that the
classification is meaningless, unless the nodes somehow communicate the
"semantics" of the flows to the nodes performing the classification. This
is the role of the flow state establishment methods, which are to be
defined separately.
> A possible fix would be to tone down "enable" (e.g. "make xxx
> possible")
> and add some minor tweaking.
>
Maybe the following edit would make this point clear:
"The usage of the 3-tuple of the Flow Label and the Source and
Destination Address fields enables efficient IPv6 flow
classification, where only IPv6 main header fields in fixed
positions are used."
Comments?
> 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.
>
> ==> this requirement seems unacceptable at the moment. This clearly
> requires (at least) de-facto API so applications could set Flow Label
> values -- and as such does not exist. If it did (and I
> believe there's
> work in progress), there would *have to be* a normative
> reference to it).
> So, clearly a MUST seems to a big no-no.
>
I agree that a standard or de-facto API would be highly desirable for
application writers, but I have had the impression that specifying APIs
is not the concern of the IETF. So even if the standard existed the
reference to it should be informative (even if the functionality is a
MUST). If somebody's business model calls for proprietary APIs, we (as
IETF) should not care.
My personal view is that the MUST is needed to get the API definitions
/standardization to happen. If it was a SHOULD, an stack implementer
might think *he* has a valid reason not implementing the interface,
rendering the flow labeling useless for uses that require the
applications to be in control of the value for a particular flow.
Also, placing the requirement weaker than MUST, and waiting for API
specifications, and then revving the standard with a MUST would be bad
practice, IMO.
Also, I don't think that it is too bad if initial implementations have
proprietary interfaces, as even it would be an improvement over the
existing situation.
In an earlier revision of the document we had text about an abstract
interface definition, but it was removed from the doc under WG consensus.
> 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 120 seconds of the termination of the previous
> flow.
>
> ==> so, if I make create a raw socket, manually fiddle in the
> flow label
> value which was previously used, and send the packet, the
> operating system
> kernel should hijack it and prevent it from going out? Get
> real. Perhaps
> s/reuse/unintentionally reuse/, or some other rewording?
>
"unintentionally" is exactly what it means, so there is no problem
doing this edit. This is related the API-issue above, as the
interface is required for the applications to be able to specify
which packets belong to which flow. No raw socket is needed for the
fiddling, as the interface enabling this is a MUST requirement
already! The operating system of the kernel should definitely not
hijack anything, but honor the value the application sets through
the implemented API.
This also touches on the "trust on the end node" issue you refer
below. More on this below.
> To enable co-existence of different methods in IPv6 nodes, the
> methods MUST meet the following basic requirements:
>
> ==> this and the following points seem a little oddly placed
> in this memo:
> they seem out-of-place, as the rest of the memo seems to
> concentrate on
> entirely different issues. Personally I view specifying how
> source nodes
> should label flows one thing, and the rest entirely another.
> But I can
> live with these, even though I think they're more fit to a
> non-standards
> track document.
>
The title of the section is "Flow State Establishment Requirements",
which clearly sets it apart from the previous section ("Flow Labeling
Requirements"). The editorial problem here is that labeling requirements
already enable most of what is needed for the flow state establishment
methods, and there is only a little to add in the section 4.
The most important part of the section 4 is the first paragraph:
"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."
It should be noted that without such a separate specifications for
specifying how nodes inform each other about the flows they have defined,
the flow label is going to find only little use, as the labeling as seen
by a node in the path typically makes no sense: there is nothing a router
could do based on classifying the flows without being told what to do to
the packets, once classified (perhaps keeping the packet of a flow on the
same next-hop is an exception here).
IMO the trust issues should be handled on the flow state establishment
method -level: Why would a node believe that a request for a flow
-specific handling should be honored?
> 5.1 Theft and Denial of Service
>
> ==> this section mainly deals with issues relating to forging
> all of the
> source,destination,label three-tuple (exception is the last
> paragraph,
> which deals with a trusted-node-but-untrusted-user/application case),
> which protects mainly against a DoS attack (resource depletion).
>
> This seems to overlook the most important part: the typical
> model today is
> that operators perform differentiation of flows *themselves*: this
> document proposes to shift that, *over an administrative
> boundary*, to the
> source nodes, which suddenly become trusted to do the right thing.
>
I would rather state that the nodes do what they want, and the operators
do what they want based on that. In the positive case someone comes up
with a specification allowing flow set-up over the administrative
interface. In the meanwhile the operators continue classifying as they
see fit based on whatever fields they were using before.
> This would be equivalent to replacing network ingress
> filtering (to drop
> packets with forged source addresses) to a requirement for
> nodes to allow
> out only packets which include their own source address.
>
> Needless to say this seems to indicate a major oversight of the
> security/operational reality. I'd be very surprised if this was not
> pushed back in the IESG unless this caveat is very explicitly
> documented.
>
There is no operational implication expected due to this specification. It
would be the flow state establishment methods and their application that
would result in new operational reality. Maybe this should be clearly
stated in the text?
> semi-editorial
> --------------
>
> Nodes keeping dynamic flow state MUST NOT assume packets
> arriving 120
> 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.
>
> ==> this is a way too sentence, 5 lines, and constructed in with a
> negative: "MUST NOT blahblah, unless foofoo". You really
> have to read
> that a couple of times to understand what it's trying to say. I'd
> strongly urge to reword and simplify.
>
One alternative way of putting this would be:
"Nodes keeping dynamic flow state may assume that packets arriving
less than 120 seconds after the previous packet of a flow still
belong to the same flow. The time of an explicit flow state refresh
by a flow state establishment method is also to be considered as a
packet arrival. A longer flow state lifetime may be specified by a
flow state establishment method."
IMO this has exactly the same (intended) meaning. Would this be better?
With 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]
--------------------------------------------------------------------
