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 --------------------------------------------------------------------
