Internetworking Over NBMA James V. Luciani INTERNET-DRAFT (Bay Networks) Hiroshi Suzuki (NEC Corporation) Naganand Doraswamy (Bay Networks) David Horton (CiTR Pty Ltd) Expires August 1998 NHRP with Mobile NHCs Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract This document describes an extension for Mobile NHCs to use when they register with their home LIS but initially connect to a non-serving NHS to do so. 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]. Luciani, et al. [Page 1] INTERNET-DRAFT NBMA NHRP Expires August 1998 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 used when a mobile NHC initially connects to an NHS which is not one of its serving NHSs and the mobile NHC and non- serving 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 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 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: Luciani, et al. [Page 2] INTERNET-DRAFT NBMA NHRP Expires August 1998 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 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 there is an explicit ordering of the 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. Calculation of the hash for this extension should allow intervening vendor private extensions. This is in line with the mechanisms described in RFC2002 [3]. An example of such an extension would be a timestamp extension which would counter replay attacks. The RFC2002 authentication extensions include a timestamp. Other examples could include new NHRP or MPOA extensions defined at a future date. Luciani, et al. [Page 3] INTERNET-DRAFT NBMA NHRP Expires August 1998 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 - 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. 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 occuring 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. When the NHC adds the authentication extension header, it performs a table looks 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. Luciani, et al. [Page 4] INTERNET-DRAFT NBMA NHRP Expires August 1998 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. 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 Luciani, et al. [Page 5] INTERNET-DRAFT NBMA NHRP Expires August 1998 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] "NBMA Next Hop Resolution Protocol (NHRP)", Luciani, Katz, Piscitello, Cole, Doraswamy, RFC TBD. [2] "HMAC: Keyed Hashing for Message Authentication", Krawczyk, Bellare, Canetti, RFC 2104. [3] "IP Mobility Support", C.Perkins, RFC 2002. [4] Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, RFC 2119. Authors' Addresses Luciani, et al. [Page 6] INTERNET-DRAFT NBMA NHRP Expires August 1998 James V. Luciani Bay Networks 3 Federal Street Mail Stop: BL3-03 Billerica, MA 01821 Phone: +1 978 916 4734 Email: luciani@baynetworks.com Hiroshi Suzuki NEC Corporation 4-1-1 Miyasaki Miyamae Kawasaki, 216 Japan Phone: +011 81 44 856 2123 Email: hiroshi@nwk.cl.nec.co.jp Naganand Doraswamy Bay 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 South Tower 339 Coronation Drive Milton, Australia 4064 Phone: +011 61 7 32592222 Email: d.horton@citr.com.au Luciani, et al. [Page 7]