idnits 2.17.1 draft-ietf-6lo-ap-nd-16.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 RFC8505, but the abstract doesn't seem to directly say this. It does mention RFC8505 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 (3 February 2020) is 1543 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 7748 (ref. 'BCP 201') ** Downref: Normative reference to an Informational RFC: RFC 8032 ** Downref: Normative reference to an Informational RFC: RFC 6234 -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186-4' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' == Outdated reference: A later version (-20) exists of draft-ietf-6lo-backbone-router-13 == Outdated reference: A later version (-23) exists of draft-ietf-lwig-curve-representations-08 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo P. Thubert, Ed. 3 Internet-Draft Cisco 4 Updates: 8505 (if approved) B.S. Sarikaya 5 Intended status: Standards Track 6 Expires: 6 August 2020 M.S. Sethi 7 Ericsson 8 R.S. Struik 9 Struik Security Consultancy 10 3 February 2020 12 Address Protected Neighbor Discovery for Low-power and Lossy Networks 13 draft-ietf-6lo-ap-nd-16 15 Abstract 17 This document updates the 6LoWPAN Neighbor Discovery (ND) protocol 18 defined in RFC 6775 and RFC 8505. The new extension is called 19 Address Protected Neighbor Discovery (AP-ND) and it protects the 20 owner of an address against address theft and impersonation attacks 21 in a low-power and lossy network (LLN). Nodes supporting this 22 extension compute a cryptographic identifier (Crypto-ID) and use it 23 with one or more of their Registered Addresses. The Crypto-ID 24 identifies the owner of the Registered Address and can be used to 25 provide proof of ownership of the Registered Addresses. Once an 26 address is registered with the Crypto-ID and a proof-of-ownership is 27 provided, only the owner of that address can modify the registration 28 information, thereby enforcing Source Address Validation. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 6 August 2020. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 67 2.3. Additional References . . . . . . . . . . . . . . . . . . 5 68 3. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 5 69 4. New Fields and Options . . . . . . . . . . . . . . . . . . . 6 70 4.1. New Crypto-ID . . . . . . . . . . . . . . . . . . . . . . 6 71 4.2. Updated EARO . . . . . . . . . . . . . . . . . . . . . . 6 72 4.3. Crypto-ID Parameters Option . . . . . . . . . . . . . . . 7 73 4.4. NDP Signature Option . . . . . . . . . . . . . . . . . . 9 74 5. Protocol Scope . . . . . . . . . . . . . . . . . . . . . . . 11 75 6. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . 11 76 6.1. First Exchange with a 6LR . . . . . . . . . . . . . . . . 12 77 6.2. NDPSO generation and verification . . . . . . . . . . . . 14 78 6.3. Multihop Operation . . . . . . . . . . . . . . . . . . . 16 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 80 7.1. Inheriting from RFC 3971 . . . . . . . . . . . . . . . . 17 81 7.2. Related to 6LoWPAN ND . . . . . . . . . . . . . . . . . . 18 82 7.3. ROVR Collisions . . . . . . . . . . . . . . . . . . . . . 18 83 7.4. Implementation Attacks . . . . . . . . . . . . . . . . . 19 84 7.5. Cross-Algorithm and Cross-Protocol Attacks . . . . . . . 19 85 7.6. Compromised 6LR . . . . . . . . . . . . . . . . . . . . . 19 86 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20 87 8.1. CGA Message Type . . . . . . . . . . . . . . . . . . . . 20 88 8.2. IPv6 ND option types . . . . . . . . . . . . . . . . . . 20 89 8.3. Crypto-Type Subregistry . . . . . . . . . . . . . . . . . 20 90 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 91 10. Normative References . . . . . . . . . . . . . . . . . . . . 21 92 11. Informative references . . . . . . . . . . . . . . . . . . . 23 93 Appendix A. Requirements Addressed in this Document . . . . . . 24 94 Appendix B. Representation Conventions . . . . . . . . . . . . . 25 95 B.1. Signature Schemes . . . . . . . . . . . . . . . . . . . . 25 96 B.2. Integer Representation for ECDSA signatures . . . . . . . 26 97 B.3. Alternative Representations of Curve25519 . . . . . . . . 26 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 100 1. Introduction 102 Neighbor Discovery Optimizations for 6LoWPAN networks [RFC6775] 103 (6LoWPAN ND) adapts the original IPv6 Neighbor Discovery (IPv6 ND) 104 protocols defined in [RFC4861] and [RFC4862] for constrained low- 105 power and lossy network (LLN). In particular, 6LoWPAN ND introduces 106 a unicast host Address Registration mechanism that reduces the use of 107 multicast compared to the Duplicate Address Detection (DAD) mechanism 108 defined in IPv6 ND. 6LoWPAN ND defines a new Address Registration 109 Option (ARO) that is carried in the unicast Neighbor Solicitation 110 (NS) and Neighbor Advertisement (NA) messages exchanged between a 111 6LoWPAN Node (6LN) and a 6LoWPAN Router (6LR). It also defines the 112 Duplicate Address Request (DAR) and Duplicate Address Confirmation 113 (DAC) messages between the 6LR and the 6LoWPAN Border Router (6LBR). 114 In LLN networks, the 6LBR is the central repository of all the 115 registered addresses in its domain. 117 The registration mechanism in "Neighbor Discovery Optimization for 118 Low-power and Lossy Networks" [RFC6775] (aka 6LoWPAN ND) prevents the 119 use of an address if that address is already registered in the subnet 120 (first come first serve). In order to validate address ownership, 121 the registration mechanism enables the 6LR and 6LBR to validate the 122 association between the registered address of a node, and its 123 Registration Ownership Verifier (ROVR). The ROVR is defined in 124 "Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505] 125 and it can be derived from the MAC address of the device (using the 126 64-bit Extended Unique Identifier EUI-64 address format specified by 127 IEEE). However, the EUI-64 can be spoofed, and therefore, any node 128 connected to the subnet and aware of a registered-address-to-ROVR 129 mapping could effectively fake the ROVR. This would allow the an 130 attacker to steal the address and redirect traffic for that address. 131 [RFC8505] defines an Extended Address Registration Option (EARO) 132 option that allows to transport alternate forms of ROVRs, and is a 133 pre-requisite for this specification. 135 In this specification, a 6LN generates a cryptographic ID (Crypto-ID) 136 and places it in the ROVR field during the registration of one (or 137 more) of its addresses with the 6LR(s). Proof of ownership of the 138 Crypto-ID is passed with the first registration exchange to a new 139 6LR, and enforced at the 6LR. The 6LR validates ownership of the 140 cryptographic ID before it creates any new registration state, or 141 changes existing information. 143 The protected address registration protocol proposed in this document 144 provides the same conceptual benefit as Source Address Validation 145 (SAVI) [RFC7039] that only the owner of an IPv6 address may source 146 packets with that address. As opposed to [RFC7039], which relies on 147 snooping protocols, the protection is based on a state that is 148 installed and maintained in the network by the owner of the address. 149 With this specification, a 6LN may use a 6LR for forwarding an IPv6 150 packets if and only if it has registered the address used as source 151 of the packet with that 6LR. 153 The 6lo adaptation layer in [RFC4944] and [RFC6282] requires a device 154 to form its IPv6 addresses based on its Layer-2 address to enable a 155 better compression. As a side note, this is incompatible with Secure 156 Neighbor Discovery (SeND) [RFC3971] and Cryptographically Generated 157 Addresses (CGAs) [RFC3972], since they derive the Interface ID (IID) 158 in IPv6 addresses from cryptographic keys. 160 2. Terminology 162 2.1. BCP 14 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 166 "OPTIONAL" in this document are to be interpreted as described in BCP 167 14 [RFC2119] [RFC8174] when, and only when, they appear in all 168 capitals, as shown here. 170 2.2. Abbreviations 172 This document uses the following abbreviations: 174 6BBR: 6LoWPAN Backbone Router 175 6LBR: 6LoWPAN Border Router 176 6LN: 6LoWPAN Node 177 6LR: 6LoWPAN Router 178 EARO: Extended Address Registration Option 179 CIPO: Crypto-ID Parameters Option 180 LLN: Low-Power and Lossy Network 181 NA: Neighbor Advertisement 182 ND: Neighbor Discovery 183 NDP: Neighbor Discovery Protocol 184 NDPSO: NDP Signature Option 185 NS: Neighbor Solicitation 186 ROVR: Registration Ownership Verifier 187 RA: Router Advertisement 188 RS: Router Solicitation 189 RSAO: RSA Signature Option 190 TID: Transaction ID 192 2.3. Additional References 194 The reader may get additional context for this specification from the 195 following references: 197 * "SEcure Neighbor Discovery (SEND)" [RFC3971], 199 * "Cryptographically Generated Addresses (CGA)" [RFC3972], 201 * "Neighbor Discovery for IP version 6" [RFC4861] , 203 * "IPv6 Stateless Address Autoconfiguration" [RFC4862], and 205 * "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): 206 Overview, Assumptions, Problem Statement, and Goals " [RFC4919]. 208 3. Updating RFC 8505 210 Section 5.3 of [RFC8505] introduces the ROVR as a generic object that 211 is designed for backward compatibility with the capability to 212 introduce new computation methods in the future. Section 7.3 213 discusses collisions when heterogeneous methods to compute the ROVR 214 field coexist inside a same network. 216 [RFC8505] was designed in preparation for this specification, which 217 is the RECOMMENDED method for building a ROVR field. 219 This specification introduces a new token called a cryptographic 220 identifier (Crypto-ID) that is transported in the ROVR field and used 221 to prove indirectly the ownership of an address that is being 222 registered by means of [RFC8505]. The Crypto-ID is derived from a 223 cryptographic public key and additional parameters. 225 The overall mechanism requires the support of Elliptic Curve 226 Cryptography (ECC) and of a hash function as detailed in Section 6.2. 227 To enable the verification of the proof, the registering node needs 228 to supply certain parameters including a Nonce and a signature that 229 will demonstrate that the node possesses the private-key 230 corresponding to the public-key used to build the Crypto-ID. 232 The elliptic curves and the hash functions that can be used with this 233 specification are listed in Table 2 in Section 8.3. The signature 234 scheme that specifies which combination is used is signaled by a 235 Crypto-Type (values to be confirmed by IANA) in a new IPv6 ND Crypto- 236 ID Parameters Option (CIPO, see Section 4.3) that contains the 237 parameters that are necessary for the proof, a Nonce option 238 ([RFC3971]) and a NDP Signature option (Section 4.4). The NA(EARO) 239 is modified to enable a challenge and transport a Nonce option. 241 4. New Fields and Options 243 4.1. New Crypto-ID 245 The Crypto-ID is transported in the ROVR field of the EARO option and 246 the EDAR message, and is associated with the Registered Address at 247 the 6LR and the 6LBR. The ownership of a Crypto-ID can be 248 demonstrated by cryptographic mechanisms, and by association, the 249 ownership of the Registered Address can be acertained. 251 A node in possession of the necessary cryptographic primitives SHOULD 252 use Crypto-ID by default as ROVR in its registrations. Whether a 253 ROVR is a Crypto-ID is indicated by a new "C" flag in the NS(EARO) 254 message. 256 The Crypto-ID is derived from the public key and a modifier as 257 follows: 259 1. The hash function indicated by the Crypto-Type is applied to the 260 CIPO. Note that all the reserved and padding bits MUST be set to 261 zero. 262 2. The leftmost bits of the resulting hash, up to the desired size, 263 are used as the Crypto-ID. 265 At the time of this writing, a minimal size for the Crypto-ID of 128 266 bits is RECOMMENDED. This value is bound to augment in the future. 268 4.2. Updated EARO 270 This specification updates the EARO option to enable the use of the 271 ROVR field to transport the Crypto-ID. 273 The resulting format is 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 | Opaque | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 |Rsvd |C| I |R|T| TID | Registration Lifetime | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | | 283 ... Registration Ownership Verifier (ROVR) ... 284 | | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Figure 1: Enhanced Address Registration Option 289 Type: 33 291 Length: Defined in [RFC8505]. 293 Status: Defined in [RFC8505]. 295 Opaque: Defined in [RFC8505]. 297 Rsvd (Reserved): 3-bit unsigned integer. It MUST be set to zero by 298 the sender and MUST be ignored by the receiver. 300 C: This "C" flag is set to indicate that the ROVR field contains a 301 Crypto-ID and that the 6LN MAY be challenged for ownership as 302 specified in this document. 304 I, R, T: Defined in [RFC8505]. 306 TID: Defined in [RFC8505]. 308 Registration Ownership Verifier (ROVR): When the "C" flag is set, 309 this field contains a Crypto-ID. 311 This specification uses Status values "Validation Requested" and 312 "Validation Failed", which are defined in [RFC8505]. 314 this specification does not define any new Status value. 316 4.3. Crypto-ID Parameters Option 318 This specification defines the Crypto-ID Parameters Option (CIPO). 319 The CIPO carries the parameters used to form a Crypto-ID. 321 In order to provide cryptographic agility [RFC7696], this 322 specification supports different elliptic curves, indicated by a 323 Crypto-Type field: 325 * NIST P-256 [FIPS186-4] MUST be supported by all implementations. 327 * The Edwards-Curve Digital Signature Algorithm (EdDSA) curve 328 Ed25519 (PureEdDSA) [RFC8032] MAY be supported as an alternate. 330 * This specification uses signature schemes which target similar 331 cryptographic strength but rely on different curves, hash 332 functions, signature algorithms, and/or representation 333 conventions. Future specification may extend this for different 334 cryptographic algorithms and longer keys, e.g., to provide a 335 better security properties or a simpler implementation. 337 0 1 2 3 338 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 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Type | Length |Reserved1| Public Key Length | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Crypto-Type | Modifier | Reserved2 | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | | 345 | | 346 . . 347 . Public Key (variable length) . 348 . . 349 | | 350 | | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | | 353 . . 354 . Padding . 355 . . 356 | | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 Figure 2: Crypto-ID Parameters Option 361 Type: 8-bit unsigned integer. to be assigned by IANA, see Table 1. 363 Length: 8-bit unsigned integer. The length of the option in units 364 of 8 octets. 366 Reserved1: 5-bit unsigned integer. It MUST be set to zero by the 367 sender and MUST be ignored by the receiver. 369 Public Key Length: 11-bit unsigned integer. The length of the 370 Public Key field in bytes. 372 Crypto-Type: 8-bit unsigned integer. The type of cryptographic 373 algorithm used in calculation Crypto-ID (see Table 2 in 374 Section 8.3). 376 Modifier: 8-bit unsigned integer. Set to an arbitrary value by the 377 creator of the Crypto-ID. The role of the modifier is to enable 378 the formation of multiple Crypto-IDs from a same key pair, which 379 reduces the traceability and thus improves the privacy of a 380 constrained node that could not maintain many key-pairs. 382 Reserved2: 16-bit unsigned integer. It MUST be set to zero by the 383 sender and MUST be ignored by the receiver. 385 Public Key: A variable-length field, size indicated in the Public 386 Key Length field. JWK-Encoded Public Key [RFC7517]. 388 Padding: A variable-length field completing the Public Key field to 389 align to the next 8-bytes boundary. It MUST be set to zero by the 390 sender and MUST be ignored by the receiver. 392 The implementation of multiple hash functions in a constrained 393 devices may consume excessive amounts of program memory. This 394 specification enables the use of SHA-256 [RFC6234] for all the 395 supported ECC curves. 397 Some code factorization is also possible for the ECC computation 398 itself. [CURVE-REPRESENTATIONS] provides information on how to 399 represent Montgomery curves and (twisted) Edwards curves as curves in 400 short-Weierstrass form and illustrates how this can be used to 401 implement elliptic curve computations using existing implementations 402 that already provide, e.g., ECDSA and ECDH using NIST [FIPS186-4] 403 prime curves. 405 For more details on representation conventions, we refer to 406 Appendix B. 408 4.4. NDP Signature Option 410 This specification defines the NDP Signature Option (NDPSO). The 411 NDPSO carries the signature that proves the ownership of the Crypto- 412 ID. 414 The format of the NDP Signature Option (NDPSO) is illustrated in 415 Figure 3. 417 As opposed to the RSA Signature Option (RSAO) defined in section 5.2. 418 of SEND [RFC3971], the NDPSO does not have a key hash field. 419 Instead, the leftmost 128 bits of the ROVR field in the EARO are used 420 to retrieve the CIPO that contains the key material used for 421 signature verification, left-padded if needed. 423 Another difference is that the NDPSO signs a fixed set of fields as 424 opposed to all options that appear prior to it in the that bears the 425 signature. This allows to elide a CIPO that the 6LR already 426 received, at the expense of the capability to add arbitrary options 427 that would signed with a RSAO. 429 The CIPO may be present in the same message as the NDPSO. If not, it 430 can be found in an abstract table that was created by a previous 431 message and indexed by the hash. 433 0 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Type | Length |Reserved1| Signature Length | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Reserved2 | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | | 441 | | 442 . . 443 . Digital Signature . 444 . . 445 | | 446 | | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | | 449 . . 450 . Padding . 451 . . 452 | | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 Figure 3: NDP signature Option 457 Type: to be assigned by IANA, see Table 1. 459 Length: 8-bit unsigned integer. The length of the option in units 460 of 8 octets. 462 Reserved1: 5-bit unsigned integer. It MUST be set to zero by the 463 sender and MUST be ignored by the receiver. 465 Digital Signature Length: 11-bit unsigned integer. The length of 466 the Digital Signature field in bytes. 468 Reserved2: 32-bit unsigned integer. It MUST be set to zero by the 469 sender and MUST be ignored by the receiver. 471 Digital Signature: A variable-length field containing a digital 472 signature. The computation of the digital signature depends on 473 the Crypto-Type which is found in the associated CIPO. For the 474 values of the Crypto-Type that are defined in this specification, 475 the signature is computed as detailed in Section 6.2. 477 Padding: A variable-length field completing the Digital Signature 478 field to align to the next 8-bytes boundary. It MUST be set to 479 zero by the sender and MUST be ignored by the receiver. 481 5. Protocol Scope 483 The scope of the protocol specified here is a 6LoWPAN LLN, typically 484 a stub network connected to a larger IP network via a Border Router 485 called a 6LBR per [RFC6775]. A 6LBR has sufficient capability to 486 satisfy the needs of duplicate address detection. 488 The 6LBR maintains registration state for all devices in its attached 489 LLN. Together with the first-hop router (the 6LR), the 6LBR assures 490 uniqueness and grants ownership of an IPv6 address before it can be 491 used in the LLN. This is in contrast to a traditional network that 492 relies on IPv6 address auto-configuration [RFC4862], where there is 493 no guarantee of ownership from the network, and each IPv6 Neighbor 494 Discovery packet must be individually secured [RFC3971]. 496 ---+-------- ............ 497 | External Network 498 | 499 +-----+ 500 | | 6LBR 501 +-----+ 502 o o o 503 o o o o 504 o o LLN o o o 505 o o o (6LR) 506 o (6LN) 508 Figure 4: Basic Configuration 510 In a mesh network, the 6LR is directly connected to the host device. 511 This specification mandates that the peer-wise layer-2 security is 512 deployed so that all the packets from a particular host are securely 513 identifiable by the 6LR. The 6LR may be multiple hops away from the 514 6LBR. Packets are routed between the 6LR and the 6LBR via other 515 6LRs. This specification mandates that a chain of trust is 516 established so that a packet that was validated by the first 6LR can 517 be safely routed by other on-path 6LRs to the 6LBR. 519 6. Protocol Flows 521 The 6LR/6LBR ensures first-come/first-serve by storing the ROVR 522 associated to the address being registered upon the first 523 registration and rejecting a registration with a different ROVR 524 value. A 6LN can claim any address as long as it is the first to 525 make that claim. After a successful registration, the 6LN becomes 526 the owner of the registered address and the address is bound to the 527 ROVR value in the 6LR/6LBR registry. 529 This specification enables the 6LR to challenge the 6LN to verify its 530 ownership of the binding by placing a Crypto-ID in the ROVR. The 531 challenge can happen at any time at the discretion of the 6LR. The 532 6LR MUST challenge the 6LN when it creates a binding and when a new 533 registration attempts to change a parameter of the binding that 534 identifies the 6LN, for instance its Source Link-Layer Address. The 535 verification protects against a rogue that would steal an address and 536 attract its traffic, or use it as source address. 538 The challenge can also triggered by the 6LBR, e.g., to enforce a 539 global policy. In that case, the 6LBR returns a status of 540 "Validation Requested" in the DAR/DAC exchange, which is echoed by 541 the 6LR in the NA (EARO) back to the registering node. A valid 542 registration in the 6LR or the 6LBR MUST NOT be altered until the 543 challenge is complete. 545 A node may use more than one IPv6 address at the same time. The 546 separation of the address and the cryptographic material avoids 547 avoids the need for the constrained device to compute multiple keys 548 for multiple addresses. The 6LN MAY use the same Crypto-ID to prove 549 the ownership of multiple IPv6 addresses. The 6LN MAY also derive 550 multiple Crypto-IDs from a same key. 552 6.1. First Exchange with a 6LR 554 A 6LN registers to a 6LR that is one hop away from it with the "C" 555 flag set in the EARO, indicating that the ROVR field contains a 556 Crypto-ID. The Target Address in the NS message indicates the IPv6 557 address that the 6LN is trying to register [RFC8505]. The on-link 558 (local) protocol interactions are shown in Figure 5. If the 6LR does 559 not have a state with the 6LN that is consistent with the NS(EARO), 560 then it replies with a challenge NA (EARO, status=Validation 561 Requested) that contains a Nonce Option (shown as NonceLR in 562 Figure 5). 564 The Nonce option contains a Nonce value that, to the extent possible 565 for the implementation, was never employed in association with the 566 key pair used to generate the Crypto-ID. This specification inherits 567 from [RFC3971] that simply indicates that the nonce is a random 568 value. Ideally, an implementation uses an unpredictable 569 cryptographically random value [RFC4086]. But that may be 570 impractical in some LLN scenarios where the devices do not have a 571 guaranteed sense of time and for which computing complex hashes is 572 detrimental to the battery lifetime. Alternatively, the device may 573 use an always-incrementing value saved in the same stable storage as 574 the key, so they are lost together, and starting at a best effort 575 random value, either as the Nonce value or as a component to its 576 computation. 578 The 6LN replies to the challenge with an NS(EARO) that includes a new 579 Nonce option (shown as NonceLN in Figure 5), the CIPO (Section 4.3), 580 and the NDPSO containing the signature. Both Nonces are included in 581 the signed material. This provides a "contributory behavior", so 582 that either party that knows it generates a good quality Nonce knows 583 that the protocol will be secure. 585 The 6LR MUST store the information associated to a Crypto-ID on the 586 first NS exchange where it appears in a fashion that the CIPO 587 parameters can be retrieved from the Crypto-ID alone. 589 6LN 6LR 590 | | 591 |<------------------------- RA -------------------------| 592 | | ^ 593 |---------------- NS with EARO (Crypto-ID) ------------>| | 594 | | option 595 |<- NA with EARO (status=Validation Requested), NonceLR-| | 596 | | v 597 |------- NS with EARO, CIPO, NonceLN and NDPSO -------->| 598 | | 599 |<------------------- NA with EARO ---------------------| 600 | | 601 ... 602 | | 603 |--------------- NS with EARO (Crypto-ID) ------------->| 604 | | 605 |<------------------- NA with EARO ---------------------| 606 | | 607 ... 608 | | 609 |--------------- NS with EARO (Crypto-ID) ------------->| 610 | | 611 |<------------------- NA with EARO ---------------------| 612 | | 614 Figure 5: On-link Protocol Operation 616 The steps for the registration to the 6LR are as follows: 618 * Upon the first exchange with a 6LR, a 6LN will be challenged to 619 prove ownership of the Crypto-ID and the Target Address being 620 registered in the Neighbor Solicitation message. When a 6LR 621 receives a NS(EARO) registration with a new Crypto-ID as a ROVR, 622 and unless the registration is rejected for another reason, it 623 MUST challenge by responding with a NA(EARO) with a status of 624 "Validation Requested". 626 * Upon receiving a first NA(EARO) with a status of "Validation 627 Requested" from a 6LR, the registering node SHOULD retry its 628 registration with a Crypto-ID Parameters Option (CIPO) 629 (Section 4.3) that contains all the necessary material for 630 building the Crypto-ID, the NonceLN that it generated, and the NDP 631 signature (Section 4.4) option that proves its ownership of the 632 Crypto-ID and intent of registering the Target Address. In 633 subsequent revalidation with the same 6LR, the 6LN MAY try to omit 634 the CIPO to save bandwidth, with the expectation that the 6LR 635 saved it. If the validation fails and it gets challenged again, 636 then it SHOULD add the CIPO again. 638 * In order to validate the ownership, the 6LR performs the same 639 steps as the 6LN and rebuilds the Crypto-ID based on the 640 parameters in the CIPO. If the rebuilt Crypto-ID matches the 641 ROVR, the 6LN also verifies the signature contained in the NDPSO 642 option. If at that point the signature in the NDPSO option can be 643 verified, then the validation succeeds. Otherwise the validation 644 fails. 646 * If the 6LR fails to validate the signed NS(EARO), it responds with 647 a status of "Validation Failed". After receiving a NA(EARO) with 648 a status of "Validation Failed", the registering node SHOULD try 649 to register an alternate target address in the NS message. 651 6.2. NDPSO generation and verification 653 The signature generated by the 6LN to provide proof-of-ownership of 654 the private-key is carried in the NDP Signature Option (NDPSO). It 655 is generated by the 6LN in a fashion that depends on the Crypto-Type 656 (see Table 2 in Section 8.3) chosen by the 6LN as follows: 658 * Concatenate the following in the order listed: 660 1. The 128-bit Message Type tag [RFC3972] (in network byte order). 661 For this specification the tag is 0x8701 55c8 0cca dd32 6ab7 e415 662 f148 84d0. (The tag value has been generated by the editor of 663 this specification on random.org). 664 2. JWK-encoded public key 665 3. the 16-byte Target Address (in network byte order) sent in the 666 Neighbor Solicitation (NS) message. It is the address which the 667 6LN is registering with the 6LR and 6LBR. 668 4. NonceLR received from the 6LR (in network byte order) in the 669 Neighbor Advertisement (NA) message. The Nonce is at least 6 670 bytes long as defined in [RFC3971]. 671 5. NonceLN sent from the 6LN (in network byte order). The Nonce is 672 at least 6 bytes long as defined in [RFC3971]. 674 6. The length of the ROVR field containing the Crypto-ID. 675 7. 1-byte Crypto-Type value sent in the CIPO option. 677 * Apply the hash function (if any) specified by the Crypto-Type to 678 the concatenated data, e.g., hash the resulting data using SHA- 679 256. 681 * Apply the signature algorithm specified by the Crypto-Type, e.g., 682 sign the hash output with ECDSA (if curve P-256 is used) or sign 683 the hash with EdDSA (if curve Ed25519 (PureEdDSA)). 685 The 6LR on receiving the NDPSO and CIPO options first regenerates the 686 Crypto-ID based on the CIPO option to make sure that the leftmost 687 bits up to the size of the ROVR match. If and only if the check is 688 successful, it tries to verify the signature in the NDPSO option 689 using the following: 691 * Concatenate the following in the order listed: 693 1. 128-bit type tag (in network byte order) 694 2. JWK-encoded public key received in the CIPO option 695 3. the 16-byte Target Address (in network byte order) received in 696 the Neighbor Solicitation (NS) message. It is the address which 697 the 6LN is registering with the 6LR and 6LBR. 698 4. NonceLR sent in the Neighbor Advertisement (NA) message. The 699 Nonce is at least 6 bytes long as defined in [RFC3971]. 700 5. NonceLN received from the 6LN (in network byte order) in the NS 701 message. The Nonce is at least 6 bytes long as defined in 702 [RFC3971]. 703 6. The length of the ROVR field in the NS message containing the 704 Crypto-ID that was received. 705 7. 1-byte Crypto-Type value received in the CIPO option. 707 * Apply the hash function (if any) specified by the Crypto-Type 708 indicated by the 6LN in the CIPO to the concatenated data. 710 * Verify the signature with the public-key in the CIPO and the 711 locally computed values using the signature algorithm specified by 712 the Crypto-Type. If the verification succeeds, the 6LR propagates 713 the information to the 6LBR using a EDAR/EDAC flow. Due to the 714 first-come/first-serve nature of the registration, if the address 715 is not registered to the 6LBR, then flow succeeds and both the 6LR 716 and 6LBR add the state information about the Crypto-ID and Target 717 Address being registered to their respective abstract database. 719 6.3. Multihop Operation 721 A new 6LN that joins the network auto-configures an address and 722 performs an initial registration to a neighboring 6LR with an NS 723 message that carries an Address Registration Option (EARO) [RFC8505]. 725 In a multihop 6LoWPAN, the registration with Crypto-ID is propagated 726 to 6LBR as shown in Figure 6, which illustrates the registration flow 727 all the way to a 6LowPAN Backbone Router (6BBR) [BACKBONE-ROUTER]. 729 The 6LR and the 6LBR communicate using ICMPv6 Extended Duplicate 730 Address Request (EDAR) and Extended Duplicate Address Confirmation 731 (EDAC) messages [RFC8505] as shown in Figure 6. This specification 732 extends EDAR/EDAC messages to carry cryptographically generated ROVR. 734 The assumption is that the 6LR and the 6LBR maintain a security 735 association, so there is no need to propagate the proof of ownership 736 to the 6LBR. The 6LBR implicitly trusts that the 6LR performs the 737 verification when the 6LBR requires it, and if there is no further 738 exchange from the 6LR to remove the state, that the verification 739 succeeded. 741 6LN 6LR 6LBR 6BBR 742 | | | | 743 | NS(EARO) | | | 744 |--------------->| | | 745 | | Extended DAR | | 746 | |-------------->| | 747 | | | | 748 | | | proxy NS(EARO) | 749 | | |--------------->| 750 | | | | NS(DAD) 751 | | | | ------> 752 | | | | 753 | | | | 754 | | | | 755 | | | proxy NA(EARO) | 756 | | |<---------------| 757 | | Extended DAC | | 758 | |<--------------| | 759 | NA(EARO) | | | 760 |<---------------| | | 761 | | | | 763 Figure 6: (Re-)Registration Flow 765 7. Security Considerations 767 7.1. Inheriting from RFC 3971 769 Observations regarding the following threats to the local network in 770 [RFC3971] also apply to this specification. 772 Neighbor Solicitation/Advertisement Spoofing: Threats in section 773 9.2.1 of RFC3971 apply. AP-ND counters the threats on NS(EARO) 774 messages by requiring that the NDP Signature and CIPO options be 775 present in these solicitations. 777 Duplicate Address Detection DoS Attack: Inside the LLN, Duplicate 778 Addresses are sorted out using the ROVR, which differentiates it 779 from a movement. A different ROVR for the same Registered address 780 entails a rejection of the second registration [RFC8505]. DAD 781 coming from the backbone are not forwarded over the LLN, which 782 provides some protection against DoS attacks inside the resource- 783 constrained part of the network. Over the backbone, the EARO 784 option is present in NS/NA messages. This protects against 785 misinterpreting a movement for a duplication, and enables the 786 backbone routers to determine which one has the freshest 787 registration [RFC8505] and is thus the best candidate to validate 788 the registration for the device attached to it [BACKBONE-ROUTER]. 789 But this specification does not guarantee that the backbone router 790 claiming an address over the backbone is not an attacker. 792 Router Solicitation and Advertisement Attacks: This specification 793 does not change the protection of RS and RA which can still be 794 protected by SEND. 796 Replay Attacks Using Nonces (NonceLR and NonceLN) generated by both 797 the 6LR and 6LN ensure a contributory behavior that provides an 798 efficient protection against replay attacks of the challenge/ 799 response flow. A nonce should never repeat for a same key. The 800 protection depends on the quality of the Nonce computation, e.g., 801 of a random number generator when used to compute the Nonce. 803 Neighbor Discovery DoS Attack: A rogue node that managed to access 804 the L2 network may form many addresses and register them using AP- 805 ND. The perimeter of the attack is all the 6LRs in range of the 806 attacker. The 6LR MUST protect itself against overflows and 807 reject excessive registration with a status 2 "Neighbor Cache 808 Full". This effectively blocks another (honest) 6LN from 809 registering to the same 6LR, but the 6LN may register to other 810 6LRs that are in its range but not in that of the rogue. 812 7.2. Related to 6LoWPAN ND 814 The threats and mediations discussed in 6LoWPAN ND [RFC6775][RFC8505] 815 also apply here, in particular denial-of-service attacks against the 816 registry at the 6LR or 6LBR. 818 Secure ND [RFC3971] forces the IPv6 address to be cryptographic since 819 it integrates the CGA as the IID in the IPv6 address. In contrast, 820 this specification saves about 1Kbyte in every NS/NA message. Also, 821 this specification separates the cryptographic identifier from the 822 registered IPv6 address so that a node can have more than one IPv6 823 address protected by the same cryptographic identifier. 825 With this specification the 6LN can freely form its IPv6 address(es) 826 in any fashion, thereby enabling either 6LoWPAN compression for IPv6 827 addresses that are derived from Layer-2 addresses, or temporary 828 addresses, e.g., formed pseudo-randomly and released in relatively 829 short cycles for privacy reasons [RFC8064][RFC8065], that cannot be 830 compressed. 832 This specification provides added protection for addresses that are 833 obtained following due procedure [RFC8505] but does not constrain the 834 way the addresses are formed or the number of addresses that are used 835 in parallel by a same entity. A rogue may still perform denial-of- 836 service attack against the registry at the 6LR or 6LBR, or attempt to 837 deplete the pool of available addresses at Layer-2 or Layer-3. 839 7.3. ROVR Collisions 841 A collision of Registration Ownership Verifiers (ROVR) (i.e., the 842 Crypto-ID in this specification) is possible, but it is a rare event. 843 Assuming in the calculations/discussion below that the hash used for 844 calculating the Crypto-ID is a well-behaved cryptographic hash and 845 thus that random collisions are the only ones possible, the formula 846 (birthday paradox) for calculating the probability of a collision is 847 1 - e^{-k^2/(2n)} where n is the maximum population size (2^64 here, 848 1.84E19) and k is the actual population (number of nodes, assuming 849 one Crypto-ID per node). 851 If the Crypto-ID is 64-bits (the least possible size allowed), the 852 chance of a collision is 0.01% for network of 66 million nodes. 853 Moreover, the collision is only relevant when this happens within one 854 stub network (6LBR). In the case of such a collision, a third party 855 node would be able to claim the registered address of an another 856 legitimate node, provided that it wishes to use the same address. To 857 prevent address disclosure and avoid the chances of collision on both 858 the RIVR and the address, it is RECOMMENDED that nodes do not derive 859 the address being registered from the ROVR. 861 7.4. Implementation Attacks 863 The signature schemes referenced in this specification comply with 864 NIST [FIPS186-4] or Crypto Forum Research Group (CFRG) standards 865 [RFC8032] and offer strong algorithmic security at roughly 128-bit 866 security level. These signature schemes use elliptic curves that 867 were either specifically designed with exception-free and constant- 868 time arithmetic in mind [BCP 201] or where one has extensive 869 implementation experience of resistance to timing attacks 870 [FIPS186-4]. However, careless implementations of the signing 871 operations could nevertheless leak information on private keys. For 872 example, there are micro-architectural side channel attacks that 873 implementors should be aware of [breaking-ed25519]. Implementors 874 should be particularly aware that a secure implementation of Ed25519 875 requires a protected implementation of the hash function SHA-512, 876 whereas this is not required with implementations of SHA-256 used 877 with ECDSA. 879 7.5. Cross-Algorithm and Cross-Protocol Attacks 881 The keypair used in this specification can be self-generated and the 882 public key does not need to be exchanged, e.g., through certificates, 883 with a third party before it is used. New keypairs can be formed for 884 new registration as the node desires. On the other hand, it is safer 885 to allocate a keypair that is used only for the address protection 886 and only for one signature scheme. The same private key MUST NOT be 887 reused with more than one signature scheme in this specification. 888 The same private key MUST NOT be used for anything other than 889 computing NDPSO signatures per this specification. 891 7.6. Compromised 6LR 893 This specification distributes the challenge and its validation at 894 the edge of the network, between the 6LN and its 6LR. This protects 895 against DOS attacks targeted at that central 6LBR. This also saves 896 back and forth exchanges across a potentially large and constrained 897 network. The downside is that the 6LBR needs to trust the 6LR for 898 performing the checking adequately, and the communication between the 899 6LR and the 6LBR must be protected to avoid tempering with the result 900 of the test. 902 If a 6LR is compromised, and provided that it knows the ROVR field 903 used by the real owner of the address, the 6LR may pretend that the 904 owner has moved, is now attached to it and has successfully passed 905 the Crpto-ID validation. The 6LR may then attract and inject traffic 906 at will on behalf of that address. Similarly, the 6LR may admit any 907 rogue and let it take ownership of any address in the network for 908 which it knows the value of ROVR. 910 8. IANA considerations 912 8.1. CGA Message Type 914 This document defines a new 128-bit value under the CGA Message Type 915 [RFC3972] name space: 0x8701 55c8 0cca dd32 6ab7 e415 f148 84d0. 917 8.2. IPv6 ND option types 919 This document registers two new ND option types under the subregistry 920 "IPv6 Neighbor Discovery Option Formats": 922 +------------------------------+-----------------+---------------+ 923 | Option Name | Suggested Value | Reference | 924 +==============================+=================+===============+ 925 | NDP Signature Option (NDPSO) | 38 | This document | 926 +------------------------------+-----------------+---------------+ 927 | Crypto-ID Parameters Option | 39 | This document | 928 | (CIPO) | | | 929 +------------------------------+-----------------+---------------+ 931 Table 1: New ND options 933 8.3. Crypto-Type Subregistry 935 IANA is requested to create a new subregistry "Crypto-Type 936 Subregistry" in the "Internet Control Message Protocol version 6 937 (ICMPv6) Parameters". The registry is indexed by an integer in the 938 interval 0..255 and contains an Elliptic Curve, a Hash Function, a 939 Signature Algorithm, and Representation Conventions, as shown in 940 Table 2, which together specify a signature scheme. The following 941 Crypto-Type values are defined in this document: 943 +----------------+-----------------+-------------+-----------------+ 944 | Crypto-Type | 0 (ECDSA256) | 1 (Ed25519) | 2 (ECDSA25519) | 945 | value | | | | 946 +================+=================+=============+=================+ 947 | Elliptic curve | NIST P-256 | Curve25519 | Curve25519 [BCP | 948 | | [FIPS186-4] | [BCP 201] | 201] | 949 +----------------+-----------------+-------------+-----------------+ 950 | Hash function | SHA-256 | SHA-512 | SHA-256 | 951 | | [RFC6234] | [RFC6234] | [RFC6234] | 952 +----------------+-----------------+-------------+-----------------+ 953 | Signature | ECDSA | Ed25519 | ECDSA | 954 | algorithm | [FIPS186-4] | [RFC8032] | [FIPS186-4] | 955 +----------------+-----------------+-------------+-----------------+ 956 | Representation | Weierstrass, | Edwards, | Weierstrass, | 957 | conventions | (un)compressed, | compressed, | (un)compressed, | 958 | | MSB/msb first | LSB/lsb | MSB/msb first | 959 | | | first | | 960 +----------------+-----------------+-------------+-----------------+ 961 | Defining | This document | This | This document | 962 | specification | | document | | 963 +----------------+-----------------+-------------+-----------------+ 965 Table 2: Crypto-Types 967 New Crypto-Type values providing similar or better security may be 968 defined in the future. 970 Assignment of new values for new Crypto-Type MUST be done through 971 IANA with either "Specification Required" or "IESG Approval" as 972 defined in [RFC8126]. 974 9. Acknowledgments 976 Many thanks to Charlie Perkins for his in-depth review and 977 constructive suggestions. The authors are also especially grateful 978 to Robert Moskowitz for his comments that led to many improvements. 979 The authors wish to thank Benjamin Kaduk, Mirja Kuhlewind, Eric 980 Vyncke, Vijay Gurbani, Al Morton and Adam Montville for their 981 constructive reviews during the IESG process. 983 10. Normative References 985 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 986 Requirement Levels", BCP 14, RFC 2119, 987 DOI 10.17487/RFC2119, March 1997, 988 . 990 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 991 Bormann, "Neighbor Discovery Optimization for IPv6 over 992 Low-Power Wireless Personal Area Networks (6LoWPANs)", 993 RFC 6775, DOI 10.17487/RFC6775, November 2012, 994 . 996 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 997 DOI 10.17487/RFC7517, May 2015, 998 . 1000 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1001 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1002 May 2017, . 1004 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 1005 "SEcure Neighbor Discovery (SEND)", RFC 3971, 1006 DOI 10.17487/RFC3971, March 2005, 1007 . 1009 [BCP 201] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1010 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1011 2016, . 1013 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 1014 Signature Algorithm (EdDSA)", RFC 8032, 1015 DOI 10.17487/RFC8032, January 2017, 1016 . 1018 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 1019 Perkins, "Registration Extensions for IPv6 over Low-Power 1020 Wireless Personal Area Network (6LoWPAN) Neighbor 1021 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 1022 . 1024 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 1025 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 1026 DOI 10.17487/RFC6234, May 2011, 1027 . 1029 [FIPS186-4] 1030 FIPS 186-4, "Digital Signature Standard (DSS), Federal 1031 Information Processing Standards Publication 186-4", US 1032 Department of Commerce/National Institute of Standards and 1033 Technology , July 2013. 1035 [SEC1] SEC1, "SEC 1: Elliptic Curve Cryptography, Version 2.0", 1036 Standards for Efficient Cryptography , June 2009. 1038 11. Informative references 1040 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1041 RFC 3972, DOI 10.17487/RFC3972, March 2005, 1042 . 1044 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1045 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1046 DOI 10.17487/RFC4861, September 2007, 1047 . 1049 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1050 Address Autoconfiguration", RFC 4862, 1051 DOI 10.17487/RFC4862, September 2007, 1052 . 1054 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1055 "Transmission of IPv6 Packets over IEEE 802.15.4 1056 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1057 . 1059 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1060 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1061 DOI 10.17487/RFC6282, September 2011, 1062 . 1064 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1065 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1066 Overview, Assumptions, Problem Statement, and Goals", 1067 RFC 4919, DOI 10.17487/RFC4919, August 2007, 1068 . 1070 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1071 "Randomness Requirements for Security", BCP 106, RFC 4086, 1072 DOI 10.17487/RFC4086, June 2005, 1073 . 1075 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1076 Writing an IANA Considerations Section in RFCs", BCP 26, 1077 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1078 . 1080 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 1081 "Source Address Validation Improvement (SAVI) Framework", 1082 RFC 7039, DOI 10.17487/RFC7039, October 2013, 1083 . 1085 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1086 Interface Identifiers with IPv6 Stateless Address 1087 Autoconfiguration (SLAAC)", RFC 7217, 1088 DOI 10.17487/RFC7217, April 2014, 1089 . 1091 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 1092 Agility and Selecting Mandatory-to-Implement Algorithms", 1093 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 1094 . 1096 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 1097 "Recommendation on Stable IPv6 Interface Identifiers", 1098 RFC 8064, DOI 10.17487/RFC8064, February 2017, 1099 . 1101 [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- 1102 Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, 1103 February 2017, . 1105 [BACKBONE-ROUTER] 1106 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 1107 Backbone Router", Work in Progress, Internet-Draft, draft- 1108 ietf-6lo-backbone-router-13, 26 September 2019, 1109 . 1112 [CURVE-REPRESENTATIONS] 1113 Struik, R., "Alternative Elliptic Curve Representations", 1114 Work in Progress, Internet-Draft, draft-ietf-lwig-curve- 1115 representations-08, 24 July 2019, 1116 . 1119 [breaking-ed25519] 1120 Samwel, N., Batina, L., Bertoni, G., Daemen, J., and R. 1121 Susella, "Breaking Ed25519 in WolfSSL", Cryptographers' 1122 Track at the RSA Conference , 2018, 1123 . 1126 Appendix A. Requirements Addressed in this Document 1128 In this section we state requirements of a secure neighbor discovery 1129 protocol for low-power and lossy networks. 1131 * The protocol MUST be based on the Neighbor Discovery Optimization 1132 for Low-power and Lossy Networks protocol defined in [RFC6775]. 1134 RFC6775 utilizes optimizations such as host-initiated interactions 1135 for sleeping resource-constrained hosts and elimination of 1136 multicast address resolution. 1137 * New options to be added to Neighbor Solicitation messages MUST 1138 lead to small packet sizes, especially compared with existing 1139 protocols such as SEcure Neighbor Discovery (SEND). Smaller 1140 packet sizes facilitate low-power transmission by resource- 1141 constrained nodes on lossy links. 1142 * The support for this registration mechanism SHOULD be extensible 1143 to more LLN links than IEEE 802.15.4 only. Support for at least 1144 the LLN links for which a 6lo "IPv6 over foo" specification 1145 exists, as well as Low-Power Wi-Fi SHOULD be possible. 1146 * As part of this extension, a mechanism to compute a unique 1147 Identifier should be provided with the capability to form a Link 1148 Local Address that SHOULD be unique at least within the LLN 1149 connected to a 6LBR. 1150 * The Address Registration Option used in the ND registration SHOULD 1151 be extended to carry the relevant forms of Unique Interface 1152 Identifier. 1153 * The Neighbor Discovery should specify the formation of a site- 1154 local address that follows the security recommendations from 1155 [RFC7217]. 1157 Appendix B. Representation Conventions 1159 B.1. Signature Schemes 1161 The signature scheme ECDSA256 corresponding to Crypto-Type 0 is 1162 ECDSA, as specified in [FIPS186-4], instantiated with the NIST prime 1163 curve P-256, as specified in Appendix B of [FIPS186-4], and the hash 1164 function SHA-256, as specified in [RFC6234], where points of this 1165 NIST curve are represented as points of a short-Weierstrass curve 1166 (see [FIPS186-4]) and are encoded as octet strings in most- 1167 significant-bit first (msb) and most-significant-byte first (MSB) 1168 order. The signature itself consists of two integers (r and s), 1169 which are each encoded as fixed-size octet strings in most- 1170 significant-bit first and most-significant-byte first order. For 1171 details on ECDSA, see [FIPS186-4]; for details on the integer 1172 encoding, see Appendix B.2. 1174 The signature scheme Ed25519 corresponding to Crypto-Type 1 is EdDSA, 1175 as specified in [RFC8032], instantiated with the Montgomery curve 1176 Curve25519, as specified in [BCP 201], and the hash function SHA-512, 1177 as specified in [RFC6234], where points of this Montgomery curve are 1178 represented as points of the corresponding twisted Edwards curve (see 1179 Appendix B.3) and are encoded as octet strings in least-significant- 1180 bit first (lsb) and least-significant-byte first (LSB) order. The 1181 signature itself consists of a bit string that encodes a point of 1182 this twisted Edwards curve, in compressed format, and an integer 1183 encoded in least-significant-bit first and least-significant-byte 1184 first order. For details on EdDSA and on the encoding conversions, 1185 see the specification of pure Ed25519 in . [RFC8032] 1187 The signature scheme ECDSA25519 corresponding to Crypto-Type 2 is 1188 ECDSA, as specified in [FIPS186-4], instantiated with the Montgomery 1189 curve Curve25519, as specified in [BCP 201], and the hash function 1190 SHA-256, as specified in [RFC6234], where points of this Montgomery 1191 curve are represented as points of a corresponding curve in short- 1192 Weierstrass form (see Appendix B.3) and are encoded as octet strings 1193 in most-significant-bit first and most-significant-byte first order. 1194 The signature itself consists of a bit string that encodes two 1195 integers, each encoded as fixed-size octet strings in most- 1196 significant-bit first and most-significant-byte first order. For 1197 details on ECDSA, see [FIPS186-4]; for details on the integer 1198 encoding, see Appendix B.2 1200 B.2. Integer Representation for ECDSA signatures 1202 With ECDSA, each signature is a pair (r, s) of integers [FIPS186-4]. 1203 Each integer is encoded as a fixed-size 256-bit bit string, where 1204 each integer is represented according to the Field Element to Octet 1205 String and Octet String to Bit String conversion rules in [SEC1] and 1206 where the ordered pair of integers is represented as the 1207 rightconcatenation of the resulting representation values. The 1208 inverse operation follows the corresponding Bit String to Octet 1209 String and Octet String to Field Element conversion rules of [SEC1]. 1211 B.3. Alternative Representations of Curve25519 1213 The elliptic curve Curve25519, as specified in [BCP 201], is a so- 1214 called Montgomery curve. Each point of this curve can also be 1215 represented as a point of a twisted Edwards curve or as a point of an 1216 elliptic curve in short-Weierstrass form, via a coordinate 1217 transformation (a so-called isomorphic mapping). The parameters of 1218 the Montgomery curve and the corresponding isomorphic curves in 1219 twisted Edwards curve and short-Weierstrass form are as indicated 1220 below. Here, the domain parameters of the Montgomery curve 1221 Curve25519 and of the twisted Edwards curve Edwards25519 are as 1222 specified in [BCP 201]; the domain parameters of the elliptic curve 1223 Wei25519 in short-Weierstrass curve comply with Section 6.1.1 of 1224 [FIPS186-4]. For details of the coordinate transformation referenced 1225 above, see [BCP 201] and [CURVE-REPRESENTATIONS]. 1227 General parameters (for all curve models): 1229 p 2^{255}-19 1230 (=0x7fffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 1231 ffffffed) 1232 h 8 1233 n 1234 723700557733226221397318656304299424085711635937990760600195093828 1235 5454250989 1236 (=2^{252} + 0x14def9de a2f79cd6 5812631a 5cf5d3ed) 1238 Montgomery curve-specific parameters (for Curve25519): 1240 A 486662 1241 B 1 1242 Gu 9 (=0x9) 1243 Gv 1244 147816194475895447910205935684099868872646061346164752889648818377 1245 55586237401 1246 (=0x20ae19a1 b8a086b4 e01edd2c 7748d14c 923d4d7e 6d7c61b2 29e9c5a2 1247 7eced3d9) 1249 Twisted Edwards curve-specific parameters (for Edwards25519): 1251 a -1 (-0x01) 1252 d -121665/121666 1253 (=3709570593466943934313808350875456518954211387984321901638878553 1254 3085940283555) 1255 (=0x52036cee 2b6ffe73 8cc74079 7779e898 00700a4d 4141d8ab 75eb4dca 1256 135978a3) 1257 Gx 1258 151122213495354007725011514095885315114540126930418572060461132839 1259 49847762202 1260 (=0x216936d3 cd6e53fe c0a4e231 fdd6dc5c 692cc760 9525a7b2 c9562d60 1261 8f25d51a) 1262 Gy 4/5 1263 (=4631683569492647816942839400347516314130799386625622561578303360 1264 3165251855960) 1265 (=0x66666666 66666666 66666666 66666666 66666666 66666666 66666666 1266 66666658) 1268 Weierstrass curve-specific parameters (for Wei25519): 1270 a 1271 192986815395526992372618308347813179755449974442734273399095973345 1272 73241639236 1273 (=0x2aaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaa98 1274 4914a144) 1275 b 1276 557517466698189089076452890782571408182411037279010123152944008379 1277 56729358436 1278 (=0x7b425ed0 97b425ed 097b425e d097b425 ed097b42 5ed097b4 260b5e9c 1279 7710c864) 1280 GX 1281 192986815395526992372618308347813179755449974442734273399095973346 1282 52188435546 1283 (=0x2aaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa 1284 aaad245a) 1285 GY 1286 147816194475895447910205935684099868872646061346164752889648818377 1287 55586237401 1288 (=0x20ae19a1 b8a086b4 e01edd2c 7748d14c 923d4d7e 6d7c61b2 29e9c5a2 1289 7eced3d9) 1291 Authors' Addresses 1293 Pascal Thubert (editor) 1294 Cisco Systems, Inc 1295 Building D 1296 45 Allee des Ormes - BP1200 1297 06254 MOUGINS - Sophia Antipolis 1298 France 1300 Phone: +33 497 23 26 34 1301 Email: pthubert@cisco.com 1303 Behcet Sarikaya 1305 Email: sarikaya@ieee.org 1307 Mohit Sethi 1308 Ericsson 1309 FI-02420 Jorvas 1310 Finland 1312 Email: mohit@piuha.net 1314 Rene Struik 1315 Struik Security Consultancy 1316 Email: rstruik.ext@gmail.com