packet, using the specified authentication algorithm, and verifies
   that it is the same as the ICV included in the Authentication Data
   field of the packet.  Details of the computation are provided below.

   If the computed and received ICV's match, then the datagram is valid,
   and it is accepted.  If the test fails, then the receiver MUST
   discard the received IP datagram as invalid; this is an auditable
   event.  The audit log entry SHOULD include the SPI value, date/time
   received, Source Address, Destination Address, and (in IPv6) the Flow
   ID.

   DISCUSSION:

      Begin by saving the ICV value and replacing it (but not any
      Authentication Data padding) with zero.  Zero all other fields
      that may have been modified during transit.  (See section 3.3.3.1
      for a discussion of which fields are zeroed before performing the
      ICV calculation.)  Check the overall length of the packet, and if
      it requires implicit padding based on the requirements of the
      authentication algorithm, append zero-filled bytes to the end of
      the packet as required.  Perform the ICV computation and compare
      the result with the saved value, using the comparison rules
      defined by the algorithm specification.  (For example, if a
      digital signature and one-way hash are used for the ICV
      computation, the matching process is more complex.)

4.  Auditing

   Not all systems that implement AH will implement auditing.  However,
   if AH is incorporated into a system that supports auditing, then the
   AH implementation MUST also support auditing and MUST allow a system
   administrator to enable or disable auditing for AH.  For the most
   part, the granularity of auditing is a local matter.  However,
   several auditable events are identified in this specification and for
   each of these events a minimum set of information that SHOULD be
   included in an audit log is defined.  Additional information also MAY
   be included in the audit log for each of these events, and additional
   events, not explicitly called out in this specification, also MAY




 
RFC 2402                IP Authentication Header           November 1998


   result in audit log entries.  There is no requirement for the
   receiver to transmit any message to the purported sender in response
   to the detection of an auditable event, because of the potential to
   induce denial of service via such action.

5.  Conformance Requirements

   Implementations that claim conformance or compliance with this
   specification MUST fully implement the AH syntax and processing
   described here and MUST comply with all requirements of the Security
   Architecture document.  If the key used to compute an ICV is manually
   distributed, correct provision of the anti-replay service would
   require correct maintenance of the counter state at the sender, until
   the key is replaced, and there likely would be no automated recovery
   provision if counter overflow were imminent.  Thus a compliant
   implementation SHOULD NOT provide this service in conjunction with
   SAs that are manually keyed.  A compliant AH implementation MUST
   support the following mandatory-to-implement algorithms:

             - HMAC with MD5 [MG97a]
             - HMAC with SHA-1 [MG97b]

6.  Security Considerations

   Security is central to the design of this protocol, and these
   security considerations permeate the specification.  Additional
   security-relevant aspects of using the IPsec protocol are discussed
   in the Security Architecture document.

7.  Differences from RFC 1826

   This specification of AH differs from RFC 1826 [ATK95] in several
   important respects, but the fundamental features of AH remain intact.
   One goal of the revision of RFC 1826 was to provide a complete
   framework for AH, with ancillary RFCs required only for algorithm
   specification.  For example, the anti-replay service is now an
   integral, mandatory part of AH, not a feature of a transform defined
   in another RFC.  Carriage of a sequence number to support this
   service is now required at all times.  The default algorithms
   required for interoperability have been changed to HMAC with MD5 or
   SHA-1 (vs. keyed MD5), for security reasons.  The list of IPv4 header
   fields excluded from the ICV computation has been expanded to include
   the OFFSET and FLAGS fields.

   Another motivation for revision was to provide additional detail and
   clarification of subtle points.  This specification provides
   rationale for exclusion of selected IPv4 header fields from AH
   coverage and provides examples on positioning of AH in both the IPv4




 
RFC 2402                IP Authentication Header           November 1998