On Tue, 18 Mar 2003 [EMAIL PROTECTED] wrote:
> > ==> 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.
Ok.
> > 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?
Fine by me.
> > 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.
This seems to be a similar point to the discussion yesterday at the
meeting about deployment problem with RFC3041 addresses, and not being to
toggle their use in an application-specific manner (even though the API is
must).
Personally, I'd rather see whole standards implemented rather than only
parts of it. That's why I tend to argue on removing or changing the parts
which make implementation or compliance difficult.
So, I think a strong SHOULD or a weak MUST is necessary, but I'd like to
get feedback particularly from apps folks.
> > 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!
I'm not sure if I agree with your last sentence. If an application
requests a specific flow label which is already used by another
application at the moment, should the node allow that or return an error?
I'd argue for an error, with a possible exception of an app run with
"root" privileges.
> > 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).
Ok.
> 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?
As long as there is a customer relationship (or similar) between the owner
of the node and (parts of) the network, this should be a non-issue.
> > 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.
Well, that might be an approach.. but I'd build on the text I proposed on
the list on the separate thread, maybe add something on top of that based
on what you say.
> > 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?
It's ok to say what's expected, but one should also then say why such
thing is expected.
In my experience, this w.g. is not the best versed in fleshing out
operational implications, and we should assume the worst.
> > 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?
This is ok by me.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
