idnits 2.17.1 draft-sarikaya-core-secure-bootsolution-00.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 18, 2013) is 4083 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: 'RFC2119' is defined on line 383, but no explicit reference was found in the text == Unused Reference: 'RFC4919' is defined on line 394, but no explicit reference was found in the text == Unused Reference: 'RFC5548' is defined on line 406, but no explicit reference was found in the text == Unused Reference: 'RFC5673' is defined on line 410, but no explicit reference was found in the text == Unused Reference: 'C1222' is defined on line 419, but no explicit reference was found in the text == Unused Reference: 'NISTIR7628VOL1' is defined on line 434, but no explicit reference was found in the text == Unused Reference: 'RFC3972' is defined on line 450, but no explicit reference was found in the text == Unused Reference: 'RFC4279' is defined on line 453, but no explicit reference was found in the text == Unused Reference: 'RFC4347' is defined on line 457, but no explicit reference was found in the text == Unused Reference: 'RFC4423' is defined on line 460, but no explicit reference was found in the text == Unused Reference: 'RFC5204' is defined on line 471, but no explicit reference was found in the text == Unused Reference: 'RFC5295' is defined on line 482, but no explicit reference was found in the text == Unused Reference: 'RFC5996' is defined on line 487, but no explicit reference was found in the text == Unused Reference: 'ROMER04' is defined on line 501, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-tls-oob-pubkey-07 ** Downref: Normative reference to an Informational RFC: RFC 4919 ** Downref: Normative reference to an Informational RFC: RFC 5548 ** Downref: Normative reference to an Informational RFC: RFC 5673 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-13 -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 4423 (Obsoleted by RFC 9063) -- Obsolete informational reference (is this intentional?): RFC 5204 (Obsoleted by RFC 8004) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 3 errors (**), 0 flaws (~~), 18 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Core B. Sarikaya 3 Internet-Draft Huawei USA 4 Intended status: Standards Track February 18, 2013 5 Expires: August 22, 2013 7 Security Bootstrapping Solution for Resource-Constrained Devices 8 draft-sarikaya-core-secure-bootsolution-00 10 Abstract 12 We present a solution to initially configure the network of resource 13 constrained nodes securely, a.k.a., security bootstrapping. The 14 solution is based on EAP-TLS authentication with the use of raw 15 public keys as certificates. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on August 22, 2013. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Secure Bootstrapping Architecture . . . . . . . . . . . . . . 3 53 3. Secure Bootstrapping Solution using Raw Public Keys . . . . . 4 54 4. Transporting EAP Messages . . . . . . . . . . . . . . . . . . 6 55 5. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 58 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 60 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 62 10.2. Informative References . . . . . . . . . . . . . . . . . 10 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 1. Introduction 67 Bootstrapping is any processing required before the network can 68 operate. The bootstrapping problem is not specific to any MAC or 69 PHY. This problem exists across any two nodes which have no previous 70 knowledge of each other. In particular, this problem is complicated 71 when the nodes are resource-constrained and may not have an advanced 72 user interface. 74 Bootstrapping needs to be secure to make sure that the network 75 operation is secure and hence secure bootstrapping ensures that only 76 the authorized nodes can get access to the network. Because of this 77 secure bootstrapping needs to preceed IP address configuration. 79 [I-D.jennings-core-transitive-trust-enrollment] defines a protocol 80 that enables sensors to securely connect into a system that uses 81 them. The protocol which is being defined is based on the Device 82 using HTTP or COAP [I-D.ietf-core-coap] to communicate with the 83 Controller. This seems to assume that the device is already 84 configured with an IP address. Such an assumption violates the 85 assumption we have in this document on secure bootstrapping. 87 Transport Layer Security (TLS) is commonly used protocol to secure 88 web browsing, emailing, or other client-server applications. In TLS, 89 the client and the server present their certificates and authenticate 90 each other. Recently, raw public key extension is defined to be used 91 as certificates [I-D.ietf-tls-oob-pubkey]. In this document we use 92 the raw public keys in EAP-TLS. 94 The document continues in Section 2 on bootstrapping architecture, in 95 Section 3 on secure bootstrapping solution, in Section 4 on 96 transporting EAP messages, in Section 5 on future work. 98 2. Secure Bootstrapping Architecture 100 Security bootstrapping architecture is structured in a hierarchy of 101 nodes going from the least resource constraint to the most resource 102 constraint. At the top there is a root node. The root node is 103 called Coordinator or Trust Center in Zigbee and 6LowPAN Border 104 Router (6LBR) in 6LoWPAN ND. 106 At the next level there are interior Routers. Routers are able to 107 run a routing protocol between other routers and the root. Routers 108 are called 6LowPAN Routers (6BR) in 6LoWPAN ND. 110 At the lowest level there are the nodes. The nodes do not run a 111 routing protocol. They can connect to the nearest router over a 112 single radio link. The nodes are called End Devices in Zigbee and 113 hosts in 6LoWPAN ND. 115 Routers first join the network as a node and go through security 116 bootstrapping operations in order to create a Master Session Key 117 (MSK). Next, routers execute routing protocol, e.g. [RFC6550] 118 specific steps to create session keys with their neighbors and to 119 establish upstream and downstream next hop parents. 121 At each node hierarachy level described above, there are lower-layer 122 and higher-layer protocols to bootstrap their ciphering keys, where 123 the lower-layer refers to layers below IP layer including IEEE 124 802.15.4 MAC layer and LoWPAN adaptation layer and the higher-layer 125 refers to IP layer and the above. In general, required bootstrapping 126 procedures depend on the bootstrapping protocols to use. Section 127 Section 3 describes the bootstrapping procedures where EAP 128 (Extensible Authentication Protocol) [RFC3748] and other protocols 129 are used as the bootstrapping protocols. 131 3. Secure Bootstrapping Solution using Raw Public Keys 133 When a new resource-constrained device is deployed, it configures its 134 global unique IPv6 address first. This is done by 6LoWPAN Neighbor 135 Discovery (6LoWPAN-ND)'s Router Solicitation/Router Advertisement 136 message exchange [RFC6775]. The newly generated IPv6 address can not 137 be used until the joining device is authenticated and securely joins 138 the network. After the authentication, the joining device receives 139 the current group key of the network, so that the IPv6 registration 140 and further communication can be protected by the link layer 141 ciphering e.g. 802.15.4, then it can start using its global unique 142 IPv6 address for communication. 144 For authentication, Extensible Authentication Protocol (EAP) MUST be 145 used. EAP authentication framework is explained in [RFC5247]. 147 The EAP method EAP-TLS [RFC5216] can be used for the resource- 148 constrained device authentication. Instead of X.509 certificates, 149 raw public key of the device MUST be used. EAP-TLS is executed 150 between the joining device and the AAA server which acts as the 151 Authentication Server (AS). After a successful authentication, the 152 device and the AAA server establish a Master Session Key (MSK), and 153 then the AAA server exports the MSK to the authenticator. Upon 154 receipt of the MSK, the authenticator distributes the group key to 155 the joining device within the authentication success message. The 156 group key is encrypted by a Key Encryption Key derived from the MSK. 158 The resource-constrained device initiates the EAP authentication 159 process by sending a message of initiation to the authenticator, i.e. 160 the root node or 6LBR. The root node requests the identity from the 161 device by sending an EAP-Request/Identity packet. The device replies 162 with an EAP-Response/Identity containing the device's ID. The 163 identity information includes the device's network access ID (NAI). 164 When the root node receives NAI of the device, it sends the identity 165 information to the AS. 167 The AS starts the EAP-TLS authentication process by sending a EAP- 168 TLS/Start packet which is an EAP-Request packet with EAP-Type=EAP-TLS 169 to the device. The device generates a client random number and 170 responds with an EAP-Response/TLS-Client-Hello message which contains 171 the TLS version, a client random number, a set of cipher suites. 172 Only one cipher suite MUST be offered in Client-Hello message with 173 RC4-SHA1. EAP-Response packet MUST have the EAP-Type value set at 174 EAP-TLS Figure 1. 176 The device MUST add an extension of type client certificate type and 177 server certificate type defined in [I-D.ietf-tls-oob-pubkey] to 178 Client-Hello message. Both of these types MUST be set to 179 RawPublicKey. 181 Upon receipt of Client Hello, if the AS supports raw public key 182 extension, it generates a server random number, a new session ID, 183 server certificate type set to RawPublicKey and includes only the 184 SubjectPublicKeyInfo part of the certificate with its raw public key, 185 rather than the whole certificate in the Certificate message and then 186 sends them to the device with an EAP-Request/TLS-Server-Hello 187 message. Server-Key-Exchange message contains a temporary key for 188 the client to encrypt Client Key Exchange message. For the device, 189 the server adds certificate request message to ask for the device's 190 RawPublicKey using client certificate type message. 192 Device receives AS's RawPublicKey. Device SHOULD verify the key 193 using out of band mechanisms. Device sends Client Certificate 194 message containing the device's RawPublicKey. With the client and 195 server random number, the device generates a pre_master_secret, then 196 sends it in Client-Key-Exchange field of EAP-Response/ 197 TLS-Client-Finished message to the AS encrypting pre_master_secret 198 with the temporary key in Server-Key-Exchange message. Device 199 includes Change Cypher Spec message to indicate that all messages 200 that follow Client Finished message will be encrypted. 202 The AS derives the Master Session Key (MSK) and replies with EAP- 203 Request/TLS-Server-Finished message. In this message, the server 204 includes Change Cypher Spec message to indicate that the server will 205 beging encrypting messages with the keys negotiated. The device also 206 derives the MSK after receiving the Server Finished and acknowledges 207 with EAP-Response/EAP-TLS message. 209 The AS then exports the MSK to the authenticator in RADIUS Access- 210 Accept message, the authenticator subsequently sends the EAP-Success 211 message to the device. The AS MUST send the group key in this 212 message and the EAP-TLS ends. 214 Device Authenticator Authentication 215 | Server 216 Device connects to | | 217 Network | | 218 |<----TLS-Start---------|<---EAP-Request--------| 219 |-TLS-ClientHello------>|----EAP-Response------>| 220 |client certificate type| | 221 |server certificate type| | 222 |<-TLS Server Hello-----|<----EAP-Request-------| 223 | |server certificate type| 224 | | Server Certificate | 225 | |client certificate type| 226 | | Certificate Request | 227 | | Server Key Exchange | 228 | | Server Hello Done | 229 |TLS-ClientCertificate->|----EAP-Response------>| 230 |Client Key Exchange | | 231 |Change Cipher Spec | | 232 |Client Finished | | 233 ||----EAP-Response------>| 236 | EAP-Success |<----EAP-Success-------| 237 |Authentication finished| | 239 Figure 1: Authentication Call Flow 241 4. Transporting EAP Messages 243 EAP can be transported between the device and the authenticator 244 either in Layer 3 using PANA [RFC5191] or in Layer 2 using IEEE 245 802.1X [802.1x]. 247 EAP is transported using RADIUS [RFC2865] between the authenticator 248 and authentication server. 250 When a device is not a direct neighbor of the authenticator, its 251 parent node MUST act as relay. Different EAP encapsulation protocols 252 have different mechanisms for the relay function, such as the PANA 253 Relay Element (PRE). 255 After the keys are established from a successful EAP method (such as 256 EAP-TLS), the device runs neighbor discovery protocol to get an IPv6 257 address assigned [RFC6775]. Data transfer can be secured using DTLS 258 or IPSec. Keys derived from EAP TLS are used in either generating 259 DTLS ciphering keys after a successful DTLS handshake or IPSec ESP 260 ciphering keys after a successful IKEv2 handshake. 262 5. Future Work 264 The nodes in a constrained network called devices have wide range of 265 capabilities and are used in diverse number of applications. 266 Different secure bootstrapping solutions may apply to different 267 applications and different types of nodes. In all cases, it is 268 assumed in this document that the devices are IPv6 enabled. 270 The solution described in Section 3 has the most stringent 271 requirements on the devices and therefore is not suitable on less 272 constrained nodes. It seems that the devices used in smart metering 273 may have enough resources to run the bootstrapping protocol and they 274 do not suffer from power constraints compared with most other devices 275 such as light switches. 277 One possible optimization in Figure 1 applies to the case where the 278 device does not have a RawPublicKey. In this case the device sends 279 only server_certificate_type set to RawPublicKey in Client-Hello 280 message. In response, AS sends its RawPublicKey in Server Hello 281 message. As a result the messages are much simpler than in Figure 1. 283 Further optimizations to the EAP-TLS call flow in Figure 1 are TBD. 285 Simpler devices such as light switches, environmental sensors, etc. 286 may have much less resources, much less constrained IPv6 stack and 287 they may not stay on for long periods of times required from the 288 execution of the secure bootstrapping protocol. 290 Identification of a set of applications with similar device 291 capabilities is TBD. 293 Modification of the protocol defined in Section 3 to define a secure 294 bootstrapping protocol for each set is TBD. 296 6. Security Considerations 298 When security bootstrapping resource constraint nodes is undertaken, 299 several attacks are possible and security bootstrapping methods 300 described in this document do not protect the nodes against such 301 attacks. These attacks are similar to the ones described in 302 [RFC3971] and mainly stem from unsecured link layer. Link layer must 303 be secured on each node before the node can begin security 304 bootstrapping. 306 If a bootstrapping protocol does not rely on a pre-shared key for 307 peer authentication, it must rely on an online or offline third-party 308 (e.g., an authentication server, a key distribution center in 309 Kerberos, a certification authority in PKI, a private key generator 310 in ID-based cryptography and so on) to prevent man-in-the-middle 311 attacks during peer authentication. Depending on use cases, a 312 resource-constrained device may not always have access to an online 313 third-party for peer authentication. 315 Depending on use cases, a bootstrapping protocol may deal with 316 authorization separately from authentication in terms of timing and 317 signaling path. For example, two resource-constrained devices A and 318 B may perform mutual authentication using authentication credentials 319 provided by an offline third-party X whereas resource-constrained 320 device A obtains authorization for running a particular application 321 with resource-constrained device B from an online third-party Y 322 before or after the authentication. In some use cases, 323 authentication and authorization are tightly coupled, e.g., 324 successful authentication also means successful authorization. A 325 bootstrapping protocol supports various types of authentication and 326 authorization or different bootstrapping protocols may be used for 327 different types of authentication and authorization. 329 If authorization information includes cryptographic keys, a special 330 care must be taken for dealing with the keys, e.g., guidelines for 331 AAA-based key management are described in [RFC4962]. A 332 recommissioning use case may require revocation and re-installation 333 of authentication credentials (i.e., a certificate or a shared secret 334 and identity information, etc.) to a large number of resource- 335 constrained devices that are already deployed. Re-installation of 336 authentication credentials must be as secure as the initial 337 installation regardless of whether the re-installation is done 338 manually or automatically. 340 If resource-constrained devices use a multicast group key for peer 341 authentication or message authentication or encryption, the group key 342 must be securely distributed to the current members of the group for 343 both initial key distribution and key update. Protocols designed for 344 group key management such as GSAKMP [RFC4535], GDOI [RFC3547] and 345 MIKEY [RFC3830] may be used for group key distribution. 346 Alternatively, key wrap attributes for securely encapsulating group 347 key may be defined in network access authentication protocols such as 348 PANA [RFC5191] and EAP-TTLSv0 [RFC5281]. Those protocols use an end- 349 to-end, point-to-point communication channel with a pair-wise 350 security association between a key distribution center and each key 351 recipient. Further considerations may be needed for more efficient 352 group key management to support a large number of resource- 353 constrained devices. 355 7. IANA Considerations 357 This memo includes no request to IANA. 359 8. Contributors 361 TBD. 363 9. Acknowledgements 365 TBD. 367 10. References 369 10.1. Normative References 371 [802.15.4] 372 IEEE Std 802.15.4-2006, "Wireless Medium Access Control 373 (MAC) and Physical Layer (PHY) Specifications for Low Rate 374 Wireless Personal Area Networks (WPANs)", September 2006. 376 [I-D.ietf-tls-oob-pubkey] 377 Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 378 T. Kivinen, "Out-of-Band Public Key Validation for 379 Transport Layer Security (TLS)", 380 draft-ietf-tls-oob-pubkey-07 (work in progress), 381 February 2013. 383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 384 Requirement Levels", BCP 14, RFC 2119, March 1997. 386 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 387 "Remote Authentication Dial In User Service (RADIUS)", 388 RFC 2865, June 2000. 390 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 391 Levkowetz, "Extensible Authentication Protocol (EAP)", 392 RFC 3748, June 2004. 394 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 395 over Low-Power Wireless Personal Area Networks (6LoWPANs): 396 Overview, Assumptions, Problem Statement, and Goals", 397 RFC 4919, August 2007. 399 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 400 Yegin, "Protocol for Carrying Authentication for Network 401 Access (PANA)", RFC 5191, May 2008. 403 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 404 Authentication Protocol", RFC 5216, March 2008. 406 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 407 "Routing Requirements for Urban Low-Power and Lossy 408 Networks", RFC 5548, May 2009. 410 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 411 "Industrial Routing Requirements in Low-Power and Lossy 412 Networks", RFC 5673, October 2009. 414 10.2. Informative References 416 [802.1x] IEEE Std 802.1X-2010, "IEEE 802.1X Port-Based Network 417 Access Control", February 2010. 419 [C1222] American National Standard, "Protocol Specification For 420 Interfacing to Data Communication Networks", ANSI C12.22- 421 2008, 2008. 423 [I-D.ietf-core-coap] 424 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 425 "Constrained Application Protocol (CoAP)", 426 draft-ietf-core-coap-13 (work in progress), December 2012. 428 [I-D.jennings-core-transitive-trust-enrollment] 429 Jennings, C., "Transitive Trust Enrollment for Constrained 430 Devices", 431 draft-jennings-core-transitive-trust-enrollment-01 (work 432 in progress), October 2012. 434 [NISTIR7628VOL1] 435 The Smart Grid Interoperability Panel - Cyber Security 436 Working Group, "Guidelines for Smart Grid Cyber Security: 437 Vol. 1, Smart Grid Cyber Security Strategy, Architecture, 438 and High-Level Requirements", NISTIR 7628, vol. 1, 2010. 440 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 441 Group Domain of Interpretation", RFC 3547, July 2003. 443 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 444 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 445 August 2004. 447 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 448 Neighbor Discovery (SEND)", RFC 3971, March 2005. 450 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 451 RFC 3972, March 2005. 453 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 454 for Transport Layer Security (TLS)", RFC 4279, 455 December 2005. 457 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 458 Security", RFC 4347, April 2006. 460 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 461 (HIP) Architecture", RFC 4423, May 2006. 463 [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, 464 "GSAKMP: Group Secure Association Key Management 465 Protocol", RFC 4535, June 2006. 467 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 468 Authorization, and Accounting (AAA) Key Management", 469 BCP 132, RFC 4962, July 2007. 471 [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 472 Rendezvous Extension", RFC 5204, April 2008. 474 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 475 Authentication Protocol (EAP) Key Management Framework", 476 RFC 5247, August 2008. 478 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 479 Protocol Tunneled Transport Layer Security Authenticated 480 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. 482 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 483 "Specification for the Derivation of Root Keys from an 484 Extended Master Session Key (EMSK)", RFC 5295, 485 August 2008. 487 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 488 "Internet Key Exchange Protocol Version 2 (IKEv2)", 489 RFC 5996, September 2010. 491 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 492 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 493 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 494 Lossy Networks", RFC 6550, March 2012. 496 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 497 "Neighbor Discovery Optimization for IPv6 over Low-Power 498 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 499 November 2012. 501 [ROMER04] Romer, K. and F. Mattern, "The design space of wireless 502 sensor networks", IEEE Wireless Communications, vol. 11, 503 no. 6, pp. 54-61, December 2004. 505 [SE2.0] ZigBee Alliance, "Smart Energy Profile 2.0 Technical 506 Requirements Document", April 2010. 508 Author's Address 510 Behcet Sarikaya 511 Huawei USA 512 5340 Legacy Dr. 513 Plano, TX 75024 515 Email: sarikaya@ieee.org