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. A possible fix would be to tone down "enable" (e.g. "make xxx possible") and add some minor tweaking. 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. 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? 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. 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. 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. 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] --------------------------------------------------------------------
