--- 1/draft-ietf-6man-flow-update-05.txt 2011-05-13 03:15:59.000000000 +0200 +++ 2/draft-ietf-6man-flow-update-06.txt 2011-05-13 03:15:59.000000000 +0200 @@ -1,21 +1,21 @@ 6MAN S. Amante Internet-Draft Level 3 Intended status: Informational B. Carpenter -Expires: November 3, 2011 Univ. of Auckland +Expires: November 12, 2011 Univ. of Auckland S. Jiang Huawei Technologies Co., Ltd - May 2, 2011 + May 11, 2011 Rationale for update to the IPv6 flow label specification - draft-ietf-6man-flow-update-05 + draft-ietf-6man-flow-update-06 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 3, 2011. + This Internet-Draft will expire on November 12, 2011. 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 @@ -56,22 +56,22 @@ 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 - Appendix A. Alternative Approaches . . . . . . . . . . . . . . . 11 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 + 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 when receiving a packet." @@ -126,23 +126,27 @@ 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]. These points must be considered - when discussing the immutability of the flow label across domain - boundaries. + [I-D.gont-6man-flowlabel-security], [NSA], [NIST]. 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). @@ -228,114 +231,116 @@ as noted above, it is not included in any transport layer pseudo- header checksums nor in IPsec authentication [RFC4302]. Both RFC 2460 and RFC 3697 define the default flow label to be zero. At the time of writing, this is the observed value in an overwhelming proportion of IPv6 packets; the most widespread operating systems and applications do not set it, and routers do not rely on it. Thus there is no reason to expect operational difficulties if a careful change is made to the rules of RFC 3697. In particular, the facts that the label is not checksummed and rarely - used mean that the current strict immutability of the label can be - moderated without serious operational consequences. + used mean that the "immutability" of the label can be moderated + without serious operational consequences. The purposes of the proposed changes are to remove the uncertainties left by RFC 3697, in order to encourage setting of the flow label by default, and to enable its generic use. The proposed generic use is to encourage uniformly distributed flow labels that can be used to - assist load distribution balancing. There should be no impact on + assist load distribution or balancing. There should be no impact on existing IETF specifications other than RFC 3697 and no impact on currently operational software and hardware. - A secondary purpose is to modify the immutability of the flow label - in a limited way, to allow hosts that do not set the flow label to - benefit from it nevertheless. The fact that the flow label may in - practice be changed en route is also reflected in the reformulation - of the rules. + A secondary purpose is to allow changes to the flow label in a + limited way, to allow hosts that do not set the flow label to benefit + from it nevertheless. The fact that the flow label may in practice + be changed en route is also reflected in the reformulation of the + rules. A general description of the changes follows. The normative text is to be found in [I-D.ietf-6man-flow-3697bis]. The definition of a flow is subtly changed from RFC 3697 to allow any node, not just the source node, to set the flow label value. However, it is recommended that sources should set a uniformly distributed flow label value in all flows, replacing the less precise recommendation made in Section 3 of RFC 3697. Both stateful and stateless methods of assigning a uniformly distributed value could be used. Flow label values should be chosen such that their bits exhibit a - high degree of variability, making them suitable for use as part of - the input to a hash function used in a load distribution scheme. At - the same time, third parties should be unlikely to be able to guess - the next value that a source of flow labels will choose. + high degree of variability, thus making them suitable for use as part + of the input to a hash function used in a load distribution scheme. + At the same time, third parties should be unlikely to be able to + guess the next value that a source of flow labels will choose. In statistics, a discrete uniform distribution is defined as a probability distribution in which each value in a given range of equally spaced values (such as a sequence of integers) is equally likely to be chosen as the next value. The values in such a distribution exhibit both variability and unguessability. Thus, an approximation to a discrete uniform distribution is preferable as the source of flow label values. In contrast, an implementation in which - flow labels are assigned sequentially is definitely not recommended. + flow labels are assigned sequentially is definitely not recommended, + to avoid guessability. In practice it is expected that a uniform distribution of flow label values will be approximated by use of a hash function or a pseudo- random number generator. Either approach will produce values which will appear pseudo-random to an external observer. - Section 3 of RFC 3697 also 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 + 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 domain using a stateful model should never export - packets originating within the domain whose flow label values do not - conform to a uniform distribution. + Internet, a network using a stateful model should never export + 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. - The immutability of the flow label, once it has been set, is not - changed. However, some qualifications are placed on this property, - to allow for the fact that the flow label is an unprotected field and - might be changed undetectably. No Internet-wide mechanism can depend + 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 legacy hosts that set the flow label according to RFC 2460 or RFC 3697. A complication that led to much discussion is the possibility that - hosts inside a particular domain might use a stateful method of - setting the flow label, and that packets bearing stateful labels + hosts inside a particular network domain might use a stateful method + of setting the flow label, and that packets bearing stateful labels might then erroneously escape the domain and be received by nodes performing stateless processing such as load balancing. This might result in undesirable operational implications (e.g., congestion, reordering) for not only the inappropriately flow-labelled packets, but also well-behaved flow-labelled packets, during forwarding at various intermediate devices. It was proposed to suggest that border routers might "correct" this problem by overwriting such labels in packets leaving the domain. However, neither domain border egress routers nor intermediate routers/devices (using a flow label, for example, as a part of an input key for a load-distribution hash) can determine by inspection that a value is not part of a uniform - distribution. Therefore, there is no way that such values can be - detected and "corrected". + distribution. Thus there is no way that such values can be detected + and "corrected". Therefore, the recommendation to choose flow labels + from a uniform distribution also applies to stateful schemes. 4. Discussion The following are some practical consequences of the above changes: o Sending hosts that are not updated will in practice continue to send all-zero labels. If there is no label-setting router along the path taken by a packet, the label will be delivered as zero. o Sending hosts conforming to the new specification will by default choose uniformly distributed labels between 1 and 0xFFFFF. o Sending hosts may continue to send all-zero labels, in which case @@ -370,40 +375,44 @@ whatever flow label handling is used on the path. Hosts and routers that adopt the recommended mechanism will enhance the performance of any load balancing devices that include the flow label in the hash used to select a particular path or server, even when packets leave the local domain. 5. Security Considerations See [I-D.ietf-6man-flow-3697bis] and - [I-D.gont-6man-flowlabel-security] for full discussion. + [I-D.gont-6man-flowlabel-security] for full discussion. Some useful + 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. This document was produced using the xml2rfc tool [RFC2629]. 8. Change log [RFC Editor: please remove] + 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 3697bis, 2011-02-26 draft-ietf-6man-flow-update-02: repurposed as rationale for update of @@ -444,34 +453,52 @@ 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-02 (work in progress), - March 2011. + draft-ietf-6man-flow-3697bis-03 (work in progress), + May 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. + [NIST] Frankel, S., Graveman, R., Pearce, J., and M. Rooks, + "Guidelines for the Secure Deployment of IPv6", National + Institute of Standards and Technology Special Publication + 800-119, 2010, . + + [NSA] Potyraj, C., "Firewall Design Considerations for IPv6", + National Security Agency I733-041R-2007, 2007, + . + + [Partridge] + Partridge, C., Arsenault, A., and S. Kent, "Information + Assurance and the Transition to IP Version 6 (IPv6)", + Military Communications Conference (MILCOM 2007) , 2007, + . + [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. + Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.