idnits 2.17.00 (12 Aug 2021) /tmp/idnits47680/draft-ietf-6lo-ap-nd-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6775, but the abstract doesn't seem to directly say this. It does mention RFC6775 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 21, 2017) is 1703 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) == Outdated reference: draft-ietf-6lo-rfc6775-update has been published as RFC 8505 == Outdated reference: draft-ietf-6lo-backbone-router has been published as RFC 8929 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo B. Sarikaya 3 Internet-Draft 4 Updates: 6775 (if approved) P. Thubert 5 Intended status: Standards Track Cisco 6 Expires: March 25, 2018 M. Sethi 7 Ericsson 8 September 21, 2017 10 Address Protected Neighbor Discovery for Low-power and Lossy Networks 11 draft-ietf-6lo-ap-nd-03 13 Abstract 15 This document defines an extension to 6LoWPAN Neighbor Discovery RFC 16 6775. Nodes supporting this extension compute a cryptographic Owner 17 Unique Interface ID and associate it with one or more of their 18 Registered Addresses. Once an address is registered with a 19 Cryptographic ID, only the owner of that ID can modify the anchor 20 state information of the Registered Address, and Source Address 21 Validation can be enforced. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 25, 2018. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Updating RFC 6775 . . . . . . . . . . . . . . . . . . . . . . 4 60 4. New Fields and Options . . . . . . . . . . . . . . . . . . . 5 61 4.1. New Crypto-ID . . . . . . . . . . . . . . . . . . . . . . 5 62 4.2. Updated EARO . . . . . . . . . . . . . . . . . . . . . . 6 63 4.3. New Crypto-ID Parameters Option . . . . . . . . . . . . . 7 64 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 65 5.1. Protocol Scope . . . . . . . . . . . . . . . . . . . . . 8 66 5.2. Protocol Flows . . . . . . . . . . . . . . . . . . . . . 9 67 5.3. Multihop Operation . . . . . . . . . . . . . . . . . . . 11 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 70 7.1. Crypto Type Registry . . . . . . . . . . . . . . . . . . 13 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 72 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 75 10.2. Informative references . . . . . . . . . . . . . . . . . 14 76 Appendix A. Requirements Addressed in this Document . . . . . . 16 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 79 1. Introduction 81 "Neighbor Discovery Optimizations for 6LoWPAN networks" [RFC6775] 82 (6LoWPAN ND) adapts the classical IPv6 ND protocol [RFC4861][RFC4862] 83 (IPv6 ND) for operations over a constrained low-power and lossy 84 network (LLN). In particular, 6LoWPAN ND introduces a unicast host 85 address registration mechanism that contributes to reduce the use of 86 multicast messages that are present in the classical IPv6 ND 87 protocol. 6LoWPAN ND defines a new Address Registration Option (ARO) 88 that is carried in the unicast Neighbor Solicitation (NS) and 89 Neighbor Advertisement (NA) messages between the 6LoWPAN Node (6LN) 90 and the 6LoWPAN Router (6LR). Additionally, it also defines the 91 Duplicate Address Request (DAR) and Duplicate Address Confirmation 92 (DAC) messages between the 6LR and the 6LoWPAN Border Router (6LBR). 93 In LLN networks, the 6LBR is the central repository of all the 94 registered addresses in its domain. 96 The registration mechanism in 6LoWPAN ND [RFC6775] prevents the use 97 of an address if that address is already present in the subnet (first 98 come first serve). In order to validate address ownership, the 99 registration mechanism enables the 6LR and 6LBR to validate claims 100 for a registered address with an associated Owner Unique Interface 101 IDentifier (OUID). 6LoWPAN ND specifies that the OUID is derived from 102 the MAC address of the device (EUI-64), which can be spoofed. 103 Therefore, any node connected to the subnet and aware of a 104 registered-address-to-OUID mapping could effectively fake the OUID, 105 steal the address and redirect traffic for that address towards a 106 different 6LN. The "Update to 6LoWPAN ND" 107 [I-D.ietf-6lo-rfc6775-update] defines an Extended ARO (EARO) option 108 that allows to transport alternate forms of OUIDs, and is a 109 prerequisite for this specification. 111 According to this specification, a 6LN generates a cryptographic ID 112 (Crypto-ID) and places it in the OUID field in the registration of 113 one (or more) of its addresses with the 6LR(s) that the 6LN uses as 114 default router(s). Proof of ownership of the cryptographic ID 115 (Crypto-ID) is passed with the first registration to a given 6LR, and 116 enforced at the 6LR, in a new Crypto-ID Parameters Option (CIPO). 117 The 6LR validates ownership of the cryptographic ID upon the creation 118 of a registration state, or a change in the anchor information, such 119 as Link-Layer Address and associated Layer-2 cryptographic material. 121 The protected address registration protocol proposed in this document 122 enables the enforcement of Source Address Validation (SAVI) 123 [RFC7039], which ensures that only the correct owner uses a 124 registered address in the source address field in IPv6 packets. 125 Consequently, a 6LN that sources a packet has to use a 6LR to which 126 the source address of the packet is registered to forward the packet. 127 The 6LR maintains state information for the registered addressed, 128 including the MAC address, and a link-layer cryptographic key 129 associated with the 6LN. In SAVI-enforcement mode, the 6LR allows 130 only packets from a connected Host if the connected Host owns the 131 registration of the source address of the packet. 133 The 6lo adaptation layer framework ([RFC4944], [RFC6282]) expects 134 that a device forms its IPv6 addresses based on Layer-2 address, so 135 as to enable a better compression. This is incompatible with "Secure 136 Neighbor Discovery (SEND)" [RFC3971] and "Cryptographically Generated 137 Addresses (CGAs)" [RFC3972], which derive the Interface ID (IID) in 138 the IPv6 addresses from cryptographic material. "Privacy 139 Considerations for IPv6 Address Generation Mechanisms" [RFC7721] 140 places additional recommendations on the way addresses should be 141 formed and renewed. 143 This document specifies that a device may form and register addresses 144 at will, without a constraint on the way the address is formed or the 145 number of addresses that are registered in parallel. It enables to 146 protect multiple addresses with a single cryptographic material and 147 to send the proof only once to a given 6LR for multiple addresses and 148 refresher registrations. 150 2. Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [RFC2119]. 156 Readers are expected to be familiar with all the terms and concepts 157 that are discussed in [RFC3971], [RFC3972], [RFC4861], [RFC4919], 158 [RFC6775], and [I-D.ietf-6lo-backbone-router] which proposes an 159 evolution of [RFC6775] for wider applicability. 161 This document defines Crypto-ID as an identifier of variable size 162 which in most cases is 64 bits long. It is generated using 163 cryptographic means explained later in this document Section 4.1. 165 The document also conforms to the terms and models described in 166 [RFC5889] and uses the vocabulary and the concepts defined in 167 [RFC4291] for the IPv6 Architecture. Finally, common terminology 168 related to Low power And Lossy Networks (LLN) defined in [RFC7102] is 169 also used. 171 3. Updating RFC 6775 173 This specification defines a cryptographic identifier (Crypto-ID) 174 that can be used as a replacement to the MAC address in the OUID 175 field of the EARO option; the computation of the Crypto-ID is 176 detailed in Section 4.1. A node in possession of the necessary 177 cryptographic material SHOULD use Crypto-ID by default as OUID in its 178 registration. Whether a OUID is a Crypto-ID is indicated by a new 179 "C" flag in the NS(EARO) message. 181 This specification introduces a new option, the CIPO, that is used to 182 prove ownership of the Crypto-ID. A node that registers for the 183 first time to a 6LR SHOULD place a CIPO option in its registration. 184 However, it is not expected to place the option in the periodic 185 refresher registrations for that address, or to register other 186 addresses with the same OUID. When a 6LR receives a NS(EARO) 187 registration with a new Crypto-ID as a OUID, it SHOULD challenge by 188 responding with a NA(EARO) with a status of "Validation Requested". 189 This process of validation MAY be skipped in networks where there is 190 no mobility. 192 The challenge MUST also be triggered in the case of a registration 193 for which the Source Link-Layer Address is not consistent with a 194 state that already exists either at the 6LR or the 6LBR. In the 195 latter case, the 6LBR returns a status of "Validation Requested" in 196 the DAR/DAC exchange, which is echoed by the 6LR in the NA (EARO) 197 back to the registering node. This flow should not alter a 198 preexisting state in the 6LR or the 6LBR. 200 Upon receiving a NA(EARO) with a status of "Validation Requested", 201 the registering node SHOULD retry its registration with a CIPO option 202 that proves its ownership of the Crypto-ID. 204 If the 6LR cannot validate the CIPO, it responds with a status of 205 "Validation Failed". After receiving a NA(EARO) with a status of 206 "Validation Failed", the registering node MUST NOT use this Crypto-ID 207 for registering with that 6LR. 209 4. New Fields and Options 211 4.1. New Crypto-ID 213 Elliptic Curve Cryptography (ECC) is used to calculate the Crypto-ID. 214 Each 6LN using a Crypto-ID for registration MUST have a public/ 215 private key pair. The digital signature is constructed by using the 216 6LN's private key over its EUI-64 (MAC) address. The signature value 217 is computed using the ECDSA signature algorithm and the hash function 218 used is SHA-256 [RFC6234]. Public Key is the most important 219 parameter in CGA Parameters (sent by 6LN in an NS message). ECC 220 Public Key could be in uncompressed form or in compressed form where 221 the first octet of the OCTET STRING is 0x04 and 0x02 or 0x03, 222 respectively. Point compression can further reduce the key size by 223 about 32 octets. 225 The Crypto-ID is computed as follows: 227 1. the modifier is set to a random or pseudo-random 128-bit value 229 2. the modifier, 9 zero octets and the ECC public key are 230 concatenated from left to right. 232 3. the SHA-256 algorithm is applied on the concatenation 234 4. the 112 leftmost bits of the hash value are retained 236 5. the modifier value, the subnet prefix and the encoded public key 237 are concatenated from left to right 239 6. NIST P-256 is executed on the concatenation 240 7. the leftmost bits of the result are used as the Crypto-ID. 242 With this specification, the last 64 bits are retained, but it could 243 be expanded to more bits in the future by increasing the size of the 244 OUID field. 246 To support cryptographic algorithm agility [RFC7696], Curve25519 247 [RFC7748] can also be used instead of NIST P-256. This is indicated 248 by 6LN using the Crypto Type field in the CIPO option. The document 249 currently only defines two possible values for the Crypto Type field. 250 A value of 0 indicates that NIST P-256 is used for the signature 251 operation and SHA-256 as the hash algorithm. A value of 1 indicates 252 that Curve25519 is used for the signature operation and SHA-256 as 253 the hash algorithm. New values for the Crypto Type maybe defined in 254 the future for new curves. 256 4.2. Updated EARO 258 This specification updates the EARO option as follows: 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Type | Length | Status | Reserved | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Reserved |C|T| TID | Registration Lifetime | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | | 268 + Owner Unique ID (EUI-64 or equivalent) + 269 | | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Figure 1: Enhanced Address Registration Option 274 Type: 33 276 Length: 8-bit unsigned integer. The length of the option 277 (including the type and length fields) in units of 8 278 bytes. 280 Status: 8-bit unsigned integer. Indicates the status of a 281 registration in the NA response. MUST be set to 0 in 282 NS messages. This specification uses values 283 introduced in the update to 6LoWPAN ND 284 [I-D.ietf-6lo-rfc6775-update], such as "Validation 285 Requested" and "Validation Failed". No additional 286 value is defined. 288 Reserved: This field is unused. It MUST be initialized to zero 289 by the sender and MUST be ignored by the receiver. 291 C: This "C" flag is set to indicate that the Owner 292 Unique ID field contains a Crypto-ID. 294 T and TID: Defined in [I-D.ietf-6lo-rfc6775-update]. 296 Owner Unique ID: When the "C" flag is set, this field contains a 297 Crypto-ID. 299 4.3. New Crypto-ID Parameters Option 301 This specification introduces a new option, the Crypto-ID Parameters 302 Option (CIPO), that carries the proof of ownership of a crypto-ID. 304 0 1 2 3 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Type | Length | Pad Length | Crypto Type | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | | 310 + + 311 | | 312 + Modifier (16 octets) + 313 | | 314 + + 315 | | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | | 318 + Subnet Prefix (8 octets) + 319 | | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | | 322 | | 323 + Public Key (variable length) + 324 | | 325 | | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | | 328 . . 329 . Padding . 330 . . 331 | | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 Figure 2: Crypto-ID Parameters Option 336 Type: CIPO, to be assigned by IANA. 338 Length: The length of the option in units of 8 octets. 340 Pad Length: The length of the Padding field. 342 Crypto Type: The type of cryptographic algorithm used in 343 calculation Crypto-ID. Default value of all zeros 344 indicate NIST P-256. A value of 1 is assigned for 345 Curve25519. New values may be defined later. 347 Modifier: 128 bit random value. 349 Subnet Prefix: 64 bit subnet prefix. 351 Public Key: ECC public key of 6LN. 353 Padding: A variable-length field making the option length a 354 multiple of 8, containing as many octets as specified 355 in the Pad Length field. 357 5. Protocol Overview 359 5.1. Protocol Scope 361 The scope of the present work is a 6LoWPAN Low Power Lossy Network 362 (LLN), typically a stub network connected to a larger IP network via 363 a Border Router called a 6LBR per [RFC6775]. 365 The 6LBR maintains a registration state for all devices in the 366 attached LLN, and, in conjunction with the first-hop router (the 367 6LR), is in a position to validate uniqueness and grant ownership of 368 an IPv6 address before it can be used in the LLN. This is a 369 fundamental difference with a classical network that relies on IPv6 370 address auto-configuration [RFC4862], where there is no guarantee of 371 ownership from the network, and any IPv6 Neighbor Discovery packet 372 must be individually secured [RFC3971]. 374 ---+-------- ............ 375 | External Network 376 | 377 +-----+ 378 | | 6LBR 379 +-----+ 380 o o o 381 o o o o 382 o o LLN o o o 383 o o o (6LR) 384 o (6LN) 386 Figure 3: Basic Configuration 388 In a mesh network, the 6LR is directly connected to the host device. 389 This specification expects that the peer-wise layer-2 security is 390 deployed so that all the packets from a particular host are securely 391 identifiable by the 6LR. The 6LR may be multiple hops away from the 392 6LBR. Packets are routed between the 6LR and the 6LBR via other 393 6LRs. This specification expects that a chain of trust is 394 established so that a packet that was validated by the first 6LR can 395 be safely routed by the next 6LRs to the 6LBR. 397 5.2. Protocol Flows 399 Figure 4 illustrates a registration flow all the way to a 6LowPAN 400 Backbone Router (6BBR). 402 A new device that joins the network auto-configures an address and 403 performs an initial registration to an on-link 6LR with an NS message 404 that carries an Address Registration Option (EARO) [RFC6775]. The 405 6LR validates the address with the central 6LBR using a DAR/DAC 406 exchange, and the 6LR confirms (or denies) the address ownership with 407 an NA message that also carries an Address Registration Option. 409 In a multihop 6LoWPAN, the registration with Crypto-ID is propagated 410 to 6LBR as described in Section 5.3. If a chain of trust is present 411 between the 6LR and the 6LBR, then there is no need to propagate the 412 proof of ownership to the 6LBR. All the 6LBR needs to know is that 413 this particular OUID is randomly generated, so as to enforce that any 414 update via a different 6LR is also random. 416 6LN 6LR 6LBR 6BBR 417 | | | | 418 | NS(EARO) | | | 419 |--------------->| | | 420 | | Extended DAR | | 421 | |-------------->| | 422 | | | | 423 | | | proxy NS(EARO) | 424 | | |--------------->| 425 | | | | NS(DAD) 426 | | | | ------> 427 | | | | 428 | | | | 429 | | | | 430 | | | proxy NA(EARO) | 431 | | |<---------------| 432 | | Extended DAC | | 433 | |<--------------| | 434 | NA(EARO) | | | 435 |<---------------| | | 436 | | | | 438 Figure 4: (Re-)Registration Flow 440 On-link (local) protocol interactions are shown in Figure 5. Crypto- 441 ID and ARO are passed to and stored by the 6LR on the first NS and 442 not sent again in the next NS. The operation starts with 6LR sending 443 a Router Advertisement (RA) message to 6LN. 445 The 6LR/6LBR ensures first-come/first-serve by storing the ARO and 446 the Crypto-ID correlated to the node being registered. The node is 447 free to claim any address it likes as long as it is the first to make 448 such a claim. After a successful registration, the node becomes the 449 owner of the registered address and the address is bound to the 450 Crypto-ID in the 6LR/6LBR registry. This binding can be verified 451 later, which prevents other nodes from stealing the address and 452 trying to attract traffic for that address or use it as their source 453 address. 455 A node may use multiple IPv6 addresses at the same time. The node 456 may use the same Crypto-ID to protect multiple IPv6 addresses. The 457 separation of the address and the Crypto-ID avoids the constrained 458 device to compute multiple keys for multiple addresses. The 459 registration process allows the node to bind all of its addresses to 460 the same Crypto-ID. 462 6LN 6LR 463 | | 464 |<------------------- RA --------------------------| 465 | | 466 |----------- NS with ARO and Crypto-ID ----------->| 467 | | 468 |<---------- NA with ARO (status=proof requested) -| 469 | | 470 |----------- NS with ARO and Crypto-ID ----------->| 471 | | 472 |<---------------- NA with ARO --------------------| 473 | | 474 ... ... 475 | | 476 |------------ NS with ARO and Crypto-ID ---------->| 477 | | 478 | | 479 |<---------------- NA with ARO --------------------| 480 ... ... 481 | | 482 |----------- NS with ARO and Crypto-ID ----------->| 483 | | 484 | | 485 |<---------------- NA with ARO --------------------| 487 Figure 5: On-link Protocol Operation 489 5.3. Multihop Operation 491 In a multihop 6LoWPAN, a 6LBR sends RAs with prefixes downstream and 492 the 6LR receives and relays them to the nodes. 6LR and 6LBR 493 communicate using ICMPv6 Duplicate Address Request (DAR) and 494 Duplicate Address Confirmation (DAC) messages. The DAR and DAC use 495 the same message format as NS and NA, but have different ICMPv6 type 496 values. 498 In ND-PAR we extend DAR/DAC messages to carry cryptographically 499 generated OUID. In a multihop 6LoWPAN, the node exchanges the 500 messages shown in Figure 4. The 6LBR must identify who owns an 501 address (EUI-64) to defend it, if there is an attacker on another 502 6LR. Because of this the content that the source signs and the 503 signature needs to be propagated to the 6LBR in the DAR message. For 504 this purpose the DAR message sent by 6LR to 6LBR MUST contain the 505 CIPO option. The DAR message also contains ARO. 507 Occasionally, a 6LR might miss the node's OUID (that it received in 508 ARO). 6LR should be able to ask for it again. This is done by 509 restarting the exchanges shown in Figure 5. The result enables 6LR 510 to refresh the information that was lost. The 6LR MUST send DAR 511 message with ARO to 6LBR. The 6LBR replies with a DAC message with 512 the information copied from the DAR, and the Status field is set to 513 zero. With this exchange, the 6LBR can (re)validate and store the 514 information to make sure that the 6LR is not a fake. 516 In some cases, the 6LBR may use a DAC message to solicit a Crypto-ID 517 from a 6LR and also requests 6LR to verify the EUI-64 6LR received 518 from 6LN. This may happen when a 6LN node is compromised and a fake 519 node is sending the Crypto-ID as if it is the node's EUI-64. Note 520 that the detection in this case can only be done by 6LBR not by 6LR. 522 6. Security Considerations 524 The observations regarding the threats to the local network in 525 [RFC3971] also apply to this specification. 527 The threats discussed in 6LoWPAN ND [RFC6775] and its update 528 [I-D.ietf-6lo-rfc6775-update] also apply here. Compared with SeND, 529 this specification saves about 1Kbyte in every NS/NA message. Also, 530 this specification separates the cryptographic identifier from the 531 registered IPv6 address so that a node can have more than one IPv6 532 address protected by the same cryptographic identifier. SeND forces 533 the IPv6 address to be cryptographic since it integrates the CGA as 534 the IID in the IPv6 address. This specification frees the device to 535 form its addresses in any fashion, so as to enable the classical 536 6LoWPAN compression which derives IPv6 addresses from Layer-2 537 addresses, as well as privacy addresses. The threats discussed in 538 Section 9.2 of [RFC3971] are countered by the protocol described in 539 this document as well. 541 Collisions of Owner Unique Interface IDentifier (OUID) (which is the 542 Crypto-ID in this specification) is a possibility that needs to be 543 considered. The formula for calculating the probability of a 544 collision is 1 - e^{-k^2/(2n)} where n is the maximum population size 545 (2^64 here, 1.84E19) and K is the actual population (number of 546 nodes). If the Crypto-ID is 64-bit long, then the chance of finding 547 a collision is 0.01% when the network contains 66 million nodes. It 548 is important to note that the collision is only relevant when this 549 happens within one stub network (6LBR). A collision of Crypto-ID is 550 a rare event. In the case of a collision, an attacker may be able to 551 claim the registered address of an another legitimate node. However 552 for this to happen, the attacker would also need to know the address 553 which was registered by the legitimate node. This registered address 554 is however never broadcasted on the network and therefore it provides 555 an additional entropy of 64-bits that an attacker must correctly 556 guess. To prevent such a scenario, it is RECOMMENDED that nodes 557 derive the address being registered independently of the OUID. 559 7. IANA considerations 561 IANA is requested to assign two new option type values for the CIPO 562 under the subregistry "IPv6 Neighbor Discovery Option Formats". 564 7.1. Crypto Type Registry 566 The following Crypto Type values are defined in this document: 568 +-------------------+-----------------------------------------+ 569 | Crypto Type value | Algorithms | 570 +-------------------+-----------------------------------------+ 571 | 0 | NIST P-256, SHA-256 [RFC6234] | 572 | 1 | Curve25519 [RFC7748], SHA-256 [RFC6234] | 573 +-------------------+-----------------------------------------+ 575 Table 1: Crypto Types 577 Assignment of new values for new Crypto Type MUST be done through 578 IANA with "Specification Required" and "IESG Approval" as defined in 579 [RFC8126]. 581 8. Acknowledgements 583 Special thanks to Charlie Perkins for his in-depth review and 584 constructive suggestions. We are also grateful to Rene Struik and 585 Robert Moskowitz for their comments that lead to many improvements to 586 this document. 588 9. Change Log 590 o submitted version -00 as a working group draft after adoption, and 591 corrected the order of authors 593 o submitted version -01 with no changes 595 o submitted version -02 with these changes: Moved Requirements to 596 Appendix A, Section 4.2 moved to Section 3, New section 4 on New 597 Fields and Options, Section 4 changed to Protocol Overview as 598 Section 5 with Protocol Scope and Flows subsections. 600 o submitted version -03 addressing Charlie Perkins' comments 602 10. References 603 10.1. Normative References 605 [I-D.ietf-6lo-rfc6775-update] 606 Thubert, P., Nordmark, E., and S. Chakrabarti, "An Update 607 to 6LoWPAN ND", draft-ietf-6lo-rfc6775-update-09 (work in 608 progress), September 2017. 610 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 611 Requirement Levels", BCP 14, RFC 2119, 612 DOI 10.17487/RFC2119, March 1997, 613 . 615 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 616 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 617 2006, . 619 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 620 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 621 DOI 10.17487/RFC4861, September 2007, 622 . 624 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 625 Address Autoconfiguration", RFC 4862, 626 DOI 10.17487/RFC4862, September 2007, 627 . 629 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 630 Bormann, "Neighbor Discovery Optimization for IPv6 over 631 Low-Power Wireless Personal Area Networks (6LoWPANs)", 632 RFC 6775, DOI 10.17487/RFC6775, November 2012, 633 . 635 10.2. Informative references 637 [I-D.ietf-6lo-backbone-router] 638 Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo- 639 backbone-router-04 (work in progress), July 2017. 641 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 642 "SEcure Neighbor Discovery (SEND)", RFC 3971, 643 DOI 10.17487/RFC3971, March 2005, 644 . 646 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 647 RFC 3972, DOI 10.17487/RFC3972, March 2005, 648 . 650 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 651 over Low-Power Wireless Personal Area Networks (6LoWPANs): 652 Overview, Assumptions, Problem Statement, and Goals", 653 RFC 4919, DOI 10.17487/RFC4919, August 2007, 654 . 656 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 657 "Transmission of IPv6 Packets over IEEE 802.15.4 658 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 659 . 661 [RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing 662 Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889, 663 September 2010, . 665 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 666 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 667 DOI 10.17487/RFC6234, May 2011, 668 . 670 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 671 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 672 DOI 10.17487/RFC6282, September 2011, 673 . 675 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 676 "Source Address Validation Improvement (SAVI) Framework", 677 RFC 7039, DOI 10.17487/RFC7039, October 2013, 678 . 680 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 681 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 682 2014, . 684 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 685 Interface Identifiers with IPv6 Stateless Address 686 Autoconfiguration (SLAAC)", RFC 7217, 687 DOI 10.17487/RFC7217, April 2014, 688 . 690 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 691 Agility and Selecting Mandatory-to-Implement Algorithms", 692 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 693 . 695 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 696 Considerations for IPv6 Address Generation Mechanisms", 697 RFC 7721, DOI 10.17487/RFC7721, March 2016, 698 . 700 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 701 for Security", RFC 7748, DOI 10.17487/RFC7748, January 702 2016, . 704 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 705 Writing an IANA Considerations Section in RFCs", BCP 26, 706 RFC 8126, DOI 10.17487/RFC8126, June 2017, 707 . 709 Appendix A. Requirements Addressed in this Document 711 In this section we state requirements of a secure neighbor discovery 712 protocol for low-power and lossy networks. 714 o The protocol MUST be based on the Neighbor Discovery Optimization 715 for Low-power and Lossy Networks protocol defined in [RFC6775]. 716 RFC6775 utilizes optimizations such as host-initiated interactions 717 for sleeping resource-constrained hosts and elimination of 718 multicast address resolution. 720 o New options to be added to Neighbor Solicitation messages MUST 721 lead to small packet sizes, especially compared with existing 722 protocols such as SEcure Neighbor Discovery (SEND). Smaller 723 packet sizes facilitate low-power transmission by resource- 724 constrained nodes on lossy links. 726 o The support for this registration mechanism SHOULD be extensible 727 to more LLN links than IEEE 802.15.4 only. Support for at least 728 the LLN links for which a 6lo "IPv6 over foo" specification 729 exists, as well as Low-Power Wi-Fi SHOULD be possible. 731 o As part of this extension, a mechanism to compute a unique 732 Identifier should be provided with the capability to form a Link 733 Local Address that SHOULD be unique at least within the LLN 734 connected to a 6LBR. 736 o The Address Registration Option used in the ND registration SHOULD 737 be extended to carry the relevant forms of Unique Interface 738 IDentifier. 740 o The Neighbour Discovery should specify the formation of a site- 741 local address that follows the security recommendations from 742 [RFC7217]. 744 Authors' Addresses 746 Behcet Sarikaya 747 Plano, TX 748 USA 750 Email: sarikaya@ieee.org 752 Pascal Thubert 753 Cisco Systems, Inc 754 Building D 755 45 Allee des Ormes - BP1200 756 MOUGINS - Sophia Antipolis 06254 757 FRANCE 759 Phone: +33 497 23 26 34 760 Email: pthubert@cisco.com 762 Mohit Sethi 763 Ericsson 764 Hirsalantie 765 Jorvas 02420 767 Email: mohit@piuha.net