rfc2520.txt

RFC 的详细文档！


RFC 2520                 NHRP with Mobile NHCs             February 1999


   When the NHC adds the authentication extension header, it performs a
   table look up in order to fetch the SPI and the security parameters
   based on the outgoing interface address. If there are no entries in
   the table and if there is support for key management, the NHC
   initiates the key management protocol to fetch the necessary
   parameters. The NHC constructs the Authentication Extension payload
   and calculates the hash by zeroing out the authentication data field.
   The result is placed in the authentication data field. The src
   address field in the payload is the internetwork address assigned to
   the outgoing interface.

   If key management is not supported and authentication is mandatory,
   the packet is dropped and this information is logged.

   On the receiving end, the serving NHS fetches the parameters based on
   the SPI and the internetwork address in the authentication extension
   payload. The authentication data field is extracted before being
   zeroed out in order to calculate the hash. It computes the hash on
   the entire payload and if the hash does not match, then an "abnormal
   event" has occurred.

   The keys used by the mobile NHC for communicating with the serving
   NHS in NHRP Registration Requests can be used in subsequent
   resolution and purge requests made directly to the serving NHS after
   receiving the NHRP Registration Reply.  However, the authentication
   extension defined in [1] MUST be used when these keys are applied to
   resolution and purge packets.

   Hop by Hop Authentication[1] and End to End authentication MAY be
   used in combination to provide protection against both spoofing and
   denial of service attacks.  If only an end-to-end Mobile NHC
   Authentication Extension is present, it MAY be the policy of each
   transit NHS to reject the NHRP Registration Request based on the
   requirement for having a Hop by Hop authentication present.  Such a
   requirement is a local matter.

2.4 Security Considerations

   It is important that the keys chosen are strong since the security of
   the entire system depends on the keys being chosen properly.

   End-to-end authentication counters spoofing attacks on the home
   subnet through not relying on the potentially compromised chain of
   trust. The use of end-end authentication is further described in [3].

   Hop-by-hop authentication prevents denial of service attacks by
   introducing access control at the first point of contact to the NHRP
   infrastructure.



Luciani, et al.               Experimental                      [Page 5]

RFC 2520                 NHRP with Mobile NHCs             February 1999


   The security of this extension is performed on an end to end basis.
   The data received can be trusted only so much as one trusts the end
   point entities in the path traversed. A chain of trust is established
   amongst NHRP entities in the path of the NHRP Message. If the
   security in an NHRP entity is compromised, then security in the
   entire NHRP domain is compromised.

   Data integrity covers the entire NHRP payload up to and including the
   Mobile NHC Authentication Extension. This guarantees that the data
   and extensions covered by this authentication hash were not modified
   and that the source is authenticated as well. If the authentication
   extension is not used or if the security is compromised, then NHRP
   entities are liable to both spoofing attacks, active attacks, and
   passive attacks.

   There is no mechanism to encrypt the messages. It is assumed that a
   standard layer 3 confidentiality mechanism will be used to encrypt
   and decrypt messages.  It is recommended to use an Internet standard
   key management protocol to negotiate the keys between the neighbors.
   Transmitting the keys in clear text, if other methods of negotiation
   is used, compromises the security completely.

References

   [1] Luciani, J., Katz, D., Piscitello, D., Cole, B. and N. Doraswamy,
       "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.

   [2] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed Hashing
       for Message Authentication", RFC 2104, February 1997.

   [3] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.

   [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.

















Luciani, et al.               Experimental                      [Page 6]

RFC 2520                 NHRP with Mobile NHCs             February 1999


Authors' Addresses

   James V. Luciani
   Nortel Networks
   3 Federal Street
   Mail Stop: BL3-03
   Billerica, MA 01821

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


   Hiroshi Suzuki
   Cisco Systems
   170 West Tasman Dr.
   San Jose, CA 96134

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


   Naganand Doraswamy
   Nortel Networks
   3 Federal Street
   Mail Stop: BL3-03
   Billerica, MA 01821

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


   David Horton
   CiTR PTY Ltd
   Level 2 North Tower
   339 Coronation Drive
   Milton, Australia 4064

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












Luciani, et al.               Experimental                      [Page 7]

RFC 2520                 NHRP with Mobile NHCs             February 1999


Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Luciani, et al.               Experimental                      [Page 8]