the correct source address.  The ability to spoof a Flow Label   typically implies being in a position to also forge an address, but   in many cases, spoofing an address may not be interesting to the   spoofer, especially if the spoofer's goal is theft of service, rather   than denial of service.   The latter can be done by a host which is not subject to ingress   filtering [INGR] or by an intermediate router.  Due to its   properties, such is typically useful only for denial of service.  In   the absence of ingress filtering, almost any third party could   instigate such an attack.   In the presence of ingress filtering, forging a non-zero Flow Label   on packets that originated with a zero label, or modifying or   clearing a label, could only occur if an intermediate system such as   a router was compromised, or through some other form of man-in-the-   middle attack.  However, the risk is limited to traffic receiving   better or worse quality of service than intended.  For example, if   Flow Labels are altered or cleared at random, flow classification   will no longer happen as intended, and the altered packets will   receive default treatment.  If a complete 3-tuple is forged, the   altered packets will be classified into the forged flow and will   receive the corresponding quality of service; this will create a   denial of service attack subtly different from one where only theRajahalme, et al.           Standards Track                     [Page 5]RFC 3697             IPv6 Flow Label Specification            March 2004   addresses are forged.  Because it is limited to a single flow   definition, e.g., to a limited amount of bandwidth, such an attack   will be more specific and at a finer granularity than a normal   address-spoofing attack.   Since flows are identified by the complete 3-tuple, ingress filtering   [INGR] will, as noted above, mitigate part of the risk.  If the   source address of a packet is validated by ingress filtering, there   can be a degree of trust that the packet has not transited a   compromised router, to the extent that ISP infrastructure may be   trusted.  However, this gives no assurance that another form of man-   in-the-middle attack has not occurred.   Only applications with an appropriate privilege in a sending host   will be entitled to set a non-zero Flow Label.  Mechanisms for this   are operating system dependent.  Related policy and authorization   mechanisms may also be required; for example, in a multi-user host,   only some users may be entitled to set the Flow Label.  Such   authorization issues are outside the scope of this specification.5.2.  IPsec and Tunneling Interactions   The IPsec protocol, as defined in [IPSec, AH, ESP], does not include   the IPv6 header's Flow Label in any of its cryptographic calculations   (in the case of tunnel mode, it is the outer IPv6 header's Flow Label   that is not included).  Hence modification of the Flow Label by a   network node has no effect on IPsec end-to-end security, because it   cannot cause any IPsec integrity check to fail.  As a consequence,   IPsec does not provide any defense against an adversary's   modification of the Flow Label (i.e., a man-in-the-middle attack).   IPsec tunnel mode provides security for the encapsulated IP header's   Flow Label.  A tunnel mode IPsec packet contains two IP headers: an   outer header supplied by the tunnel ingress node and an encapsulated   inner header supplied by the original source of the packet.  When an   IPsec tunnel is passing through nodes performing flow classification,   the intermediate network nodes operate on the Flow Label in the outer   header.  At the tunnel egress node, IPsec processing includes   removing the outer header and forwarding the packet (if required)   using the inner header.  The IPsec protocol requires that the inner   header's Flow Label not be changed by this decapsulation processing   to ensure that modifications to label cannot be used to launch theft-   or denial-of-service attacks across an IPsec tunnel endpoint.  This   document makes no change to that requirement; indeed it forbids   changes to the Flow Label.Rajahalme, et al.           Standards Track                     [Page 6]RFC 3697             IPv6 Flow Label Specification            March 2004   When IPsec tunnel egress decapsulation processing includes a   sufficiently strong cryptographic integrity check of the encapsulated   packet (where sufficiency is determined by local security policy),   the tunnel egress node can safely assume that the Flow Label in the   inner header has the same value as it had at the tunnel ingress node.   This analysis and its implications apply to any tunneling protocol   that performs integrity checks.  Of course, any Flow Label set in an   encapsulating IPv6 header is subject to the risks described in the   previous section.5.3.  Security Filtering Interactions   The Flow Label does nothing to eliminate the need for packet   filtering based on headers past the IP header, if such filtering is   deemed necessary for security reasons on nodes such as firewalls or   filtering routers.6.  Acknowledgements   The discussion on the topic in the IPv6 WG mailing list has been   instrumental for the definition of this specification.  The authors   want to thank 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   for their contributions.7.  References7.1.  Normative References   [IPv6]      Deering, S. and R. Hinden, "Internet Protocol Version 6               Specification", RFC 2460, December 1998.   [KEYWORDS]  Bradner, S., "Key words for use in RFCs to indicate               requirement levels", BCP 14, RFC 2119, March 1997.   [RND]       Eastlake, D., Crocker, S. and J. Schiller, "Randomness               Recommendations for Security", RFC 1750, December 1994.7.2.  Informative References   [AH]        Kent, S. and R. Atkinson, "IP Authentication Header", RFC               2402, November 1998.   [ESP]       Kent, S. and R. Atkinson, "IP Encapsulating Security               Payload (ESP)", RFC 2406, November 1998.Rajahalme, et al.           Standards Track                     [Page 7]RFC 3697             IPv6 Flow Label Specification            March 2004   [INGR]      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.   [IPSec]     Kent, S. and R. Atkinson, "Security Architecture for the               Internet Protocol", RFC 2401, November 1998.Authors' Addresses   Jarno Rajahalme   Nokia Research Center   P.O. Box 407   FIN-00045 NOKIA GROUP,   Finland   EMail: jarno.rajahalme@nokia.com   Alex Conta   Transwitch Corporation   3 Enterprise Drive   Shelton, CT 06484   USA   EMail: aconta@txc.com   Brian E. Carpenter   IBM Zurich Research Laboratory   Saeumerstrasse 4 / Postfach   8803 Rueschlikon   Switzerland   EMail: brc@zurich.ibm.com   Steve Deering   Cisco Systems, Inc.   170 West Tasman Drive   San Jose, CA 95134-1706   USARajahalme, et al.           Standards Track                     [Page 8]RFC 3697             IPv6 Flow Label Specification            March 2004Full Copyright Statement   Copyright (C) The Internet Society (2004).  This document is subject   to the rights, licenses and restrictions contained in BCP 78 and   except as set forth therein, the authors retain all their rights.   This document and the information contained herein are provided on an   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Intellectual Property   The IETF takes no position regarding the validity or scope of any   Intellectual Property Rights or other rights that might be claimed   to pertain to the implementation or use of the technology   described in this document or the extent to which any license   under such rights might or might not be available; nor does it   represent that it has made any independent effort to identify any   such rights.  Information on the procedures with respect to   rights in RFC documents can be found in BCP 78 and BCP 79.   Copies of IPR disclosures made to the IETF Secretariat and any   assurances of licenses to be made available, or the result of an   attempt made to obtain a general license or permission for the use   of such proprietary rights by implementers or users of this   specification can be obtained from the IETF on-line IPR repository   at http://www.ietf.org/ipr.   The IETF invites any interested party to bring to its attention   any copyrights, patents or patent applications, or other   proprietary rights that may cover technology that may be required   to implement this standard.  Please address the information to the   IETF at ietf-ipr@ietf.org.Acknowledgement   Funding for the RFC Editor function is currently provided by the   Internet Society.Rajahalme, et al.           Standards Track                     [Page 9]