summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2520.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2520.txt')
-rw-r--r--doc/rfc/rfc2520.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc2520.txt b/doc/rfc/rfc2520.txt
new file mode 100644
index 0000000..ce9453c
--- /dev/null
+++ b/doc/rfc/rfc2520.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+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]
+
+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: +1 978 916 4734
+ EMail: luciani@baynetworks.com
+
+
+ Hiroshi Suzuki
+ Cisco Systems
+ 170 West Tasman Dr.
+ San Jose, CA 96134
+
+ Phone: +1 408 525 6006
+ EMail: hsuzuki@cisco.com
+
+
+ Naganand Doraswamy
+ Nortel Networks
+ 3 Federal Street
+ Mail Stop: BL3-03
+ Billerica, MA 01821
+
+ Phone: +1 978 916 4734
+ EMail: naganand@baynetworks.com
+
+
+ David Horton
+ CiTR PTY Ltd
+ Level 2 North Tower
+ 339 Coronation Drive
+ Milton, Australia 4064
+
+ Phone: +61 7 32592222
+ EMail: d.horton@citr.com.au
+
+
+
+
+
+
+
+
+
+
+
+
+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]
+