idnits 2.17.1 draft-ietf-6lo-ap-nd-07.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 abstract seems to contain references ([I-D.ietf-6lo-RFC6775-update], [RFC6775]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC6775, but the abstract doesn't seem to directly say this. It does mention RFC6775 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 3, 2018) is 2056 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-186-4' ** Downref: Normative reference to an Informational RFC: RFC 6606 ** Downref: Normative reference to an Informational RFC: RFC 7228 == Outdated reference: A later version (-20) exists of draft-ietf-6lo-backbone-router-06 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 3 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: 6775 (if approved) B. Sarikaya 5 Intended status: Standards Track 6 Expires: March 7, 2019 M. Sethi 7 Ericsson 8 September 3, 2018 10 Address Protected Neighbor Discovery for Low-power and Lossy Networks 11 draft-ietf-6lo-ap-nd-07 13 Abstract 15 This document defines an extension to 6LoWPAN Neighbor Discovery (ND) 16 [RFC6775] [I-D.ietf-6lo-rfc6775-update] called Address Protected ND 17 (AP-ND); AP-ND protects the owner of an address against address theft 18 and impersonation inside a low-power and lossy network (LLN). Nodes 19 supporting this extension compute a cryptographic Owner Unique 20 Interface ID and associate it with one or more of their Registered 21 Addresses. The Cryptographic ID identifies the owner of the 22 Registered Address and can be used for proof-of-ownership. It is 23 used in 6LoWPAN ND in place of the EUI-64-based unique ID that is 24 associated with the registration. Once an address is registered with 25 a Cryptographic ID, only the owner of that ID can modify the 26 registration information of the Registered Address, and Source 27 Address Validation can be enforced. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on March 7, 2019. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 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. References . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.3. 6LoWPAN sub-glossary . . . . . . . . . . . . . . . . . . 5 68 2.4. Crypto-ID . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3. Updating RFC 6775 . . . . . . . . . . . . . . . . . . . . . . 6 70 4. New Fields and Options . . . . . . . . . . . . . . . . . . . 6 71 4.1. Encoding the Public Key . . . . . . . . . . . . . . . . . 7 72 4.2. New Crypto-ID . . . . . . . . . . . . . . . . . . . . . . 7 73 4.3. Updated EARO . . . . . . . . . . . . . . . . . . . . . . 7 74 4.4. Crypto-ID Parameters Option . . . . . . . . . . . . . . . 9 75 4.5. Nonce Option . . . . . . . . . . . . . . . . . . . . . . 10 76 4.6. NDP Signature Option . . . . . . . . . . . . . . . . . . 10 77 5. Protocol Scope . . . . . . . . . . . . . . . . . . . . . . . 10 78 6. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . 11 79 6.1. First Exchange with a 6LR . . . . . . . . . . . . . . . . 12 80 6.2. Multihop Operation . . . . . . . . . . . . . . . . . . . 13 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 82 7.1. Inheriting from RFC 3971 . . . . . . . . . . . . . . . . 15 83 7.2. Related to 6LoWPAN ND . . . . . . . . . . . . . . . . . . 16 84 7.3. ROVR Collisions . . . . . . . . . . . . . . . . . . . . . 16 85 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17 86 8.1. CGA Message Type . . . . . . . . . . . . . . . . . . . . 17 87 8.2. Crypto-Type Subregistry . . . . . . . . . . . . . . . . . 17 88 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 91 10.2. Informative references . . . . . . . . . . . . . . . . . 19 92 Appendix A. Requirements Addressed in this Document . . . . . . 21 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 95 1. Introduction 97 "Neighbor Discovery Optimizations for 6LoWPAN networks" [RFC6775] 98 (6LoWPAN ND) adapts the IPv6 ND (NDv6) protocol [RFC4861][RFC4862] 99 (IPv6 ND) for operations over a constrained low-power and lossy 100 network (LLN). In particular, 6LoWPAN ND introduces a unicast host 101 address registration mechanism that reduces the use of multicast 102 messages that are present in the NDv6 protocol. 6LoWPAN ND defines a 103 new Address Registration Option (ARO) that is carried in the unicast 104 Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages 105 exchanged between a 6LoWPAN Node (6LN) and a 6LoWPAN Router (6LR). 106 It also defines the Duplicate Address Request (DAR) and Duplicate 107 Address Confirmation (DAC) messages between the 6LR and the 6LoWPAN 108 Border Router (6LBR). In LLN networks, the 6LBR is the central 109 repository of all the registered addresses in its domain. 111 The registration mechanism in 6LoWPAN ND [RFC6775] prevents the use 112 of an address if that address is already registered in the subnet 113 (first come first serve). In order to validate address ownership, 114 the registration mechanism enables the 6LR and 6LBR to validate the 115 association between a registered address and a Registration Ownership 116 Verifier (ROVR). 6LoWPAN ND specifies that the ROVR is derived from 117 the MAC address of the device (using the 64-bit Extended Unique 118 Identifier EUI-64 address format specified by IEEE), which can be 119 spoofed. Therefore, any node connected to the subnet and aware of a 120 registered-address-to-ROVR mapping could effectively fake the ROVR, 121 steal the address and redirect traffic for that address towards a 122 different 6LN. The "Registration Extensions for 6LoWPAN Neighbor 123 Discovery" [I-D.ietf-6lo-rfc6775-update] defines an Extended ARO 124 (EARO) option that allows to transport alternate forms of ROVRs, and 125 is a prerequisite for this specification. 127 According to this specification, a 6LN generates a cryptographic ID 128 (Crypto-ID) and places it in the ROVR field in the registration of 129 one (or more) of its addresses with the 6LR(s) that the 6LN uses as 130 default router(s). Proof of ownership of the cryptographic ID 131 (Crypto-ID) is passed with the first registration exchange to a new 132 6LR, and enforced at the 6LR. The 6LR validates ownership of the 133 cryptographic ID before it can create a registration, or a change the 134 information, that is the Link-Layer Address and associated 135 parameters, in an existing registration state. 137 The protected address registration protocol proposed in this document 138 enables Source Address Validation (SAVI) [RFC7039], which ensures 139 that only the owner uses a registered address in the source address 140 field in IPv6 packets. Consequently, a 6LN that sources a packet has 141 to use a 6LR to which the source address of the packet is registered 142 to forward the packet. The 6LR maintains state information for the 143 registered addressed, including the MAC address, and a link-layer 144 cryptographic key associated with the 6LN. In SAVI-enforcement mode, 145 the 6LR allows only packets from a connected Host if the connected 146 Host owns the registration of the source address of the packet. 148 The 6lo adaptation layer framework ([RFC4944], [RFC6282]) specifies 149 that a device forms its IPv6 addresses based on Layer-2 address, so 150 as to enable a better compression. This is incompatible with "Secure 151 Neighbor Discovery (SeND)" [RFC3971] and "Cryptographically Generated 152 Addresses (CGAs)" [RFC3972], which derive the Interface ID (IID) in 153 the IPv6 addresses from key material. "Privacy Considerations for 154 IPv6 Address Generation Mechanisms" [RFC7721] places additional 155 recommendations on the way addresses should be formed and renewed. 157 This document specifies that a device may form and register addresses 158 at will, without a constraint on the way the address is formed or the 159 number of addresses that are registered in parallel, Multiple 160 addresses with a single ROVR, which only needs to be sent once to a 161 given 6LR for multiple addresses and registration updates. 163 2. Terminology 165 2.1. BCP 14 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 169 "OPTIONAL" in this document are to be interpreted as described in BCP 170 14 [RFC2119] [RFC8174] when, and only when, they appear in all 171 capitals, as shown here. 173 2.2. References 175 In this document, readers will encounter terms and concepts that are 176 discussed in the following documents: 178 o "SEcure Neighbor Discovery (SEND)" [RFC3971], 180 o "Cryptographically Generated Addresses (CGA)" [RFC3972], 182 o "Neighbor Discovery for IP version 6" [RFC4861], 184 o "IPv6 Stateless Address Autoconfiguration" [RFC4862], 186 o "Problem Statement and Requirements for IPv6 over Low-Power 187 Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606], 189 o "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): 190 Overview, Assumptions, Problem Statement, and Goals" [RFC4919], 192 o "Neighbor Discovery Optimization for Low-power and Lossy Networks" 193 [RFC6775], 195 o "Terms Used in Routing for Low-Power and Lossy Networks (LLNs)" 196 [RFC7102], 198 o "Terminology for Constrained-Node Networks" [RFC7228], and 200 o "Registration Extensions for 6LoWPAN Neighbor Discovery" 201 [I-D.ietf-6lo-rfc6775-update] 203 2.3. 6LoWPAN sub-glossary 205 This document often uses the following acronyms: 207 6BBR: 6LoWPAN Backbone Router (proxy for the registration) 208 [I-D.ietf-6lo-backbone-router] 210 6LBR: 6LoWPAN Border Router 212 6LN: 6LoWPAN Node 214 6LR: 6LoWPAN Router (relay to the registration process) 216 CIPO: Crypto-ID Parameters Option 218 (E)ARO: (Extended) Address Registration Option 220 DAD: Duplicate Address Detection 222 LLN: Low-Power and Lossy Network (a typical IoT network) 224 NA: Neighbor Advertisement 226 ND: Neighbor Discovery 228 NDP: Neighbor Discovery Protocol 230 NDPSO: NDP Signature Option 232 NS: Neighbor Solicitation 234 ROVR: Registration Ownership Verifier (pronounced rover) 236 RA: Router Advertisement 238 RS: Router Solicitation 239 RSAO: RSA Signature Option 241 TID: Transaction ID (a sequence counter in the EARO) 243 2.4. Crypto-ID 245 This document defines a new Crypto-ID as an identifier of variable 246 size which is 64 to 256 bits long. It is generated using 247 cryptographic means explained later in this document Section 4.2. 248 "Elliptic Curves for Security" [RFC7748] and "Edwards-Curve Digital 249 Signature Algorithm (EdDSA)" [RFC8032] provides information on 250 Elliptic Curve Cryptography (ECC) and a (twisted) Edwards curve, 251 Ed25519, which can be used with this specification. "Alternative 252 Elliptic Curve Representations" 253 [I-D.struik-lwig-curve-representations] provides additional 254 information on how to represent Montgomery curves and (twisted) 255 Edwards curves as curves in short-Weierstrass form and illustrates 256 how this can be used to implement elliptic curve computations using 257 existing implementations that already implement, e.g., ECDSA and ECDH 258 using NIST [FIPS-186-4] prime curves. 260 3. Updating RFC 6775 262 This specification defines a cryptographic identifier (Crypto-ID) 263 that can be used as a replacement to the MAC address in the ROVR 264 field of the EARO option; the computation of the Crypto-ID is 265 detailed in Section 4.2. A node in possession of the necessary 266 cryptographic material SHOULD use Crypto-ID by default as ROVR in its 267 registration. Whether a ROVR is a Crypto-ID is indicated by a new 268 "C" flag in the NS(EARO) message. 270 In order to prove its ownership of a Crypto-ID, the registering node 271 needs to supply certain parameters including a nonce and a signature 272 that will prove that the node has the private key corresponding to 273 the public key used to build the Crypto-ID. This specification adds 274 the capability to carry new options in the NS(EARO) and the NA(EARO). 275 The NS(EARO) carries a variation of the CGA Option (Section 4.4), a 276 Nonce option and a variation of the RSA Signature option 277 (Section 4.6) in the NS(EARO). The NA(EARO) carries a Nonce option. 279 4. New Fields and Options 281 In order to avoid the need for new ND option types, this 282 specification reuses / extends options defined in SEND [RFC3971] and 283 6LoWPAN ND [RFC6775] [I-D.ietf-6lo-rfc6775-update]. This applies in 284 particular to the CGA option and the RSA Signature Option. This 285 specification provides aliases for the specific variations of those 286 options as used in AP-ND. The presence of the EARO option in the NS/ 287 NA messages indicates that the crypto options are to be processed as 288 specified in this document, not as a SEND message. 290 4.1. Encoding the Public Key 292 A 6LN provides its public key in an NS message. The public key could 293 be in uncompressed form or in compressed form where the first octet 294 of the OCTET STRING is 0x04 and 0x02 or 0x03, respectively. Point 295 compression can further reduce the key size by about 32 octets. 297 4.2. New Crypto-ID 299 Each 6LN using a Crypto-ID for registration MUST have a public/ 300 private key pair. 302 The Crypto-ID is computed as follows: 304 1. An 8-bit modifier is selected, enabling a device to form multiple 305 Crypto-IDs with a single key pair. This is useful for privacy 306 reasons in order to avoid the correlation of addresses based on 307 their Crypto-ID; 309 2. the modifier value and the DER-encoded public key (Section 4.1) 310 are concatenated from left to right; 312 3. The digital signature is constructed by using the 6LN's private 313 key over its EUI-64 (MAC) address. The signature value is 314 computed using the ECDSA signature algorithm and the hash 315 function used is SHA-256 [RFC6234]. 317 4. the leftmost bits of the resulting hash are used as the Crypto- 318 ID, up to the size of the ROVR field. 320 4.3. Updated EARO 322 This specification updates the EARO option as follows: 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Type | Length | Status | Opaque | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 |Rsvd |C| I |R|T| TID | Registration Lifetime | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | | 332 ... Registration Ownership Verifier (ROVR) ... 333 | | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 Figure 1: Enhanced Address Registration Option 338 Type: 33 340 Length: 8-bit unsigned integer. The length of the option 341 (including the type and length fields) in units of 8 342 bytes. 344 Status: 8-bit unsigned integer. Indicates the status of a 345 registration in the NA response. MUST be set to 0 in 346 NS messages. 348 Opaque: Defined in [I-D.ietf-6lo-rfc6775-update]. 350 Rsvd (Reserved): This field is unused. It MUST be initialized to 351 zero by the sender and MUST be ignored by the 352 receiver. 354 C: This "C" flag is set to indicate that the Owner 355 Unique ID field contains a Crypto-ID and that the 6LN 356 MAY be challenged for ownership as specified in this 357 document. 359 I: Defined in [I-D.ietf-6lo-rfc6775-update]. 361 R: Defined in [I-D.ietf-6lo-rfc6775-update]. 363 T and TID: Defined in [I-D.ietf-6lo-rfc6775-update]. 365 Registration Ownership Verifier (ROVR): When the "C" flag is set, 366 this field contains a Crypto-ID. 368 This specification uses Status values "Validation Requested" and 369 "Validation Failed", which are defined in 6LoWPAN ND 370 [I-D.ietf-6lo-rfc6775-update]. No other new Status values is 371 defined. 373 4.4. Crypto-ID Parameters Option 375 This specification defines the Crypto-ID Parameters Option (CIPO), as 376 a variation of the CGA Option that carries the parameters used to 377 form a Crypto-ID. In order to provide cryptographic agility 378 [RFC7696], AP-ND supports two possible signature algorithms, 379 indicated by a Crypto-Type field. Elliptic Curve Cryptography (ECC) 380 is used to calculate the Crypto-ID. NIST P-256 [FIPS186-4] MUST be 381 supported by all implementations. The Edwards-Curve Digital 382 Signature Algorithm (EdDSA) curve Ed25519ph (pre-hashing) [RFC8032] 383 MAY be supported as an alternate. 385 0 1 2 3 386 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 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Type | Length | Pad Length | Reserved | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Crypto-Type | Modifier | Reserved | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | | 393 | | 394 . . 395 . Public Key (variable length) . 396 . . 397 | | 398 | | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | | 401 . . 402 . Padding . 403 . . 404 | | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 Figure 2: Crypto-ID Parameters Option 409 Type: 11. This is the same value as the CGA Option, CIPO 410 is a particular case of the CGA option 412 Length: 8-bit unsigned integer. The length of the option in 413 units of 8 octets. 415 Modifier: 8-bit unsigned integer. 417 Pad Length: 8-bit unsigned integer. The length of the Padding 418 field. 420 Crypto-Type: The type of cryptographic algorithm used in 421 calculation Crypto-ID. A value of 0 indicates NIST 422 P-256, with SHA-256 as the hash algorithm. A value 423 of 1 is assigned for Ed25519ph, with SHA-256 as the 424 hash algorithm. 426 Public Key: DER-Encoded Public Key. 428 Padding: A variable-length field making the option length a 429 multiple of 8, containing as many octets as specified 430 in the Pad Length field. 432 4.5. Nonce Option 434 This document reuses the Nonce Option defined in section 5.3.2. of 435 SEND [RFC3971] without a change. 437 4.6. NDP Signature Option 439 This document reuses the RSA Signature Option (RSAO) defined in 440 section 5.2. of SEND [RFC3971]. Admittedly, the name is ill-chosen 441 since the option is extended for non-RSA Signatures and this 442 specification defines an alias to avoid the confusion. 444 The description of the operation on the option detailed in section 445 5.2. of SEND [RFC3971] apply, but for the following changes: 447 o The 128-bit CGA Message Type tag [RFC3972] for AP-ND is 0x8701 448 55c8 0cca dd32 6ab7 e415 f148 84d0. (The tag value has been 449 generated by the editor of this specification on random.org). 451 o The signature is computed using the hash algorithm and the digital 452 signature indicated in the Crypto-Type field of the CIPO option 453 using the private key associated with the public key in the CIPO. 455 o The alias NDP Signature Option (NDPSO) can be used to refer to the 456 RSAO when used as described in this specification. 458 5. Protocol Scope 460 The scope of the present work is a 6LoWPAN Low Power Lossy Network 461 (LLN), typically a stub network connected to a larger IP network via 462 a Border Router called a 6LBR per [RFC6775]. A 6LBR has sufficient 463 capability to satisfy the needs of DAD. 465 The 6LBR maintains registration state for all devices in its attached 466 LLN. Together with the first-hop router (the 6LR), the 6LBR assures 467 uniqueness and grants ownership of an IPv6 address before it can be 468 used in the LLN. This is in contrast to a traditional network that 469 relies on IPv6 address auto-configuration [RFC4862], where there is 470 no guarantee of ownership from the network, and each IPv6 Neighbor 471 Discovery packet must be individually secured [RFC3971]. 473 ---+-------- ............ 474 | External Network 475 | 476 +-----+ 477 | | 6LBR 478 +-----+ 479 o o o 480 o o o o 481 o o LLN o o o 482 o o o (6LR) 483 o (6LN) 485 Figure 3: Basic Configuration 487 In a mesh network, the 6LR is directly connected to the host device. 488 This specification mandates that the peer-wise layer-2 security is 489 deployed so that all the packets from a particular host are securely 490 identifiable by the 6LR. The 6LR may be multiple hops away from the 491 6LBR. Packets are routed between the 6LR and the 6LBR via other 492 6LRs. This specification mandates that a chain of trust is 493 established so that a packet that was validated by the first 6LR can 494 be safely routed by the next 6LRs to the 6LBR. 496 6. Protocol Flows 498 The 6LR/6LBR ensures first-come/first-serve by storing the EARO 499 information including the Crypto-ID associated to the node being 500 registered. The node can claim any address as long as it is the 501 first to make such a claim. After a successful registration, the 502 node becomes the owner of the registered address and the address is 503 bound to the Crypto-ID in the 6LR/6LBR registry. 505 This specification enables the 6LR to verify the ownership of the 506 binding at any time assuming that the "C" flag is set. The 507 verification prevents other nodes from stealing the address and 508 trying to attract traffic for that address or use it as their source 509 address. 511 A node may use multiple IPv6 addresses at the same time. The node 512 may use a same Crypto-ID, or multiple crypto-IDs derived from a same 513 key pair, to protect multiple IPv6 addresses. The separation of the 514 address and the cryptographic material avoids the constrained device 515 to compute multiple keys for multiple addresses. The registration 516 process allows the node to use the same Crypto-ID for all of its 517 addresses. 519 6.1. First Exchange with a 6LR 521 A 6LN registers to a 6LR that is one hop away from it with the "C" 522 flag set in the EARO, indicating that the ROVR field contains a 523 Crypto-ID. The on-link (local) protocol interactions are shown in 524 Figure 4 If the 6LR does not have a state with the 6LN that is 525 consistent with the NS(EARO), then it replies with a challenge NA 526 (EARO, status=Validation Requested) that contains a Nonce Option. 527 The Nonce option MUST contain a Nonce value that was never used with 528 this device. 530 The 6LN replies to the challenge with an NS(EARO) that includes the 531 echoed Nonce option, the CIPO Section 4.4, and the NDPSO with the 532 signature. The information associated to a crypto-ID stored by the 533 6LR on the first NS exchange where it appears. The 6LR SHOULD store 534 the CIPO parameters associated with the crypto-ID so it can be used 535 for more than one address. 537 6LN 6LR 538 | | 539 |<------------------------- RA -------------------------| 540 | | ^ 541 |---------------- NS with EARO (Crypto-ID) ------------>| | 542 | | option 543 |<- NA with EARO (status=Validation Requested), Nonce --| | 544 | | v 545 |-------- NS with EARO, CIPO, Nonce and NDPSO --------->| 546 | | 547 |<------------------- NA with EARO ---------------------| 548 | | 549 ... 550 | | 551 |--------------- NS with EARO (Crypto-ID) ------------->| 552 | | 553 |<------------------- NA with EARO ---------------------| 554 | | 555 ... 556 | | 557 |--------------- NS with EARO (Crypto-ID) ------------->| 558 | | 559 |<------------------- NA with EARO ---------------------| 560 | | 562 Figure 4: On-link Protocol Operation 564 The steps for the registration to the 6LR are as follows: 566 o Upon the first exchange with a 6LR, a 6LN may be challenged to 567 prove ownership of the Crypto-ID. The proof is not needed again 568 in later registrations for that address, or when registering other 569 addresses with the same ROVR. When a 6LR receives a NS(EARO) 570 registration with a new Crypto-ID as a ROVR, it SHOULD challenge 571 by responding with a NA(EARO) with a status of "Validation 572 Requested". This process of validation MAY be skipped in networks 573 where there is no mobility. 575 o The challenge is triggered when the registration for a Source 576 Link-Layer Address is not verifiable either at the 6LR or the 577 6LBR. In the latter case, the 6LBR returns a status of 578 "Validation Requested" in the DAR/DAC exchange, which is echoed by 579 the 6LR in the NA (EARO) back to the registering node. The 580 challenge MUST NOT alter a valid registration in the 6LR or the 581 6LBR. 583 o Upon receiving a NA(EARO) with a status of "Validation Requested", 584 the registering node SHOULD retry its registration with a Crypto- 585 ID Parameters Option (CIPO) (Section 4.4) that contains all the 586 necessary material for building the Crypto-ID, the Nonce and the 587 NDP signature (Section 4.6) options that prove its ownership of 588 the Crypto-ID. 590 o In order to validate the ownership, the 6LR performs the same 591 steps as the 6LN and rebuilds the Crypto-ID based on the 592 parameters in the CIPO. If the result is different then the 593 validation fails. Else, the 6LR checks the signature in the NDPSO 594 using the public key in the CIPO. If it is correct then the 595 validation passes, else it fails. 597 o If the 6LR fails to validate the signed NS(EARO), it responds with 598 a status of "Validation Failed". After receiving a NA(EARO) with 599 a status of "Validation Failed", the registering node SHOULD try 600 an alternate Crypto-ID. The registering node MUST NOT use the 601 same Crypto-ID for subsequent registration attempts. 603 6.2. Multihop Operation 605 In a multihop 6LoWPAN, the registration with Crypto-ID is propagated 606 to 6LBR as described in this section. If the 6LR and the 6LBR 607 maintain a security association, then there is no need to propagate 608 the proof of ownership to the 6LBR. 610 A new device that joins the network auto-configures an address and 611 performs an initial registration to a neighboring 6LR with an NS 612 message that carries an Address Registration Option (EARO) [RFC6775]. 613 The 6LR validates the address with an 6LBR using a DAR/DAC exchange, 614 and the 6LR confirms (or denies) the address ownership with an NA 615 message that also carries an Address Registration Option. 617 Figure 5 illustrates a registration flow all the way to a 6LowPAN 618 Backbone Router (6BBR). 620 6LN 6LR 6LBR 6BBR 621 | | | | 622 | NS(EARO) | | | 623 |--------------->| | | 624 | | Extended DAR | | 625 | |-------------->| | 626 | | | | 627 | | | proxy NS(EARO) | 628 | | |--------------->| 629 | | | | NS(DAD) 630 | | | | ------> 631 | | | | 632 | | | | 633 | | | | 634 | | | proxy NA(EARO) | 635 | | |<---------------| 636 | | Extended DAC | | 637 | |<--------------| | 638 | NA(EARO) | | | 639 |<---------------| | | 640 | | | | 642 Figure 5: (Re-)Registration Flow 644 In a multihop 6LoWPAN, a 6LBR sends RAs with prefixes downstream and 645 the 6LR receives and relays them to the nodes. 6LR and 6LBR 646 communicate using ICMPv6 Duplicate Address Request (DAR) and 647 Duplicate Address Confirmation (DAC) messages. The DAR and DAC use 648 the same message format as NS and NA, but have different ICMPv6 type 649 values. 651 In AP-ND we extend DAR/DAC messages to carry cryptographically 652 generated ROVR. In a multihop 6LoWPAN, the node exchanges the 653 messages shown in Figure 5. The 6LBR must identify who owns an 654 address (EUI-64) to defend it, if there is an attacker on another 655 6LR. 657 7. Security Considerations 659 7.1. Inheriting from RFC 3971 661 Observations regarding the following threats to the local network in 662 [RFC3971] also apply to this specification. 664 Neighbor Solicitation/Advertisement Spoofing 666 Threats in section 9.2.1 of RFC3971 apply. AP-ND counters the 667 threats on NS(EARO) messages by requiring that the NDP Signature 668 and CIPO options be present in these solicitations. 670 Neighbor Unreachability Detection Failure 672 With RFC6775, a NUD can still be used by the endpoint to assess 673 the liveness of a device. The NUD request may be protected by 674 SEND in which case the provision in section 9.2 of RFC 3972 675 applies. The response to the NUD may be proxied by a backbone 676 router only if it has a fresh registration state for it. For a 677 registration being protected by this specification, the proxied 678 NUD response provides truthful information on the original owner 679 of the address but it cannot be proven using SEND. If the NUD 680 response is not proxied, the 6LR will pass the lookup to the end 681 device which will respond with a traditional NA. If the 6LR does 682 not have a registration associated for the device, it can issue a 683 NA with EARO (status=Validation Requested) upon the NA from the 684 device, which will trigger a NS that will recreate and revalidate 685 the ND registration. 687 Duplicate Address Detection DoS Attack 689 Inside the LLN, Duplicate Addresses are sorted out using the ROVR, 690 which differentiates it from a movement. DAD coming from the 691 backbone are not forwarded over the LLN, which provides some 692 protection against DoS attacks inside the resource-constrained 693 part of the network. Over the backbone, the EARO option is 694 present in NS/NA messages. This protects against misinterpreting 695 a movement for a duplication, and enables the backbone routers to 696 determine which one has the freshest registration and is thus the 697 best candidate to validate the registration for the device 698 attached to it. But this specification does not guarantee that 699 the backbone router claiming an address over the backbone is not 700 an attacker. 702 Router Solicitation and Advertisement Attacks 703 This specification does not change the protection of RS and RA 704 which can still be protected by SEND. 706 Replay Attacks 708 A Nonce given by the 6LR in the NA with EARO (status=Validation 709 Requested) and echoed in the signed NS guarantees against replay 710 attacks of the NS(EARO). The NA(EARO) is not protected and can be 711 forged by a rogue node that is not the 6LR in order to force the 712 6LN to rebuild a NS(EARO) with the proof of ownership, but that 713 rogue node must have access to the L2 radio network next to the 714 6LN to perform the attack. 716 Neighbor Discovery DoS Attack 718 A rogue node that managed to access the L2 network may form many 719 addresses and register them using AP-ND. The perimeter of the 720 attack is all the 6LRs in range of the attacker. The 6LR must 721 protect itself against overflows and reject excessive registration 722 with a status 2 "Neighbor Cache Full". This effectively blocks 723 another (honest) 6LN from registering to the same 6LR, but the 6LN 724 may register to other 6LRs that are in its range but not in that 725 of the rogue. 727 7.2. Related to 6LoWPAN ND 729 The threats discussed in 6LoWPAN ND [RFC6775] and its update 730 [I-D.ietf-6lo-rfc6775-update] also apply here. Compared with SeND, 731 this specification saves about 1Kbyte in every NS/NA message. Also, 732 this specification separates the cryptographic identifier from the 733 registered IPv6 address so that a node can have more than one IPv6 734 address protected by the same cryptographic identifier. SeND forces 735 the IPv6 address to be cryptographic since it integrates the CGA as 736 the IID in the IPv6 address. This specification frees the device to 737 form its addresses in any fashion, thereby enabling not only 6LoWPAN 738 compression which derives IPv6 addresses from Layer-2 addresses but 739 also privacy addresses. 741 7.3. ROVR Collisions 743 A collision of Registration Ownership Verifiers (ROVR) (i.e., the 744 Crypto-ID in this specification) is possible, but it is a rare event. 745 The formula for calculating the probability of a collision is 1 - 746 e^{-k^2/(2n)} where n is the maximum population size (2^64 here, 747 1.84E19) and K is the actual population (number of nodes). If the 748 Crypto-ID is 64-bits, the chance of a collision is 0.01% when the 749 network contains 66 million nodes. Moreover, the collision is only 750 relevant when this happens within one stub network (6LBR). In the 751 case of such a collision, an attacker may be able to claim the 752 registered address of an another legitimate node. However for this 753 to happen, the attacker would also need to know the address which was 754 registered by the legitimate node. This registered address is never 755 broadcasted on the network and therefore providing an additional 756 64-bits that an attacker must correctly guess. To prevent address 757 disclosure, it is RECOMMENDED that nodes derive the address being 758 registered independently of the ROVR. 760 8. IANA considerations 762 8.1. CGA Message Type 764 This document defines a new 128-bit value under the CGA Message Type 765 [RFC3972] namespace, 0x8701 55c8 0cca dd32 6ab7 e415 f148 84d0. 767 8.2. Crypto-Type Subregistry 769 IANA is requested to create a new subregistry "Crypto-Type 770 Subregistry" in the "Internet Control Message Protocol version 6 771 (ICMPv6) Parameters". The registry is indexed by an integer 0..255 772 and contains a Signature Algorithm and a Hash Function as shown in 773 Table 1. The following Crypto-Type values are defined in this 774 document: 776 +--------------+-----------------+---------------+------------------+ 777 | Crypto-Type | Signature | Hash Function | Defining | 778 | value | Algorithm | | Specification | 779 +--------------+-----------------+---------------+------------------+ 780 | 0 | NIST P-256 | SHA-256 | RFC THIS | 781 | | [FIPS186-4] | [RFC6234] | | 782 | 1 | Ed25519ph | SHA-256 | RFC THIS | 783 | | [RFC8032] | [RFC6234] | | 784 +--------------+-----------------+---------------+------------------+ 786 Table 1: Crypto-Types 788 Assignment of new values for new Crypto-Type MUST be done through 789 IANA with "Specification Required" and "IESG Approval" as defined in 790 [RFC8126]. 792 9. Acknowledgments 794 Many thanks to Charlie Perkins for his in-depth review and 795 constructive suggestions. We are also especially grateful to Rene 796 Struik and Robert Moskowitz for their comments that lead to many 797 improvements to this document, in particular WRT ECC computation and 798 references. 800 10. References 802 10.1. Normative References 804 [FIPS-186-4] 805 FIPS 186-4, "Digital Signature Standard (DSS), Federal 806 Information Processing Standards Publication 186-4", US 807 Department of Commerce/National Institute of Standards and 808 Technology Gaithersburg, MD, July 2013. 810 [I-D.ietf-6lo-rfc6775-update] 811 Thubert, P., Nordmark, E., Chakrabarti, S., and C. 812 Perkins, "Registration Extensions for 6LoWPAN Neighbor 813 Discovery", draft-ietf-6lo-rfc6775-update-21 (work in 814 progress), June 2018. 816 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 817 Requirement Levels", BCP 14, RFC 2119, 818 DOI 10.17487/RFC2119, March 1997, 819 . 821 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 822 "SEcure Neighbor Discovery (SEND)", RFC 3971, 823 DOI 10.17487/RFC3971, March 2005, 824 . 826 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 827 RFC 3972, DOI 10.17487/RFC3972, March 2005, 828 . 830 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 831 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 832 DOI 10.17487/RFC4861, September 2007, 833 . 835 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 836 Address Autoconfiguration", RFC 4862, 837 DOI 10.17487/RFC4862, September 2007, 838 . 840 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 841 Statement and Requirements for IPv6 over Low-Power 842 Wireless Personal Area Network (6LoWPAN) Routing", 843 RFC 6606, DOI 10.17487/RFC6606, May 2012, 844 . 846 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 847 Bormann, "Neighbor Discovery Optimization for IPv6 over 848 Low-Power Wireless Personal Area Networks (6LoWPANs)", 849 RFC 6775, DOI 10.17487/RFC6775, November 2012, 850 . 852 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 853 Constrained-Node Networks", RFC 7228, 854 DOI 10.17487/RFC7228, May 2014, 855 . 857 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 858 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 859 May 2017, . 861 10.2. Informative references 863 [FIPS186-4] 864 "FIPS Publication 186-4: Digital Signature Standard", July 865 2013, . 868 [I-D.ietf-6lo-backbone-router] 869 Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo- 870 backbone-router-06 (work in progress), February 2018. 872 [I-D.struik-lwig-curve-representations] 873 Struik, R., "Alternative Elliptic Curve Representations", 874 draft-struik-lwig-curve-representations-02 (work in 875 progress), July 2018. 877 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 878 over Low-Power Wireless Personal Area Networks (6LoWPANs): 879 Overview, Assumptions, Problem Statement, and Goals", 880 RFC 4919, DOI 10.17487/RFC4919, August 2007, 881 . 883 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 884 "Transmission of IPv6 Packets over IEEE 802.15.4 885 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 886 . 888 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 889 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 890 DOI 10.17487/RFC6234, May 2011, 891 . 893 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 894 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 895 DOI 10.17487/RFC6282, September 2011, 896 . 898 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 899 "Source Address Validation Improvement (SAVI) Framework", 900 RFC 7039, DOI 10.17487/RFC7039, October 2013, 901 . 903 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 904 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 905 2014, . 907 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 908 Interface Identifiers with IPv6 Stateless Address 909 Autoconfiguration (SLAAC)", RFC 7217, 910 DOI 10.17487/RFC7217, April 2014, 911 . 913 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 914 Agility and Selecting Mandatory-to-Implement Algorithms", 915 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 916 . 918 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 919 Considerations for IPv6 Address Generation Mechanisms", 920 RFC 7721, DOI 10.17487/RFC7721, March 2016, 921 . 923 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 924 for Security", RFC 7748, DOI 10.17487/RFC7748, January 925 2016, . 927 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 928 Signature Algorithm (EdDSA)", RFC 8032, 929 DOI 10.17487/RFC8032, January 2017, 930 . 932 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 933 Writing an IANA Considerations Section in RFCs", BCP 26, 934 RFC 8126, DOI 10.17487/RFC8126, June 2017, 935 . 937 Appendix A. Requirements Addressed in this Document 939 In this section we state requirements of a secure neighbor discovery 940 protocol for low-power and lossy networks. 942 o The protocol MUST be based on the Neighbor Discovery Optimization 943 for Low-power and Lossy Networks protocol defined in [RFC6775]. 944 RFC6775 utilizes optimizations such as host-initiated interactions 945 for sleeping resource-constrained hosts and elimination of 946 multicast address resolution. 948 o New options to be added to Neighbor Solicitation messages MUST 949 lead to small packet sizes, especially compared with existing 950 protocols such as SEcure Neighbor Discovery (SEND). Smaller 951 packet sizes facilitate low-power transmission by resource- 952 constrained nodes on lossy links. 954 o The support for this registration mechanism SHOULD be extensible 955 to more LLN links than IEEE 802.15.4 only. Support for at least 956 the LLN links for which a 6lo "IPv6 over foo" specification 957 exists, as well as Low-Power Wi-Fi SHOULD be possible. 959 o As part of this extension, a mechanism to compute a unique 960 Identifier should be provided with the capability to form a Link 961 Local Address that SHOULD be unique at least within the LLN 962 connected to a 6LBR. 964 o The Address Registration Option used in the ND registration SHOULD 965 be extended to carry the relevant forms of Unique Interface 966 IDentifier. 968 o The Neighbour Discovery should specify the formation of a site- 969 local address that follows the security recommendations from 970 [RFC7217]. 972 Authors' Addresses 974 Pascal Thubert (editor) 975 Cisco Systems, Inc 976 Building D 977 45 Allee des Ormes - BP1200 978 MOUGINS - Sophia Antipolis 06254 979 FRANCE 981 Phone: +33 497 23 26 34 982 Email: pthubert@cisco.com 983 Behcet Sarikaya 984 Plano, TX 985 USA 987 Email: sarikaya@ieee.org 989 Mohit Sethi 990 Ericsson 991 Hirsalantie 992 Jorvas 02420 994 Email: mohit@piuha.net