--- 1/draft-ietf-6man-flow-update-06.txt 2011-07-05 16:16:17.000000000 +0200 +++ 2/draft-ietf-6man-flow-update-07.txt 2011-07-05 16:16:17.000000000 +0200 @@ -1,21 +1,21 @@ 6MAN S. Amante Internet-Draft Level 3 Intended status: Informational B. Carpenter -Expires: November 12, 2011 Univ. of Auckland +Expires: January 6, 2012 Univ. of Auckland S. Jiang Huawei Technologies Co., Ltd - May 11, 2011 + July 5, 2011 Rationale for update to the IPv6 flow label specification - draft-ietf-6man-flow-update-06 + draft-ietf-6man-flow-update-07 Abstract Various published proposals for use of the IPv6 flow label are incompatible with its original specification in RFC 3697. Furthermore, very little practical use is made of the flow label, partly due to some uncertainties about the correct interpretation of the specification. This document discusses and motivates changes to the specification in order to clarify it, and to introduce some additional flexibility. @@ -28,21 +28,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on November 12, 2011. + This Internet-Draft will expire on January 6, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -55,21 +55,21 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Impact of current specification . . . . . . . . . . . . . . . 3 3. Changes to specification . . . . . . . . . . . . . . . . . . . 6 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. Change log [RFC Editor: please remove] . . . . . . . . . . . . 10 - 9. Informative References . . . . . . . . . . . . . . . . . . . . 10 + 9. Informative References . . . . . . . . . . . . . . . . . . . . 11 Appendix A. Alternative Approaches . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction The flow label field in the IPv6 header was reserved but left experimental by [RFC2460], which mandates only that "Hosts or routers that do not support the functions of the Flow Label field are required to set the field to zero when originating a packet, pass the field on unchanged when forwarding a packet, and ignore the field @@ -121,46 +121,46 @@ make any use at all of the flow label unless hosts choose to set it. It also forbids clearing the flow label for security reasons. This last point highlights the security properties, or rather the lack of them, of the flow label. The flow label field is always unprotected as it travels through the network, because there is no IPv6 header checksum, and the flow label is not included in transport pseudo-header checksums, nor in IPsec checksums. As a result, intentional and malicious changes to its value cannot be detected. Also, it could be used as a covert data channel, since apparently - pseudo-random flow label values could in fact consist of covert data. - If the flow label were to carry quality of service semantics, then - like the diffserv code point [RFC2474], it would not be intrinsically - trustworthy across domain boundaries. As a result, some security - specialists believe that flow labels should be cleared for safety - [I-D.gont-6man-flowlabel-security], [NSA], [NIST]. These points must - be considered when discussing the immutability of the flow label + pseudo-random flow label values could in fact consist of covert data + [NIST]. If the flow label were to carry quality of service + semantics, then like the diffserv code point [RFC2474], it would not + be intrinsically trustworthy across domain boundaries. As a result, + some security specialists believe that flow labels should be cleared + for safety [I-D.gont-6man-flowlabel-security], [NSA]. These points + must be considered when discussing the immutability of the flow label across domain boundaries. In fact, the adjective "immutable" is confusing, since it implies a property that the flow label field does not actually possess. It has therefore been abandoned as a descriptive term in [I-D.ietf-6man-flow-3697bis]. It is only used in the present document to explain why it has been abandoned. Rule (b) appears to forbid any usage in which the bits of the flow label are encoded with a specific semantic meaning. However, the words "MUST NOT assume" are to be interpreted precisely - if a router knows by configuration or by signaling that the flow label has been assigned in a certain way, it can make use of that knowledge. It is not made clear by the rule that there is an implied distinction between stateless models (in which case no assumption may be made) and stateful models (in which the router has explicit knowledge). If the word "alone" is overlooked, rule (c) has sometimes been interpreted to forbid the use of the flow label as part of a hash used by load distribution mechanisms. In this case too, the word - "alone" is to be interpreted precisely - a router is allowed to + "alone" needs to be taken into account - a router is allowed to combine the flow label value with other data in order to produce a uniformly distributed hash. Both before and after these rules were laid down, a considerable number of proposals for use of the flow label were published that seem incompatible with them. Numerous examples and an analysis are presented in [I-D.hu-flow-label-cases]. Those examples propose use cases in which some or all of the following apply: o The flow label may be changed by intermediate systems. o It doesn't matter if the flow label is changed, because the @@ -287,30 +287,29 @@ random number generator. Either approach will produce values which will appear pseudo-random to an external observer. Section 3 of RFC 3697 allows nodes to participate in an unspecified stateful method of flow state establishment. The changes do not remove that option, but it is made clear that stateless models are also possible and are the recommended default. The specific text about requirements for stateful models has been reduced to a bare minimum requirement that they do not interfere with the stateless model. To enable stateless load distribution at any point in the - Internet, a network using a stateful model should never export - packets whose flow label values do not conform to a uniform - distribution. + Internet, a node using a stateful model should never send packets + whose flow label values do not conform to a uniform distribution. The main novelty is that a forwarding node (typically a first-hop or ingress router) may set the flow label value if the source has not done so, according to the same recommendations that apply to the source. This might place a considerable processing load on ingress - routers, even if they adopted a stateless method of flow - identification and label assignment. + routers that choose to do so, even if they adopted a stateless method + of flow identification and label assignment. The value of the flow label, once it has been set, must not be changed. However, some qualifications are placed on this rule, to allow for the fact that the flow label is an unprotected field and might be misused. No Internet-wide mechanism can depend mathematically on immutable flow labels. The new rules require that flow labels exported to the Internet should always be either zero or uniformly distributed, but even this cannot be relied on mathematically. Use cases need to be robust against non-conforming flow label values. This will also enhance compatibility with any @@ -386,30 +385,33 @@ remarks are in [Partridge]. 6. IANA Considerations This document requests no action by IANA. 7. Acknowledgements The authors are grateful to Qinwen Hu for general discussion about the flow label and for his work in searching the literature. - Valuable comments and contributions were made by Fred Baker, Steve - Blake, Remi Despres, Alan Ford, Fernando Gont, Brian Haberman, Tony - Hain, Joel Halpern, Chris Morrow, Thomas Narten, Pekka Savola, Mark - Smith, Pascal Thubert, Iljitsch van Beijnum, and other participants - in the 6man working group. + Valuable comments and contributions were made by Ran Atkinson, Fred + Baker, Steve Blake, Remi Despres, Alan Ford, Fernando Gont, Brian + Haberman, Tony Hain, Joel Halpern, Chris Morrow, Thomas Narten, Pekka + Savola, Mark Smith, Pascal Thubert, Iljitsch van Beijnum, and other + participants in the 6man working group. This document was produced using the xml2rfc tool [RFC2629]. 8. Change log [RFC Editor: please remove] + draft-ietf-6man-flow-update-07: minor editorial fix, AD comments, + 2011-07-05 + draft-ietf-6man-flow-update-06: updated again to be in step with RFC 3697bis, 2011-05-11 draft-ietf-6man-flow-update-05: updated again to be in step with RFC 3697bis, 2011-05-02 draft-ietf-6man-flow-update-04: updated again to be in step with RFC 3697bis, 2011-03-13 draft-ietf-6man-flow-update-03: updated to be in step with RFC @@ -453,22 +455,22 @@ November 2010. [I-D.hu-flow-label-cases] Hu, Q. and B. Carpenter, "Survey of proposed use cases for the IPv6 flow label", draft-hu-flow-label-cases-03 (work in progress), February 2011. [I-D.ietf-6man-flow-3697bis] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", - draft-ietf-6man-flow-3697bis-03 (work in progress), - May 2011. + draft-ietf-6man-flow-3697bis-05 (work in progress), + June 2011. [I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching] Beckman, M., "IPv6 Dynamic Flow Label Switching (FLS)", draft-martinbeckman-ietf-ipv6-fls-ipv6flowswitching-03 (work in progress), March 2007. [McGann05] McGann, O. and D. Malone, "Flow Label Filtering Feasibility", European Conference on Computer Network Defence , 2005.