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