rfc2520.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                       J. Luciani
Request for Comments: 2520                             Nortel Networks
Category: Experimental                                       H. Suzuki
                                                         Cisco Systems
                                                          N. Doraswamy
                                                       Nortel Networks
                                                             D. Horton
                                                          CiTR Pty Ltd
                                                         February 1999


                         NHRP with Mobile NHCs

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

   This document describes an extension to NHRP [1] which would allow
   Mobile NHCs to perform a registration with and attach to an NHS in
   their home LIS in an authenticated manner.

   As described in this document, Mobile NHCs are NHCs which are not
   configured with enough information to find a specific serving NHS in
   their home LIS, but which have a mechanism to find an NHS (which may
   or may not be a serving NHS) to which they will attach.  As described
   in [1], an NHC may attach to a 'surrogate' NHS by using a mechanism
   such as an anycast address.  In this case, the NHC may use the
   surrogate NHS to send a NHRP Registration Request toward the NHC's
   home LIS where a serving NHS resides.  However, as defined in [1],
   packet authentication is performed on a hop by hop basis.  In the
   mobile NHC case, it is not practical for the mobile NHC be in a
   security relationship with every surrogate NHS, thus it is presumably
   desirable to have some form of end to end only authentication for the
   case of a mobile NHC's registration.  This document describes an
   authentication extension for NHRP which has such end to end only
   semantics.






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


1. Introduction

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [4].

   This document describes an extension for Mobile NHCs to use when they
   wish to register with their home LIS but initially connect to a non-
   serving NHS to do so.  The reader is encouraged to read [1] for more
   details on the NHRP registration process.

2.0 Definition of the NHRP Mobile NHC Authentication Extension

    Compulsory = 1
    Type = 10 (proposed)
    Length = variable

   The NHRP Mobile NHC Authentication Extension is carried in NHRP
   Registration packets to convey end to end authentication Information.
   This extension is defined in contrast to the NHRP Authentication
   Extension defined in [1] which has hop by hop semantics.

   This new extension is used when a mobile NHC initially connects to an
   NHS which is not one of its serving NHSs and the mobile NHC and
   nonserving NHS are not in a security relationship.  The mobile NHC
   does this in order to send an NHRP Registration Request, via normal
   routing and forwarding processes, to one of its serving NHSs with
   which it does have a security relationship.  As defined in [1], a
   serving NHS is an NHS in the NHC's home LIS with which the NHC will
   register.  Upon receiving such an NHRP Registration Request, the
   serving NHS will do the following: authenticate the sender NHC, set
   up a VC to the NHC, and then send an NHRP Resolution Reply in
   response on that new VC.

   Note that, as defined in [1], a transit NHS (such as the one to which
   the mobile NHC initially connects) must ignore an extension which it
   does not understand and that an NHS must not change the order of
   extensions in an NHRP packet. Thus, the end to end semantics of this
   extension are preserved without causing changes to existing
   implementations.

   If a serving NHS receives a packet which fails the hop by hop
   authentication test defined in [1] then the NHS MUST generate an
   Error Indication of type 'Authentication Failure' and discard the
   packet.  However in the case where the NHRP Mobile NHC Authentication
   Extension is used as described above, sending an Error Indication is
   not possible since no route exists back toward the mobile NHC
   assuming a VC does not already exist between the mobile NHC and the



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


   serving NHS which received the NHRP Registration Request. In this
   case, the NHRP Registration Request is merely dropped.

2.1 Header Format

   The authentication header has the following format:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Reserved                    | Security Parameter Index (SPI)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Src Addr...                                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Security Parameter Index (SPI) can be thought of as an index into a
   table that maintains the keys and other information such as a hash
   algorithm. Src and Dst communicate either offline using manual keying
   or online using a key management protocol to populate this table. The
   sending NHRP entity always allocates the SPI and the parameters
   associated with it.

   The Src Addr field is a variable length field which contains the
   address assigned to the outgoing interface. The length of the field
   is obtained from the source protocol length field in the mandatory
   part of the NHRP header.  The tuple <spi, src addr> uniquely
   identifies the key and the other parameters that are used in
   authentication.

   The length of the authentication data field is dependent on the hash
   algorithm used. The Authentication Data field contains the keyed hash
   calculated over the following fields: fixed part (with hop count,
   packet size and checksum being treated as if set to zero), mandatory
   part, and extensions up to and including the Mobile NHC
   Authentication extension.

   Note that [1] defines an explicit ordering of extensions such that:

     (a) If the Responder Address extension exists then it must appear
         before the Authentication Extension.

     (b) Any extensions that may be modified in transit (e.g., Forward
         Transit Extension, Hop by Hop Authentication Extension) must
         appear after the Mobile NHC Authentication Extension.



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


2.2 SPI and Security Parameters Negotiation

   SPI's can be negotiated either manually or using an Internet Key
   Management protocol. Manual keying MUST be supported. The following
   parameters are associated with the tuple <SPI, src>- lifetime,
   Algorithm, Key. Lifetime indicates the duration in seconds for which
   the key is valid. In case of manual keying, this duration can be
   infinite. Also, in order to better support manual keying, there may
   be multiple tuples active at the same time (Dst being the same).

   Algorithm specifies the hash algorithm agreed upon by the two
   entities. HMAC-MD5-128 [2] is the default algorithm and MUST be
   implemented. Other algorithms MAY be supported by defining new
   values.  IANA will assign the numbers to identify the algorithm being
   used as described in [1].

   Any Internet standard key management protocol MAY so be used to
   negotiate the SPI and parameters.

2.3 Message Processing

   Unauthenticated 'Mobile' Registration Request processing proceeds as
   follows [1]:

      - the NHC inserts the internetwork address of a serving NHS in the
        'Destination  Protocol Address' field; If the NHS address is
        unknown, then the NHC inserts its own internetwork address.  A '
        responder address' extension is optionally added.
      - the non-serving NHS forwards the packet along the routed path
        based on the contents of the 'Destination Protocol Address'
        field.
      - the serving NHS which receives the NHRP Registration Request
        will set up a direct VCC to NHC after authenticating the request
      - the serving NHS will then send the NHRP Registration Reply back
        to the NHC on that new VCC.  Note that the NHS MUST wait some
        configured interval before doing this reply in order to prevent
        a race condition from occurring between the VC setup and sending
        the NHRP reply packet.
      - the NHC will subsequently send all NHRP traffic to the serving
        NHS on the direct VCC.











Luciani, et al.               Experimental                      [Page 4]