rfc3697.txt

IPv6协议中flow_label的相关RFC

   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 the



Rajahalme, 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.  References

7.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: [e-mail]


   Alex Conta
   Transwitch Corporation
   3 Enterprise Drive
   Shelton, CT 06484
   USA

   EMail: [e-mail]


   Brian E. Carpenter
   IBM Zurich Research Laboratory
   Saeumerstrasse 4 / Postfach
   8803 Rueschlikon
   Switzerland

   EMail: [e-mail]


   Steve Deering
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134-1706
   USA










Rajahalme, et al.           Standards Track                     [Page 8]

RFC 3697             IPv6 Flow Label Specification            March 2004


Full 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 [e-mail].

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.









Rajahalme, et al.           Standards Track                     [Page 9]