RFC 2520

NHRP with Mobile NHCs

📅 published February 1999, from ietf

RFC 2520: NHRP with Mobile NHCs 🦋

okay bestie, so RFC 2520 is titled NHRP with Mobile NHCs 🎀 It came out of the Network Working Group in February 1999 and is marked Experimental. The authors are J. Luciani (Nortel Networks), H. Suzuki (Cisco Systems), N. Doraswamy (Nortel Networks), and D. Horton (CiTR Pty Ltd). The title block doesn't list anything it obsoletes or updates, so it's standing on its own 💅

Status of this Memo 📜

this one is an Experimental Protocol for the Internet community 🧪 it's not an Internet standard of any kind. they actually want feedback and suggestions for improvement, so go for it 💖 and the memo can be shared freely, distribution is unlimited ✨

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

Abstract 🦋

so this doc extends NHRP [1] so that Mobile NHCs can register with an NHS in their home LIS and attach to it in an authenticated way 🔐

a Mobile NHC is an NHC that doesn't have enough config to find a specific serving NHS in its home LIS 🧭 but it has a way to find some NHS (which might or might not be the serving one) and attach to that. as [1] describes, an NHC can attach to a 'surrogate' NHS using something like an anycast address 🛰️ then the NHC uses that surrogate to send an NHRP Registration Request toward its home LIS, where the serving NHS lives 📨

here's the tea ☕ [1] does packet authentication hop by hop, and for a mobile NHC it's not practical to have a security relationship with every surrogate NHS 😭 so it's presumably desirable to have end to end only authentication for a mobile NHC's registration. this doc describes an authentication extension for NHRP with exactly those end to end only semantics 💜

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 doc is an extension for Mobile NHCs that want to register with their home LIS but first connect to a non-serving NHS to do it 🧚 the reader is encouraged to check out [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 rides along in NHRP Registration packets to carry end to end authentication Information 🫶 it's different from the NHRP Authentication Extension in [1], which has hop by hop semantics 🔄

you use this new extension when a mobile NHC first connects to an NHS that isn't one of its serving NHSs, and the mobile NHC and that non-serving NHS aren't in a security relationship 🙈 the mobile NHC does this so it can send an NHRP Registration Request, through normal routing and forwarding, to one of its serving NHSs, which it does have a security relationship with 🔐 as [1] defines it, a serving NHS is an NHS in the NHC's home LIS that the NHC will register with 👑 when that serving NHS gets the Registration Request, it does three things: it authenticates the sender NHC, sets up a VC to the NHC, and then sends an NHRP Resolution Reply back on that new VC 🦋

heads up, [1] says a transit NHS (like the one the mobile NHC first connects to) must ignore an extension it doesn't understand, and an NHS must not change the order of extensions in an NHRP packet 🧠 so the end to end semantics of this extension survive without messing with existing implementations ✨

if a serving NHS gets a packet that fails the hop by hop authentication test from [1], then the NHS MUST generate an Error Indication of type Authentication Failure and discard the packet 🚫 BUT when the NHRP Mobile NHC Authentication Extension is used like we just described, sending an Error Indication isn't possible 😭 there's no route back toward the mobile NHC, assuming no VC already exists between the mobile NHC and the serving NHS that got the Registration Request 💀 in that case the Registration Request is just dropped 🥀

2.1 Header Format 🍓

the authentication header looks like this 👇

   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... -+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

the Security Parameter Index (SPI) is basically an index into a table that holds the keys and other info, like a hash algorithm 🗂️ Src and Dst either talk offline using manual keying, or online using a key management protocol, to fill that table up 🔑 the sending NHRP entity is always the one that allocates the SPI and the parameters tied to it 💅

the Src Addr field is variable length 📏 it holds the address assigned to the outgoing interface 🌐 its length comes 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 used in authentication 🔐

the length of the authentication data field depends on the hash algorithm in use 🧮 the Authentication Data field holds the keyed hash calculated over these fields: the fixed part (with hop count, packet size and checksum treated as if they were set to zero), the mandatory part, and extensions up to and including the Mobile NHC Authentication extension 🫶

ok this part is so important 🥹 [1] defines an explicit ordering of extensions, like this:

  • (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.

2.2 SPI and Security Parameters Negotiation 🔑

SPI's can be negotiated manually or with an Internet Key Management protocol 🤝 Manual keying MUST be supported, no exceptions 💖 the following parameters are tied to the tuple <SPI, src>: lifetime, Algorithm, and Key 🗝️ Lifetime is how many seconds the key stays valid 🕰️ with manual keying that duration can be infinite ♾️ also, to support manual keying better, there can be multiple tuples active at the same time (Dst being the same) 🌸

Algorithm is the hash algorithm the two entities agreed on 🧁 HMAC-MD5-128 [2] is the default and MUST be implemented 💜 other algorithms MAY be supported by defining new values 🦄 IANA assigns the numbers that 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 goes like this, per [1] 🗺️

  • the NHC puts the internetwork address of a serving NHS in the Destination Protocol Address field; if the NHS address is unknown, then the NHC puts in 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 that gets the NHRP Registration Request sets up a direct VCC to the NHC after authenticating the request 🔐
  • the serving NHS then sends the NHRP Registration Reply back to the NHC on that new VCC. the NHS MUST wait some configured interval before doing this reply, so no race condition happens between the VC setup and sending the NHRP reply packet ⏳
  • the NHC then sends all NHRP traffic to the serving NHS on the direct VCC 🚀

when the NHC adds the authentication extension header, it does a table look up to fetch the SPI and the security parameters based on the outgoing interface address 🔍 if there are no entries in the table and key management is supported, the NHC kicks off the key management protocol to fetch the parameters it needs 🔑 the NHC builds the Authentication Extension payload and calculates the hash by zeroing out the authentication data field 🧮 the result goes in the authentication data field 💅 the src address field in the payload is the internetwork address assigned to the outgoing interface 🌐

if key management isn't supported and authentication is mandatory, the packet gets dropped and that's 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 gets extracted before it's zeroed out so the hash can be calculated 🧠 it computes the hash over the entire payload, and if the hash doesn't match, an "abnormal event" has occurred 🚨

the keys a mobile NHC uses to talk to the serving NHS in NHRP Registration Requests can be reused in later resolution and purge requests sent directly to the serving NHS after it gets the NHRP Registration Reply 🔁 but 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 together to protect 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 needing Hop by Hop authentication to be present 🚧 that kind of requirement is a local matter 🏠

2.4 Security Considerations 🔐

Okay, bestie, this one is serious. The keys you pick have to be strong, because the security of the whole system depends on choosing them properly. Weak keys and the whole thing falls apart 💀

End-to-end authentication 🛡️ shuts down spoofing attacks on the home subnet, and it does that by not leaning on the chain of trust, which could already be compromised. More on end-to-end authentication is in [3]. ✨

Hop-by-hop authentication 🚪 stops denial of service attacks by putting access control at the very first point of contact with the NHRP infrastructure. Bouncer energy 💅

Security for this extension works on an end-to-end basis 🔗. Data can only be trusted as much as you trust the endpoint entities along the path it traveled. A chain of trust gets set up among the NHRP entities on the path of the NHRP Message, and if security in one NHRP entity gets compromised, security in the entire NHRP domain is compromised too. One weak link and the whole group chat gets leaked 😭

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 weren't modified, and that the source is authenticated too. But if the authentication extension isn't used, or the security is compromised, NHRP entities are open to spoofing attacks, active attacks, and passive attacks. Not me being exposed like that 🙈

There is no mechanism to encrypt the messages 🫣. The assumption is 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. And if you negotiate keys some other way and send them in clear text, the security is completely compromised. Please don't do that, periodt 🚫🔑

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.

Authors' Addresses 🫶

Here are the squad members who made this happen 💖

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

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. 🌈

📦 where this page comes from