Pekka, 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 > > > > The chairs belive this draft represents the consensus of the working group > > and resolves issues raised during and subsequent to the working group last > > call. However given the time that has elapsed we think a short working > > group last call is desirable to verify the consensus before forwarding the > > document to the IESG. > > [note: I had already written this message once but accidentally cancelled > the message -- hope I don't forget anything] > > In summary, I don't believe the doc is ready to be sent to the IESG. > There are a few major issues to be worked out yet, the last of the the > most important. > > Comments below. > > 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.
The goal of this document is not to describe use cases. It is to set the minimum conditions hosts and routers must meet. I do not believe we should add use cases to this document. > > A possible fix would be to tone down "enable" (e.g. "make xxx possible") > and add some minor tweaking. I don't think we need to tweak. "Enable" is exactly right. > > 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. 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 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. > > 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. Then you don't want a change here? > > 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. It says *nothing* about how differentiation is done. That is indeed a separate and quite complex discussion, that will keep the QOS community busy for years. The idea is to keep that discussion out of the IPv6 WG, by defining the boundary conditions here, so that the flow label becomes a viable tool for differentiation downstream. I think this was clear in the previous WG discussions. > > 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. No. The checks can perfectly well be applied at ISP ingress. I did want to include more aggressive text about ingress filtering, but in fact it would be out of place. (By the way, do you think nodes *should* be allowed to forge the 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. I think your interpretation is quite wrong, but we can certainly ask a security expert or two. Thanks for the review, and for the editos below. Brian > > 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. > > editorial > --------- > > If an IPv6 node is not providing flow-specific treatment, it MUST > ignore the field when receiving or forwarding a packet. > > ==> reword: "providing .. treatment" seems to sound awkward in the case of > "receiving a packet" (ie. in the case of end-node, not router). > > -- > 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] --------------------------------------------------------------------
