idnits 2.17.1 draft-ietf-ion-nhrp-mobile-nhc-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 8 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 35 has weird spacing: '...tration with ...' == Line 137 has weird spacing: '...: fixed part ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1999) is 9052 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '2') ** Obsolete normative reference: RFC 2002 (ref. '3') (Obsoleted by RFC 3220) Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internetworking Over NBMA James V. Luciani 3 INTERNET-DRAFT (Nortel Networks) 4 Hiroshi Suzuki 5 (Cisco Systems) 6 Naganand Doraswamy 7 (Nortel Networks) 8 David Horton 9 (CiTR Pty Ltd) 11 Expires July 1999 13 NHRP with Mobile NHCs 15 Status of this Memo 17 This document is an Internet Draft. Internet Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its Areas, 19 and its Working Groups. Note that other groups may also distribute 20 working documents as Internet Drafts. 22 Internet Drafts are draft documents valid for a maximum of six 23 months. Internet Drafts may be updated, replaced, or obsoleted by 24 other documents at any time. It is not appropriate to use Internet 25 Drafts as reference material or to cite them other than as a "working 26 draft" or "work in progress". 28 Please check the I-D abstract listing contained in each Internet 29 Draft directory to learn the current status of this or any other 30 Internet Draft. 32 Abstract 34 This document describes an extension to NHRP [1] which would allow 35 Mobile NHCs to perform a registration with and attach to an NHS in 36 their home LIS in an authenticated manner. 38 As described in this document, Mobile NHCs are NHCs which are not 39 configured with enough information to find a specific serving NHS in 40 their home LIS, but which have a mechanism to find an NHS (which may 41 or may not be a serving NHS) to which they will attach. As described 42 in [1], an NHC may attach to a 'surrogate' NHS by using a mechanism 43 such as an anycast address. In this case, the NHC may use the 44 surrogate NHS to send a NHRP Registration Request toward the NHC's 45 home LIS where a serving NHS resides. However, as defined in [1], 46 packet authentication is performed on a hop by hop basis. In the 47 mobile NHC case, it is not practical for the mobile NHC be in a 48 security relationship with every surrogate NHS, thus it is presumably 49 desirable to have some form of end to end only authentication for the 50 case of a mobile NHC's registration. This document describes an 51 authentication extension for NHRP which has such end to end only 52 semantics. 54 1. Introduction 56 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 57 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 58 document, are to be interpreted as described in [4]. 60 This document describes an extension for Mobile NHCs to use when they 61 wish to register with their home LIS but initially connect to a non- 62 serving NHS to do so. The reader is encouraged to read [1] for more 63 details on the NHRP registration process. 65 2.0 Definition of the NHRP Mobile NHC Authentication Extension 67 Compulsory = 1 68 Type = 10 (proposed) 69 Length = variable 71 The NHRP Mobile NHC Authentication Extension is carried in NHRP 72 Registration packets to convey end to end authentication Information. 73 This extension is defined in contrast to the NHRP Authentication 74 Extension defined in [1] which has hop by hop semantics. 76 This new extension is used when a mobile NHC initially connects to an 77 NHS which is not one of its serving NHSs and the mobile NHC and non- 78 serving NHS are not in a security relationship. The mobile NHC does 79 this in order to send an NHRP Registration Request, via normal 80 routing and forwarding processes, to one of its serving NHSs with 81 which it does have a security relationship. As defined in [1], a 82 serving NHS is an NHS in the NHC's home LIS with which the NHC will 83 register. Upon receiving such an NHRP Registration Request, the 84 serving NHS will do the following: authenticate the sender NHC, set 85 up a VC to the NHC, and then send an NHRP Resolution Reply in 86 response on that new VC. 88 Note that, as defined in [1], a transit NHS (such as the one to which 89 the mobile NHC initially connects) must ignore an extension which it 90 does not understand and that an NHS must not change the order of 91 extensions in an NHRP packet. Thus, the end to end semantics of this 92 extension are preserved without causing changes to existing 93 implementations. 95 If a serving NHS receives a packet which fails the hop by hop 96 authentication test defined in [1] then the NHS MUST generate an 97 Error Indication of type 'Authentication Failure' and discard the 98 packet. However in the case where the NHRP Mobile NHC Authentication 99 Extension is used as described above, sending an Error Indication is 100 not possible since no route exists back toward the mobile NHC 101 assuming a VC does not already exist between the mobile NHC and the 102 serving NHS which received the NHRP Registration Request. In this 103 case, the NHRP Registration Request is merely dropped. 105 2.1 Header Format 107 The authentication header has the following format: 109 0 1 2 3 110 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 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Reserved | Security Parameter Index (SPI)| 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | Src Addr... | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | | 117 +-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+ 118 | | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 Security Parameter Index (SPI) can be thought of as an index into a 122 table that maintains the keys and other information such as a hash 123 algorithm. Src and Dst communicate either offline using manual keying 124 or online using a key management protocol to populate this table. The 125 sending NHRP entity always allocates the SPI and the parameters 126 associated with it. 128 The Src Addr field is a variable length field which contains the 129 address assigned to the outgoing interface. The length of the field 130 is obtained from the source protocol length field in the mandatory 131 part of the NHRP header. The tuple uniquely 132 identifies the key and the other parameters that are used in 133 authentication. 135 The length of the authentication data field is dependent on the hash 136 algorithm used. The Authentication Data field contains the keyed hash 137 calculated over the following fields: fixed part (with hop count, 138 packet size and checksum being treated as if set to zero), mandatory 139 part, and extensions up to and including the Mobile NHC 140 Authentication extension. 142 Note that [1] defines an explicit ordering of extensions such that: 144 (a) If the Responder Address extension exists then it must appear 145 before the Authentication Extension. 147 (b) Any extensions that may be modified in transit (e.g., Forward 148 Transit Extension, Hop by Hop Authentication Extension) must appear 149 after the Mobile NHC Authentication Extension. 151 2.2 SPI and Security Parameters Negotiation 153 SPI's can be negotiated either manually or using an Internet Key 154 Management protocol. Manual keying MUST be supported. The following 155 parameters are associated with the tuple - lifetime, 156 Algorithm, Key. Lifetime indicates the duration in seconds for which 157 the key is valid. In case of manual keying, this duration can be 158 infinite. Also, in order to better support manual keying, there may 159 be multiple tuples active at the same time (Dst being the same). 161 Algorithm specifies the hash algorithm agreed upon by the two 162 entities. HMAC-MD5-128 [2] is the default algorithm and MUST be 163 implemented. Other algorithms MAY be supported by defining new 164 values. IANA will assign the numbers to identify the algorithm being 165 used as described in [1]. 167 Any Internet standard key management protocol MAY so be used to 168 negotiate the SPI and parameters. 170 2.3 Message Processing 172 Unauthenticated 'Mobile' Registration Request processing proceeds as 173 follows [1]: 174 - the NHC inserts the internetwork address of a serving NHS in 175 the 'Destination Protocol Address' field; If the NHS address 176 is unknown, then the NHC inserts its own internetwork address. 177 A 'responder address' extension is optionally added. 178 - the non-serving NHS forwards the packet along the routed path 179 based on the contents of the 'Destination Protocol Address' field. 180 - the serving NHS which receives the NHRP Registration Request will 181 set up a direct VCC to NHC after authenticating the request 182 - the serving NHS will then send the NHRP Registration Reply 183 back to the NHC on that new VCC. Note that the NHS MUST wait some 184 configured interval before doing this reply in order to prevent a 185 race condition from occurring between the VC setup and sending the 186 NHRP reply packet. 187 - the NHC will subsequently send all NHRP traffic to the serving NHS on 188 the direct VCC. 190 When the NHC adds the authentication extension header, it performs a 191 table looks up in order to fetch the SPI and the security parameters 192 based on the outgoing interface address. If there are no entries in 193 the table and if there is support for key management, the NHC 194 initiates the key management protocol to fetch the necessary 195 parameters. The NHC constructs the Authentication Extension payload 196 and calculates the hash by zeroing out the authentication data field. 197 The result is placed in the authentication data field. The src 198 address field in the payload is the internetwork address assigned to 199 the outgoing interface. 201 If key management is not supported and authentication is mandatory, 202 the packet is dropped and this information is logged. 204 On the receiving end, the serving NHS fetches the parameters based on 205 the SPI and the internetwork address in the authentication extension 206 payload. The authentication data field is extracted before being 207 zeroed out in order to calculate the hash. It computes the hash on 208 the entire payload and if the hash does not match, then an "abnormal 209 event" has occurred. 211 The keys used by the mobile NHC for communicating with the serving 212 NHS in NHRP Registration Requests can be used in subsequent 213 resolution and purge requests made directly to the serving NHS after 214 receiving the NHRP Registration Reply. However, the authentication 215 extension defined in [1] MUST be used when these keys are applied to 216 resolution and purge packets. 218 Hop by Hop Authentication[1] and End to End authentication MAY be 219 used in combination to provide protection against both spoofing and 220 denial of service attacks. If only an end-to-end Mobile NHC 221 Authentication Extension is present, it MAY be the policy of each 222 transit NHS to reject the NHRP Registration Request based on the 223 requirement for having a Hop by Hop authentication present. Such a 224 requirement is a local matter. 226 2.4 Security Considerations 228 It is important that the keys chosen are strong since the security of 229 the entire system depends on the keys being chosen properly. 231 End-to-end authentication counters spoofing attacks on the home 232 subnet through not relying on the potentially compromised chain of 233 trust. The use of end-end authentication is further described in [3]. 235 Hop-by-hop authentication prevents denial of service attacks by 236 introducing access control at the first point of contact to the NHRP 237 infrastructure. 239 The security of this extension is performed on an end to end basis. 240 The data received can be trusted only so much as one trusts the end 241 point entities in the path traversed. A chain of trust is established 242 amongst NHRP entities in the path of the NHRP Message . If the 243 security in an NHRP entity is compromised, then security in the 244 entire NHRP domain is compromised. 246 Data integrity covers the entire NHRP payload up to and including the 247 Mobile NHC Authentication Extension. This guarantees that the data 248 and extensions covered by this authentication hash were not modified 249 and that the source is authenticated as well. If the authentication 250 extension is not used or if the security is compromised, then NHRP 251 entities are liable to both spoofing attacks, active attacks, and 252 passive attacks. 254 There is no mechanism to encrypt the messages. It is assumed that a 255 standard layer 3 confidentiality mechanism will be used to encrypt 256 and decrypt messages. It is recommended to use an Internet standard 257 key management protocol to negotiate the keys between the neighbors. 258 Transmitting the keys in clear text, if other methods of negotiation 259 is used, compromises the security completely. 261 References 262 [1] "NBMA Next Hop Resolution Protocol (NHRP)", Luciani, Katz, Piscitello, 263 Cole, Doraswamy, RFC2332. 265 [2] "HMAC: Keyed Hashing for Message Authentication", Krawczyk, Bellare, 266 Canetti, RFC 2104. 268 [3] "IP Mobility Support", C.Perkins, RFC 2002. 270 [4] Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, 271 RFC 2119. 273 Authors' Addresses 274 James V. Luciani 275 Nortel Networks 276 3 Federal Street 277 Mail Stop: BL3-03 278 Billerica, MA 01821 279 Phone: +1 978 916 4734 280 Email: luciani@baynetworks.com 282 Hiroshi Suzuki 283 Cisco Systems 284 170 West Tasman Dr. 285 San Jose, CA 96134 286 Phone: +1 408 525 6006 287 Email: hsuzuki@cisco.com 289 Naganand Doraswamy 290 Nortel Networks 291 3 Federal Street 292 Mail Stop: BL3-03 293 Billerica, MA 01821 294 Phone: +1 978 916 4734 295 Email: naganand@baynetworks.com 297 David Horton 298 CiTR PTY Ltd 299 Level 2 South Tower 300 339 Coronation Drive 301 Milton, Australia 4064 302 Phone: +011 61 7 32592222 303 Email: d.horton@citr.com.au