Pekka, Please see in line:
Pekka Savola wrote: > > On Wed, 12 Mar 2003, Alex Conta wrote: > [....] > > > > > > 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. > > > > > > > > But this is a statement about what hosts must do to make the flow label > > > > useful. > > > > > > No, that's not correct, or either of us is misunderstanding the paragraph > > > above (if so, a wording change is needed). > > > > > > The nodes (kernel, in particular) are able to mark flows by itself, > > > without any interaction from the applications -- so having apps have a > > > MUST possibility to influence the flow labeling is undoubtedly useful, but > > > certainly not something requiring MUST, considering the current situation. > > > > > > > In simplified translation, the text says that the IP layer is not the > > only layer selecting flow label values. This is the way it MUST be: in a > > node, which is sourcing labeled packets, the flow label value is in the > > same category with other fields of the IPv6 header: clients of the IP > > layer (layers above) MUST be able to set the value, if they need to. > > ... > > > > Note: I'd argue for MUST myuself if we had had a standard (or even > > > de-facto standard!) mechanism specified (and hopefully implemented) for 1 > > > year before this being sent to the IESG. > > > > > > > The (this) requirement is not conditional to the existence of an API, or > > an API function call mechanism. Rather the API, or the API function > > call, or the API function call parameter, is a consequence of this > > requirement, which is the way it should be. > > No, I have to disagree with this approach. In this case, making a > normative reference to an API document (which would delay the publication > of flow label specification until the API is published) would be OK, but > I'm not sure that's what folks would want. > I think this was never intended: it is not a normative reference to an API document. It is simply a requirement for implementations. > For *applications* and application writers (which are also the customers > of flow label spec here) requiring that implementations provide any > programming interface at all, one specific to the implementation is the > worst choice possible. So, if one would like to write portable > applications, you'd have to use each implementation-specific programming > interface for every implementation. > The mechanism, whatever it is, a standard or proprietary API, or one function call of an API, or one or more parameters of an existent function call, or anything else, are all completely independent of this flow label specification. Please remember: publishing IPv6 specs as proposed standard (RFC), was never dependent on publishing or referencing an API. > That seems counter-productive and unacceptable, IMO -- but I'd like to > hear what application writers would say about that. I agree with the need > of a way to have applications to be able to influence the flow label, but > a MUST would possibly lead to one of the below: > > 1) all implementations implementing different programming interfaces; a > non-starter for applications > I think this is orthogonal to the flow label specification. > 2) implementations not implementing all of the flow label spec, ie. just > blatantly ignoring the MUST (compare with the temporary/public address > knob in the default address selection, in RFC3484 sect 5r7 -- this was a > bad last-minute compromise which nobody have implemented AFAIK) > It is a fact of life to have non-fully compliant implementations. That is orthogonal to the progress of a specification to proposed standard. > 3) implementations waiting for an API before implementing the flow label > spec > > > > > If you want to standardize a socket API extension that's fine, > > > > the Open Group exists for that. However, I believe a MUST is needed. > > > > > > A MUST without a means is bad practise, IMO. > > > > > > > This sets the rule, from the protocol stack angle, for the flow label > > related API, API function call, or API function call parameter(s). The > > rule will bring the "means". > > I guess we disagree on the usability of the API for application writers if > the API is not uniform enough. Personally, I view an > implementation-specific API for something generic like this useless (as a > programmer). Even if we do not go any further on this, I think we reached an area which is way outside the scope of the flow label specification. I may agree with you close to 100% on what you say right above, but only as part of a completely different topic, which is not this flow label specification, it is not this last call. > > > > > > 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? > > > > > > > > Yes, the stack is supposed to do that. It's not hard. In an earlier version > > > > we included an algorithm, but the WG wanted it removed, so we removed it. > > > > > > Yes, the stack can do it easily -- no doubt about that -- but it's > > > *wrong*; this is connected to the security issue, below. > > > > > > > There were people that requested this particular behavior. > > I wonder if they realized the implications. I'm sure that e.g. people > focusing on the network part of the flow label would really appreciate > having a flow labels guaranteed to be distinct, so their use in QoS and > whatever would be a lot simplified, but that ignores the big picture at > the expense of looking at only part of the solution space. > I think they did. Even though it is succinct, the specification defines, or mentions a number of mechanisms pertinent to a very diverse set of views, and uses. Personally, I favor some over the others, but after thinking, and understanding, I agreed that all can work. This was essential for being part of the current consensus, which took a long time, and a lot of work, from the WG, the authors, the WG chairs, and the area directors. > > So, were you saying earlier that if the text in the draft > > > > ***MUST ensure that it does not reuse Flow Label values....*** > > > > were: > > > > ***MUST ensure that it does not unintentionally reuse Flow Label > > values....*** > > > > it would be OK with you ? > > I find that acceptable. Extra text in security considerations would still > be required, though (as noted later in my message). > Let's hold on to this (including the word "unintentionally") for a moment. >[...] > > Here is another opinion. The two are the essential aspects of the flow > > label mechanism: setting the flow label in nodes sourcing packets(1), > > and processing flow labels in nodes receiving labeled packets (2) > > [packet forwarding nodes]. > > [...] > > As I read it, you wrote that as a disagreement, but IMO that sounds very > much like a partial agreement to me: that flow labeling consists of two > different functions. > Indeed, there is partial agreement. And there would be full agreement, if you looked at that as two functions, or rather two components of one mechanism. > These functions have entirely different requirements and considerations, > but naturally, both are required to implement flow labeling. > > I was just arguing that "2" and "1+1" still makes "2", but "1+1" could be > simpler for those that are only interested in the first or second "1", > etc. > Indeed, so we agree, as I expected above. > > > > > 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. > > > > > > > > No, it adds the *labelling* of flows to the source, as a new capability. > > > > > > The labeling with current "service model" leads to differentiation. I'll > > > try to reword it again below. If the "service model" would be such that > > > the source node is *not* expected to label flows correctly, I'd certainly > > > agree. > > > > From the point of view of the "operators model", servicing packets based > > on packet classification, labeling flows is essentially not different > > than setting other packet header fields, which are used for packet > > classification, so I do not understand why you see a difference. There > > is no intention in the draft to shift the current model to a different > > one, to any "administrative body" on the source nodes. > > The spec very clearly states that flow labeling enables classification > based on (src, dst, flow label). That is clearly different than (src, > dst, protocol, srcport, dstport). > You're pointing now to a difference in the placement of the fields in the headers, which I think is orthogonal to the difference you were pointing at before, to which I responded that there is no difference. Earlier, I think you were trying to say that without flow label, there is a certain model, which changes with the use of the flow label. Essentially, I responded that it is not the case, the model does not change: the model of trusting/doubting a flow label is not different from the model of trusting/doubting a pair of ports and a protocol number: they're all set by the source node of the packets, and are part of some classifiers set with some direct/indirect knowledge/agreement from network infrastructure operators. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings Regards, Alex Conta
smime.p7s
Description: S/MIME Cryptographic Signature
