idnits 2.17.00 (12 Aug 2021) /tmp/idnits56263/draft-ietf-6lo-ap-nd-04.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 (November 14, 2017) is 1649 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: May 18, 2018 M. Sethi 7 Ericsson 8 November 14, 2017 10 Address Protected Neighbor Discovery for Low-power and Lossy Networks 11 draft-ietf-6lo-ap-nd-04 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 May 18, 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 . . . . . . . . . . . . . . . . . . . . . . 9 65 5.1. Protocol Scope . . . . . . . . . . . . . . . . . . . . . 9 66 5.2. Protocol Flows . . . . . . . . . . . . . . . . . . . . . 10 67 5.3. Multihop Operation . . . . . . . . . . . . . . . . . . . 12 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 70 7.1. Crypto Type Registry . . . . . . . . . . . . . . . . . . 13 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 74 9.2. Informative references . . . . . . . . . . . . . . . . . 14 75 Appendix A. Requirements Addressed in this Document . . . . . . 16 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 78 1. Introduction 80 "Neighbor Discovery Optimizations for 6LoWPAN networks" [RFC6775] 81 (6LoWPAN ND) adapts the classical IPv6 ND protocol [RFC4861][RFC4862] 82 (IPv6 ND) for operations over a constrained low-power and lossy 83 network (LLN). In particular, 6LoWPAN ND introduces a unicast host 84 address registration mechanism that contributes to reduce the use of 85 multicast messages that are present in the classical IPv6 ND 86 protocol. 6LoWPAN ND defines a new Address Registration Option (ARO) 87 that is carried in the unicast Neighbor Solicitation (NS) and 88 Neighbor Advertisement (NA) messages between the 6LoWPAN Node (6LN) 89 and the 6LoWPAN Router (6LR). Additionally, it also defines the 90 Duplicate Address Request (DAR) and Duplicate Address Confirmation 91 (DAC) messages between the 6LR and the 6LoWPAN Border Router (6LBR). 92 In LLN networks, the 6LBR is the central repository of all the 93 registered addresses in its domain. 95 The registration mechanism in 6LoWPAN ND [RFC6775] prevents the use 96 of an address if that address is already present in the subnet (first 97 come first serve). In order to validate address ownership, the 98 registration mechanism enables the 6LR and 6LBR to validate claims 99 for a registered address with an associated Owner Unique Interface 100 IDentifier (OUID). 6LoWPAN ND specifies that the OUID is derived from 101 the MAC address of the device (EUI-64), which can be spoofed. 102 Therefore, any node connected to the subnet and aware of a 103 registered-address-to-OUID mapping could effectively fake the OUID, 104 steal the address and redirect traffic for that address towards a 105 different 6LN. The "Update to 6LoWPAN ND" 106 [I-D.ietf-6lo-rfc6775-update] defines an Extended ARO (EARO) option 107 that allows to transport alternate forms of OUIDs, and is a 108 prerequisite for this specification. 110 According to this specification, a 6LN generates a cryptographic ID 111 (Crypto-ID) and places it in the OUID field in the registration of 112 one (or more) of its addresses with the 6LR(s) that the 6LN uses as 113 default router(s). Proof of ownership of the cryptographic ID 114 (Crypto-ID) is passed with the first registration to a given 6LR, and 115 enforced at the 6LR, in a new Crypto-ID Parameters Option (CIPO). 116 The 6LR validates ownership of the cryptographic ID upon the creation 117 of a registration state, or a change in the anchor information, such 118 as Link-Layer Address and associated Layer-2 cryptographic material. 120 The protected address registration protocol proposed in this document 121 enables the enforcement of Source Address Validation (SAVI) 122 [RFC7039], which ensures that only the correct owner uses a 123 registered address in the source address field in IPv6 packets. 124 Consequently, a 6LN that sources a packet has to use a 6LR to which 125 the source address of the packet is registered to forward the packet. 126 The 6LR maintains state information for the registered addressed, 127 including the MAC address, and a link-layer cryptographic key 128 associated with the 6LN. In SAVI-enforcement mode, the 6LR allows 129 only packets from a connected Host if the connected Host owns the 130 registration of the source address of the packet. 132 The 6lo adaptation layer framework ([RFC4944], [RFC6282]) expects 133 that a device forms its IPv6 addresses based on Layer-2 address, so 134 as to enable a better compression. This is incompatible with "Secure 135 Neighbor Discovery (SEND)" [RFC3971] and "Cryptographically Generated 136 Addresses (CGAs)" [RFC3972], which derive the Interface ID (IID) in 137 the IPv6 addresses from cryptographic material. "Privacy 138 Considerations for IPv6 Address Generation Mechanisms" [RFC7721] 139 places additional recommendations on the way addresses should be 140 formed and renewed. 142 This document specifies that a device may form and register addresses 143 at will, without a constraint on the way the address is formed or the 144 number of addresses that are registered in parallel. It enables to 145 protect multiple addresses with a single cryptographic material and 146 to send the proof only once to a given 6LR for multiple addresses and 147 refresher registrations. 149 2. Terminology 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC2119]. 155 Readers are expected to be familiar with all the terms and concepts 156 that are discussed in [RFC3971], [RFC3972], [RFC4861], [RFC4919], 157 [RFC6775], and [I-D.ietf-6lo-backbone-router] which proposes an 158 evolution of [RFC6775] for wider applicability. 160 This document defines Crypto-ID as an identifier of variable size 161 which in most cases is 64 bits long. It is generated using 162 cryptographic means explained later in this document Section 4.1. 163 "Elliptic Curves for Security" [RFC7748] and "Edwards-Curve Digital 164 Signature Algorithm (EdDSA)" [RFC8032] provides information on 165 Elliptic Curve Cryptography (ECC) and a (twisted) Edwards curve, 166 Ed25519, which can be used with this specification. "Alternative 167 Elliptic Curve Representations" 168 [I-D.struik-lwip-curve-representations] provides additional 169 information on how to represent Montgomery curves and (twisted) 170 Edwards curves as curves in short-Weierstrass form and illustrates 171 how this can be used to implement elliptic curve computations using 172 existing implementations that already implement, e.g., ECDSA and ECDH 173 using NIST [FIPS186-4] prime curves. 175 The document also conforms to the terms and models described in 176 [RFC5889] and uses the vocabulary and the concepts defined in 177 [RFC4291] for the IPv6 Architecture. Finally, common terminology 178 related to Low power And Lossy Networks (LLN) defined in [RFC7102] is 179 also used. 181 3. Updating RFC 6775 183 This specification defines a cryptographic identifier (Crypto-ID) 184 that can be used as a replacement to the MAC address in the OUID 185 field of the EARO option; the computation of the Crypto-ID is 186 detailed in Section 4.1. A node in possession of the necessary 187 cryptographic material SHOULD use Crypto-ID by default as OUID in its 188 registration. Whether a OUID is a Crypto-ID is indicated by a new 189 "C" flag in the NS(EARO) message. 191 This specification introduces a new option, the CIPO, that is used to 192 prove ownership of the Crypto-ID. A node that registers for the 193 first time to a 6LR SHOULD place a CIPO option in its registration. 194 However, it is not expected to place the option in the periodic 195 refresher registrations for that address, or to register other 196 addresses with the same OUID. When a 6LR receives a NS(EARO) 197 registration with a new Crypto-ID as a OUID, it SHOULD challenge by 198 responding with a NA(EARO) with a status of "Validation Requested". 199 This process of validation MAY be skipped in networks where there is 200 no mobility. 202 The challenge MUST also be triggered in the case of a registration 203 for which the Source Link-Layer Address is not consistent with a 204 state that already exists either at the 6LR or the 6LBR. In the 205 latter case, the 6LBR returns a status of "Validation Requested" in 206 the DAR/DAC exchange, which is echoed by the 6LR in the NA (EARO) 207 back to the registering node. This flow should not alter a 208 preexisting state in the 6LR or the 6LBR. 210 Upon receiving a NA(EARO) with a status of "Validation Requested", 211 the registering node SHOULD retry its registration with a CIPO option 212 that proves its ownership of the Crypto-ID. 214 If the 6LR cannot validate the CIPO, it responds with a status of 215 "Validation Failed". After receiving a NA(EARO) with a status of 216 "Validation Failed", the registering node MUST NOT use this Crypto-ID 217 for registering with that 6LR. 219 4. New Fields and Options 221 4.1. New Crypto-ID 223 Elliptic Curve Cryptography (ECC) is used to calculate the Crypto-ID. 224 Each 6LN using a Crypto-ID for registration MUST have a public/ 225 private key pair. The digital signature is constructed by using the 226 6LN's private key over its EUI-64 (MAC) address. The signature value 227 is computed using the ECDSA signature algorithm and the hash function 228 used is SHA-256 [RFC6234]. Public Key is the most important 229 parameter in CGA Parameters (sent by 6LN in an NS message). ECC 230 Public Key could be in uncompressed form or in compressed form where 231 the first octet of the OCTET STRING is 0x04 and 0x02 or 0x03, 232 respectively. Point compression can further reduce the key size by 233 about 32 octets. 235 To support cryptographic algorithm agility [RFC7696], Edwards-Curve 236 Digital Signature Algorithm (EdDSA) curve Ed25519ph (pre-hashing) 237 [RFC8032] can also be used as an alternate to the default NIST P-256 238 [FIPS186-4]. This is indicated by 6LN using the Crypto Type field in 239 the CIPO option. The document currently only defines two possible 240 values for the Crypto Type field. A value of 0 indicates that NIST 241 P-256 is used for the signature operation and SHA-256 as the hash 242 algorithm. A value of 1 indicates that Ed25519ph is used for the 243 signature operation and SHA-256 as the hash algorithm. New values 244 for the Crypto Type maybe defined in the future for new curves. 246 The Crypto-ID is computed as follows: 248 1. the modifier is set to a random or pseudo-random 128-bit value 250 2. the modifier, 9 zero octets and the ECC public key are 251 concatenated from left to right. 253 3. the SHA-256 algorithm is applied on the concatenation 255 4. the 112 leftmost bits of the hash value are retained 257 5. the modifier value, the EUI-64 transformation of the device Link 258 Layer Address and the encoded public key are concatenated from 259 left to right 261 6. Digital signature (NIST P-256 or EdDSA) is executed on the 262 concatenation 264 7. the leftmost bits of the resulting signature are used as the 265 Crypto-ID. 267 With this specification, only 64 bits are retained, but it could be 268 expanded to more bits in the future by increasing the size of the 269 OUID field. 271 4.2. Updated EARO 273 This specification updates the EARO option as follows: 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Type | Length | Status | Reserved | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Reserved |C|T| TID | Registration Lifetime | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | | 283 + Owner Unique ID (EUI-64 or equivalent) + 284 | | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Figure 1: Enhanced Address Registration Option 289 Type: 33 291 Length: 8-bit unsigned integer. The length of the option 292 (including the type and length fields) in units of 8 293 bytes. 295 Status: 8-bit unsigned integer. Indicates the status of a 296 registration in the NA response. MUST be set to 0 in 297 NS messages. This specification uses values 298 introduced in the update to 6LoWPAN ND 299 [I-D.ietf-6lo-rfc6775-update], such as "Validation 300 Requested" and "Validation Failed". No additional 301 value is defined. 303 Reserved: This field is unused. It MUST be initialized to zero 304 by the sender and MUST be ignored by the receiver. 306 C: This "C" flag is set to indicate that the Owner 307 Unique ID field contains a Crypto-ID. 309 T and TID: Defined in [I-D.ietf-6lo-rfc6775-update]. 311 Owner Unique ID: When the "C" flag is set, this field contains a 312 Crypto-ID. 314 4.3. New Crypto-ID Parameters Option 316 This specification introduces a new option, the Crypto-ID Parameters 317 Option (CIPO), that carries the proof of ownership of a crypto-ID. 319 0 1 2 3 320 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 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Type | Length | Pad Length | Crypto Type | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | | 325 + + 326 | | 327 + Modifier (16 octets) + 328 | | 329 + + 330 | | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | | 333 + Subnet Prefix (8 octets) + 334 | | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | | 337 | | 338 + Public Key (variable length) + 339 | | 340 | | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | | 343 . . 344 . Padding . 345 . . 346 | | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 Figure 2: Crypto-ID Parameters Option 351 Type: CIPO, to be assigned by IANA. 353 Length: The length of the option in units of 8 octets. 355 Pad Length: The length of the Padding field. 357 Crypto Type: The type of cryptographic algorithm used in 358 calculation Crypto-ID. Default value of all zeros 359 indicate NIST P-256. A value of 1 is assigned for 360 Ed25519ph. New values may be defined later. 362 Modifier: 128 bit random value. 364 Subnet Prefix: 64 bit subnet prefix. 366 Public Key: ECC public key of 6LN. 368 Padding: A variable-length field making the option length a 369 multiple of 8, containing as many octets as specified 370 in the Pad Length field. 372 5. Protocol Overview 374 5.1. Protocol Scope 376 The scope of the present work is a 6LoWPAN Low Power Lossy Network 377 (LLN), typically a stub network connected to a larger IP network via 378 a Border Router called a 6LBR per [RFC6775]. 380 The 6LBR maintains a registration state for all devices in the 381 attached LLN, and, in conjunction with the first-hop router (the 382 6LR), is in a position to validate uniqueness and grant ownership of 383 an IPv6 address before it can be used in the LLN. This is a 384 fundamental difference with a classical network that relies on IPv6 385 address auto-configuration [RFC4862], where there is no guarantee of 386 ownership from the network, and any IPv6 Neighbor Discovery packet 387 must be individually secured [RFC3971]. 389 ---+-------- ............ 390 | External Network 391 | 392 +-----+ 393 | | 6LBR 394 +-----+ 395 o o o 396 o o o o 397 o o LLN o o o 398 o o o (6LR) 399 o (6LN) 401 Figure 3: Basic Configuration 403 In a mesh network, the 6LR is directly connected to the host device. 404 This specification expects that the peer-wise layer-2 security is 405 deployed so that all the packets from a particular host are securely 406 identifiable by the 6LR. The 6LR may be multiple hops away from the 407 6LBR. Packets are routed between the 6LR and the 6LBR via other 408 6LRs. This specification expects that a chain of trust is 409 established so that a packet that was validated by the first 6LR can 410 be safely routed by the next 6LRs to the 6LBR. 412 5.2. Protocol Flows 414 Figure 4 illustrates a registration flow all the way to a 6LowPAN 415 Backbone Router (6BBR). 417 A new device that joins the network auto-configures an address and 418 performs an initial registration to an on-link 6LR with an NS message 419 that carries an Address Registration Option (EARO) [RFC6775]. The 420 6LR validates the address with the central 6LBR using a DAR/DAC 421 exchange, and the 6LR confirms (or denies) the address ownership with 422 an NA message that also carries an Address Registration Option. 424 In a multihop 6LoWPAN, the registration with Crypto-ID is propagated 425 to 6LBR as described in Section 5.3. If a chain of trust is present 426 between the 6LR and the 6LBR, then there is no need to propagate the 427 proof of ownership to the 6LBR. All the 6LBR needs to know is that 428 this particular OUID is randomly generated, so as to enforce that any 429 update via a different 6LR is also random. 431 6LN 6LR 6LBR 6BBR 432 | | | | 433 | NS(EARO) | | | 434 |--------------->| | | 435 | | Extended DAR | | 436 | |-------------->| | 437 | | | | 438 | | | proxy NS(EARO) | 439 | | |--------------->| 440 | | | | NS(DAD) 441 | | | | ------> 442 | | | | 443 | | | | 444 | | | | 445 | | | proxy NA(EARO) | 446 | | |<---------------| 447 | | Extended DAC | | 448 | |<--------------| | 449 | NA(EARO) | | | 450 |<---------------| | | 451 | | | | 453 Figure 4: (Re-)Registration Flow 455 On-link (local) protocol interactions are shown in Figure 5. Crypto- 456 ID and ARO are passed to and stored by the 6LR on the first NS and 457 not sent again in the next NS. The operation starts with 6LR sending 458 a Router Advertisement (RA) message to 6LN. 460 The 6LR/6LBR ensures first-come/first-serve by storing the ARO and 461 the Crypto-ID correlated to the node being registered. The node is 462 free to claim any address it likes as long as it is the first to make 463 such a claim. After a successful registration, the node becomes the 464 owner of the registered address and the address is bound to the 465 Crypto-ID in the 6LR/6LBR registry. This binding can be verified 466 later, which prevents other nodes from stealing the address and 467 trying to attract traffic for that address or use it as their source 468 address. 470 A node may use multiple IPv6 addresses at the same time. The node 471 may use the same Crypto-ID to protect multiple IPv6 addresses. The 472 separation of the address and the Crypto-ID avoids the constrained 473 device to compute multiple keys for multiple addresses. The 474 registration process allows the node to bind all of its addresses to 475 the same Crypto-ID. 477 6LN 6LR 478 | | 479 |<------------------- RA --------------------------| 480 | | 481 |----------- NS with ARO and Crypto-ID ----------->| 482 | | 483 |<---------- NA with ARO (status=proof requested) -| 484 | | 485 |----------- NS with ARO and Crypto-ID ----------->| 486 | | 487 |<---------------- NA with ARO --------------------| 488 | | 489 ... ... 490 | | 491 |------------ NS with ARO and Crypto-ID ---------->| 492 | | 493 | | 494 |<---------------- NA with ARO --------------------| 495 ... ... 496 | | 497 |----------- NS with ARO and Crypto-ID ----------->| 498 | | 499 | | 500 |<---------------- NA with ARO --------------------| 502 Figure 5: On-link Protocol Operation 504 5.3. Multihop Operation 506 In a multihop 6LoWPAN, a 6LBR sends RAs with prefixes downstream and 507 the 6LR receives and relays them to the nodes. 6LR and 6LBR 508 communicate using ICMPv6 Duplicate Address Request (DAR) and 509 Duplicate Address Confirmation (DAC) messages. The DAR and DAC use 510 the same message format as NS and NA, but have different ICMPv6 type 511 values. 513 In ND-PAR we extend DAR/DAC messages to carry cryptographically 514 generated OUID. In a multihop 6LoWPAN, the node exchanges the 515 messages shown in Figure 4. The 6LBR must identify who owns an 516 address (EUI-64) to defend it, if there is an attacker on another 517 6LR. Because of this the content that the source signs and the 518 signature needs to be propagated to the 6LBR in the DAR message. For 519 this purpose the DAR message sent by 6LR to 6LBR MUST contain the 520 CIPO option. The DAR message also contains ARO. 522 Occasionally, a 6LR might miss the node's OUID (that it received in 523 ARO). 6LR should be able to ask for it again. This is done by 524 restarting the exchanges shown in Figure 5. The result enables 6LR 525 to refresh the information that was lost. The 6LR MUST send DAR 526 message with ARO to 6LBR. The 6LBR replies with a DAC message with 527 the information copied from the DAR, and the Status field is set to 528 zero. With this exchange, the 6LBR can (re)validate and store the 529 information to make sure that the 6LR is not a fake. 531 In some cases, the 6LBR may use a DAC message to solicit a Crypto-ID 532 from a 6LR and also requests 6LR to verify the EUI-64 6LR received 533 from 6LN. This may happen when a 6LN node is compromised and a fake 534 node is sending the Crypto-ID as if it is the node's EUI-64. Note 535 that the detection in this case can only be done by 6LBR not by 6LR. 537 6. Security Considerations 539 The observations regarding the threats to the local network in 540 [RFC3971] also apply to this specification. 542 The threats discussed in 6LoWPAN ND [RFC6775] and its update 543 [I-D.ietf-6lo-rfc6775-update] also apply here. Compared with SeND, 544 this specification saves about 1Kbyte in every NS/NA message. Also, 545 this specification separates the cryptographic identifier from the 546 registered IPv6 address so that a node can have more than one IPv6 547 address protected by the same cryptographic identifier. SeND forces 548 the IPv6 address to be cryptographic since it integrates the CGA as 549 the IID in the IPv6 address. This specification frees the device to 550 form its addresses in any fashion, so as to enable the classical 551 6LoWPAN compression which derives IPv6 addresses from Layer-2 552 addresses, as well as privacy addresses. The threats discussed in 553 Section 9.2 of [RFC3971] are countered by the protocol described in 554 this document as well. 556 Collisions of Owner Unique Interface IDentifier (OUID) (which is the 557 Crypto-ID in this specification) is a possibility that needs to be 558 considered. The formula for calculating the probability of a 559 collision is 1 - e^{-k^2/(2n)} where n is the maximum population size 560 (2^64 here, 1.84E19) and K is the actual population (number of 561 nodes). If the Crypto-ID is 64-bit long, then the chance of finding 562 a collision is 0.01% when the network contains 66 million nodes. It 563 is important to note that the collision is only relevant when this 564 happens within one stub network (6LBR). A collision of Crypto-ID is 565 a rare event. In the case of a collision, an attacker may be able to 566 claim the registered address of an another legitimate node. However 567 for this to happen, the attacker would also need to know the address 568 which was registered by the legitimate node. This registered address 569 is however never broadcasted on the network and therefore it provides 570 an additional entropy of 64-bits that an attacker must correctly 571 guess. To prevent such a scenario, it is RECOMMENDED that nodes 572 derive the address being registered independently of the OUID. 574 7. IANA considerations 576 IANA is requested to assign two new option type values for the CIPO 577 under the subregistry "IPv6 Neighbor Discovery Option Formats". 579 7.1. Crypto Type Registry 581 The following Crypto Type values are defined in this document: 583 +-------------------+--------------------------------------------+ 584 | Crypto Type value | Algorithms | 585 +-------------------+--------------------------------------------+ 586 | 0 | NIST P-256 [FIPS186-4] , SHA-256 [RFC6234] | 587 | 1 | Ed25519ph [RFC8032], SHA-256 [RFC6234] | 588 +-------------------+--------------------------------------------+ 590 Table 1: Crypto Types 592 Assignment of new values for new Crypto Type MUST be done through 593 IANA with "Specification Required" and "IESG Approval" as defined in 594 [RFC8126]. 596 8. Acknowledgements 598 Many thanks to Charlie Perkins for his in-depth review and 599 constructive suggestions. We are also especially grateful to Rene 600 Struik and Robert Moskowitz for their comments that lead to many 601 improvements to this document, in particular WRT ECC computation and 602 references. 604 9. References 606 9.1. Normative References 608 [I-D.ietf-6lo-rfc6775-update] 609 Thubert, P., Nordmark, E., Chakrabarti, S., and C. 610 Perkins, "An Update to 6LoWPAN ND", draft-ietf-6lo- 611 rfc6775-update-10 (work in progress), October 2017. 613 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 614 Requirement Levels", BCP 14, RFC 2119, 615 DOI 10.17487/RFC2119, March 1997, 616 . 618 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 619 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 620 2006, . 622 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 623 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 624 DOI 10.17487/RFC4861, September 2007, 625 . 627 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 628 Address Autoconfiguration", RFC 4862, 629 DOI 10.17487/RFC4862, September 2007, 630 . 632 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 633 Bormann, "Neighbor Discovery Optimization for IPv6 over 634 Low-Power Wireless Personal Area Networks (6LoWPANs)", 635 RFC 6775, DOI 10.17487/RFC6775, November 2012, 636 . 638 9.2. Informative references 640 [FIPS186-4] 641 "FIPS Publication 186-4: Digital Signature Standard", July 642 2013, . 645 [I-D.ietf-6lo-backbone-router] 646 Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo- 647 backbone-router-04 (work in progress), July 2017. 649 [I-D.struik-lwip-curve-representations] 650 Struik, R., "Alternative Elliptic Curve Representations", 651 draft-struik-lwip-curve-representations-00 (work in 652 progress), October 2017. 654 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 655 "SEcure Neighbor Discovery (SEND)", RFC 3971, 656 DOI 10.17487/RFC3971, March 2005, 657 . 659 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 660 RFC 3972, DOI 10.17487/RFC3972, March 2005, 661 . 663 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 664 over Low-Power Wireless Personal Area Networks (6LoWPANs): 665 Overview, Assumptions, Problem Statement, and Goals", 666 RFC 4919, DOI 10.17487/RFC4919, August 2007, 667 . 669 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 670 "Transmission of IPv6 Packets over IEEE 802.15.4 671 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 672 . 674 [RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing 675 Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889, 676 September 2010, . 678 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 679 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 680 DOI 10.17487/RFC6234, May 2011, 681 . 683 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 684 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 685 DOI 10.17487/RFC6282, September 2011, 686 . 688 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 689 "Source Address Validation Improvement (SAVI) Framework", 690 RFC 7039, DOI 10.17487/RFC7039, October 2013, 691 . 693 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 694 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 695 2014, . 697 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 698 Interface Identifiers with IPv6 Stateless Address 699 Autoconfiguration (SLAAC)", RFC 7217, 700 DOI 10.17487/RFC7217, April 2014, 701 . 703 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 704 Agility and Selecting Mandatory-to-Implement Algorithms", 705 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 706 . 708 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 709 Considerations for IPv6 Address Generation Mechanisms", 710 RFC 7721, DOI 10.17487/RFC7721, March 2016, 711 . 713 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 714 for Security", RFC 7748, DOI 10.17487/RFC7748, January 715 2016, . 717 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 718 Signature Algorithm (EdDSA)", RFC 8032, 719 DOI 10.17487/RFC8032, January 2017, 720 . 722 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 723 Writing an IANA Considerations Section in RFCs", BCP 26, 724 RFC 8126, DOI 10.17487/RFC8126, June 2017, 725 . 727 Appendix A. Requirements Addressed in this Document 729 In this section we state requirements of a secure neighbor discovery 730 protocol for low-power and lossy networks. 732 o The protocol MUST be based on the Neighbor Discovery Optimization 733 for Low-power and Lossy Networks protocol defined in [RFC6775]. 734 RFC6775 utilizes optimizations such as host-initiated interactions 735 for sleeping resource-constrained hosts and elimination of 736 multicast address resolution. 738 o New options to be added to Neighbor Solicitation messages MUST 739 lead to small packet sizes, especially compared with existing 740 protocols such as SEcure Neighbor Discovery (SEND). Smaller 741 packet sizes facilitate low-power transmission by resource- 742 constrained nodes on lossy links. 744 o The support for this registration mechanism SHOULD be extensible 745 to more LLN links than IEEE 802.15.4 only. Support for at least 746 the LLN links for which a 6lo "IPv6 over foo" specification 747 exists, as well as Low-Power Wi-Fi SHOULD be possible. 749 o As part of this extension, a mechanism to compute a unique 750 Identifier should be provided with the capability to form a Link 751 Local Address that SHOULD be unique at least within the LLN 752 connected to a 6LBR. 754 o The Address Registration Option used in the ND registration SHOULD 755 be extended to carry the relevant forms of Unique Interface 756 IDentifier. 758 o The Neighbour Discovery should specify the formation of a site- 759 local address that follows the security recommendations from 760 [RFC7217]. 762 Authors' Addresses 764 Behcet Sarikaya 765 Plano, TX 766 USA 768 Email: sarikaya@ieee.org 770 Pascal Thubert 771 Cisco Systems, Inc 772 Building D 773 45 Allee des Ormes - BP1200 774 MOUGINS - Sophia Antipolis 06254 775 FRANCE 777 Phone: +33 497 23 26 34 778 Email: pthubert@cisco.com 780 Mohit Sethi 781 Ericsson 782 Hirsalantie 783 Jorvas 02420 785 Email: mohit@piuha.net