RFC 1826                IP Authentication Header             August 1995


5. CONFORMANCE REQUIREMENTS

   Implementations that claim conformance or compliance with this
   specification MUST fully implement the header described here, MUST
   support manual key distribution for use with this option, MUST comply
   with all requirements of the "Security Architecture for the Internet
   Protocol" [Atk95a], and MUST support the use of keyed MD5 as
   described in the companion document entitled "IP Authentication using
   Keyed MD5" [MS95].  Implementations MAY also implement other
   authentication algorithms.  Implementors should consult the most
   recent version of the "IAB Official Standards" RFC for further
   guidance on the status of this document.

6. SECURITY CONSIDERATIONS

   This entire RFC discusses an authentication mechanism for IP.  This
   mechanism is not a panacea to the several security issues in any
   internetwork, however it does provide a component useful in building
   a secure internetwork.

   Users need to understand that the quality of the security provided by
   this specification depends completely on the strength of whichever
   cryptographic algorithm has been implemented, the strength of the key
   being used, the correctness of that algorithm's implementation, upon
   the security of the key management mechanism and its implementation,
   and upon the correctness of the IP Authentication Header and IP
   implementations in all of the participating systems. If any of these
   assumptions do not hold, then little or no real security will be
   provided to the user.  Implementors are encouraged to use high
   assurance methods to develop all of the security relevant parts of
   their products.

   Users interested in confidentiality should consider using the IP
   Encapsulating Security Payload (ESP) instead of or in conjunction
   with this specification [Atk95b].  Users seeking protection from
   traffic analysis might consider the use of appropriate link
   encryption.  Description and specification of link encryption is
   outside the scope of this note [VK83].  Users interested in combining
   the IP Authentication Header with the IP Encapsulating Security
   Payload should consult the IP Encapsulating Security Payload
   specification for details.

   One particular issue is that in some cases a packet which causes an
   error to be reported back via ICMP might be so large as not to
   entirely fit within the ICMP message returned.  In such cases, it
   might not be possible for the receiver of the ICMP message to
   independently authenticate the portion of the returned message.  This
   could mean that the host receiving such an ICMP message would either




 
RFC 1826                IP Authentication Header             August 1995


   trust an unauthenticated ICMP message, which might in turn create
   some security problem, or not trust and hence not react appropriately
   to some legitimate ICMP message that should have been reacted to.  It
   is not clear that this issue can be fully resolved in the presence of
   packets that are the same size as or larger than the minimum IP MTU.
   Similar complications arise if an encrypted packet causes an ICMP
   error message to be sent and that packet is truncated.

   Active attacks are now widely known to exist in the Internet [CER95].
   The presence of active attacks means that unauthenticated source
   routing, either unidirectional (receive-only) or with replies
   following the original received source route represents a significant
   security risk unless all received source routed packets are
   authenticated using the IP Authentication Header or some other
   cryptologic mechanism.  It is noteworthy that the attacks described
   in [CER95] include a subset of those described in [Bel89].

   The use of IP tunneling with AH creates multiple pairs of endpoints
   that might perform AH processing.  Implementers and administrators
   should carefully consider the impacts of tunneling on authenticity of
   the received tunneled packets.

ACKNOWLEDGEMENTS

   This document benefited greatly from work done by Bill Simpson, Perry
   Metzger, and Phil Karn to make general the approach originally
   defined by the author for SIP, SIPP, and finally IPv6.

   The basic concept here is derived in large part from the SNMPv2
   Security Protocol work described in [GM93].  Steve Bellovin, Steve
   Deering, Frank Kastenholz, Dave Mihelcic, and Hilarie Orman provided
   thoughtful critiques of early versions of this note.  Francis Dupont
   discovered and pointed out the security issue with ICMP in low IP MTU
   links that is noted just above.