idnits 2.17.1 draft-ietf-ion-nhrp-mobile-nhc-00.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-24) 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 118 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. -- 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 (August 1998) is 9384 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '2') ** Obsolete normative reference: RFC 2002 (ref. '3') (Obsoleted by RFC 3220) Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 3 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 (Bay Networks) 4 Hiroshi Suzuki 5 (NEC Corporation) 6 Naganand Doraswamy 7 (Bay Networks) 8 David Horton 9 (CiTR Pty Ltd) 11 Expires August 1998 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 months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 29 Directories on ds.internic.net (US East Coast), nic.nordu.net 30 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 31 Rim). 33 Abstract 35 This document describes an extension for Mobile NHCs to use when they 36 register with their home LIS but initially connect to a non-serving 37 NHS to do so. 39 1. Introduction 41 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 42 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 43 document, are to be interpreted as described in [4]. 45 This document describes an extension for Mobile NHCs to use when they 46 wish to register with their home LIS but initially connect to a non- 47 serving NHS to do so. The reader is encouraged to read [1] for more 48 details on the NHRP registration process. 50 2.0 Definition of the NHRP Mobile NHC Authentication Extension 52 Compulsory = 1 53 Type = 10 (proposed) 54 Length = variable 56 The NHRP Mobile NHC Authentication Extension is carried in NHRP 57 Registration packets to convey end to end authentication Information. 58 This extension is used when a mobile NHC initially connects to an NHS 59 which is not one of its serving NHSs and the mobile NHC and non- 60 serving NHS are not in a security relationship. The mobile NHC does 61 this in order to send an NHRP Registration Request, via normal 62 routing and forwarding processes, to one of its serving NHSs with 63 which it does have a security relationship. As defined in [1], a 64 serving NHS is an NHS in the NHC's home LIS with which the NHC will 65 register. Upon receiving such an NHRP Registration Request, the 66 serving NHS will do the following: authenticate the sender NHC, set 67 up a VC to the NHC, and then send an NHRP Resolution Reply in 68 response on that new VC. 70 Note that a transit NHS (such as the one to which the mobile NHC 71 initially connects) MUST ignore an extension which it does not 72 understand and that an NHS MUST not change the order of extensions in 73 an NHRP packet. Thus, the end to end semantics of this extension are 74 preserved without causing changes to existing implementations. 76 If a serving NHS receives a packet which fails the hop by hop 77 authentication test defined in [1] then the NHS MUST generate an 78 Error Indication of type "Authentication Failure" and discard the 79 packet. However in the case where the NHRP Mobile NHC Authentication 80 Extension is used as described above, sending an Error Indication is 81 not possible since no route exists back toward the mobile NHC 82 assuming a VC does not already exist between the mobile NHC and the 83 serving NHS which received the NHRP Registration Request. In this 84 case, the NHRP Registration Request is merely dropped. 86 2.1 Header Format 88 The authentication header has the following format: 90 0 1 2 3 91 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 92 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 93 | Reserved | Security Parameter Index (SPI)| 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 | Src Addr... | 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | | 98 +-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+ 99 | | 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 Security Parameter Index (SPI) can be thought of as an index into a 103 table that maintains the keys and other information such as a hash 104 algorithm. Src and Dst communicate either offline using manual keying 105 or online using a key management protocol to populate this table. The 106 sending NHRP entity always allocates the SPI and the parameters 107 associated with it. 109 The Src Addr field is a variable length field which contains the 110 address assigned to the outgoing interface. The length of the field 111 is obtained from the source protocol length field in the mandatory 112 part of the NHRP header. The tuple uniquely 113 identifies the key and the other parameters that are used in 114 authentication. 116 The length of the authentication data field is dependent on the hash 117 algorithm used. The Authentication Data field contains the keyed hash 118 calculated over the following fields: fixed part (with hop count, 119 packet size and checksum being treated as if set to zero), mandatory 120 part, and extensions up to and including the Mobile NHC 121 Authentication extension. 123 Note that there is an explicit ordering of the extensions such that: 125 (a) If the Responder Address extension exists then it MUST appear 126 before the Authentication Extension. 128 (b) Any extensions that may be modified in transit (e.g., Forward 129 Transit Extension, Hop by Hop Authentication Extension) MUST appear 130 after the Mobile NHC Authentication Extension. 132 Calculation of the hash for this extension should allow intervening 133 vendor private extensions. This is in line with the mechanisms 134 described in RFC2002 [3]. An example of such an extension would be a 135 timestamp extension which would counter replay attacks. The RFC2002 136 authentication extensions include a timestamp. Other examples could 137 include new NHRP or MPOA extensions defined at a future date. 139 2.2 SPI and Security Parameters Negotiation 141 SPI's can be negotiated either manually or using an Internet Key 142 Management protocol. Manual keying MUST be supported. The following 143 parameters are associated with the tuple - lifetime, 144 Algorithm, Key. Lifetime indicates the duration in seconds for which 145 the key is valid. In case of manual keying, this duration can be 146 infinite. Also, in order to better support manual keying, there may 147 be multiple tuples active at the same time (Dst being the same). 149 Algorithm specifies the hash algorithm agreed upon by the two 150 entities. HMAC-MD5-128 [2] is the default algorithm. Other algorithms 151 MAY be supported by defining new values. IANA will assign the numbers 152 to identify the algorithm being used as described in [1]. 154 Any Internet standard key management protocol MAY so be used to 155 negotiate the SPI and parameters. 157 2.3 Message Processing 159 Unauthenticated 'Mobile' Registration Request processing proceeds as 160 follows [1]: 161 - the NHC inserts the internetwork address of a serving NHS in 162 the 'Destination Protocol Address' field; If the NHS address 163 is unknown, then the NHC inserts its own internetwork address. 164 A 'responder address' extension is optionally added. 165 - the non-serving NHS forwards the packet along the routed path 166 based on the contents of the 'Destination Protocol Address' field. 167 - the serving NHS which receives the NHRP Registration Request will 168 set up a direct VCC to NHC after authenticating the request 169 - the serving NHS will then send the NHRP Registration Reply 170 back to the NHC on that new VCC. Note that the NHS MUST wait some 171 configured interval before doing this reply in order to prevent a 172 race condition from occuring between the VC setup and sending the 173 NHRP reply packet. 174 - the NHC will subsequently send all NHRP traffic to the serving NHS on 175 the direct VCC. 177 When the NHC adds the authentication extension header, it performs a 178 table looks up in order to fetch the SPI and the security parameters 179 based on the outgoing interface address. If there are no entries in 180 the table and if there is support for key management, the NHC 181 initiates the key management protocol to fetch the necessary 182 parameters. The NHC constructs the Authentication Extension payload 183 and calculates the hash by zeroing out the authentication data field. 185 The result is placed in the authentication data field. The src 186 address field in the payload is the internetwork address assigned to 187 the outgoing interface. 189 If key management is not supported and authentication is mandatory, 190 the packet is dropped and this information is logged. 192 On the receiving end, the serving NHS fetches the parameters based on 193 the SPI and the internetwork address in the authentication extension 194 payload. The authentication data field is extracted before being 195 zeroed out in order to calculate the hash. It computes the hash on 196 the entire payload and if the hash does not match, then an "abnormal 197 event" has occurred. 199 The keys used by the mobile NHC for communicating with the serving 200 NHS in NHRP Registration Requests can be used in subsequent 201 resolution and purge requests made directly to the serving NHS after 202 receiving the NHRP Registration Reply. However, the authentication 203 extension defined in [1] MUST be used when these keys are applied to 204 resolution and purge packets. 206 Hop by Hop Authentication[1] and End to End authentication may be 207 used in combination to provide protection against both spoofing and 208 denial of service attacks. If only an end-to-end Mobile NHC 209 Authentication Extension is present, it MAY be the policy of each 210 transit NHS to reject the NHRP Registration Request based on the 211 requirement for having a Hop by Hop authentication present. Such a 212 requirement is a local matter. 214 2.4 Security Considerations 216 It is important that the keys chosen are strong since the security of 217 the entire system depends on the keys being chosen properly. 219 End-to-end authentication counters spoofing attacks on the home 220 subnet through not relying on the potentially compromised chain of 221 trust. The use of end-end authentication is further described in [3]. 223 Hop-by-hop authentication prevents denial of service attacks by 224 introducing access control at the first point of contact to the NHRP 225 infrastructure. 227 The security of this extension is performed on an end to end basis. 228 The data received can be trusted only so much as one trusts the end 229 point entities in the path traversed. A chain of trust is established 230 amongst NHRP entities in the path of the NHRP Message . If the 231 security in an NHRP entity is compromised, then security in the 232 entire NHRP domain is compromised. 234 Data integrity covers the entire NHRP payload up to and including the 235 Mobile NHC Authentication Extension. This guarantees that the data 236 and extensions covered by this authentication hash were not modified 237 and that the source is authenticated as well. If the authentication 238 extension is not used or if the security is compromised, then NHRP 239 entities are liable to both spoofing attacks, active attacks, and 240 passive attacks. 242 There is no mechanism to encrypt the messages. It is assumed that a 243 standard layer 3 confidentiality mechanism will be used to encrypt 244 and decrypt messages. It is recommended to use an Internet standard 245 key management protocol to negotiate the keys between the neighbors. 246 Transmitting the keys in clear text, if other methods of negotiation 247 is used, compromises the security completely. 249 References 250 [1] "NBMA Next Hop Resolution Protocol (NHRP)", Luciani, Katz, Piscitello, 251 Cole, Doraswamy, RFC TBD. 253 [2] "HMAC: Keyed Hashing for Message Authentication", Krawczyk, Bellare, 254 Canetti, RFC 2104. 256 [3] "IP Mobility Support", C.Perkins, RFC 2002. 258 [4] Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, 259 RFC 2119. 261 Authors' Addresses 262 James V. Luciani 263 Bay Networks 264 3 Federal Street 265 Mail Stop: BL3-03 266 Billerica, MA 01821 267 Phone: +1 978 916 4734 268 Email: luciani@baynetworks.com 270 Hiroshi Suzuki 271 NEC Corporation 272 4-1-1 Miyasaki Miyamae 273 Kawasaki, 216 Japan 274 Phone: +011 81 44 856 2123 275 Email: hiroshi@nwk.cl.nec.co.jp 277 Naganand Doraswamy 278 Bay Networks 279 3 Federal Street 280 Mail Stop: BL3-03 281 Billerica, MA 01821 282 Phone: +1 978 916 4734 283 Email: naganand@baynetworks.com 285 David Horton 286 CiTR PTY Ltd 287 Level 2 South Tower 288 339 Coronation Drive 289 Milton, Australia 4064 290 Phone: +011 61 7 32592222 291 Email: d.horton@citr.com.au