rfc2402.txt

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


RFC 2402                IP Authentication Header           November 1998


3.3.3.2  Padding

3.3.3.2.1  Authentication Data Padding

   As mentioned in section 2.6, the Authentication Data field explicitly
   includes padding to ensure that the AH header is a multiple of 32
   bits (IPv4) or 64 bits (IPv6).  If padding is required, its length is
   determined by two factors:

             - the length of the ICV
             - the IP protocol version (v4 or v6)

   For example, if the output of the selected algorithm is 96-bits, no
   padding is required for either IPv4 or for IPv6.  However, if a
   different length ICV is generated, due to use of a different
   algorithm, then padding may be required depending on the length and
   IP protocol version.  The content of the padding field is arbitrarily
   selected by the sender.  (The padding is arbitrary, but need not be
   random to achieve security.)  These padding bytes are included in the
   Authentication Data calculation, counted as part of the Payload
   Length, and transmitted at the end of the Authentication Data field
   to enable the receiver to perform the ICV calculation.

3.3.3.2.2  Implicit Packet Padding

   For some authentication algorithms, the byte string over which the
   ICV computation is performed must be a multiple of a blocksize
   specified by the algorithm.  If the IP packet length (including AH)
   does not match the blocksize requirements for the algorithm, implicit
   padding MUST be appended to the end of the packet, prior to ICV
   computation.  The padding octets MUST have a value of zero.  The
   blocksize (and hence the length of the padding) is specified by the
   algorithm specification.  This padding is not transmitted with the
   packet.  Note that MD5 and SHA-1 are viewed as having a 1-byte
   blocksize because of their internal padding conventions.

3.3.4  Fragmentation

   If required, IP fragmentation occurs after AH processing within an
   IPsec implementation.  Thus, transport mode AH is applied only to
   whole IP datagrams (not to IP fragments).  An IP packet to which AH
   has been applied may itself be fragmented by routers en route, and
   such fragments must be reassembled prior to AH processing at a
   receiver.  In tunnel mode, AH is applied to an IP packet, the payload
   of which may be a fragmented IP packet.  For example, a security
   gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec
   implementation (see the Security Architecture document for details)
   may apply tunnel mode AH to such fragments.



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


3.4  Inbound Packet Processing

   If there is more than one IPsec header/extension present, the
   processing for each one ignores (does not zero, does not use) any
   IPsec headers applied subsequent to the header being processed.

3.4.1  Reassembly

   If required, reassembly is performed prior to AH processing.  If a
   packet offered to AH for processing appears to be an IP fragment,
   i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set,
   the receiver MUST discard the packet; this is an auditable event. The
   audit log entry for this event SHOULD include the SPI value,
   date/time, Source Address, Destination Address, and (in IPv6) the
   Flow ID.

   NOTE: For packet reassembly, the current IPv4 spec does NOT require
   either the zero'ing of the OFFSET field or the clearing of the MORE
   FRAGMENTS flag.  In order for a reassembled packet to be processed by
   IPsec (as opposed to discarded as an apparent fragment), the IP code
   must do these two things after it reassembles a packet.

3.4.2  Security Association Lookup

   Upon receipt of a packet containing an IP Authentication Header, the
   receiver determines the appropriate (unidirectional) SA, based on the
   destination IP address, security protocol (AH), and the SPI.  (This
   process is described in more detail in the Security Architecture
   document.)  The SA indicates whether the Sequence Number field will
   be checked, specifies the algorithm(s) employed for ICV computation,
   and indicates the key(s) required to validate the ICV.

   If no valid Security Association exists for this session (e.g., the
   receiver has no key), the receiver MUST discard the packet; this is
   an auditable event.  The audit log entry for this event SHOULD
   include the SPI value, date/time, Source Address, Destination
   Address, and (in IPv6) the Flow ID.

3.4.3  Sequence Number Verification

   All AH implementations MUST support the anti-replay service, though
   its use may be enabled or disabled by the receiver on a per-SA basis.
   (Note that there are no provisions for managing transmitted Sequence
   Number values among multiple senders directing traffic to a single SA
   (irrespective of whether the destination address is unicast,
   broadcast, or multicast).  Thus the anti-replay service SHOULD NOT be
   used in a multi-sender environment that employs a single SA.)




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


   If the receiver does not enable anti-replay for an SA, no inbound
   checks are performed on the Sequence Number.  However, from the
   perspective of the sender, the default is to assume that anti-replay
   is enabled at the receiver.  To avoid having the sender do
   unnecessary sequence number monitoring and SA setup (see section
   3.3.2), if an SA establishment protocol such as IKE is employed, the
   receiver SHOULD notify the sender, during SA establishment, if the
   receiver will not provide anti-replay protection.

   If the receiver has enabled the anti-replay service for this SA, the
   receiver packet counter for the SA MUST be initialized to zero when
   the SA is established.  For each received packet, the receiver MUST
   verify that the packet contains a Sequence Number that does not
   duplicate the Sequence Number of any other packets received during
   the life of this SA.  This SHOULD be the first AH check applied to a
   packet after it has been matched to an SA, to speed rejection of
   duplicate packets.

   Duplicates are rejected through the use of a sliding receive window.
   (How the window is implemented is a local matter, but the following
   text describes the functionality that the implementation must
   exhibit.)  A MINIMUM window size of 32 MUST be supported; but a
   window size of 64 is preferred and SHOULD be employed as the default.
   Another window size (larger than the MINIMUM) MAY be chosen by the
   receiver.  (The receiver does NOT notify the sender of the window
   size.)

   The "right" edge of the window represents the highest, validated
   Sequence Number value received on this SA.  Packets that contain
   Sequence Numbers lower than the "left" edge of the window are
   rejected.  Packets falling within the window are checked against a
   list of received packets within the window.  An efficient means for
   performing this check, based on the use of a bit mask, is described
   in the Security Architecture document.

   If the received packet falls within the window and is new, or if the
   packet is to the right of the window, then the receiver proceeds to
   ICV verification.  If the ICV validation fails, the receiver MUST
   discard the received IP datagram as invalid; this is an auditable
   event.  The audit log entry for this event SHOULD include the SPI
   value, date/time, Source Address, Destination Address, the Sequence
   Number, and (in IPv6) the Flow ID.  The receive window is updated
   only if the ICV verification succeeds.








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


   DISCUSSION:

      Note that if the packet is either inside the window and new, or is
      outside the window on the "right" side, the receiver MUST
      authenticate the packet before updating the Sequence Number window
      data.

3.4.4  Integrity Check Value Verification

   The receiver computes the ICV over the appropriate fields of the
   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



Kent & Atkinson             Standards Track                    [Page 15]

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



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


   and v6 contexts.  Auditing requirements have been clarified in this
   version of the specification.  Tunnel mode AH was mentioned only in
   passing in RFC 1826, but now is a mandatory feature of AH.
   Discussion of interactions with key management and with security
   labels have been moved to the Security Architecture document.

Acknowledgements

   For over 3 years, this document has evolved through multiple versions
   and iterations.  During this time, many people have contributed
   significant ideas and energy to the process and the documents
   themselves.  The authors would like to thank Karen Seo for providing
   extensive help in the review, editing, background research, and
   coordination for this version of the specification.  The authors
   would also like to thank the members of the IPsec and IPng working
   groups, with special mention of the efforts of (in alphabetic order):
   Steve Bellovin, Steve Deering, Francis Dupont, Phil Karn, Frank
   Kastenholz, Perry Metzger, David Mihelcic, Hilarie Orman, Norman
   Shulman, William Simpson, and Nina Yuan.