idnits 2.17.1 draft-kumar-dice-dtls-relay-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 : ---------------------------------------------------------------------------- ** There are 80 instances of too long lines in the document, the longest one being 19 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 417 has weird spacing: '...relayed messa...' -- The document date (April 22, 2014) is 3654 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) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-07) exists of draft-marin-ace-wg-coap-eap-00 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DICE Working Group S. Kumar 3 Internet-Draft Philips Research 4 Intended status: Standards Track S. Keoh 5 Expires: October 24, 2014 University of Glasgow Singapore 6 O. Garcia-Morchon 7 Philips Research 8 April 22, 2014 10 DTLS Relay for Constrained Environments 11 draft-kumar-dice-dtls-relay-01 13 Abstract 15 The 6LoWPAN and CoAP standards defined for resource-constrained 16 devices are fast emerging as the de-facto protocols for enabling the 17 Internet-of-Things (IoTs). Security is an important concern in IoTs 18 and the DTLS protocol has been chosen as the preferred method for 19 securing CoAP messages. DTLS is a point-to-point protocol relying on 20 the IP routing to deliver messages between the client and the server. 21 However in some low-power lossy networks (LLNs) with multi-hop, a new 22 "joining" device may not be initially IP routable until it is 23 authenticated to the network. This prevents DTLS from being directly 24 useful as an authentication and confidentiality protocol during this 25 stage, requiring other security protocols to be implemented on the 26 device. These devices being resource-constrained often cannot 27 accommodate more than one security protocol in their code memory. To 28 overcome this problem and reuse DTLS, we present a DTLS Relay 29 solution for the non-IP routable "joining" device to establish a 30 secure DTLS connection with a DTLS server. Further we present a 31 stateful and stateless mode of operation for the DTLS Relay. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on October 24, 2014. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. DTLS relay . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. Relay in Stateful mode . . . . . . . . . . . . . . . . . 6 71 3.2. Relay in Stateless mode . . . . . . . . . . . . . . . . . 8 72 3.3. Comparison between the two modes . . . . . . . . . . . . 10 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 78 7.2. Informative References . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 The Internet-of-Things (IoTs) vision is more closer to reality with 84 the IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) 85 [RFC4944] and Constrained Application Protocol (CoAP) 86 [I-D.ietf-core-coap] standards . The 6LoWPAN adaptation layer allows 87 for transmission of IPv6 Packets over IEEE 802.15.4 networks 88 [ieee802.15.4] and thereby enabling end-to-end IPv6 connectivity of 89 "Things". CoAP is a web protocol based on REST architecture designed 90 to work under the special requirements of the constrained 91 environment. It supports binding to UDP [RFC0768] which is preferred 92 over TCP [RFC0793] in low-power lossy networks (LLNs) such as IEEE 93 802.15.4. 95 Security is important concern in such a wireless multi-hop network 96 that could be used in various application domains such as smart 97 energy and building automation. However security protocols are often 98 heavy-weight both in terms of code and network processing. Due to 99 the constrained nature of most of these devices, multiple security 100 protocols for different purposes and at different networking layers 101 are hard to envision. It is more efficient to use a single security 102 protocol to fulfill multiple security requirements in such 103 constrained environments. 105 CoAP has chosen Datagram Transport Layer Security (DTLS) [RFC6347] as 106 the preferred security protocol for authenticity and confidentiality 107 of the messages. It is based on Transport Layer Security (TLS) 108 [RFC5246] with modifications to run over UDP. DTLS makes use of 109 additional reliability mechanisms in its handshake due to the lack of 110 TCP reliable transmission mechanisms that are available to TLS. 112 DTLS is a point-to-point protocol relying on the underlying IP layer 113 to perform the routing between the DTLS client and the DTLS server. 114 However in some LLNs with multi-hop, a new "joining" device may not 115 be initially IP routable until it is authenticated to the network. A 116 new "joining" device can only initially use a link-local IPv6 address 117 to communicate with a neighbour node using neighbour discovery 118 [RFC6775] until it receives the necessary network configuration 119 parameters. However, before the device can receive these 120 configuration parameters, it may need to authenticate itself or wish 121 to authenticate the network to which it connects. DTLS although a 122 suitable protocol for such authentication and secure transfer of 123 configuration parameters, would not work due to the lack of IP 124 routability of DTLS messages between the intended recipients. 126 We present a DTLS Relay solution to overcome this problem for the 127 "joining" device to establish a secure DTLS connection with a DTLS 128 server. This draft is inspired by the Protocol for carrying 129 Authentication for Network Access (PANA) Relay Element [RFC6345] 130 which is intended to solve a similar problem when PANA [RFC5191] is 131 used as the transport protocol for Extensible Authentication Protocol 132 (EAP) [RFC3748] based network access. Recently there has been 133 interest in transporting EAP over CoAP 134 [I-D.marin-ace-wg-coap-eap][I-D.ohba-core-eap-based-bootstrapping] 135 and presented DTLS Relay solution can be used to secure these 136 messages. Further we present a stateful and stateless mode of 137 operation for the DTLS Relay. 139 This draft is an early description of the solutions and does not 140 provide the complete details yet. This draft is structured as 141 follows: we present a use-case for the DTLS Relay in Section 2, then 142 present the DTLS Relay solution in Section 3 for stateful and 143 stateless mode of operation. We compare these two solutions in 144 Section 3.3. Further we present some security considerations in 145 Section 5. 147 2. Use Case 149 We present here a target usecase based on 150 [I-D.jennings-core-transitive-trust-enrollment] describing a 151 rendezvous protocol that allows a constrained IoT device to securely 152 connect into a system or network. The main idea is that the joining 153 Device has a pre-established trust relationship with a "Transfer 154 Agent" entity, for e.g. Pre-Shared Keys provisioned during 155 manufacturing. This "Transfer Agent" provides the needed trust 156 credentials to the Device and/or a Controller in the system to 157 establish a secured connection to perform further authentication and 158 transfer of system/network configuration parameters. This step is 159 enabled by an "Introducer" entity which informs the "Transfer Agent" 160 about the details of Controller to which the joining Device should 161 connect, and provide to the Controller the identity including one- 162 time credentials for enable secure connection to the Device. The 163 transitive trust trust establishment procedure is explained in detail 164 in [I-D.jennings-core-transitive-trust-enrollment] and we focus here 165 on how to enable this using DTLS. 167 As depicted in the Figure 1, the joining Device (D) is multi-hop away 168 from the Controller (C) and not yet authenticated into the network. 169 At this stage, it can only communicate one-hop to its nearest 170 neighbour (N) using their link-local IPv6 addresses. However, the 171 Device needs to communicate with end-to-end security with a Transfer 172 Agent (T) or to Controller (C) to authenticate and get the relevant 173 system/network parameters. If the Device (D), initiates a DTLS 174 connection to the Transfer Agent that has been pre-configured, then 175 the packets are dropped at the neighbour (N) since the Device (D) is 176 not yet admitted to the network or there is no IP-routability to 177 Device (D) for any returned messages. 179 Trust Agent 180 ++++ 181 |T | 182 | | +--+ 183 ++++ |N'| 184 | --+--+ 185 | ++++ / 186 | |C |---- +--+ +--+ 187 --| | \ |N |........|D | 188 ++++ \-----| | | | 189 Controller +--+ +--+ 190 Neighbour "join" Device 192 Figure 1: Use case depiction in a multi-hop network 194 Further the Device (D) may wish to establish a secure connection to 195 the Controller (C) in the network assuming credentials are exchanged 196 out-of-band, for e.g. a hash of the Device (D)'s raw public key could 197 be provided to the Controller (C). However, the Device (D) is 198 unaware of the IP address of the Controller (C) to initiate a DTLS 199 connection and perform authentication. 201 To overcome these problems with non-routability of DTLS packets and/ 202 or discovery of the destination address of the DTLS server to 203 contact, we define a DTLS Relay solution. This DTLS Relay ability is 204 configured into all authenticated devices in the network which may 205 act as the Neighbour (N) device for newly joining nodes. The DTLS 206 Relay allows for relaying of the packets from the Neighbour (N) using 207 IP-routing to the intended DTLS server. Further, if the DTLS server 208 address is not known to the joining Device (D), then messages are 209 delivered to a pre-configured DTLS server address (mostly the 210 Controller (C)) known to the DTLS Relay. 212 3. DTLS relay 214 In this section, we describe how the DTLS Relay functionality can be 215 achieved. When a joining device as a client attempts a DTLS 216 connection (for example to a "Transfer Agent"), it uses its link- 217 local IP address as its IP source address. This message is 218 transmitted one-hop to a neighbour node. Under normal circumstances, 219 this message would be dropped at the neighbour node since the joining 220 device is not yet IP routable, or it is not yet authenticated to send 221 messages through the network. However, if the neighbour device has 222 the DTLS Relay functionality enabled, it forwards DTLS messages to 223 specific servers. Additional security mechanisms need to exist to 224 prevent this forwarding functionality to be used by rogue nodes to 225 bypass any network authentication procedures and are discussed in 226 Section 5. 228 The DTLS Relay can operate in two different modes: stateful and 229 stateless. We present here both the methods, however for inter- 230 operability, only one of the modes should be mandated. Within each 231 mode, the DTLS Relay can further forward packets based on the client 232 defined DTLS server address or a DTLS server address that has been 233 configured into the Relay. 235 3.1. Relay in Stateful mode 237 The neighbour node on receiving a DTLS message from a joining device 238 enters into DTLS Relay mode. In this mode, the neighbour node has 239 the additional functionality to send DTLS messages further to the 240 end-point DTLS server the joining device wishes to contact. In the 241 stateful mode of operation, the message is transmitted to the end- 242 point as originating from the DTLS Relay by replacing the IP address 243 and port to DTLS Relay's own IP address and a randomly chosen port. 244 The DTLS message itself is not modified. 246 Additionally, the DTLS Relay must track the ongoing DTLS connections 247 based on the following 4-tuple stored locally: 249 o Client source IP address (IP_C) 251 o Client source port (p_C) 253 o DTLS Server IP address (IP_S) 255 o Relay source port (p_R) 257 The DTLS server communicates to the Relay as if it were communicating 258 to the end-point Client with no modification required to the DTLS 259 messages. The Relay on receiving this message, looks up its locally 260 stored 4-tuple array to identify to which joining device (if multiple 261 exists) the message belongs. The DTLS message's destination address 262 is replaced with that of the link-local address and port of the 263 joining device from the lookup array and forwarded to it. The Relay 264 does not modify the DTLS packets and therefore the normal processing 265 and security of DTLS is unaffected. 267 The following message flow diagram indicates the various steps of the 268 process where the DTLS server address in known to the joining device: 270 +---------------+---------------+----------------+---------------------------+ 271 | DTLS Client | DTLS Relay | DTLS Server | Message | 272 | (C) | (R) | (S) | Src_IP:port | Dst_IP:port | 273 +---------------+---------------+----------------+-------------+-------------+ 274 | --ClientHello--> | IP_C:p_C | IP_S:5684 | 275 | --ClientHello--> | IP_R:p_R | IP_S:5684 | 276 | | | | 277 | <--ServerHello-- | IP_S:5684 | IP_R:p_R | 278 | : | | | 279 | <--ServerHello-- | IP_S:5684 | IP_C:p_C | 280 | : | | | 281 | :: | : | : | 282 | :: | : | : | 283 | --Finished--> | IP_C:p_C | IP_S:5684 | 284 | --Finished--> | IP_R:p_R | IP_S:5684 | 285 | | | | 286 | <--Finished-- | IP_S:5684 | IP_R:p_R | 287 | <--Finished-- | IP_S:5684 | IP_C:p_C | 288 | :: | : | : | 289 +------------------------------------------------+-------------+-------------+ 290 IP_C:p_C = IP (non-routable) and port of Client 291 IP_S:5684 = IP and coaps port of Server 292 IP_R:p_R = IP and port of Relay 294 Figure 2: Message flow in Stateful mode with DTLS Server defined by 295 Client 297 In the situation where the joining device is unaware of the IP 298 address of DTLS server it needs to contact, for e.g. the Controller 299 of the network, the DTLS Relay can be configured with IP destination 300 of the default DTLS server that a joining device needs to contact. 301 The joining device initiates its DTLS request as if the DTLS Relay is 302 the intended end-point DTLS server. The DTLS relay translates the 303 DTLS message as in the previous case by modifying both the source and 304 destination IP address to forward the message to the intended DTLS 305 server. The Relay keeps a similar 4-tuple array to enable 306 translation of the DTLS messages received from the server and forward 307 it to the DTLS Client. The following message flow indicates this 308 process: 310 +---------------+---------------+----------------+---------------------------+ 311 | DTLS Client | DTLS Relay | DTLS Server | Message | 312 | (C) | (R) | (S) | Src_IP:port | Dst_IP:port | 313 +---------------+---------------+----------------+-------------+-------------+ 314 | --ClientHello--> | IP_C:p_C | IP_Ra:5684 | 315 | --ClientHello--> | IP_Rb:p_Rb| IP_S:5684 | 316 | | | | 317 | <--ServerHello-- | IP_S:5684 | IP_Rb:p_Rb | 318 | : | | | 319 | <--ServerHello-- | IP_Ra:5684| IP_C:p_C | 320 | : | | | 321 | :: | : | : | 322 | :: | : | : | 323 | --Finished--> | IP_C:p_C | IP_Ra:5684 | 324 | --Finished--> | IP_Rb:p_Rb| IP_S:5684 | 325 | | | | 326 | <--Finished-- | IP_S:5684 | IP_Rb:p_Rb | 327 | <--Finished-- | IP_Ra:5684| IP_C:p_C | 328 | :: | : | : | 329 +------------------------------------------------+-------------+-------------+ 330 IP_C:p_C = IP (non-routable) and port of Client 331 IP_S:5684 = IP and coaps port of Server 332 IP_Ra:5684 = IP and coaps port of Relay 333 IP_Rb:p_Rb = IP (can be same as IP_Ra) and the port of Relay 335 Figure 3: Message flow in Stateful mode with DTLS Server defined by 336 Relay 338 3.2. Relay in Stateless mode 340 In the alternative mode of operation for the DTLS Relay, a stateless 341 approach is applied where th Relay does not need to store a local 342 4-tuple array. Just as in the previous case, if a DTLS client with 343 only link local addressing wants to contact a trusted end-point DTLS 344 server, it send the DTLS message to the Relay. The Relay instead of 345 translating, encapsulates this message into a new type of message 346 called DTLS Relay (DRY) message. The DRY consists of two parts: 348 o Header (H) field: consisting of the source link-local address and 349 port of the DTLS Client device, and 351 o Contents (C) field: containing the original DTLS message. 353 The DTLS end server on receiving the DRY message, decapsulates it to 354 retrieve the two parts. It then uses the Header field information to 355 associate the new state created on the server for the DTLS connection 356 to the DTLS client's address and port. The DTLS server then performs 357 the normal DTLS operations on the DTLS message contents. However 358 when the DTLS server replies, it also encapsulates its message in a 359 DRY message back to the Relay with the Header containing the original 360 source link-local address and port of the DTLS Client. The Relay can 361 decapsulate the DRY message, retrieves the Header information to 362 forward this message to the right DTLS Client device. 364 The following figure depicts the message flow diagram when the DTLS 365 server end-point address is known only to the Relay: 367 +----------------+---------------------+---------------------+---------------------------+ 368 | DTLS Client | DTLS Relay | DTLS Server | Message | 369 | (C) | (R) | (S) | Src_IP:port | Dst_IP:port | 370 +----------------+---------------------+---------------------+-------------+-------------+ 371 | --ClientHello--> | IP_C:p_C | IP_Ra:5684 | 372 | --DRY[H(IP_C:p_C),C(ClientHello)]--> | IP_Rb:p_Rb| IP_S:5684 | 373 | | | | 374 | <--DRY[H(IP_C:p_C),C(ServerHello)]-- | IP_S:5684 | IP_Rb:p_Rb | 375 | : | | | 376 | <--ServerHello-- | IP_Ra:5684| IP_C:p_C | 377 | : | | | 378 | :: | : | : | 379 | :: | : | : | 380 | --Finished--> | IP_C:p_C | IP_Ra:5684 | 381 | --DRY[H(IP_C:p_C),C(Finished)]--> | IP_Rb:p_Rb| IP_S:5684 | 382 | | | | 383 | <--DRY[H(IP_C:p_C),C(Finished)]-- | IP_S:5684 | IP_Rb:p_Rb | 384 | <--Finished-- | IP_Ra:5684| IP_C:p_C | 385 | :: | : | : | 386 +------------------------------------------------------------+-------------+-------------+ 387 IP_C:p_C = IP (non-routable) and port of Client 388 IP_S:5684 = IP and coaps port of Server 389 IP_Ra:5684 = IP and coaps port of Relay 390 IP_Rb:p_Rb = IP (can be same as IP_Ra) and the port of Relay 392 DRY[H(),C()] = DTLS Relay message with header H and content C 394 Figure 4: Message flow in Stateless mode with DTLS Server defined by 395 Relay 397 The message flow for the case in which the DTLS Client is aware of 398 the end-point DTLS server's address is similar and not described 399 further. It can be derived based on Figure 2 and Figure 4. 401 3.3. Comparison between the two modes 403 The stateful and stateless mode of operation for the DTLS Relay have 404 their advantages and disadvantages. This comparison should enable to 405 make a good choice between the two based on the available device 406 resources and network bandwidth in a given deployment. 408 +-------------------+-----------------------------------+--------------------------------+ 409 | Properties | Stateful mode | Stateless mode | 410 +-------------------+-----------------------------------+--------------------------------+ 411 | State information |The Relay needs additional storage | No information is maintained by| 412 | |to maintain mapping of the joining | the Relay. | 413 | |device's address with the port | | 414 | |number being used to communicate | | 415 | |with the Server. | | 416 +-------------------+-----------------------------------+--------------------------------+ 417 | Packet size |The size of the relayed message is |The size of the relayed message| 418 | |the same as the original message . |is bigger than the original, it | 419 | | |includes additional source and | 420 | | |destination addresses. | 421 +-------------------+-----------------------------------+--------------------------------+ 422 | Standardization |The additional functionalities of |New DRY message to encapsulate | 423 | requirements |the Relay to maintain state |DTLS message. The Server and the| 424 | |information, and modify the source |Relay have to understand the DRY| 425 | |and destination addresses of the |message in order to process it. | 426 | |DTLS handshake messages. | | 427 +-------------------+-----------------------------------+--------------------------------+ 429 Table 1: Comparison between stateful and stateless mode DTLS Relay 431 Figure 5 433 4. IANA Considerations 435 tbd 437 Note to RFC Editor: this section may be removed on publication as an 438 RFC. 440 5. Security Considerations 442 Additional security considerations need to be taken into account 443 about forwarding of messages from devices through a network to which 444 it has not yet been admitted. This can lead to denial-of-service 445 attacks or misuse of network resources without proper authentication. 446 One way to overcome any large scale misuse of the network is to have 447 a management message from the Controller that initiates already 448 authenticated devices in the network to enter into a DTLS Relay mode. 449 The devices can stay such a Relay mode for a fixed period of time or 450 until the Controller sends a new management message blocking the DTLS 451 Relay mode in all devices in the network. This is often possible 452 since the administrator of the network can be aware when new devices 453 join the network either because of the "Introduction" phase or 454 commissioning phase. 456 Other mechanisms based on IP destination filtering can be applied by 457 the controller to all Relay nodes to avoid misuse of the network 458 resources. 460 6. Acknowledgements 462 The authors would like to thank Sahil Sharma, Ernest Ma, Dee 463 Denteneer and Peter Lenoir for the valuable discussions and 464 suggestions, 466 7. References 468 7.1. Normative References 470 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 471 Security Version 1.2", RFC 6347, January 2012. 473 7.2. Informative References 475 [I-D.ietf-core-coap] 476 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 477 Application Protocol (CoAP)", draft-ietf-core-coap-18 478 (work in progress), June 2013. 480 [I-D.jennings-core-transitive-trust-enrollment] 481 Jennings, C., "Transitive Trust Enrollment for Constrained 482 Devices", draft-jennings-core-transitive-trust- 483 enrollment-01 (work in progress), October 2012. 485 [I-D.marin-ace-wg-coap-eap] 486 Lopez, R. and R. Sanchez, "EAP-based Authentication 487 Service for CoAP", draft-marin-ace-wg-coap-eap-00 (work in 488 progress), April 2014. 490 [I-D.ohba-core-eap-based-bootstrapping] 491 Das, S. and Y. Ohba, "Provisioning Credentials for CoAP 492 Applications using EAP", draft-ohba-core-eap-based- 493 bootstrapping-01 (work in progress), March 2012. 495 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 496 August 1980. 498 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 499 793, September 1981. 501 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 502 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 503 3748, June 2004. 505 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 506 "Transmission of IPv6 Packets over IEEE 802.15.4 507 Networks", RFC 4944, September 2007. 509 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 510 Yegin, "Protocol for Carrying Authentication for Network 511 Access (PANA)", RFC 5191, May 2008. 513 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 514 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 516 [RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and A. 517 Yegin, "Protocol for Carrying Authentication for Network 518 Access (PANA) Relay Element", RFC 6345, August 2011. 520 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 521 "Neighbor Discovery Optimization for IPv6 over Low-Power 522 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 523 November 2012. 525 [ieee802.15.4] 526 IEEE Computer Society, , "IEEE Std. 802.15.4-2003", 527 October 2003. 529 Authors' Addresses 531 Sandeep S. Kumar 532 Philips Research 533 High Tech Campus 34 534 Eindhoven 5656 AE 535 NL 537 Email: sandeep.kumar@philips.com 538 Sye Loong Keoh 539 University of Glasgow Singapore 540 Republic PolyTechnic, 9 Woodlands Ave 9 541 Singapore 838964 542 SG 544 Email: SyeLoong.Keoh@glasgow.ac.uk 546 Oscar Garcia-Morchon 547 Philips Research 548 High Tech Campus 34 549 Eindhoven 5656 AE 550 NL 552 Email: oscar.garcia@philips.com