rfc1826.txt

RFC 的详细文档！

   dependent.  If the processing of the authentication algorithm
   indicates the datagram is valid, then it is accepted.  If the
   algorithm determines that the data and the Authentication Header do
   not match, then the receiver SHOULD discard the received IP datagram
   as invalid and MUST record the authentication failure in the system
   log or audit log.  If such a failure occurs, the recorded log data
   MUST include the SPI value, date/time received, clear-text Sending
   Address, clear-text Destination Address, and (if it exists) the
   clear-text Flow ID.  The log data MAY also include other information
   about the failed packet.







Atkinson                    Standards Track                     [Page 9]

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



Atkinson                    Standards Track                    [Page 10]

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.

REFERENCES

   [Atk95a] Atkinson, R., "Security Architecture for the Internet
            Protocol", RFC 1825, NRL, August 1995.

   [Atk95b] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827,
            NRL, August 1995.

   [Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol
           Suite", ACM Computer Communications Review, Vol. 19, No. 2,
           March 1989.





Atkinson                    Standards Track                    [Page 11]

RFC 1826                IP Authentication Header             August 1995


   [BCCH94] Braden, R., Clark, D., Crocker, S., and C. Huitema, "Report
            of IAB Workshop on Security in the Internet Architecture",
            RFC 1636, USC/Information Sciences Institute, MIT, Trusted
            Information Systems, INRIA, June 1994, pp. 21-34.

   [CER95] Computer Emergency Response Team (CERT), "IP Spoofing Attacks
           and Hijacked Terminal Connections", CA-95:01, January 1995.
           Available via anonymous ftp from info.cert.org in
           /pub/cert_advisories.

   [GM93]  Galvin J., and K. McCloghrie, "Security Protocols for
           version 2 of the Simple Network Management Protocol
           (SNMPv2)", RFC 1446, Trusted Information Systems, Hughes LAN
           Systems, April 1993.

   [Hin94] Bob Hinden (Editor), Internet Protocol version 6 (IPv6)
           Specification, Work in Progress, October 1994.

   [Ken91] Kent, S., "US DoD Security Options for the Internet Protocol",
           RFC 1108, BBN Communications, November 1991.

   [Kno93] Knowles, Stev, "IESG Advice from Experience with Path MTU
           Discovery", RFC 1435, FTP Software, March 1993.

   [MS95]  Metzger, P., and W. Simpson, "IP Authentication with Keyed
           MD5", RFC 1828, Piermont, Daydreamer, August 1995.

   [MD90]  Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
           DECWRL, Stanford University, November 1990.

   [STD-2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
           RFC 1700, USC/Information Sciences Institute, October 1994.

   [Riv92] Rivest, R., "MD5 Digest Algorithm", RFC 1321, MIT and RSA Data
           Security, Inc., April 1992.

   [VK83]  V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level
           Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983.













Atkinson                    Standards Track                    [Page 12]

RFC 1826                IP Authentication Header             August 1995


DISCLAIMER

   The views and specification here are those of the author and are not
   necessarily those of his employer.  The Naval Research Laboratory has
   not passed judgement on the merits, if any, of this work.  The author
   and his employer specifically disclaim responsibility for any
   problems arising from correct or incorrect implementation or use of
   this specification.

AUTHOR INFORMATION

   Randall Atkinson
   Information Technology Division
   Naval Research Laboratory
   Washington, DC 20375-5320
   USA

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































Atkinson                    Standards Track                    [Page 13]