idnits 2.17.1 draft-ietf-6lo-ap-nd-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6775, but the abstract doesn't seem to directly say this. It does mention RFC6775 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 24, 2017) is 2521 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-21) exists of draft-ietf-6lo-rfc6775-update-05 == Outdated reference: A later version (-20) exists of draft-ietf-6lo-backbone-router-03 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-11 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo B. Sarikaya 3 Internet-Draft Huawei USA 4 Updates: 6775 (if approved) P. Thubert 5 Intended status: Standards Track Cisco 6 Expires: November 25, 2017 M. Sethi 7 Ericsson 8 May 24, 2017 10 Address Protected Neighbor Discovery for Low-power and Lossy Networks 11 draft-ietf-6lo-ap-nd-02 13 Abstract 15 This document defines an extension to 6LoWPAN Neighbor Discovery, RFC 16 6775. Nodes supporting this extension compute a cryptographic Owner 17 Unique Interface ID and associate it with one or more of their 18 Registered Addresses. Once an address is registered with a 19 Cryptographic ID, only the owner of that ID can modify the anchor 20 state information of the Registered Address, and Source Address 21 Validation can be enforced. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on November 25, 2017. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Updating RFC 6775 . . . . . . . . . . . . . . . . . . . . . . 4 60 4. New Fields and Options . . . . . . . . . . . . . . . . . . . 5 61 4.1. New Crypto-ID . . . . . . . . . . . . . . . . . . . . . . 5 62 4.2. Updated EARO . . . . . . . . . . . . . . . . . . . . . . 6 63 4.3. New Crypto-ID Parameters Option . . . . . . . . . . . . . 7 64 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 65 5.1. Protocol Scope . . . . . . . . . . . . . . . . . . . . . 8 66 5.2. Protocol Flows . . . . . . . . . . . . . . . . . . . . . 9 67 5.3. Multihop Operation . . . . . . . . . . . . . . . . . . . 11 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 71 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 74 10.2. Informative references . . . . . . . . . . . . . . . . . 14 75 Appendix A. Requirements Addressed in this Document . . . . . . 16 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 78 1. Introduction 80 Neighbor discovery for IPv6 [RFC4861] and stateless address 81 autoconfiguration [RFC4862] and their extensions are collectively 82 referred to as the IPv6 Neighbor Discovery Protocol (IPv6 NDP). In 83 order to enable IPv6 NDP operations over a constrained low-power and 84 lossy network (LLN), "Neighbor Discovery optimizations for 6LoWPAN 85 networks" [RFC6775] (6LoWPAN ND), reduces the use of multicast in the 86 original protocol and introduces a unicast host address registration 87 technique. The registration mechanism leverages a new Address 88 Registration Option (ARO) that is carried in the unicast Neighbor 89 Solicitation (NS) and Neighbor Advertisement (NA) messages between 90 the 6LoWPAN Node (6LN) and the 6LoWPAN Router (6LR), as well as the 91 Duplicate Address Request (DAR) and Duplicate Address Confirmation 92 (DAC) messages between the 6LR and the 6LoWPAN Border Router (6LBR), 93 which is the central repository of all the registered addresses in 94 its domain. 96 The registration mechanism in 6LoWPAN ND [RFC6775] was created for 97 the original purpose of Duplicate Address Detection (DAD), whereby 98 use of an address would be granted as long as the address is not 99 already present in the subnet (first come first serve). In order to 100 validate address ownership, the registration mechanism enables the 101 6LR and 6LBR to correlate further claims for a registered address 102 from the device to which it is granted with a Owner Unique Interface 103 IDentifier (OUID). With 6LoWPAN ND, the OUID is derived from the MAC 104 address of the device (EUI-64), which can be spoofed. Therefore, any 105 node connected to the subnet and aware of a registered-address-to- 106 OUID mapping may effectively fake the OUID, steal the address and 107 attract the traffic for that address towards a different Node. In 108 order to allow a more secured registration mechanism, the "Update to 109 6LoWPAN ND" [I-D.ietf-6lo-rfc6775-update] opens the semantics of the 110 ARO option and allows to transport alternate forms of OUIDs. 112 With this specification, a 6LN generates a cryptographic ID (Crypto- 113 ID) and places it in the OUID field in the registration of one (or 114 more) of its addresses with the 6LR(s) that it uses as default 115 router(s). Proof of ownership of the cryptographic ID (Crypto-ID) is 116 passed with the first registration to a given 6LR, and enforced at 117 the 6LR, in a new Crypto-ID Parameters Option (CIPO). The 6LR 118 validates ownership of the cryptographic ID upon the creation of a 119 registration state, or a change in the anchor information, such as 120 Link-Layer Address and associated Layer-2 cryptographic material. 122 The protected address registration protocol proposed in this document 123 enables the enforcement of Source Address Validation (SAVI) 124 [RFC7039], which ensures that only the correct owner uses a 125 registered address in the source address field in IPv6 packets. With 126 this specification, a 6LN that sources a packet has to use a 6LR to 127 which the source address of the packet is registered to forward the 128 packet. The 6LR maintains state information for the registered 129 addressed along with the MAC address, and link-layer cryptographic 130 key associated with that node. In SAVI-enforcement mode, the 6LR 131 allows only packets from a connected Host if the connected Host owns 132 the registration of the source address of the packet. 134 The 6lo adaptation layer framework ([RFC4944], [RFC6282]) expects 135 that a device forms its IPv6 addresses based on Layer-2 address, so 136 as to enable a better compression. This is incompatible with "Secure 137 Neighbor Discovery (SEND)" [RFC3971] and "Cryptographically Generated 138 Addresses (CGAs)" [RFC3972], which derive the Interface ID (IID) in 139 the IPv6 addresses from cryptographic material. "Privacy 140 Considerations for IPv6 Address Generation Mechanisms" 141 [I-D.ietf-6man-ipv6-address-generation-privacy] places additional 142 recommendations on the way addresses should be formed and renewed. 144 This specification allows a device to form and register addresses at 145 will, without a constraint on the way the address is formed or the 146 number of addresses that are registered in parallel. It enables to 147 protect multiple addresses with a single cryptographic material and 148 to send the proof only once to a given 6LR for multiple addresses and 149 refresher registrations. 151 2. Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 Readers are expected to be familiar with all the terms and concepts 158 that are discussed in [RFC3971], [RFC3972], [RFC4861], [RFC4919], 159 [RFC6775], and [I-D.ietf-6lo-backbone-router] which proposes an 160 evolution of [RFC6775] for wider applicability. 162 This document defines Crypto-ID as an identifier of variable size 163 which in most cases is 64 bits long. It is generated using 164 cryptographic means explained later in this document. 166 The document also conforms to the terms and models described in 167 [RFC5889] and uses the vocabulary and the concepts defined in 168 [RFC4291] for the IPv6 Architecture. 170 This document uses [RFC7102] for Terminology in Low power And Lossy 171 Networks. 173 3. Updating RFC 6775 175 With this specification, a node SHOULD use a cryptographic identifier 176 (Crypto-ID) as OUID in its registration; the Crypto-ID is calculated 177 as described in Section 4.1. The fact that a OUID is a Crypto-ID is 178 indicated in a new 'C' flag in the NS(ARO) message. 180 This specification also introduces a new option, the CIPO, that is 181 used to prove ownership of the Crypto-ID. A node that registers for 182 the first time to a 6LR SHOULD place a CIPO option to its 183 registration but is not expected to place the option in the next 184 periodic refresher registrations for that address, or for the 185 registration of other addresses with the same OUID. When a 6LR 186 receives a NS(ARO) registration with a new Crypto-ID as a OUID, then 187 it SHOULD challenge by responding with a NA(ARO) with a status of 188 "Proof requested". This whole process MAY be skipped in networks 189 where there is no or ultra low expectations of mobility. 191 The challenge will also be triggered in the case of a registration 192 for which the Source Link-Layer Address is not consistent with a 193 state that already exists either at the 6LR or the 6LBR. In the 194 latter case, the 6LBR returns a status of "Proof requested" in the 195 DAR/DAC exchange, which is echoed by the 6LR in the NA (ARO) back to 196 the registering node. This flow should not alter a preexisting state 197 in the 6LR or the 6LBR. 199 Upon a NA(ARO) with a status of "Proof requested", the registering 200 node SHOULD retry its registration with a CIPO option that proves its 201 ownership of the Crypto-ID. 203 If the 6LR cannot validate the proof, it responds with a status of 204 "Incorrect Proof". Upon a NA(ARO) with a status of "Incorrect 205 Proof", the registering node SHOULD NOT use this Crypto-ID for 206 registering with that 6LR anymore. 208 4. New Fields and Options 210 4.1. New Crypto-ID 212 Elliptic Curve Cryptography (ECC) is used in the calculation of the 213 Crypto-ID. The digital signature is constructed by using the 6LN's 214 private key over its EUI-64 (MAC) address. The signature value is 215 computed using the ECDSA signature algorithm and the hash function 216 used is SHA-256 [RFC6234]. Public Key is the most important 217 parameter in CGA Parameters (sent by 6LN in an NS message). ECC 218 Public Key could be in uncompressed form or in compressed form where 219 the first octet of the OCTET STRING is 0x04 and 0x02 or 0x03, 220 respectively. Point compression can further reduce the key size by 221 about 32 octets. 223 First, the modifier is set to a random or pseudo-random 128-bit 224 value. Next, concatenate from left to right the modifier, 9 zero 225 octets and the ECC public key. SHA-256 algorithm is applied on the 226 concatenation. The 112 leftmost bits of the hash value is taken. 227 Concatenate from left to right the modifier value, the subnet prefix 228 and the encoded public key. NIST P-256 is executed on the 229 concatenation. The leftmost bits of the result is used as the 230 Crypto-ID. With this specification, the last 64 bits are retained, 231 but it could be expanded to more bits in the future by increasing the 232 size of the OUID field. 234 In respecting the cryptographic algorithm agility [RFC7696], Curve 235 25519 [RFC7748] can also be used instead of NIST P-256. This is 236 indicated by 6LN by setting the Crypto Type field in the CIPO option 237 to a value of 1. If 6LBR does not support Curve 25519, it will set 238 Crypto Type field to zero. This means that the default algorithm 239 (NIST P-256) will be used. 241 4.2. Updated EARO 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Type | Length | Status | Reserved | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Reserved |C|T| TID | Registration Lifetime | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | | 251 + Owner Unique ID (EUI-64 or equivalent) + 252 | | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 Figure 1: Enhanced Address Registration Option 257 Type: 259 33 261 Length: 263 8-bit unsigned integer. The length of the option (including the 264 type and length fields) in units of 8 bytes. 266 Status: 268 8-bit unsigned integer. Indicates the status of a registration in 269 the NA response. MUST be set to 0 in NS messages. This 270 specification leverages values introduced in the Update to 6LoWPAN 271 ND [I-D.ietf-6lo-rfc6775-update], such as 5: Proof Requested, and 272 does not require additional values to be defined. 274 Reserved: 276 This field is unused. It MUST be initialized to zero by the 277 sender and MUST be ignored by the receiver. 279 C: 281 This specification introduces a C bit, which is set to indicate 282 that the Owner Unique ID field contains a Crypto-ID. 284 T and TID: 286 Defined in [I-D.ietf-6lo-rfc6775-update]. 288 Owner Unique ID: 290 When using this specification, this field contains a Crypto-ID. 292 4.3. New Crypto-ID Parameters Option 294 This specification introduces a new option, the Crypto-ID Parameters 295 Option (CIPO), that carries the proof of ownership of a crypto-ID. 297 0 1 2 3 298 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 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Type | Length | Pad Length | Crypto Type | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | | 303 + + 304 | | 305 + Modifier (16 octets) + 306 | | 307 + + 308 | | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | | 311 + Subnet Prefix (8 octets) + 312 | | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | | 315 | | 316 + Public Key (variable length) + 317 | | 318 | | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | | 321 . . 322 . Padding . 323 . . 324 | | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Figure 2: Crypto-ID Parameters Option 329 Type: 331 CIPO, to be assigned by IANA. 333 Length: 335 The length of the option in units of 8 octets. 337 Pad Length: 339 The length of the Padding field. 341 Crypto Type: 343 The type of cryptographic algorithm used in calculation Crypto-ID. 344 Default value of all zeros indicate NIST P-256. A value of 1 is 345 assigned for Curve 25519. New values may be defined later. 347 Modifier: 349 128 bit random value. 351 Subnet Prefix: 353 64 bit subnet prefix. 355 Public Key: 357 ECC public key of 6LN. 359 Padding: 361 A variable-length field making the option length a multiple of 8, 362 containing as many octets as specified in the Pad Length field. 364 5. Protocol Overview 366 5.1. Protocol Scope 368 The scope of the present work is a 6LoWPAN Low Power Lossy Network 369 (LLN), typically a stub network connected to a larger IP network via 370 a Border Router called a 6LBR per [RFC6775]. 372 The 6LBR maintains a registration state for all devices in the 373 attached LLN, and, in conjunction with the first-hop router (the 374 6LR), is in a position to validate uniqueness and grant ownership of 375 an IPv6 address before it can be used in the LLN. This is a 376 fundamental difference with a classical network that relies on IPv6 377 address auto-configuration [RFC4862], where there is no guarantee of 378 ownership from the network, and any IPv6 Neighbor Discovery packet 379 must be individually secured [RFC3971]. 381 ---+-------- ............ 382 | External Network 383 | 384 +-----+ 385 | | 6LBR 386 +-----+ 387 o o o 388 o o o o 389 o o LLN o o o 390 o o o (6LR) 391 o (6LN) 393 Figure 3: Basic Configuration 395 In a mesh network, the 6LR is directly connected to the host device. 396 This specification expects that the peer-wise layer-2 security is 397 deployed so that all the packets from a particular host are securely 398 identifiable by the 6LR. The 6LR may be multiple hops away from the 399 6LBR. Packets are routed between the 6LR and the 6LBR via other 400 6LRs. This specification expects that a chain of trust is 401 established so that a packet that was validated by the first 6LR can 402 be safely routed by the next 6LRs to the 6LBR. 404 5.2. Protocol Flows 406 The 6TiSCH Architecture [I-D.ietf-6tisch-architecture] suggests to 407 use of RPL [RFC6550] as the routing protocol between the 6LRs and the 408 6LBR. In that model, a registration flow happens as shown in 409 Figure 4. 411 6LoWPAN Node 6LR 6LBR 412 (RPL leaf) (router) (RPL root) 413 | | | 414 | 6LoWPAN ND | 6LoWPAN ND | 415 | | | 416 | | | 417 | NS(ARO) | | 418 |-------------->| | 419 | 6LoWPAN ND | DAR | 420 | |-------------->| 421 | |(then RPL DAO) | 422 | | | 423 | | DAC | 424 | |<--------------| 425 | NA(ARO) | | 426 |<--------------| | 427 | | | 428 | | | 430 Figure 4: (Re-)Registration Flow 432 A new device that joins the network auto-configures an address and 433 performs an initial registration to an on-link 6LR with an NS message 434 that carries an Address Registration Option (ARO) [RFC6775]. The 6LR 435 validates the address with the central 6LBR using a DAR/DAC exchange, 436 and the 6LR confirms (or denies) the address ownership with an NA 437 message that also carries an Address Registration Option. 439 In a multihop 6LoWPAN, the registration with Crypto-ID is propagated 440 to 6LBR as described in Section 5.3. If a chain of trust is present 441 between the 6LR and the 6LBR, then there is no need to propagate the 442 proof of ownership to the 6LBR. All the 6LBR needs to know is that 443 this particular OUID is randomly generated, so as to enforce that any 444 update via a different 6LR is also random. 446 Local or on-link protocol interactions are shown in Figure 5. 447 Crypto-ID and ARO are passed to and stored by the 6LR/6LBR on the 448 first NS and not sent again in the next NS. The operation starts 449 with 6LR sending a Router Advertisement (RA) message to 6LN. 451 The 6LR/6LBR ensures first-come/first-serve by storing the ARO and 452 the Crypto-ID correlated to the node being registered. The node is 453 free to claim any address it likes as long as it is the first to make 454 such a claim. After a successful registration, the node becomes the 455 owner of the registered address and the address is bound to the 456 Crypto-ID in the 6LR/6LBR registry. This binding can be verified 457 later, which prevents other nodes from stealing the address and 458 trying to attract traffic for that address or use it as their source 459 address. 461 A node may uses multiple IPv6 addresses at any time. This condition 462 may happen for privacy reasons 463 [I-D.ietf-6man-ipv6-address-generation-privacy], or when the node 464 moves at a different place and auto-configures an new address from a 465 different prefix. In those situations, the node may use the same 466 Crypto-ID to protect multiple IPv6 addresses. The separation of the 467 address and the Crypto-ID avoids the constrained device to compute 468 multiple keys for multiple addresses. The registration process 469 allows the node to tie all of its addresses to the same Crypto-ID and 470 have the 6LR/6LBR enforce first-come first-serve after that. 472 6LN 6LR 473 | | 474 |<------------------- RA --------------------------| 475 | | 476 |----------- NS with ARO and Crypto-ID ----------->| 477 | | 478 |<---------- NA with ARO (status=proof requested) -| 479 | | 480 |----------- NS with ARO and Crypto-ID ----------->| 481 | | 482 |<---------------- NA with ARO --------------------| 483 | | 484 ... ... 485 | | 486 |------------ NS with ARO and Crypto-ID ---------->| 487 | | 488 | | 489 |<---------------- NA with ARO --------------------| 490 ... ... 491 | | 492 |----------- NS with ARO and Crypto-ID ----------->| 493 | | 494 | | 495 |<---------------- NA with ARO --------------------| 497 Figure 5: On-link Protocol Operation 499 5.3. Multihop Operation 501 In multihop 6LoWPAN, 6LBR sends RAs with prefixes downstream and it 502 is the 6LR that receives and relays them to the nodes. 6LR and 6LBR 503 communicate with the ICMPv6 Duplicate Address Request (DAR) and the 504 Duplicate Address Confirmation (DAC) messages. The DAR and DAC use 505 the same message format as NS and NA with different ICMPv6 type 506 values. 508 In ND-PAR we extend DAR/DAC messages to carry cryptographically 509 generated OUID. In a multihop 6LoWPAN, the node exchanges the 510 messages shown in Figure 4. The 6LBR must be aware of who owns an 511 address (EUI-64) to defend the first node if there is an attacker on 512 another 6LR. Because of this the content that the source signs and 513 the signature needs to be propagated to the 6LBR in DAR message. For 514 this purpose the DAR message sent by 6LR to 6LBR MUST contain the 515 CIPO option. DAR message also contains ARO. 517 It is possible that occasionally, a 6LR may miss the node's OUID 518 (that it received in ARO). 6LR should be able to ask for it again. 519 This is done by restarting the exchanges shown in Figure 5. The 520 result enables 6LR to refresh the information that was lost. 6LR MUST 521 send DAR message with ARO to 6LBR. 6LBR as a reply forms a DAC 522 message with the information copied from the DAR and the Status field 523 is set to zero. With this exchange, the 6LBR can (re)validate and 524 store the information to make sure that the 6LR is not a fake. 526 In some cases 6LBR may use DAC message to signal to 6LR that it 527 expects Crypto-ID from 6LR also asks 6LR to verify the EUI-64 6LR 528 received from 6LN. This may happen when a 6LN node is compromised 529 and a fake node is sending the Crypto-ID as if it is the node's EUI- 530 64. Note that the detection in this case can only be done by 6LBR 531 not by 6LR. 533 6. Security Considerations 535 The observations regarding the threats to the Local Link Network in 536 [RFC3971] also apply to this specification. 538 This document inherits threats discussed in 6LoWPAN ND [RFC6775] and 539 its update [I-D.ietf-6lo-rfc6775-update] and addresses the potential 540 attacks related to address stealing and spoofing within a LLN. 541 Compared with SeND, this specification saves about 1Kbyte in every 542 NS/NA message. Also, this specification separates the cryptographic 543 identifier from the registered IPv6 address so that a node can have 544 more than one IPv6 address protected by the same cryptographic 545 identifier. SeND forces the IPv6 address to be cryptographic since 546 it integrates the CGA as the IID in the IPv6 address. This 547 specification frees the device to form its addresses in any fashion, 548 so as to enable the classical 6LoWPAN compression which derives IPv6 549 addresses from Layer-2 addresses, as well as privacy addresses. 551 The threats discussed in Section 9.2 of [RFC3971] are countered by 552 the protocol described in this document as well. 554 Collisions of Crypto-ID is a possibility that needs to be considered. 555 The formula for calculating probability of a collision is 1 - 556 e^{-k^2/(2n)}. If the Crypto-ID is 64-bit long, then the chance of 557 finding a collision is 0.01% when the network contains 66 million 558 nodes. It is important to note that the collision is only relevant 559 when this happens within one stub network (6LBR). A collision of ID 560 in ND-PAR is a rare event. However, when such a collision does 561 happen, the protocol operation is not affected, although it opens a 562 window for a node to hijack an address from another. The link-layer 563 security ensures that the nodes would normally not be aware of a 564 collision on the subnet. If a malicious node is able to gain 565 knowledge of a collision through other means, the only thing that it 566 could do is to steal addresses from the other honest node. This 567 would be no different from what is already possible in a 6lo network 568 today. 570 7. IANA considerations 572 IANA is requested to assign two new option type values for the CIPO 573 under the subregistry "IPv6 Neighbor Discovery Option Formats". 575 8. Acknowledgements 577 We are grateful to Rene Struik and Robert Moskowitz for their 578 comments that lead to many improvements to this document. 580 9. Change Log 582 o submitted version -00 as a working group draft after adoption, and 583 corrected the order of authors 585 o submitted version -01 with no changes 587 o submitted version -02 with these changes: Moved Requirements to 588 Appendix A, Section 4.2 moved to Section 3, New section 4 on New 589 Fields and Options, Section 4 changed to Protocol Overview as 590 Section 5 with Protocol Scope and Flows subsections. 592 10. References 594 10.1. Normative References 596 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, 598 DOI 10.17487/RFC2119, March 1997, 599 . 601 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 602 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 603 2006, . 605 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 606 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 607 DOI 10.17487/RFC4861, September 2007, 608 . 610 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 611 Address Autoconfiguration", RFC 4862, 612 DOI 10.17487/RFC4862, September 2007, 613 . 615 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 616 Bormann, "Neighbor Discovery Optimization for IPv6 over 617 Low-Power Wireless Personal Area Networks (6LoWPANs)", 618 RFC 6775, DOI 10.17487/RFC6775, November 2012, 619 . 621 [I-D.ietf-6lo-rfc6775-update] 622 Thubert, P., Nordmark, E., and S. Chakrabarti, "An Update 623 to 6LoWPAN ND", draft-ietf-6lo-rfc6775-update-05 (work in 624 progress), May 2017. 626 10.2. Informative references 628 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 629 "SEcure Neighbor Discovery (SEND)", RFC 3971, 630 DOI 10.17487/RFC3971, March 2005, 631 . 633 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 634 RFC 3972, DOI 10.17487/RFC3972, March 2005, 635 . 637 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 638 "Transmission of IPv6 Packets over IEEE 802.15.4 639 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 640 . 642 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 643 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 644 DOI 10.17487/RFC6282, September 2011, 645 . 647 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 648 over Low-Power Wireless Personal Area Networks (6LoWPANs): 649 Overview, Assumptions, Problem Statement, and Goals", 650 RFC 4919, DOI 10.17487/RFC4919, August 2007, 651 . 653 [RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing 654 Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889, 655 September 2010, . 657 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 658 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 659 DOI 10.17487/RFC6234, May 2011, 660 . 662 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 663 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 664 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 665 Low-Power and Lossy Networks", RFC 6550, 666 DOI 10.17487/RFC6550, March 2012, 667 . 669 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 670 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 671 2014, . 673 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 674 "Source Address Validation Improvement (SAVI) Framework", 675 RFC 7039, DOI 10.17487/RFC7039, October 2013, 676 . 678 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 679 Interface Identifiers with IPv6 Stateless Address 680 Autoconfiguration (SLAAC)", RFC 7217, 681 DOI 10.17487/RFC7217, April 2014, 682 . 684 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 685 Agility and Selecting Mandatory-to-Implement Algorithms", 686 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 687 . 689 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 690 for Security", RFC 7748, DOI 10.17487/RFC7748, January 691 2016, . 693 [I-D.ietf-6lo-backbone-router] 694 Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo- 695 backbone-router-03 (work in progress), January 2017. 697 [I-D.ietf-6tisch-architecture] 698 Thubert, P., "An Architecture for IPv6 over the TSCH mode 699 of IEEE 802.15.4", draft-ietf-6tisch-architecture-11 (work 700 in progress), January 2017. 702 [I-D.ietf-6man-ipv6-address-generation-privacy] 703 Cooper, A., Gont, F., and D. Thaler, "Privacy 704 Considerations for IPv6 Address Generation Mechanisms", 705 draft-ietf-6man-ipv6-address-generation-privacy-08 (work 706 in progress), September 2015. 708 Appendix A. Requirements Addressed in this Document 710 In this section we state requirements of a secure neighbor discovery 711 protocol for low-power and lossy networks. 713 o The protocol MUST be based on the Neighbor Discovery Optimization 714 for Low-power and Lossy Networks protocol defined in [RFC6775]. 715 RFC6775 utilizes optimizations such as host-initiated interactions 716 for sleeping resource-constrained hosts and elimination of 717 multicast address resolution. 719 o New options to be added to Neighbor Solicitation messages MUST 720 lead to small packet sizes, especially compared with existing 721 protocols such as SEcure Neighbor Discovery (SEND). Smaller 722 packet sizes facilitate low-power transmission by resource- 723 constrained nodes on lossy links. 725 o The support for this registration mechanism SHOULD be extensible 726 to more LLN links than IEEE 802.15.4 only. Support for at least 727 the LLN links for which a 6lo "IPv6 over foo" specification 728 exists, as well as Low-Power Wi-Fi SHOULD be possible. 730 o As part of this extension, a mechanism to compute a unique 731 Identifier should be provided with the capability to form a Link 732 Local Address that SHOULD be unique at least within the LLN 733 connected to a 6LBR. 735 o The Address Registration Option used in the ND registration SHOULD 736 be extended to carry the relevant forms of Unique Interface 737 IDentifier. 739 o The Neighbour Discovery should specify the formation of a site- 740 local address that follows the security recommendations from 741 [RFC7217]. 743 Authors' Addresses 745 Behcet Sarikaya 746 Huawei USA 747 5340 Legacy Dr. Building 3 748 Plano, TX 75024 750 Email: sarikaya@ieee.org 752 Pascal Thubert 753 Cisco Systems, Inc 754 Building D 755 45 Allee des Ormes - BP1200 756 MOUGINS - Sophia Antipolis 06254 757 FRANCE 759 Phone: +33 497 23 26 34 760 Email: pthubert@cisco.com 762 Mohit Sethi 763 Ericsson 764 Hirsalantie 765 Jorvas 02420 767 Email: mohit@piuha.net