--- 1/draft-ietf-6man-flow-3697bis-05.txt 2011-07-11 23:16:11.000000000 +0200 +++ 2/draft-ietf-6man-flow-3697bis-06.txt 2011-07-11 23:16:11.000000000 +0200 @@ -1,23 +1,23 @@ 6MAN S. Amante Internet-Draft Level 3 Obsoletes: 3697 (if approved) B. Carpenter Updates: 2205, 2460 (if approved) Univ. of Auckland Intended status: Standards Track S. Jiang -Expires: December 31, 2011 Huawei Technologies Co., Ltd +Expires: January 12, 2012 Huawei Technologies Co., Ltd J. Rajahalme Nokia Siemens Networks - June 29, 2011 + July 11, 2011 IPv6 Flow Label Specification - draft-ietf-6man-flow-3697bis-05 + draft-ietf-6man-flow-3697bis-06 Abstract This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of scope for this document. @@ -33,21 +33,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 December 31, 2011. + This Internet-Draft will expire on January 12, 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 @@ -73,39 +73,39 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. IPv6 Flow Label Specification . . . . . . . . . . . . . . . . 5 3. Flow Labeling Requirements in the Stateless Scenario . . . . . 6 4. Flow State Establishment Requirements . . . . . . . . . . . . 8 5. Essential correction to RFC 2205 . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6.1. Covert Channel Risk . . . . . . . . . . . . . . . . . . . 9 6.2. Theft and Denial of Service . . . . . . . . . . . . . . . 9 6.3. IPsec and Tunneling Interactions . . . . . . . . . . . . . 11 - 6.4. Security Filtering Interactions . . . . . . . . . . . . . 11 + 6.4. Security Filtering Interactions . . . . . . . . . . . . . 12 7. Differences from RFC 3697 . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 10. Change log [RFC Editor: Please remove] . . . . . . . . . . . . 13 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 Appendix A. Example 20-bit Hash Function . . . . . . . . . . . . 15 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction From the viewpoint of the network layer, a flow is a sequence of packets sent from a particular source to a particular unicast, anycast, or multicast destination that a node desires to label as a flow. From an upper layer viewpoint, a flow could consist of all - packets in a specific transport connection or a media stream. - However, a flow is not necessarily 1:1 mapped to a transport + packets in one direction of a specific transport connection or media + stream. However, a flow is not necessarily 1:1 mapped to a transport connection. Traditionally, flow classifiers have been based on the 5-tuple of the source and destination addresses, ports, and the transport protocol type. However, some of these fields may be unavailable due to either fragmentation or encryption, or locating them past a chain of IPv6 extension headers may be inefficient. Additionally, if classifiers depend only on IP layer headers, later introduction of alternative transport layer protocols will be easier. @@ -244,22 +244,22 @@ by chance assigned the same flow label value, and have the same source and destination addresses, it simply means that they will receive the same treatment throughout the network. As long as this is a low probability event, it will not significantly affect load distribution. A possible stateless algorithm is to use a suitable 20 bit hash of values from the IP packet's 5-tuple. A simple example hash function is described in Appendix A. - An alternative approach is to to use a pseudo-random number generator - to assign a flow label value for a given transport session; such a + An alternative approach is to use a pseudo-random number generator to + assign a flow label value for a given transport session; such a method will require minimal local state to be kept at the source node, by recording the flow label associated with each transport socket. Viewed externally, either of these approaches will produce values that appear to be uniformly distributed and pseudo-random. An implementation in which flow labels are assigned sequentially is NOT RECOMMENDED, as it would then be simple for on-path observers to guess the next value. @@ -284,29 +284,29 @@ * A forwarding node might use the 5-tuple to define a flow whenever possible, but use the 2-tuple when the complete 5-tuple is not available. In this case, unfragmented and fragmented packets belonging to the same transport session would receive different flow label values, altering the effect of subsequent load distribution based on the flow label. * A forwarding node might use the 2-tuple to define a flow in all cases. In this case, subsequent load distribution would be based only on IP addresses. - o This option, if implemented, would presumably be of value in - first-hop or ingress routers. It might place a considerable per- - packet processing load on them, even if they adopted a stateless - method of flow identification and label assignment. However, it - will not interfere with host-to-router load sharing [RFC4311]. - Therefore, it needs to be under the control of network managers, - to avoid unwanted processing load and any other undesirable - effects. For this reason it MUST be a configurable option, - disabled by default. + o The option to set the flow label in a forwarding node, if + implemented, would presumably be of value in first-hop or ingress + routers. It might place a considerable per-packet processing load + on them, even if they adopted a stateless method of flow + identification and label assignment. However, it will not + interfere with host-to-router load sharing [RFC4311]. It needs to + be under the control of network managers, to avoid unwanted + processing load and any other undesirable effects. For this + reason it MUST be a configurable option, disabled by default. The preceding rules taken together allow a given network to include routers that set flow labels on behalf of hosts that do not do so. The complications described explain why the principal recommendation is that the source hosts should set the label. 4. Flow State Establishment Requirements A node that sets the flow label MAY also take part in a flow state establishment method that results in assigning specific treatments to @@ -335,43 +335,47 @@ revealing some structure of the underlying communications. Even if the flow label were encrypted, its presence as a constant value in a fixed position might assist traffic analysis and cryptoanalysis. The flow label is not protected in any way, even if IPsec authentication [RFC4302] is in use, so it can be forged by an on-path attacker. Implementers are advised that any en-route change to the flow label value is undetectable. On the other hand, a uniformly distributed pseudo-random flow label cannot be readily guessed by an attacker; see [I-D.gont-6man-flowlabel-security] for further - discussion. + discussion. If a hash algorithm is used, as suggested in Section 3, + it SHOULD include a step that makes the flow-label value + significantly difficult to predict, even with knowledge of the + algorithm being used. 6.1. Covert Channel Risk The flow label could be used as a covert data channel, since apparently pseudo-random flow label values could in fact consist of - covert data. This could for example be achieved using a series of - otherwise innocuous UDP packets whose flow label values constitute a - covert message, or by co-opting a TCP session to carry a covert + covert data [NSA]. This could for example be achieved using a series + of otherwise innocuous UDP packets whose flow label values constitute + a covert message, or by co-opting a TCP session to carry a covert message in the flow labels of successive packets. Both of these could be recognised as suspicious - the first because isolated UDP packets would not normally be expected to have non-zero flow labels, and the second because the flow label values in a given TCP session should all be equal. However, other methods, such as co-opting the flow labels of occasional packets, might be rather hard to detect. In situations where the covert channel risk is considered significant, the only certain defense is for a firewall to rewrite - non-zero flow labels in a stateless manner, like a first-hop router - (see Section 3). This would be an exceptional violation of the rule - that the flow label, once set to a non-zero value, must not be + non-zero flow labels. This would be an exceptional violation of the + rule that the flow label, once set to a non-zero value, must not be changed. To preserve load distribution capability, such a firewall - MUST NOT set non-zero flow labels to zero. + SHOULD rewrite labels by following the method described for a + forwarding node (see Section 3) and MUST NOT set non-zero flow labels + to zero. 6.2. Theft and Denial of Service Since the mapping of network traffic to flow-specific treatment is triggered by the IP addresses and Flow Label value of the IPv6 header, an adversary may be able to obtain unintended service by modifying the IPv6 header or by injecting packets with false addresses and/or labels. Theft of service is not further discussed in this document, since it can only be analysed for specific stateful methods of using the flow label. However, a denial of service attack @@ -511,20 +515,23 @@ Contributors to the original development of RFC 3697 included Ran Atkinson, Steve Blake, Jim Bound, Francis Dupont, Robert Elz, Tony Hain, Robert Hancock, Bob Hinden, Christian Huitema, Frank Kastenholz, Thomas Narten, Charles Perkins, Pekka Savola, Hesham Soliman, Michael Thomas, Margaret Wasserman, and Alex Zinin. This document was produced using the xml2rfc tool [RFC2629]. 10. Change log [RFC Editor: Please remove] + draft-ietf-6man-flow-3697bis-06: resolved IETF Last Call comments, + 2011-07-11. + draft-ietf-6man-flow-3697bis-05: resolved AD comments, improved hash algorithm, 2011-06-29. draft-ietf-6man-flow-3697bis-04: update to resolve further WG comments, 2011-05-11: o Suggested a specific hash algorithm to generate a flow label. o Removed reference to stateful domain. o Added text about covert channel and tuned text about firewall behavior; removed the confusing word "immutable". o Added that Section 6 of RFC 2460 is replaced. @@ -573,22 +580,26 @@ 11.2. Informative References [I-D.gont-6man-flowlabel-security] Gont, F., "Security Assessment of the IPv6 Flow Label", draft-gont-6man-flowlabel-security-01 (work in progress), November 2010. [I-D.ietf-6man-flow-update] Amante, S., Carpenter, B., and S. Jiang, "Rationale for update to the IPv6 flow label specification", - draft-ietf-6man-flow-update-06 (work in progress), - May 2011. + draft-ietf-6man-flow-update-07 (work in progress), + July 2011. + + [NSA] Potyraj, C., "Firewall Design Considerations for IPv6", + National Security Agency I733-041R-2007, 2007, + . [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004. @@ -634,22 +645,22 @@ 3. If the two bits are 01, output a 0 bit. 4. If the two bits are 10, output a 1 bit. 5. Repeat with the next two bits in the input 64 bit string. 6. Stop when 16 bits have been output (or when the 64 bit string is exhausted). 4. Add the two port numbers to the resulting 16 bit number. 5. Shift the resulting value 4 bits left and mask with 0xfffff. 6. In the highly unlikely event that the result is exactly zero, set the flow label arbitrarily to the value 1. - Note that this simple example does not include any form of - obfuscation. + Note that this simple example does not include a step to prevent + predictability, as recommended in Section 6. Authors' Addresses Shane Amante Level 3 Communications, LLC 1025 Eldorado Blvd Broomfield, CO 80021 USA Email: shane@level3.net