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

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/