idnits 2.17.1 draft-sarikaya-6lo-cga-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 49 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2015) is 3336 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) == Unused Reference: 'NIST-ST' is defined on line 774, but no explicit reference was found in the text == Unused Reference: 'I-D.rafiee-6man-ssas' is defined on line 779, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3756 ** Downref: Normative reference to an Informational RFC: RFC 4903 ** Downref: Normative reference to an Informational RFC: RFC 4919 ** Downref: Normative reference to an Informational RFC: RFC 5889 -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' -- Possible downref: Non-RFC (?) normative reference: ref. 'Guide' == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-06 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo B. Sarikaya, Ed. 3 Internet-Draft Huawei USA 4 Intended status: Standards Track F. Xia 5 Expires: September 10, 2015 Huawei Technologies Co., Ltd. 6 P. Thubert, Ed. 7 Cisco 8 March 9, 2015 10 Lightweight and Secure Neighbor Discovery for Low-power and Lossy 11 Networks 12 draft-sarikaya-6lo-cga-nd-02 14 Abstract 16 This document defines a lightweight and secure version of 6LoWPAN 17 Neighbor Discovery for application in low-power and lossy networks. 18 Cryptographically Generated Address and digital signatures are 19 calculated using Elliptic Curve Cryptography, so that the 20 cryptographic operations are suitable for low power devices. An 21 optimal version of this protocol is also specified which supports 22 faster CGA calculation and multi-hop operation. A node computes a 23 Cryptographically Generated Address to be used as a Unique Interface 24 ID, and associate all its Registered Addresses with that Unique 25 Interface ID in place of the EUI-64 that is used in RFC 6775 to 26 uniquely identify the interface of the Registered Address. Once an 27 address is registered with a cryptographic unique ID, only the owner 28 of that ID can modify the state in the 6LR and 6LBR regarding the 29 Registered Address. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 10, 2015. 48 Copyright Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. New and Modified Options . . . . . . . . . . . . . . . . . . 5 69 4.1. Modified Address Registration Option . . . . . . . . . . 5 70 4.2. CGA Parameters and Digital Signature Option . . . . . . . 6 71 4.3. Digital Signature Option . . . . . . . . . . . . . . . . 8 72 4.4. Calculation of the Digital Signature and CGA Using ECC . 10 73 5. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 10 74 6. Optimizations . . . . . . . . . . . . . . . . . . . . . . . . 11 75 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 11 76 6.2. Protocol Operations . . . . . . . . . . . . . . . . . . . 14 77 6.3. Multihop Operation . . . . . . . . . . . . . . . . . . . 15 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 79 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16 80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 83 10.2. Informative references . . . . . . . . . . . . . . . . . 18 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 86 1. Introduction 88 Neighbor discovery for IPv6 [RFC4861] and stateless address 89 autoconfiguration [RFC4862], together referred to as neighbor 90 discovery protocols (NDP), are defined for regular hosts operating 91 with wired/wireless links. These protocols are not suitable and 92 require optimizations for resource constrained, low power hosts 93 operating with lossy wireless links. Neighbor Discovery 94 optimizations for 6LoWPAN networks include simple optimizations such 95 as a host address registration feature using the address registration 96 option (ARO) which is sent in unicast Neighbor Solicitation (NS) and 97 Neighbor Advertisement (NA) messages [RFC6775]. With 6LoWPAN ND 98 [RFC6775], the ARO option includes a EUI-64 address to uniquely 99 identify the interface of the Registered Address on the registering 100 device, so as to correlate further registrations for a same address 101 and avoid address duplication. The EUI-64 address is not secured and 102 its ownership cannot be verified. It results that any device 103 claiming the same EUI-64 address may take over a registration and 104 attract the traffic for that address. 106 Neighbor Discovery Protocols (NDP) are not secure especially when 107 physical security on the link is not assured and vulnerable to 108 attacks defined in [RFC3756]. Secure neighbor discovery protocol 109 (SEND) is defined to secure NDP [RFC3971]. Cryptographically 110 Generated Addresses (CGA) are used in SEND [RFC3972]. SEND mandates 111 the use of the RSA signature algorithm which is computationally heavy 112 and not suitable to use for low-power and resource constrained nodes. 113 The use of an RSA public key and signature leads to long message 114 sizes not suitable to use in low-bit rate, short range, asymmetric 115 and non-transitive links such as IEEE 802.15.4. 117 In this document, we extend 6LoWPAN ND with CGA; but as opposed to 118 SEND, the cryptographic address is not necessarily used as Interface 119 ID (IID) in an IPv6 address but as a correlator associated to the 120 registration of the IPv6 address. This approach is made possible 121 with 6LoWPAN ND [RFC6775], where the 6LR and the 6LBR maintain a 122 state for each Registered Address. If a CGA is associated with an 123 original 6LoWPAN ND registration and stored in the registration 124 state, then it can be used to validate that any update to the 125 registration state is made by the owner of that CGA. 127 To achieve this, this specification replaces the EUI-64 address, that 128 is used in 6LoWPAN ND to avoid address duplication, with a CGA 129 address whose ownership can be verified; it also provides new means 130 for the 6LR to validate ownership of the CGA address by the 131 registering device. A node generates one 64-bit CGA address and uses 132 it as Unique Interface ID in the registration of (one or more of) its 133 addresses with the 6LR, which it attaches to and uses as default 134 router. The 6LR validates ownership of the CGA address typically 135 upon creation or update of a registration state, for instance 136 following an apparent movement from a point of attachment to another. 137 The ARO option is modified to indicate that the Unique Interface ID 138 is CGA-based, and through the DAR/DAC exchange, the 6LBR is kept 139 aware that this is the case and whether the 6LR has verified the 140 claim. 142 CGA generation is based on elliptic curve cryptography (ECC)and 143 signature is calculated using elliptic curve digital signature 144 algorithm (ECDSA) known to be lightweight, leading to much smaller 145 packet sizes. The resulting protocol is called Lightweight Secure 146 Neighbor Discovery Protocol (LSEND). 148 2. Terminology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119]. 154 Readers are expected to be familiar with all the terms and concepts 155 that are discussed in [RFC3971], [RFC3972], "neighbor Discovery for 156 IP version 6" [RFC4861], "IPv6 over Low-Power Wireless Personal Area 157 Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and 158 Goals" [RFC4919], neighbor Discovery Optimization for Low-power and 159 Lossy Networks [RFC6775] where the 6LoWPAN Router (6LR) and the 160 6LoWPAN Border Router (6LBR) are introduced, and 161 [I-D.chakrabarti-nordmark-6man-efficient-nd], which proposes an 162 evolution of [RFC6775] for a larger applicability. 164 The draft also conforms to the terms and models described in 165 [RFC5889] and uses the vocabulary and the concepts defined in 166 [RFC4291] for the IPv6 Architecture. 168 3. Requirements 170 In this section we state requirements of a secure neighbor discovery 171 protocol for low-power and lossy networks. 173 The protocol MUST be based on the Neighbor Discovery Optimization for 174 Low-power and Lossy Networks protocol defined in [RFC6775] due to the 175 host-initiated interactions to allow for sleeping hosts, elimination 176 of multicast-based address resolution for hosts, etc. 178 New options to be added to Neighbor Solicitation messages MUST lead 179 to small packet sizes. Smaller packet sizes facilitate low-power 180 transmission by resource constrained nodes on lossy links. 182 CGA generation, signature and key hash calculation MUST avoid the use 183 of SHA-1 which is known to have security flaws. In this document, we 184 use SHA-2 instead of SHA-1 and thus avoid SHA-1's flaws. 186 Public key and signature sizes MUST be minimized and signature 187 calculation MUST be lightweight. In this document we adopt ECC and 188 ECDSA with the P-256 curve in order to meet this requirement. 190 The support of the registration mechanism SHOULD be extended to more 191 LLN links than IEEE 802.15.4, matching at least the LLN links for 192 which a 6lo "IPv6 over foo" specification exists, as well as Low- 193 Power Wi-Fi. 195 As part of this extension, a mechanism to compute a unique Identifier 196 should be provided, with the capability to form a Link- Local Address 197 that SHOULD be unique at least within the LLN connected to a 6LBR 198 discovered by ND in each node within the LLN. 200 The Address Registration Option used in the ND registration SHOULD be 201 extended to carry the relevant forms of Unique Interface IDentifier. 203 The Neighbour Discovery should specify the formation of a site-local 204 address that follows the security recommendations from [RFC7217]. 206 4. New and Modified Options 208 4.1. Modified Address Registration Option 210 The ARO option is modified to transport a CGA-based Unique Interface 211 ID. 213 0 1 2 3 214 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 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Type | Length | Status | Reserved | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Res | IDS |T| TID | Registration Lifetime | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | | 221 ~ Unique Interface Identifier (variable length) ~ 222 | | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 Track Forwarding, Transport Mode 227 Fields: 229 Type: 33 [RFC6775] 231 Length: 8-bit unsigned integer. Defined in [RFC6775]. The 232 length of the option (including the type and length 233 fields) in units of 8 bytes. The value 0 is invalid. 235 Status: 8-bit unsigned integer. Extended from [RFC6775]. 236 Indicates the status of a registration in the NA 237 response. MUST be set to 0 in NS messages. A new 238 status for req-proof of to-be-defined-by-iana (4 239 suggested) indicates that the cryptographic material 240 that proves the CGA ownership is requested in a new NS. 242 Reserved: 8 bits. This field is unused. It MUST be initialized 243 to zero by the sender and MUST be ignored by the 244 receiver. 246 Res: 4 bits. This field is unused. It MUST be initialized 247 to zero by the sender and MUST be ignored by the 248 receiver. 250 IDS: Identifier name Space. Indicates the name space for 251 the Unique Interface Identifier. IDS of 0 means EUI-64 252 UID. A new IDS to be assigned by IANA (a value of 2 is 253 suggested) is defined for CGA-based Unique Interface 254 ID. 256 T bit: 1 bit flag. Set if the TID octet is valid. 258 TID: 8-bit integer. It is a transaction id maintained by 259 the host and used by the 6LR to indicate the 260 registration that is being validated 262 Registration Lifetime: 16-bit unsigned integer. Defined in 263 [RFC6775]. The amount of time in a unit of 60 seconds 264 that the router should retain the Neighbor Cache entry 265 for the sender of the NS that includes this option. A 266 value of zero means to remove the registration. 268 Unique Interface Identifier: 8 bytes. May be CGA-based with this 269 specification. 271 4.2. CGA Parameters and Digital Signature Option 273 This option contains both CGA parameters and the digital signature. 275 A summary of the CGA Parameters and Digital Signature Option format 276 is shown below. 278 0 1 2 3 279 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 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Type | Length | Pad Length | Sig. Length | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | | 284 . . 285 . CGA Parameters . 286 . . 287 | | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | | 290 . . 291 . Digital Signature . 292 . . 293 | | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | | 296 . . 297 . Padding . 298 . . 299 | | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 Type 304 TBA1 for CGA Parameters and Digital Signature 306 Length 308 The length of the option (including the Type, Length, Pad Length, 309 Signature Length, CGA Parameters, Digital Signature and Padding 310 fields) in units of 8 octets. 312 Pad Length 314 The length of the Padding field. 316 Sig Length 318 The length of the Digital Signature field. 320 CGA Parameters 322 The CGA Parameters field is variable-length containing the CGA 323 Parameters data structure described in Section 4 of [RFC3972]. 325 Digital Signature 327 The Digital Signature field is a variable length field containing 328 a Elliptic Curve Digital Signature Algorithm (ECDSA) signature 329 (with SHA-256 and P-256 curve of [FIPS-186-3]). Digital signature 330 is constructed as explained in Section 4.4. 332 Padding 334 The Padding field contains a variable-length field making the CGA 335 Parameters and Digital Signature Option length a multiple of 8. 337 4.3. Digital Signature Option 339 This option contains the digital signature. 341 A summary of the Digital Signature Option format is shown below. 342 Note that this option has the same format as RSA Signature Option 343 defined in [RFC3971]. The differences are that Digital Signature 344 field carries an ECDSA signature not an RSA signature, and in 345 calculating Key Hash field SHA-2 is used instead of SHA-1. 347 In the sequence of octets to be signed using the sender's private key 348 includes 128-bit CGA Message Type tag. In LSEND, CGA Message Type 349 tag of 0xE8C47FB7FD2BB885DAB2D31A0F2808B4 MUST be used. 351 0 1 2 3 352 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 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Type | Length | Reserved | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | | 357 | Key Hash | 358 | | 359 | | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | | 362 . . 363 . Digital Signature . 364 . . 365 | | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | | 368 . . 369 . Padding . 370 . . 371 | | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 Type 376 TBA2 for Digital Signature 378 Length 380 The length of the option (including the Type, Length, Reserved, 381 Key Hash, Digital Signature and Padding fields) in units of 8 382 octets. 384 Key Hash 386 The Key Hash field is a 128-bit field containing the most 387 significant (leftmost) 128 bits of a SHA-2 hash of the public key 388 used for constructing the signature. This is the same as in 389 [RFC3971] except for SHA-1 which has been replaced by SHA-2. 391 Digital Signature 393 Same as in Section 4.2. 395 Padding 396 The Padding field contains a variable-length field containing as 397 many bytes long as remain after the end of the signature. 399 4.4. Calculation of the Digital Signature and CGA Using ECC 401 Due to the use of Elliptic Curve Cryptography, the following 402 modifications are needed to [RFC3971] and [RFC3972]. 404 The digital signature is constructed by using the sender's private 405 key over the same sequence of octets specified in Section 5.2 of 406 [RFC3971] up to all neighbor discovery protocol options preceding the 407 Digital Signature option containing the ECC-based signature. The 408 signature value is computed using the ECDSA signature algorithm as 409 defined in [SEC1] and hash function SHA-256. 411 Public Key is the most important parameter in CGA Parameters defined 412 in Section 4.2. Public Key MUST be DER-encoded ASN.1 structure of 413 the type SubjectPublicKeyInfo formatted as ECC Public Key. The 414 AlgorithmIdentifier, contained in ASN.1 structure of type 415 SubjectPublicKeyInfo, MUST be the (unrestricted) id- ecPublicKey 416 algorithm identifier, which is OID 1.2.840.10045.2.1, and the 417 subjectPublicKey MUST be formatted as an ECC Public Key, specified in 418 Section 2.2 of [RFC5480]. 420 Note that the ECC key lengths are determined by the namedCurves 421 parameter stored in ECParameters field of the AlgorithmIdentifier. 422 The named curve to use is secp256r1 corresponding to P-256 which is 423 OID 1.2.840.10045.3.1.7 [SEC2]. 425 ECC Public Key could be in uncompressed form or in compressed form 426 where the first octet of the OCTET STRING is 0x04 and 0x02 or 0x03, 427 respectively. Point compression using secp256r1 reduces the key size 428 by 32 octets. In LSEND, point compression MUST be supported. 430 5. Protocol Interactions 432 Lightweight Secure Neighbor Discovery for Low-power and Lossy 433 Networks (LSEND for LLN) modifies Neighbor Discovery Optimization for 434 Low-power and Lossy Networks [RFC6775] as explained in this section. 435 Protocol interactions are shown in Figure 1. 437 6LoWPAN Nodes (6LN, or simply "nodes") receive RAs from adjacent 6LRs 438 and generate their own cryptographically generated addresses using 439 elliptic curve cryptography as explained in Section 4.4. The node 440 sends a neighbor solicitation (NS) message with the address 441 registration option (ARO) to 6LR. Such a NS is called an address 442 registration NS. 444 6LN 6LR 445 | | 446 |<-----------------------RA-------------------------------| 447 | | 448 |---------------NS with ARO and CGA UID --------------->| 449 | | 450 |<-----------------------NA with ARO (status=req-proof) --| 451 | | 452 |---------------NS with ARO and Digital Signature Option->| 453 | | 454 |<-----------------------NA with ARO----------------------| 455 | | 456 ... 457 | | 458 |---------------NS with ARO and CGA UID --------------->| 459 | | | 460 |<-----------------------NA with ARO----------------------| 461 ... 462 | | 463 |---------------NS with ARO and CGA UID --------------->| 464 | | | 465 |<-----------------------NA with ARO----------------------| 467 Figure 1: Lightweight SEND for LLN Protocol 469 6. Optimizations 471 In this section we present optimizations to the base LSEND defined 472 above. We use EUI-64 identifier instead of source address in CGA 473 calculations. We also extend LSEND operation to 6LoWPAN multihop 474 network. 476 6.1. Overview 478 The scope of the present work is a 6LoWPAN Low Power Lossy Network 479 (LLN), typically a stub network connected to a larger IP network via 480 a Border Router called a 6LBR per [RFC6775]. 482 ---+-------- ............ ------------ 483 | External Network | 484 | 485 +-----+ 486 | | LLN Border 487 | | router 488 +-----+ 489 o o o 490 o o o o 491 o o LLN o o o 492 o o o o 493 o 495 Figure 2: Basic Configuration 497 The 6LBR maintains a registration state for all devices in the 498 attached LLN, and, in conjunction with the first-hop router (the 499 6LR), is in position to validate uniqueness and grant ownership of an 500 IPv6 address before it can be used in the LLN. This is a fundamental 501 difference with a classical network that relies on IPv6 address auto- 502 configuration [RFC4862], where there is no guarantee of ownership 503 from the network, and any IPv6 Neighbor Discovery packet must be 504 individually secured [RFC3971]. 506 In a route-over mesh network, the 6LR is directly connected to the 507 host device; this specification expects that peer-wise Layer-2 508 security is deployed so that all the packets from a particular host 509 are identified as such by the 6LR. The 6LR may be multiple hops away 510 from the 6LBR. Packets are routed between the 6LR and the 6LBR via 511 other 6LRs; this specification expects that a chain of trust is 512 established so that a packet that was validated by the first 6LR can 513 be safely routed by the next 6LRs and 6LBR. 515 The [I-D.ietf-6tisch-architecture] suggests to use RPL [RFC6550] as 516 the routing protocol between the 6LRs and the 6LBR, and to leverage 517 [I-D.chakrabarti-nordmark-6man-efficient-nd] to extend the LLN in a 518 larger multilink subnet [RFC4903]. In that model, a registration 519 flow happens as shown in Figure 3: 521 6LoWPAN Node 6LR 6LBR 6BBR 522 (RPL leaf) (router) (root) 523 | | | | 524 | 6LoWPAN ND |6LoWPAN ND+RPL | Efficient ND | IPv6 ND 525 | LLN link |Route-Over mesh| IPv6 link | Backbone 526 | | | | 527 | NS(ARO) | | | 528 |-------------->| | | 529 | 6LoWPAN ND | DAR (then DAO)| | 530 | |-------------->| | 531 | | | NS(ARO) | 532 | | |-------------->| 533 | | | | DAD 534 | | | |------> 535 | | | | 536 | | | NA(ARO) | 537 | | |<--------------| 538 | | DAC | | 539 | |<--------------| | 540 | NA(ARO) | | | 541 |<--------------| | | 543 Figure 3: (Re-)Registration Flow over Multi-Link Subnet 545 A new device that joins the network auto-configures and address and 546 performs an initial registration to an on-link 6LR with an NS message 547 that carries a new Address Registration Option (ARO) [RFC6775]. The 548 6LR validates with address with the central 6LBR using a DAR/DAC 549 exchange, and the 6LR confirms (or infirms) the address ownership 550 with an NA message that also carries an Address Registration Option. 552 The registration mechanism in [RFC6775] was created for the original 553 purpose of Duplicate Address Detection (DAD), whereby use of an 554 address would be granted as long as the address is not already 555 present in the subnet. But [RFC6775] does not require that the 6LR 556 use the registration for source address validation (SAVI). 558 In order to validate address ownership, that mechanism enables the 559 6LBR to correlate further claims for a registered address with the 560 device to which it is granted, based on a Unique Interface IDentifier 561 (UID) that is derived from the MAC address of the device (EUI-64). 563 The limit of the mechanism in [RFC6775] is that it does not enable to 564 prove the UID itself, so any node connected to the subnet and aware 565 of the address/UID mapping may effectively fake the same UID and 566 steal an address. 568 This draft uses a Cryptographically Generated Address (CGA) [RFC3972] 569 as an alternate UID for the registration. Proof of ownership of the 570 UID is passed with the first registration to a given 6LR, and 571 enforced at the 6LR, which validates the proof. With this new 572 operation, the 6LR allows only packets from a connected host if the 573 connected host owns the registration of the source address of the 574 packet. 576 If a chain of trust is present between the 6LR and the 6LBR, then 577 there is no need to propagate the proof of ownership to the 6LBR. 578 All the 6LBR need to know is that this particular UID is based on 579 CGA, so as to enforce that any update via a different 6LR is also 580 based on CGA. 582 6.2. Protocol Operations 584 Digital signature and CGA are calculated over EUI-64 or interface id 585 of the node. It is only done initially at once not repeated with 586 every message the node sends. The calculation does not change even 587 if the node has a new address since EUI-64 does not change. This 588 means that this CGA can be used to claim multiple targets. The 589 calculation is ECC based as described in Section 4.4. 591 Protocol interactions are as defined in Section 5. The address 592 registration NS message contains CGA Parameters and Digital Signature 593 Option defined in Section 4.2. The node MUST set the Extended Unique 594 Interface IDentifier (EUI-64) field [Guide] in ARO to the 595 crypotographically generated address. The Subnet Prefix field of CGA 596 Parameters MUST be set to the 64-bit prefix in the RA message 597 received from 6LBR. Source address MUST be set to the prefix 598 concatenated with the node's crypotographically generated address. 599 The Public Key field of CGA Parameters MUST be set to the node's ECC 600 Public Key. 602 CGA calculated may need to be modified before it is used as EUI-64. 603 The b2 bit or U/L or "u" bit MUST be set to zero for globally unique 604 and b1 bit or I/G or "g" bit MUST be set to zero for unicast before 605 using it in IPv6 address as the interface identifier. In LSEND, 606 senders and receivers ignore any differences in the three leftmost 607 bits and in bits 6 and 7 (i.e., the "u" and "g" bits) in the 608 interface identifiers [RFC3972]. 610 The Target Address field in NS message is set to the prefix 611 concatenated with the node's crypotographically generated address. 612 This address does not need duplicate address detection as EUI-64 is 613 globally unique. So a host cannot steal an address that is already 614 registered unless it has the key for the EUI-64. The same EUI-64 can 615 thus be used to protect multiple addresses e.g. when the node 616 receives a different prefix. The node adds CGA Parameters (including 617 Public Key) and Digital Signature Option defined in Section 4.2 into 618 NS message. The node sends the address registration option (ARO) 619 which is set to the CGA calculated. 621 Protocol interactions given in Figure 1 are modified a bit in that 622 Digital Signature option with the public key and ARO are passed to 623 and stored by the 6LR/6LBR on the first NS and not sent again the in 624 the next NS. 626 The 6LR/6LBR ensures first-come/first-serve by storing the ARO and 627 the cryptographical material correlated to the target being 628 registered. Then, if the node is the first to claim any address it 629 likes, then it becomes owner of that address and the address is bound 630 to the CGA in the 6LR/6LBR registry. This procedure avoids the 631 constrained device to compute multiple keys for multiple addresses. 632 The registration process allows the node to tie all the addresses to 633 the same EUI-64 and have the 6LR/6LBR enforce first come first serve 634 after that. 636 6.3. Multihop Operation 638 In multihop 6LoWPAN, 6LBR sends RAs with prefixes downstream and it 639 is the 6LR that receives and relays them to the nodes. 6LR and 6LBR 640 communicate with the ICMPv6 Duplicate Address Request (DAR) and the 641 Duplicate Address Confirmation (DAC) messages. The DAR and DAC use 642 the same message format as NS and NA with different ICMPv6 type 643 values. 645 In LSEND we extend DAR/DAC messages to carry CGA Parameters and 646 Digital Signature Option defined in Section 4.2. 648 In a multihop 6LoWPAN, the node exchanges the messages shown in 649 Figure 3. 6LBR must be aware of who owns an address (EUI-64) to 650 defend the first user if there is an attacker on another 6LR. 651 Because of this the content that the source signs and the signature 652 needs to be propagated to the 6LBR in DAR message. For this purpose 653 we need the DAR message sent by 6LR to 6LBR MUST contain CGA 654 Parameters and Digital Signature Option carrying the CGA that the 655 node calculates and its public key. DAR message also contains ARO. 657 It is possible that occasionally, 6LR may miss the node's CGA (that 658 it received in ARO) or the crypto information (that it received in 659 CGA Parameters and Digital Signature Option). 6LR should be able to 660 ask for it again. This is done by restarting the exchanges shown in 661 Figure 1. The result enables 6LR to refresh CGA and public key 662 information that was lost. 6LR MUST send DAR message with CGA 663 Parameters and Digital Signature Option and ARO to 6LBR. 6LBR as a 664 reply forms a DAC message with the information copied from the DAR 665 and the Status field is set to zero. With this exchange, the 6LBR 666 can (re)validate and store the CGA and crypto information to make 667 sure that the 6LR is not a fake. 669 7. Security Considerations 671 The same considerations regarding the threats to the Local Link Not 672 Covered (as in [RFC3971]) apply. 674 The threats discussed in Section 9.2 of [RFC3971] are countered by 675 the protocol described in this document as well. 677 As to the attacks to the protocol itself, denial of service attacks 678 that involve producing a very high number of packets are deemed 679 unlikely because of the assumptions on the node capabilities in low- 680 power and lossy networks. 682 8. IANA considerations 684 This document defines two new options to be used in neighbor 685 discovery protocol messages and new type values for CGA Parameters 686 and Digital Signature Option (TBA1) and Digital Signature Option 687 (TBA2) need to be assigned by IANA. 689 This document defines 0xE8C47FB7FD2BB885DAB2D31A0F2808B4 for LSEND 690 CGA Message Type Tag. 692 9. Acknowledgements 694 TBD. 696 10. References 698 10.1. Normative References 700 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 701 Requirement Levels", BCP 14, RFC 2119, March 1997. 703 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 704 Discovery (ND) Trust Models and Threats", RFC 3756, May 705 2004. 707 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 708 Neighbor Discovery (SEND)", RFC 3971, March 2005. 710 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 711 RFC 3972, March 2005. 713 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 714 Architecture", RFC 4291, February 2006. 716 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 717 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 718 September 2007. 720 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 721 Address Autoconfiguration", RFC 4862, September 2007. 723 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June 724 2007. 726 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 727 over Low-Power Wireless Personal Area Networks (6LoWPANs): 728 Overview, Assumptions, Problem Statement, and Goals", RFC 729 4919, August 2007. 731 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 732 "Elliptic Curve Cryptography Subject Public Key 733 Information", RFC 5480, March 2009. 735 [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad 736 Hoc Networks", RFC 5889, September 2010. 738 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 739 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 740 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 741 Lossy Networks", RFC 6550, March 2012. 743 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 744 "Neighbor Discovery Optimization for IPv6 over Low-Power 745 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 746 November 2012. 748 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 749 Interface Identifiers with IPv6 Stateless Address 750 Autoconfiguration (SLAAC)", RFC 7217, April 2014. 752 [SEC1] "Standards for Efficient Crtptography Group. SEC 1: 753 Elliptic Curve Cryptography Version 2.0", May 2009. 755 [Guide] "Guidelines for 64-bit global Identifier (EUI-64TM)", 756 November 2012, 757 . 759 [ANSIX9.62] 760 "American National Standards Institute (ANSI), ANS 761 X9.62-2005: The Elliptic Curve Digital Signature Algorithm 762 (ECDSA)", November 2005. 764 10.2. Informative references 766 [SEC2] "Standards for Efficient Crtptography Group. SEC 2: 767 Recommended Elliptic Curve Domain Parameters Version 2.0", 768 January 2010. 770 [FIPS-186-3] 771 "National Institute of Standards and Technology, "Digital 772 Signature Standard"", June 2009. 774 [NIST-ST] "National Institute of Standards and Technology, "NIST 775 Comments on Cryptanalytic Attackts on SHA-1"", January 776 2009, 777 . 779 [I-D.rafiee-6man-ssas] 780 Rafiee, H. and C. Meinel, "A Simple Secure Addressing 781 Scheme for IPv6 AutoConfiguration (SSAS)", draft-rafiee- 782 6man-ssas-11 (work in progress), September 2014. 784 [I-D.chakrabarti-nordmark-6man-efficient-nd] 785 Chakrabarti, S., Nordmark, E., Thubert, P., and M. 786 Wasserman, "IPv6 Neighbor Discovery Optimizations for 787 Wired and Wireless Networks", draft-chakrabarti-nordmark- 788 6man-efficient-nd-07 (work in progress), February 2015. 790 [I-D.ietf-6tisch-architecture] 791 Thubert, P., Watteyne, T., Struik, R., and M. Richardson, 792 "An Architecture for IPv6 over the TSCH mode of IEEE 793 802.15.4e", draft-ietf-6tisch-architecture-06 (work in 794 progress), March 2015. 796 Authors' Addresses 798 Behcet Sarikaya (editor) 799 Huawei USA 800 5340 Legacy Dr. Building 3 801 Plano, TX 75024 803 Email: sarikaya@ieee.org 804 Frank Xia 805 Huawei Technologies Co., Ltd. 806 101 Software Avenue, Yuhua District 807 Nanjing, Jiangsu 210012, China 809 Phone: ++86-25-56625443 810 Email: xiayangsong@huawei.com 812 Pascal Thubert (editor) 813 Cisco Systems, Inc 814 Building D 815 45 Allee des Ormes - BP1200 816 MOUGINS - Sophia Antipolis 06254 817 FRANCE 819 Phone: +33 497 23 26 34 820 Email: pthubert@cisco.com