rfc2474.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,124 行 · 第 1/4 页

RFC 2474             Differentiated Services Field         December 1998


   The defense against this class of theft- and denial-of-service
   attacks consists of the combination of traffic conditioning at DS
   domain boundaries with security and integrity of the network
   infrastructure within a DS domain.  DS domain boundary nodes MUST
   ensure that all traffic entering the domain is marked with codepoint
   values appropriate to the traffic and the domain, remarking the
   traffic with new codepoint values if necessary.  These DS boundary
   nodes are the primary line of defense against theft- and denial-of-
   service attacks based on modified codepoints, as success of any such
   attack indicates that the codepoints used by the attacking traffic
   were inappropriate.  An important instance of a boundary node is that
   any traffic-originating node within a DS domain is the initial
   boundary node for that traffic.  Interior nodes in a DS domain rely
   on DS codepoints to associate traffic with the forwarding PHBs, and
   are NOT REQUIRED to check codepoint values before using them.  As a
   result, the interior nodes depend on the correct operation of the DS
   domain boundary nodes to prevent the arrival of traffic with
   inappropriate codepoints or in excess of provisioned levels that
   would disrupt operation of the domain.

7.2  IPsec and Tunnelling Interactions

   The IPsec protocol, as defined in [ESP, AH], does not include the IP
   header's DS field in any of its cryptographic calculations (in the
   case of tunnel mode, it is the outer IP header's DS field that is not
   included).  Hence modification of the DS field by a network node has
   no effect on IPsec's 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 DS
   field (i.e., a man-in-the-middle attack), as the adversary's
   modification will also have no effect on IPsec's end-to-end security.

   IPsec's tunnel mode provides security for the encapsulated IP
   header's DS field.  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 hosted (in whole or in part) on a
   differentiated services network, the intermediate network nodes
   operate on the DS field 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 DS field not be
   changed by this decapsulation processing to ensure that modifications
   to the DS field cannot be used to launch theft- or denial-of-service
   attacks across an IPsec tunnel endpoint.  This document makes no
   change to that requirement.  If the inner IP header has not been
   processed by a DS boundary node for the tunnel egress node's DS




Nichols, et. al.            Standards Track                    [Page 16]

RFC 2474             Differentiated Services Field         December 1998


   domain, the tunnel egress node is the boundary node for traffic
   exiting the tunnel, and hence MUST ensure that the resulting traffic
   has appropriate DS codepoints.

   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 DS field in the
   inner header has the same value as it had at the tunnel ingress node.
   An important consequence is that otherwise insecure links within a DS
   domain can be secured by a sufficiently strong IPsec tunnel.  This
   analysis and its implications apply to any tunnelling protocol that
   performs integrity checks, but the level of assurance of the inner
   header's DS field depends on the strength of the integrity check
   performed by the tunnelling protocol.  In the absence of sufficient
   assurance for a tunnel that may transit nodes outside the current DS
   domain (or is otherwise vulnerable), the encapsulated packet MUST be
   treated as if it had arrived at a boundary from outside the DS
   domain.

8.  Acknowledgements

   The authors would like to acknowledge the Differentiated Services
   Working Group for discussions which helped shape this document.

9.  References

   [AH]        Kent, S. and R. Atkinson, "IP Authentication Header",
               RFC 2402, November 1998.

   [ARCH]      Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
               and W. Weiss, "An Architecture for Differentiated
               Services", RFC 2475, December 1998.

   [CBQ]       S. Floyd and V. Jacobson, "Link-sharing and Resource
               Management Models for Packet Networks", IEEE/ACM
               Transactions on Networking, Vol. 3 no. 4, pp. 365-386,
               August 1995.

   [CONS]      Narten, T. and H. Alvestrand, "Guidelines for Writing an
               IANA Considerations Section in RFCs", RFC 2434, October
               1998.

   [DRR]       M. Shreedhar and G. Varghese, Efficient Fair Queueing
               using Deficit Round Robin", Proc. ACM SIGCOMM 95, 1995.






Nichols, et. al.            Standards Track                    [Page 17]

RFC 2474             Differentiated Services Field         December 1998


   [ESP]       Kent, S. and R. Atkinson, "IP Encapsulating Security
               Payload (ESP)", RFC 2406, November 1998.

   [HPFQA]     J. Bennett and Hui Zhang, "Hierarchical Packet Fair
               Queueing Algorithms", Proc. ACM SIGCOMM 96, August 1996.

   [IPv6]      Deering, S. and R. Hinden, "Internet Protocol, Version 6
               (IPv6) Specification", RFC 2460, December 1998.

   [RFC791]    Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,
               September 1981.

   [RFC1122]   Braden, R., "Requirements for Internet hosts -
               communication layers", STD 3, RFC 1122, October 1989.

   [RFC1812]   Baker, F., Editor, "Requirements for IP Version 4
               Routers", RFC 1812, June 1995.

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RPS]       D. Stiliadis and A. Varma, "Rate-Proportional Servers:  A
               Design Methodology for Fair Queueing Algorithms", IEEE/
               ACM Trans. on Networking, April 1998.



























Nichols, et. al.            Standards Track                    [Page 18]

RFC 2474             Differentiated Services Field         December 1998


Authors' Addresses

   Kathleen Nichols
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA  95134-1706

   Phone:  [phone]
   EMail: [e-mail]


   Steven Blake
   Torrent Networking Technologies
   3000 Aerial Center, Suite 140
   Morrisville, NC  27560

   Phone:  [phone] x232
   EMail: [e-mail]


   Fred Baker
   Cisco Systems
   519 Lado Drive
   Santa Barbara, CA  93111

   Phone:  [phone]
   EMail: [e-mail]


   David L. Black
   EMC Corporation
   35 Parkwood Drive
   Hopkinton, MA  01748

   Phone:  [phone] x76140
   EMail: [e-mail]















Nichols, et. al.            Standards Track                    [Page 19]

RFC 2474             Differentiated Services Field         December 1998


Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.
























Nichols, et. al.            Standards Track                    [Page 20]