Hi Brian and Rémi: This set of rules recognizes that the flow label can be overridden to be used locally in a network according to the rules and policies that apply to this network. I'm all for it. OTOH, the proposal assumes that the rules in place in that network are necessarily related to load balancing. There I have to disagree.
While this is certainly the most widespread usage of the FL that we know of today, I do not see the value of placing a constraint there. But if the use is local and the local network can ensure that the contiguous routers that use it do so in a consistent fashion, there's no point telling them what they do with it. You know that in the back of my mind I still wish to use the Flow Label as an alternate to the RPL HbH option. In a RPL network, we can afford to do load balancing based on classical tuple, but we need space for the datapath validation information. For all I know, it is a fair usage of the flow label, and this demonstrates that there's no one-size-fits-all definition of what to do with it. In fact, I cannot see how we could agree on a global significance of the field at this point so keeping it local makes great sense. What must be ensured is that if a router uses the FL in a certain fashion, then the next router understands it or ignores it leaving it untouched. This means we should: - define boundaries where the usage of a field must be consistent (one hop? One subnet? ISP boundaries?) - allow network-local usages that are open but must be consistent with the network boundaries as specified above. - propose some such recognized-valid usages (like: source application mapping flows or sessions onto FL, routers applying multi-topology routing tag, routers applying load balancing tags...) At the end of the day, we should let the network designer decide what's most important for his network. What do you think? Pascal > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Brian E Carpenter > Sent: Thursday, September 09, 2010 11:51 PM > To: Rémi Després > Cc: Thomas Narten; 6man 6man; Steven Blake; Fred Baker (fred) > Subject: Re: Revising Flow-Labels of RFC-3697 - A possible direction? > > Rémi, > > This is quite similar to one possible version of > draft-carpenter-6man-flow-update-04 that is spinning around on my hard disk. > But I really want to get clarity (if not rough consensus) on the immutability > thread before being certain what we should propose. > > I think the rules about tunnels should be completely separate, and they are > really the subject of the other draft, draft-carpenter-flow-ecmp-02. > > Regards > Brian Carpenter > > On 2010-09-10 00:09, Rémi Després wrote: > > Hi all. > > > > Draft-gont-6man-flowlabel-security is based on the assumption that FL > > values > are set as currently specified in RFC 3697, i.e. with a *stateful* algorithm > that > needs to keep track of flow establishments and terminations, and with FL > immutability. > > However, assuming that the aim of envisaged revision of RFC 3697 is to have > FLs actually used, *stateless* FL assignments, with some restricted mutability > rules, is in my understanding, a valuable approach. > > > > With this stateless operation, FL values may be determined on a per- > datagram basis. They may in particular be simple hashes of n-tuples that > identify flows. > > A potential drawback is that, in rare occasions (i.e. bad luck with the > > hash > algorithm), two simultaneous flows from a same source may have the same FL > value although they have different n-tuples. > > But load balancing, which the intended purpose of FLs, only operates on > > flow > aggregates. > > Thus, routing to the same path two flows from a same source has no more > effect than doing it for two flows from different sources. The effect is > negligible. > > > > The best combination I personally get, considering past discussions on a > potential RFC-3697 revision, is so far as follows: > > > > R1. Packet sources SHOULD set FLs to non-zero values that generally differ > from a flow to another (e.g. with currently specified stateful algorithms, or > with > n-tuple hashes). > > > > R2. Packet sources MUST set FLs to zero otherwise. > > > > R3. Intermediate nodes MAY replace null FL values by non-zero FL values, > PROVIDED these non-zero values generally differ from a flow to another. > > > > R4. Intermediate nodes MAY replace non-zero FL values by non-zero FL > values, PROVIDED these non-zero values generally differ from a flow to > another. > > > > R5. Intermediate nodes MAY replace non-zero FL values by null values ONLY > IF found necessary for some identified policy-dependent security reason (e.g. > in > some managed firewalls). > > > > R6. Nodes that tunnel flow aggregates SHOULD replicate non-zero FLs of > encapsulated packets in encapsulating packets. > > > > R7. Nodes that tunnel flow aggregates SHOULD set FLs of encapsulating > packets that contain null FLs to a value that characterize the tunnel itself, > and > MUST set it to 0 otherwise. > > > > NOTE: Since most packets of a fragmented TCP datagram don't contain ports > that identify the 5-tuple of their flow, computing new non-zero FL values > implies operation at the datagram layer. > > > > > > Criticisms and/or support of this approach, in general or in details, are > solicited. > > The idea is to determine whether continuing to contribute in this direction > > is > useful or not. > > > > > > Regards, > > RD > > > > > > > > Le 13 août 2010 à 02:45, Fernando Gont a écrit : > > > >> Folks, > >> > >> I have just published an Internet-Draft entitled "Security Assessment > >> of the IPv6 Flow Label" that analyzes the security implications of > >> the Flow Label header field, and proposes a scheme to set the Flow > >> Label that is compliant with RFC 3697, and compatible with > >> draft-blake-ipv6-flow-label-nonce-02. > >> > >> The I-D is available at: > >> http://tools.ietf.org/id/draft-gont-6man-flowlabel-security-00.txt > >> > >> Thanks! > >> > >> Kind regards, > >> Fernando > >> > >> > >> > >> > >> -------- Original Message -------- > >> Subject: New Version Notification for > >> draft-gont-6man-flowlabel-security-00 > >> Date: Thu, 12 Aug 2010 15:07:50 -0700 (PDT) > >> From: IETF I-D Submission Tool <[email protected]> > >> To: [email protected] > >> > >> > >> A new version of I-D, draft-gont-6man-flowlabel-security-00.txt has > >> been successfully submitted by Fernando Gont and posted to the IETF > repository. > >> > >> Filename: draft-gont-6man-flowlabel-security > >> Revision: 00 > >> Title: Security Assessment of the IPv6 Flow Label > >> Creation_date: 2010-08-12 > >> WG ID: Independent Submission > >> Number_of_pages: 20 > >> > >> Abstract: > >> This document discusses the security implications of the IPv6 "Flow > >> Label" header field, and analyzes possible schemes for selecting the > >> Flow Label value of IPv6 packets. > >> > >> > >> > >> > >> The IETF Secretariat. > >> > >> > >> > >> > >> -- > >> Fernando Gont > >> e-mail: [email protected] || [email protected] PGP Fingerprint: 7809 > >> 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > >> > >> > >> > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> [email protected] > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > > > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
