As per Relevance of the word registration, we have this rfc below:
Network Working Group J.
Request for Comments: 2520 Nortel
Category: Experimental H.
Cisco
N.
Nortel
D.
CiTR Pty
February 1999
NHRP with Mobile
Status of this
This memo defines an Experimental Protocol for the
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
Copyright (C) The Internet Society (1999). All Rights Reserved
This document describes an extension to NHRP [1] which would
Mobile NHCs to perform a registration with and attach to an NHS
their home LIS in an authenticated manner
As described in this document, Mobile NHCs are NHCs which are
configured with enough information to find a specific serving NHS
their home LIS, but which have a mechanism to find an NHS (which
or may not be a serving NHS) to which they will attach. As
in [1], an NHC may attach to a 'surrogate' NHS by using a
such as an anycast address. In this case, the NHC may use
surrogate NHS to send a NHRP Registration Request toward the NHC'
home LIS where a serving NHS resides. However, as defined in [1],
packet authentication is performed on a hop by hop basis. In
mobile NHC case, it is not practical for the mobile NHC be in
security relationship with every surrogate NHS, thus it is
desirable to have some form of end to end only authentication for
case of a mobile NHC's registration. This document describes
authentication extension for NHRP which has such end to end
semantics
Luciani, et al. Experimental [Page 1]
RFC 2520 NHRP with Mobile NHCs February 1999
1.
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in
document, are to be interpreted as described in [4].
This document describes an extension for Mobile NHCs to use when
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
details on the NHRP registration process
2.0 Definition of the NHRP Mobile NHC Authentication
Compulsory = 1
Type = 10 (proposed
Length =
The NHRP Mobile NHC Authentication Extension is carried in
Registration packets to convey end to end authentication Information
This extension is defined in contrast to the NHRP
Extension defined in [1] which has hop by hop semantics
This new extension is used when a mobile NHC initially connects to
NHS which is not one of its serving NHSs and the mobile NHC
nonserving NHS are not in a security relationship. The mobile
does this in order to send an NHRP Registration Request, via
routing and forwarding processes, to one of its serving NHSs
which it does have a security relationship. As defined in [1],
serving NHS is an NHS in the NHC's home LIS with which the NHC
register. Upon receiving such an NHRP Registration Request,
serving NHS will do the following: authenticate the sender NHC,
up a VC to the NHC, and then send an NHRP Resolution Reply
response on that new VC
Note that, as defined in [1], a transit NHS (such as the one to
the mobile NHC initially connects) must ignore an extension which
does not understand and that an NHS must not change the order
extensions in an NHRP packet. Thus, the end to end semantics of
extension are preserved without causing changes to
implementations
If a serving NHS receives a packet which fails the hop by
authentication test defined in [1] then the NHS MUST generate
Error Indication of type 'Authentication Failure' and discard
packet. However in the case where the NHRP Mobile NHC
Extension is used as described above, sending an Error Indication
not possible since no route exists back toward the mobile
assuming a VC does not already exist between the mobile NHC and
Luciani, et al. Experimental [Page 2]
RFC 2520 NHRP with Mobile NHCs February 1999
serving NHS which received the NHRP Registration Request. In
case, the NHRP Registration Request is merely dropped
2.1 Header
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
table that maintains the keys and other information such as a
algorithm. Src and Dst communicate either offline using manual
or online using a key management protocol to populate this table.
sending NHRP entity always allocates the SPI and the
associated with it
The Src Addr field is a variable length field which contains
address assigned to the outgoing interface. The length of the
is obtained from the source protocol length field in the
part of the NHRP header. The tuple
identifies the key and the other parameters that are used
authentication
The length of the authentication data field is dependent on the
algorithm used. The Authentication Data field contains the keyed
calculated over the following fields: fixed part (with hop count
packet size and checksum being treated as if set to zero),
part, and extensions up to and including the Mobile
Authentication extension
Note that [1] defines an explicit ordering of extensions such that
(a) If the Responder Address extension exists then it must
before the Authentication Extension
(b) Any extensions that may be modified in transit (e.g.,
Transit Extension, Hop by Hop Authentication Extension)
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
SPI's can be negotiated either manually or using an Internet
Management protocol. Manual keying MUST be supported. The
parameters are associated with the tuple - lifetime
Algorithm, Key. Lifetime indicates the duration in seconds for
the key is valid. In case of manual keying, this duration can
infinite. Also, in order to better support manual keying, there
be multiple tuples active at the same time (Dst being the same).
Algorithm specifies the hash algorithm agreed upon by the
entities. HMAC-MD5-128 [2] is the default algorithm and MUST
implemented. Other algorithms MAY be supported by defining
values. IANA will assign the numbers to identify the algorithm
used as described in [1].
Any Internet standard key management protocol MAY so be used
negotiate the SPI and parameters
2.3 Message
Unauthenticated 'Mobile' Registration Request processing proceeds
follows [1]:
- the NHC inserts the internetwork address of a serving NHS in
'Destination Protocol Address' field; If the NHS address
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
based on the contents of the 'Destination Protocol Address
field
- the serving NHS which receives the NHRP Registration
will set up a direct VCC to NHC after authenticating the
- the serving NHS will then send the NHRP Registration Reply
to the NHC on that new VCC. Note that the NHS MUST wait
configured interval before doing this reply in order to
a race condition from occurring between the VC setup and
the NHRP reply packet
- the NHC will subsequently send all NHRP traffic to the
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
table look up in order to fetch the SPI and the security
based on the outgoing interface address. If there are no entries
the table and if there is support for key management, the
initiates the key management protocol to fetch the
parameters. The NHC constructs the Authentication Extension
and calculates the hash by zeroing out the authentication data field
The result is placed in the authentication data field. The
address field in the payload is the internetwork address assigned
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
the SPI and the internetwork address in the authentication
payload. The authentication data field is extracted before
zeroed out in order to calculate the hash. It computes the hash
the entire payload and if the hash does not match, then an "
event" has occurred
The keys used by the mobile NHC for communicating with the
NHS in NHRP Registration Requests can be used in
resolution and purge requests made directly to the serving NHS
receiving the NHRP Registration Reply. However, the
extension defined in [1] MUST be used when these keys are applied
resolution and purge packets
Hop by Hop Authentication[1] and End to End authentication MAY
used in combination to provide protection against both spoofing
denial of service attacks. If only an end-to-end Mobile
Authentication Extension is present, it MAY be the policy of
transit NHS to reject the NHRP Registration Request based on
requirement for having a Hop by Hop authentication present. Such
requirement is a local matter
2.4 Security
It is important that the keys chosen are strong since the security
the entire system depends on the keys being chosen properly
End-to-end authentication counters spoofing attacks on the
subnet through not relying on the potentially compromised chain
trust. The use of end-end authentication is further described in [3].
Hop-by-hop authentication prevents denial of service attacks
introducing access control at the first point of contact to the
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
point entities in the path traversed. A chain of trust is
amongst NHRP entities in the path of the NHRP Message. If
security in an NHRP entity is compromised, then security in
entire NHRP domain is compromised
Data integrity covers the entire NHRP payload up to and including
Mobile NHC Authentication Extension. This guarantees that the
and extensions covered by this authentication hash were not
and that the source is authenticated as well. If the
extension is not used or if the security is compromised, then
entities are liable to both spoofing attacks, active attacks,
passive attacks
There is no mechanism to encrypt the messages. It is assumed that
standard layer 3 confidentiality mechanism will be used to
and decrypt messages. It is recommended to use an Internet
key management protocol to negotiate the keys between the neighbors
Transmitting the keys in clear text, if other methods of
is used, compromises the security completely
[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
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
Levels", BCP 14, RFC 2119, March 1997.
Luciani, et al. Experimental [Page 6]
RFC 2520 NHRP with Mobile NHCs February 1999
Authors'
James V.
Nortel
3 Federal
Mail Stop: BL3-03
Billerica, MA 01821
Phone: +1 978 916 4734
EMail: luciani@baynetworks.
Hiroshi
Cisco
170 West Tasman Dr
San Jose, CA 96134
Phone: +1 408 525 6006
EMail: hsuzuki@cisco.
Naganand
Nortel
3 Federal
Mail Stop: BL3-03
Billerica, MA 01821
Phone: +1 978 916 4734
EMail: naganand@baynetworks.
David
CiTR PTY
Level 2 North
339 Coronation
Milton, Australia 4064
Phone: +61 7 32592222
EMail: d.horton@citr.com.
Luciani, et al. Experimental [Page 7]
RFC 2520 NHRP with Mobile NHCs February 1999
Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Luciani, et al. Experimental [Page 8]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
