Le 10 sept. 2010 à 15:18, Pascal Thubert (pthubert) a écrit : > 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. That's where there is a problem. If an intermediate network modifies the FL for a different purpose, and doesn't restore it at its exit, then downstream networks can no longer use FLs for load balancing as currently specified. The whole purpose of RFC3697 is then defeated. Note that intermediate networks have always been free to use FLs for their own usage PROVIDED they restore received values at exit. This is an internal matter. The unavoidable choice seems to be between: a) keep the currently defined purpose (load balancing), improve the specification (e.g., in substance, with something like the proposed 7 rules), and thus preserve *backward compatibility*. b) now permit all traversed networks to freely modify FLs for their own purposes, and to leave arbitrary FL values at exit, thus *deprecating the current purpose* and losing backward compatibility. c) officially deprecate the current purpose, and *reserve FLs for some future use TBD* The worse would be not to choose, defeating in practice all purposes. Discussing the same points over and over again is just a waste of energy. > 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. If the choice is to preserve backward compatibility (BTW the choice for which I vote), I am confident that a consensus can be identified and documented. The short 7 rules I listed are a tentative to capture what the current best consensus seems to be (I may be wrong, but it's worth trying). > 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. Sure, but provided standards are still complied after their networks have been traversed. > What do you think? Expressed above. Regards, RD > > Pascal > >> -----Original Message----- >> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] 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 <idsubmiss...@ietf.org> >>>> To: ferna...@gont.com.ar >>>> >>>> >>>> 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: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 >>>> 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >>>> >>>> >>>> >>>> >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>> >>> >>> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
