idnits 2.17.1 draft-sarikaya-6lo-cga-nd-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 10, 2014) is 3484 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 564, but no explicit reference was found in the text == Unused Reference: 'I-D.rafiee-6man-ssas' is defined on line 569, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3756 -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' -- Possible downref: Non-RFC (?) normative reference: ref. 'Guide' == Outdated reference: A later version (-07) exists of draft-thubert-6lo-rfc6775-update-reqs-04 Summary: 1 error (**), 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: April 13, 2015 Huawei Technologies Co., Ltd. 6 October 10, 2014 8 Lightweight and Secure Neighbor Discovery for Low-power and Lossy 9 Networks 10 draft-sarikaya-6lo-cga-nd-01 12 Abstract 14 Modifications to 6lowpan Neighbor Discovery protocol are proposed in 15 order to secure the neighbor discovery for low-power and lossy 16 networks. This document defines lightweight and secure version of 17 the neighbor discovery for low-power and lossy networks. The nodes 18 generate a Cryptographically Generated Address, register the 19 Cryptographically Generated Address with a default router and 20 periodically refresh the registration. Cryptographically generated 21 address and digital signatures are calculated using elliptic curve 22 cryptography, so that the cryptographic operations are suitable for 23 low power devices. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 13, 2015. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 62 4. New Options . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4.1. CGA Parameters and Digital Signature Option . . . . . . . 3 64 4.2. Digital Signature Option . . . . . . . . . . . . . . . . 5 65 4.3. Calculation of the Digital Signature and CGA Using ECC . 7 66 5. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 7 67 5.1. Packet Sizes . . . . . . . . . . . . . . . . . . . . . . 9 68 6. Optimizations . . . . . . . . . . . . . . . . . . . . . . . . 9 69 6.1. Multihop Operation . . . . . . . . . . . . . . . . . . . 11 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 75 10.2. Informative references . . . . . . . . . . . . . . . . . 13 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 78 1. Introduction 80 Neighbor discovery for IPv6 [RFC4861] and stateless address 81 autoconfiguration [RFC4862], together referred to as neighbor 82 discovery protocols (NDP), are defined for regular hosts operating 83 with wired/wireless links. These protocols are not suitable and 84 require optimizations for resource constrained, low power hosts 85 operating with lossy wireless links. Neighbor discovery 86 optimizations for 6lowpan networks include simple optimizations such 87 as a host address registration feature using the address registration 88 option which is sent in unicast Neighbor Solicitation (NS) and 89 Neighbor Advertisement (NA) messages [RFC6775]. 91 Neighbor discovery protocols (NDP) are not secure especially when 92 physical security on the link is not assured and vulnerable to 93 attacks defined in [RFC3756]. Secure neighbor discovery protocol 94 (SEND) is defined to secure NDP [RFC3971]. Cryptographically 95 generated addresses (CGA) are used in SEND [RFC3972]. SEND mandates 96 the use of the RSA signature algorithm which is computationally heavy 97 and not suitable to use for low-power and resource constrained nodes. 98 The use of an RSA public key and signature leads to long message 99 sizes not suitable to use in low-bit rate, short range, asymmetric 100 and non-transitive links such as IEEE 802.15.4. 102 In this document we extend the 6lowpan neighbor discovery protocol 103 with cryptographically generated addresses. The nodes generate CGAs 104 and register them with the default router. CGA generation is based 105 on elliptic curve cryptography (ECC)and signature is calculated using 106 elliptic curve digital signature algorithm (ECDSA) known to be 107 lightweight, leading to much smaller packet sizes. The resulting 108 protocol is called Lightweight Secure Neighbor Discovery Protocol 109 (LSEND). 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 The terminology in this document is based on the definitions in 118 [RFC3971], [RFC3972] in addition to the ones specified in [RFC6775]. 120 3. Problem Statement 122 6LowPAN neighbor discovery protocol [RFC6775] needs to be extended to 123 make it secure and also for being more efficient as well as other use 124 cases. Requirements on such enhancements are stated in 125 [I-D.thubert-6lo-rfc6775-update-reqs]. 127 4. New Options 129 4.1. CGA Parameters and Digital Signature Option 131 This option contains both CGA parameters and the digital signature. 133 A summary of the CGA Parameters and Digital Signature Option format 134 is shown below. 136 0 1 2 3 137 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 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Type | Length | Pad Length | Sig. Length | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | | 142 . . 143 . CGA Parameters . 144 . . 145 | | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | | 148 . . 149 . Digital Signature . 150 . . 151 | | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | | 154 . . 155 . Padding . 156 . . 157 | | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 Type 162 TBA1 for CGA Parameters and Digital Signature 164 Length 166 The length of the option (including the Type, Length, Pad Length, 167 Signature Length, CGA Parameters, Digital Signature and Padding 168 fields) in units of 8 octets. 170 Pad Length 172 The length of the Padding field. 174 Sig Length 176 The length of the Digital Signature field. 178 CGA Parameters 180 The CGA Parameters field is variable-length containing the CGA 181 Parameters data structure described in Section 4 of [RFC3972]. 183 Digital Signature 185 The Digital Signature field is a variable length field containing 186 a Elliptic Curve Digital Signature Algorithm (ECDSA) signature 187 (with SHA-256 and P-256 curve of [FIPS-186-3]). Digital signature 188 is constructed as explained in Section 4.3. 190 Padding 192 The Padding field contains a variable-length field making the CGA 193 Parameters and Digital Signature Option length a multiple of 8. 195 4.2. Digital Signature Option 197 This option contains the digital signature. 199 A summary of the Digital Signature Option format is shown below. 200 Note that this option has the same format as RSA Signature Option 201 defined in [RFC3971]. The differences are that Digital Signature 202 field carries an ECDSA signature not an RSA signature, and in 203 calculating Key Hash field SHA-2 is used instead of SHA-1. 205 In the sequence of octets to be signed using the sender's private key 206 includes 128-bit CGA Message Type tag. In LSEND, CGA Message Type 207 tag of 0xE8C47FB7FD2BB885DAB2D31A0F2808B4 MUST be used. 209 0 1 2 3 210 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 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Type | Length | Reserved | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | | 215 | Key Hash | 216 | | 217 | | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | | 220 . . 221 . Digital Signature . 222 . . 223 | | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | | 226 . . 227 . Padding . 228 . . 229 | | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 Type 234 TBA2 for Digital Signature 236 Length 238 The length of the option (including the Type, Length, Reserved, 239 Key Hash, Digital Signature and Padding fields) in units of 8 240 octets. 242 Key Hash 244 The Key Hash field is a 128-bit field containing the most 245 significant (leftmost) 128 bits of a SHA-2 hash of the public key 246 used for constructing the signature. This is the same as in 247 [RFC3971] except for SHA-1 which has been replaced by SHA-2. 249 Digital Signature 251 Same as in Section 4.1. 253 Padding 254 The Padding field contains a variable-length field containing as 255 many bytes long as remain after the end of the signature. 257 4.3. Calculation of the Digital Signature and CGA Using ECC 259 Due to the use of Elliptic Curve Cryptography, the following 260 modifications are needed to [RFC3971] and [RFC3972]. 262 The digital signature is constructed by using the sender's private 263 key over the same sequence of octets specified in Section 5.2 of 264 [RFC3971] up to all neighbor discovery protocol options preceding the 265 Digital Signature option containing the ECC-based signature. The 266 signature value is computed using the ECDSA signature algorithm as 267 defined in [SEC1] and hash function SHA-256. 269 Public Key is the most important parameter in CGA Parameters defined 270 in Section 4.1. Public Key MUST be DER-encoded ASN.1 structure of 271 the type SubjectPublicKeyInfo formatted as ECC Public Key. The 272 AlgorithmIdentifier, contained in ASN.1 structure of type 273 SubjectPublicKeyInfo, MUST be the (unrestricted) id- ecPublicKey 274 algorithm identifier, which is OID 1.2.840.10045.2.1, and the 275 subjectPublicKey MUST be formatted as an ECC Public Key, specified in 276 Section 2.2 of [RFC5480]. 278 Note that the ECC key lengths are determined by the namedCurves 279 parameter stored in ECParameters field of the AlgorithmIdentifier. 280 The named curve to use is secp256r1 corresponding to P-256 which is 281 OID 1.2.840.10045.3.1.7 [SEC2]. 283 ECC Public Key could be in uncompressed form or in compressed form 284 where the first octet of the OCTET STRING is 0x04 and 0x02 or 0x03, 285 respectively. Point compression using secp256r1 reduces the key size 286 by 32 octets. In LSEND, point compression MUST be supported. 288 5. Protocol Interactions 290 Lightweight Secure Neighbor Discovery for Low-power and Lossy 291 Networks (LSEND for LLN) modifies Neighbor Discovery Optimization for 292 Low-power and Lossy Networks [RFC6775] as explained in this section. 293 Protocol interactions are shown in Figure 1. 295 6LoWPAN Border Routers (6LBR) send router advertisements (RA). 296 6LoWPAN Nodes (6LN, or simply "nodes") receive these RAs and generate 297 their own cryptographically generated addresses using elliptic curve 298 cryptography as explained in Section 4.3. The node sends a neighbor 299 solicitation (NS) message with the address registration option (ARO) 300 to 6LBR. Such a NS is called an address registration NS. 302 An LSEND for LLN node MUST send an address registration NS message 303 after adding CGA Parameters and Digital Signature Option defined in 304 Section 4.1. Source address MUST be set to its crypotographically 305 generated address. An LSEND for LLN node MUST set the Extended 306 Unique Identifier (EUI-64) field [Guide] in ARO to the rightmost 64 307 bits of its crypotographically generated address. The Subnet Prefix 308 field of CGA Parameters MUST be set to the leftmost 64 bits of its 309 crypotographically generated address. The Public Key field of CGA 310 Parameters MUST be set to the node's ECC Public Key. 312 6LBR receives the address registration NS. 6LBR then verifies the 313 source address as described in Section 5.1.2. of [RFC3971] using the 314 claimed source address and CGA Parameters field in the message. 315 After successfully verifying the address 6LBR next does a 316 cryptographic check of the signature included in the Digital 317 Signature field in the message. If all checks succeed then 6LBR 318 performs a duplicate address detection procedure on the address. If 319 that also succeeds 6LBR registers the CGA in the neighbor cache. 6LBR 320 also caches the node's public key. 322 6LBR sends an address registration neighbor advertisement (NA) as a 323 reply to confirm the node's registration. Status is set to 0 to 324 indicate success. This completes initial address registration. The 325 address registration needs to be refreshed after the neighbor cache 326 entry times out. 328 6LN 6LBR 329 | | 330 |<-----------------------RA-------------------------------| 331 | | 332 |---------------NS with ARO and CGA Option--------------->| 333 | | 334 |<-----------------------NA with ARO----------------------| 335 | | 336 |---------------NS with ARO and Digital Signature Option->| 337 | | 338 |<-----------------------NA with ARO----------------------| 339 | | 340 |---------------NS with ARO and Digital Signature Option->| 341 | | 342 |<-----------------------NA with ARO----------------------| 344 Figure 1: Lightweight SEND for LLN Protocol 346 In order to refresh the neighbor cache entry, an LSEND for LLN node 347 MUST send an address registration NS message after adding the Digital 348 Signature Option defined in Section 4.2. The Key Hash field is a 349 hash of the node's public key and MUST be set as described in 350 Section 4.2. The Digital Signature field MUST be set as described in 351 Section 4.2. 353 6LBR receives the address registration refresh NS. 6LBR uses the key 354 hash field in Digital Signature Option to find the node's public key 355 from the neighbor cache. 6LBR verifies the digital signature in the 356 NS. In case of successful verification, 6LBR sends back an address 357 registration neighbor advertisement (NA) to the node and sets the 358 status to 0 indicating successful refreshment of the CGA of the node. 359 Similar refresh NS and NA exchanges happen afterwards as shown in 360 Figure 1. 362 5.1. Packet Sizes 364 An original address registration NS message that contains a 40 byte 365 header and ARO is 16 octets. DER-encoded ECC Public Key for P-256 366 curve is 88 octets long uncompressed and 88-32=56 octets with point 367 compression. Digital Signature field when using ECDSA for P-256 368 curve is 72 octets long without padding bytes for a DER encoding of 369 the ASN.1 type "ECDSA-sig-value" [ANSIX9.62]. 371 CGA Parameters and Digital Signature Option's CGA Parameters include 372 16 octet modifier, 8 octet prefix obtained from the router 373 advertisement message sent from 6LBR, 1 octet collision count and 56 374 octet Public Key. Digital Signature is 72 octets. The option is 160 375 octets with Padding of 7 octets. The total message size of an 376 original LSEND address registration NS message is 216 octets and such 377 a message can be encapsulated into three 802.15.4 frames. 379 An address registration refresh NS message contains an ARO which is 380 16 octets and the digital signature option containing 16 octet key 381 hash and 71 octet signature and 5 octet Padding. The message is 152 382 octets long with the header. Such a message could be encapsulated in 383 two 802.15.4 frames. 385 The overhead of LSEND is valid initially and in base LSEND, possibly 386 after bootstrapping at the address registration neighbor solicitation 387 message. It disappears after that as we explain below in Section 6 388 in case optimal LSEND is used. 390 6. Optimizations 392 In this section we present optimizations to the base LSEND defined 393 above. We use EUI-64 identifier instead of source address in CGA 394 calculations. We also extend LSEND operation to 6LoWPAN multihop 395 network. 397 Digital signature and CGA are calculated over EUI-64 or interface id 398 of the node. It is only done initially at once not repeated with 399 every message the node sends. The calculation does not change even 400 if the node has a new address since EUI-64 does not change. This 401 means that this CGA can be used to claim multiple targets. The 402 calculation is ECC based as described in Section 4.3. 404 Protocol interactions are as defined in Section 5. The address 405 registration NS message contains CGA Parameters and Digital Signature 406 Option defined in Section 4.1. The node MUST set the Extended Unique 407 Identifier (EUI-64) field [Guide] in ARO to the crypotographically 408 generated address. The Subnet Prefix field of CGA Parameters MUST be 409 set to the 64-bit prefix in the RA message received from 6LBR. 410 Source address MUST be set to the prefix concatenated with the node's 411 crypotographically generated address. The Public Key field of CGA 412 Parameters MUST be set to the node's ECC Public Key. 414 CGA calculated may need to be modified before it is used as EUI-64. 415 The b2 bit or U/L or "u" bit MUST be set to zero for globally unique 416 and b1 bit or I/G or "g" bit MUST be set to zero for unicast before 417 using it in IPv6 address as the interface identifier. In LSEND, 418 senders and receivers ignore any differences in the three leftmost 419 bits and in bits 6 and 7 (i.e., the "u" and "g" bits) in the 420 interface identifiers [RFC3972]. 422 The Target Address field in NS message is set to the prefix 423 concatenated with the node's crypotographically generated address. 424 This address does not need duplicate address detection as EUI-64 is 425 globally unique. So a host cannot steal an address that is already 426 registered unless it has the key for the EUI-64. The same EUI-64 can 427 thus be used to protect multiple addresses e.g. when the node 428 receives a different prefix. The node adds CGA Parameters (including 429 Public Key) and Digital Signature Option defined in Section 4.1 into 430 NS message. The node sends the address registration option (ARO) 431 which is set to the CGA calculated. 433 Protocol interactions given in xref target="Dynamic-fig"/> are 434 modified a bit in that Digital Signature option with the public key 435 and ARO are passed to and stored by the 6LR/6LBR on the first NS and 436 not sent again the in the next NS. 438 The 6LR/6LBR ensures first-come/first-serve by storing the ARO and 439 the cryptographical material correlated to the target being 440 registered. Then, if the node is the first to claim any address it 441 likes, then it becomes owner of that address and the address is bound 442 to the CGA in the 6LR/6LBR registry. This procedure avoids the 443 constrained device to compute multiple keys for multiple addresses. 444 The registration process allows the node to tie all the addresses to 445 the same EUI-64 and have the 6LR/6LBR enforce first come first serve 446 after that. 448 6.1. Multihop Operation 450 In multihop 6LoWPAN, 6LBR sends RAs with prefixes downstream and it 451 is the 6LR that receives and relays them to the nodes. 6LR and 6LBR 452 communicate with the ICMPv6 Duplicate Address Request (DAR) and the 453 Duplicate Address Confirmation (DAC) messages. The DAR and DAC use 454 the same message format as NS and NA with different ICMPv6 type 455 values. 457 In LSEND we extend DAR/DAC messages to carry CGA Parameters and 458 Digital Signature Option defined in Section 4.1. 460 In a multihop 6LoWPAN, the node exchanges the messages shown in 461 Figure 1 with 6LR not with 6LBR. 6LBR must be aware of who owns an 462 address (EUI-64) to defend the first user if there is an attacker on 463 another 6LR. Because of this the content that the source signs and 464 the signature needs to be propagated to the 6LBR in DAR message. For 465 this purpose we need the DAR message sent by 6LR to 6LBR MUST contain 466 CGA Parameters and Digital Signature Option carrying the CGA that the 467 node calculates and its public key. DAR message also contains ARO. 469 It is possible that occasionally, 6LR may miss the node's CGA (that 470 it received in ARO) or the crypto information (that it received in 471 CGA Parameters and Digital Signature Option). 6LR should be able to 472 ask for it again. This is done by restarting the exchanges shown in 473 Figure 1. The result enables 6LR to refresh CGA and public key 474 information that was lost. 6LR MUST send DAR message with CGA 475 Parameters and Digital Signature Option and ARO to 6LBR. 6LBR as a 476 reply forms a DAC message with the information copied from the DAR 477 and the Status field is set to zero. With this exchange, the 6LBR 478 can (re)validate and store the CGA and crypto information to make 479 sure that the 6LR is not a fake. 481 7. Security Considerations 483 The same considerations regarding the threats to the Local Link Not 484 Covered (as in [RFC3971]) apply. 486 The threats discussed in Section 9.2 of [RFC3971] are countered by 487 the protocol described in this document as well. 489 As to the attacks to the protocol itself, denial of service attacks 490 that involve producing a very high number of packets are deemed 491 unlikely because of the assumptions on the node capabilities in low- 492 power and lossy networks. 494 8. IANA considerations 496 This document defines two new options to be used in neighbor 497 discovery protocol messages and new type values for CGA Parameters 498 and Digital Signature Option (TBA1) and Digital Signature Option 499 (TBA2) need to be assigned by IANA. 501 This document defines 0xE8C47FB7FD2BB885DAB2D31A0F2808B4 for LSEND 502 CGA Message Type Tag. 504 9. Acknowledgements 506 Greg Zaverucha from RIM made contributions to this document. 507 Comments from Pascal Thubert are appreciated. 509 10. References 511 10.1. Normative References 513 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 514 Requirement Levels", BCP 14, RFC 2119, March 1997. 516 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 517 Discovery (ND) Trust Models and Threats", RFC 3756, May 518 2004. 520 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 521 Neighbor Discovery (SEND)", RFC 3971, March 2005. 523 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 524 RFC 3972, March 2005. 526 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 527 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 528 September 2007. 530 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 531 Address Autoconfiguration", RFC 4862, September 2007. 533 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 534 "Elliptic Curve Cryptography Subject Public Key 535 Information", RFC 5480, March 2009. 537 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 538 "Neighbor Discovery Optimization for IPv6 over Low-Power 539 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 540 November 2012. 542 [SEC1] "Standards for Efficient Crtptography Group. SEC 1: 543 Elliptic Curve Cryptography Version 2.0", May 2009. 545 [Guide] "Guidelines for 64-bit global Identifier (EUI-64TM)", 546 November 2012, 547 . 549 [ANSIX9.62] 550 "American National Standards Institute (ANSI), ANS 551 X9.62-2005: The Elliptic Curve Digital Signature Algorithm 552 (ECDSA)", November 2005. 554 10.2. Informative references 556 [SEC2] "Standards for Efficient Crtptography Group. SEC 2: 557 Recommended Elliptic Curve Domain Parameters Version 2.0", 558 January 2010. 560 [FIPS-186-3] 561 "National Institute of Standards and Technology, "Digital 562 Signature Standard"", June 2009. 564 [NIST-ST] "National Institute of Standards and Technology, "NIST 565 Comments on Cryptanalytic Attackts on SHA-1"", January 566 2009, 567 . 569 [I-D.rafiee-6man-ssas] 570 Rafiee, H. and C. Meinel, "A Simple Secure Addressing 571 Scheme for IPv6 AutoConfiguration (SSAS)", draft-rafiee- 572 6man-ssas-11 (work in progress), September 2014. 574 [I-D.thubert-6lo-rfc6775-update-reqs] 575 Thubert, P., "Requirements for an update to 6LoWPAN ND", 576 draft-thubert-6lo-rfc6775-update-reqs-04 (work in 577 progress), August 2014. 579 Authors' Addresses 581 Behcet Sarikaya (editor) 582 Huawei USA 583 5340 Legacy Dr. Building 3 584 Plano, TX 75024 586 Email: sarikaya@ieee.org 587 Frank Xia 588 Huawei Technologies Co., Ltd. 589 101 Software Avenue, Yuhua District 590 Nanjing, Jiangsu 210012, China 592 Phone: ++86-25-56625443 593 Email: xiayangsong@huawei.com