rfc2402.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,236 行 · 第 1/4 页

Kent & Atkinson             Standards Track                    [Page 17]

RFC 2402                IP Authentication Header           November 1998


Appendix A -- Mutability of IP Options/Extension Headers

A1.  IPv4 Options

   This table shows how the IPv4 options are classified with regard to
   "mutability".  Where two references are provided, the second one
   supercedes the first.  This table is based in part on information
   provided in RFC1700, "ASSIGNED NUMBERS", (October 1994).

           Opt.
Copy Class  #   Name                      Reference
---- ----- ---  ------------------------  ---------
IMMUTABLE -- included in ICV calculation
  0   0     0   End of Options List       [RFC791]
  0   0     1   No Operation              [RFC791]
  1   0     2   Security                  [RFC1108(historic but in use)]
  1   0     5   Extended Security         [RFC1108(historic but in use)]
  1   0     6   Commercial Security       [expired I-D, now US MIL STD]
  1   0    20   Router Alert              [RFC2113]
  1   0    21   Sender Directed Multi-    [RFC1770]
                Destination Delivery
MUTABLE -- zeroed
  1   0      3  Loose Source Route        [RFC791]
  0   2      4  Time Stamp                [RFC791]
  0   0      7  Record Route              [RFC791]
  1   0      9  Strict Source Route       [RFC791]
  0   2     18  Traceroute                [RFC1393]

EXPERIMENTAL, SUPERCEDED -- zeroed
  1   0      8  Stream ID                 [RFC791, RFC1122 (Host Req)]
  0   0     11  MTU Probe                 [RFC1063, RFC1191 (PMTU)]
  0   0     12  MTU Reply                 [RFC1063, RFC1191 (PMTU)]
  1   0     17  Extended Internet Proto   [RFC1385, RFC1883 (IPv6)]
  0   0     10  Experimental Measurement  [ZSu]
  1   2     13  Experimental Flow Control [Finn]
  1   0     14  Experimental Access Ctl   [Estrin]
  0   0     15  ???                       [VerSteeg]
  1   0     16  IMI Traffic Descriptor    [Lee]
  1   0     19  Address Extension         [Ullmann IPv7]

   NOTE: Use of the Router Alert option is potentially incompatible with
   use of IPsec.  Although the option is immutable, its use implies that
   each router along a packet's path will "process" the packet and
   consequently might change the packet.  This would happen on a hop by
   hop basis as the packet goes from router to router.  Prior to being
   processed by the application to which the option contents are
   directed, e.g., RSVP/IGMP, the packet should encounter AH processing.




Kent & Atkinson             Standards Track                    [Page 18]

RFC 2402                IP Authentication Header           November 1998


   However, AH processing would require that each router along the path
   is a member of a multicast-SA defined by the SPI.  This might pose
   problems for packets that are not strictly source routed, and it
   requires multicast support techniques not currently available.

   NOTE: Addition or removal of any security labels (BSO, ESO, CIPSO) by
   systems along a packet's path conflicts with the classification of
   these IP Options as immutable and is incompatible with the use of
   IPsec.

   NOTE: End of Options List options SHOULD be repeated as necessary to
   ensure that the IP header ends on a 4 byte boundary in order to
   ensure that there are no unspecified bytes which could be used for a
   covert channel.

A2.  IPv6 Extension Headers

   This table shows how the IPv6 Extension Headers are classified with
   regard to "mutability".

Option/Extension Name                  Reference
-----------------------------------    ---------
MUTABLE BUT PREDICTABLE -- included in ICV calculation
  Routing (Type 0)                    [RFC1883]

BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING TRANSIT)
  Hop by Hop options                  [RFC1883]
  Destination options                 [RFC1883]

NOT APPLICABLE
  Fragmentation                       [RFC1883]

      Options -- IPv6 options in the Hop-by-Hop and Destination
             Extension Headers contain a bit that indicates whether the
             option might change (unpredictably) during transit.  For
             any option for which contents may change en-route, the
             entire "Option Data" field must be treated as zero-valued
             octets when computing or verifying the ICV.  The Option
             Type and Opt Data Len are included in the ICV calculation.
             All options for which the bit indicates immutability are
             included in the ICV calculation.  See the IPv6
             specification [DH95] for more information.

      Routing (Type 0) -- The IPv6 Routing Header "Type 0" will
             rearrange the address fields within the packet during
             transit from source to destination.  However, the contents
             of the packet as it will appear at the receiver are known
             to the sender and to all intermediate hops.  Hence, the



Kent & Atkinson             Standards Track                    [Page 19]

RFC 2402                IP Authentication Header           November 1998


             IPv6 Routing Header "Type 0" is included in the
             Authentication Data calculation as mutable but predictable.
             The sender must order the field so that it appears as it
             will at the receiver, prior to performing the ICV
             computation.

      Fragmentation -- Fragmentation occurs after outbound IPsec
             processing (section 3.3) and reassembly occurs before
             inbound IPsec processing (section 3.4).  So the
             Fragmentation Extension Header, if it exists, is not seen
             by IPsec.

             Note that on the receive side, the IP implementation could
             leave a Fragmentation Extension Header in place when it
             does re-assembly.  If this happens, then when AH receives
             the packet, before doing ICV processing, AH MUST "remove"
             (or skip over) this header and change the previous header's
             "Next Header" field to be the "Next Header" field in the
             Fragmentation Extension Header.

             Note that on the send side, the IP implementation could
             give the IPsec code a packet with a Fragmentation Extension
             Header with Offset of 0 (first fragment) and a More
             Fragments Flag of 0 (last fragment).  If this happens, then
             before doing ICV processing, AH MUST first "remove" (or
             skip over) this header and change the previous header's
             "Next Header" field to be the "Next Header" field in the
             Fragmentation Extension Header.

References

   [ATK95]   Atkinson, R., "The IP Authentication Header", RFC 1826,
             August 1995.

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

   [DH95]    Deering, S., and B. Hinden, "Internet Protocol version 6
             (IPv6) Specification", RFC 1883, December 1995.

   [HC98]    Harkins, D., and D. Carrel, "The Internet Key Exchange
             (IKE)", RFC 2409, November 1998.

   [KA97a]   Kent, S., and R. Atkinson, "Security Architecture for the
             Internet Protocol", RFC 2401, November 1998.

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



Kent & Atkinson             Standards Track                    [Page 20]

RFC 2402                IP Authentication Header           November 1998


   [MG97a]   Madson, C., and R. Glenn, "The Use of HMAC-MD5-96 within
             ESP and AH", RFC 2403, November 1998.

   [MG97b]   Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within
             ESP and AH", RFC 2404, November 1998.

   [STD-2]   Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
             1700, October 1994.  See also:
             http://www.iana.org/numbers.html

Disclaimer

   The views and specification here are those of the authors and are not
   necessarily those of their employers.  The authors and their
   employers specifically disclaim responsibility for any problems
   arising from correct or incorrect implementation or use of this
   specification.

Author Information

   Stephen Kent
   BBN Corporation
   70 Fawcett Street
   Cambridge, MA  02140
   USA

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


   Randall Atkinson
   @Home Network
   425 Broadway,
   Redwood City, CA  94063
   USA

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













Kent & Atkinson             Standards Track                    [Page 21]

RFC 2402                IP Authentication Header           November 1998


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.


























Kent & Atkinson             Standards Track                    [Page 22]