rfc2402.txt

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

                 except for mutable fields

   In the IPv6 context, AH is viewed as an end-to-end payload, and thus
   should appear after hop-by-hop, routing, and fragmentation extension
   headers.  The destination options extension header(s) could appear
   either before or after the AH header depending on the semantics
   desired.  The following diagram illustrates AH transport mode
   positioning for a typical IPv6 packet.

                       BEFORE APPLYING AH
            ---------------------------------------
      IPv6  |             | ext hdrs |     |      |
            | orig IP hdr |if present| TCP | Data |
            ---------------------------------------

                      AFTER APPLYING AH
            ------------------------------------------------------------
      IPv6  |             |hop-by-hop, dest*, |    | dest |     |      |
            |orig IP hdr  |routing, fragment. | AH | opt* | TCP | Data |
            ------------------------------------------------------------
            |<---- authenticated except for mutable fields ----------->|

                 * = if present, could be before AH, after AH, or both





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


   ESP and AH headers can be combined in a variety of modes.  The IPsec
   Architecture document describes the combinations of security
   associations that must be supported.

   Tunnel mode AH may be employed in either hosts or security gateways
   (or in so-called "bump-in-the-stack" or "bump-in-the-wire"
   implementations, as defined in the Security Architecture document).
   When AH is implemented in a security gateway (to protect transit
   traffic), tunnel mode must be used.  In tunnel mode, the "inner" IP
   header carries the ultimate source and destination addresses, while
   an "outer" IP header may contain distinct IP addresses, e.g.,
   addresses of security gateways.  In tunnel mode, AH protects the
   entire inner IP packet, including the entire inner IP header. The
   position of AH in tunnel mode, relative to the outer IP header, is
   the same as for AH in transport mode.  The following diagram
   illustrates AH tunnel mode positioning for typical IPv4 and IPv6
   packets.

          ------------------------------------------------
    IPv4  | new IP hdr* |    | orig IP hdr*  |    |      |
          |(any options)| AH | (any options) |TCP | Data |
          ------------------------------------------------
          |<- authenticated except for mutable fields -->|
          |           in the new IP hdr                  |

          --------------------------------------------------------------
    IPv6  |           | ext hdrs*|    |            | ext hdrs*|   |    |
          |new IP hdr*|if present| AH |orig IP hdr*|if present|TCP|Data|
          --------------------------------------------------------------
          |<-- authenticated except for mutable fields in new IP hdr ->|

           * = construction of outer IP hdr/extensions and modification
               of inner IP hdr/extensions is discussed below.

3.2  Authentication Algorithms

   The authentication algorithm employed for the ICV computation is
   specified by the SA.  For point-to-point communication, suitable
   authentication algorithms include keyed Message Authentication Codes
   (MACs) based on symmetric encryption algorithms (e.g., DES) or on
   one-way hash functions (e.g., MD5 or SHA-1).  For multicast
   communication, one-way hash algorithms combined with asymmetric
   signature algorithms are appropriate, though performance and space
   considerations currently preclude use of such algorithms.  The
   mandatory-to-implement authentication algorithms are described in
   Section 5 "Conformance Requirements".  Other algorithms MAY be
   supported.




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


3.3  Outbound Packet Processing

   In transport mode, the sender inserts the AH header after the IP
   header and before an upper layer protocol header, as described above.
   In tunnel mode, the outer and inner IP header/extensions can be
   inter-related in a variety of ways.  The construction of the outer IP
   header/extensions during the encapsulation process is described in
   the Security Architecture document.

   If there is more than one IPsec header/extension required, the order
   of the application of the security headers MUST be defined by
   security policy.  For simplicity of processing, each IPsec header
   SHOULD ignore the existence (i.e., not zero the contents or try to
   predict the contents) of IPsec headers to be applied later.  (While a
   native IP or bump-in-the-stack implementation could predict the
   contents of later IPsec headers that it applies itself, it won't be
   possible for it to predict any IPsec headers added by a bump-in-the-
   wire implementation between the host and the network.)

3.3.1  Security Association Lookup

   AH is applied to an outbound packet only after an IPsec
   implementation determines that the packet is associated with an SA
   that calls for AH processing.  The process of determining what, if
   any, IPsec processing is applied to outbound traffic is described in
   the Security Architecture document.

3.3.2  Sequence Number Generation

   The sender's counter is initialized to 0 when an SA is established.
   The sender increments the Sequence Number for this SA and inserts the
   new value into the Sequence Number Field.  Thus the first packet sent
   using a given SA will have a Sequence Number of 1.

   If anti-replay is enabled (the default), the sender checks to ensure
   that the counter has not cycled before inserting the new value in the
   Sequence Number field.  In other words, the sender MUST NOT send a
   packet on an SA if doing so would cause the Sequence Number to cycle.
   An attempt to transmit a packet that would result in Sequence Number
   overflow is an auditable event.  (Note that this approach to Sequence
   Number management does not require use of modular arithmetic.)

   The sender assumes anti-replay is enabled as a default, unless
   otherwise notified by the receiver (see 3.4.3).  Thus, if the counter
   has cycled, the sender will set up a new SA and key (unless the SA
   was configured with manual key management).





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


   If anti-replay is disabled, the sender does not need to monitor or
   reset the counter, e.g., in the case of manual key management (see
   Section 5.) However, the sender still increments the counter and when
   it reaches the maximum value, the counter rolls over back to zero.

3.3.3  Integrity Check Value Calculation

   The AH ICV is computed over:
           o IP header fields that are either immutable in transit or
             that are predictable in value upon arrival at the endpoint
             for the AH SA
           o the AH header (Next Header, Payload Len, Reserved, SPI,
             Sequence Number, and the Authentication Data (which is set
             to zero for this computation), and explicit padding bytes
             (if any))
           o the upper level protocol data, which is assumed to be
             immutable in transit

3.3.3.1  Handling Mutable Fields

   If a field may be modified during transit, the value of the field is
   set to zero for purposes of the ICV computation.  If a field is
   mutable, but its value at the (IPsec) receiver is predictable, then
   that value is inserted into the field for purposes of the ICV
   calculation.  The Authentication Data field is also set to zero in
   preparation for this computation.  Note that by replacing each
   field's value with zero, rather than omitting the field, alignment is
   preserved for the ICV calculation.  Also, the zero-fill approach
   ensures that the length of the fields that are so handled cannot be
   changed during transit, even though their contents are not explicitly
   covered by the ICV.

   As a new extension header or IPv4 option is created, it will be
   defined in its own RFC and SHOULD include (in the Security
   Considerations section) directions for how it should be handled when
   calculating the AH ICV.  If the IP (v4 or v6) implementation
   encounters an extension header that it does not recognize, it will
   discard the packet and send an ICMP message.  IPsec will never see
   the packet.  If the IPsec implementation encounters an IPv4 option
   that it does not recognize, it should zero the whole option, using
   the second byte of the option as the length.  IPv6 options (in
   Destination extension headers or Hop by Hop extension header) contain
   a flag indicating mutability, which determines appropriate processing
   for such options.







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


3.3.3.1.1  ICV Computation for IPv4

3.3.3.1.1.1  Base Header Fields

   The IPv4 base header fields are classified as follows:

   Immutable
             Version
             Internet Header Length
             Total Length
             Identification
             Protocol (This should be the value for AH.)
             Source Address
             Destination Address (without loose or strict source routing)

   Mutable but predictable
             Destination Address (with loose or strict source routing)

   Mutable (zeroed prior to ICV calculation)
             Type of Service (TOS)
             Flags
             Fragment Offset
             Time to Live (TTL)
             Header Checksum

      TOS -- This field is excluded because some routers are known to
             change the value of this field, even though the IP
             specification does not consider TOS to be a mutable header
             field.

      Flags -- This field is excluded since an intermediate router might
             set the DF bit, even if the source did not select it.

      Fragment Offset -- Since AH is applied only to non-fragmented IP
             packets, the Offset Field must always be zero, and thus it
             is excluded (even though it is predictable).

      TTL -- This is changed en-route as a normal course of processing
             by routers, and thus its value at the receiver is not
             predictable by the sender.

      Header Checksum -- This will change if any of these other fields
             changes, and thus its value upon reception cannot be
             predicted by the sender.







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


3.3.3.1.1.2  Options

   For IPv4 (unlike IPv6), there is no mechanism for tagging options as
   mutable in transit.  Hence the IPv4 options are explicitly listed in
   Appendix A and classified as immutable, mutable but predictable, or
   mutable.  For IPv4, the entire option is viewed as a unit; so even
   though the type and length fields within most options are immutable
   in transit, if an option is classified as mutable, the entire option
   is zeroed for ICV computation purposes.

3.3.3.1.2  ICV Computation for IPv6

3.3.3.1.2.1  Base Header Fields

   The IPv6 base header fields are classified as follows:

   Immutable
             Version
             Payload Length
             Next Header (This should be the value for AH.)
             Source Address
             Destination Address (without Routing Extension Header)

   Mutable but predictable
             Destination Address (with Routing Extension Header)

   Mutable (zeroed prior to ICV calculation)
             Class
             Flow Label
             Hop Limit

3.3.3.1.2.2  Extension Headers Containing 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.

3.3.3.1.2.3  Extension Headers Not Containing Options

   The IPv6 extension headers that do not contain options are explicitly
   listed in Appendix A and classified as immutable, mutable but
   predictable, or mutable.



Kent & Atkinson             Standards Track                    [Page 11]