idnits 2.17.1 draft-richardson-6tisch--security-6top-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 4, 2014) is 3583 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6550' is defined on line 592, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-6tisch-coap-00 == Outdated reference: A later version (-04) exists of draft-ietf-6tisch-6top-interface-00 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-01 == Outdated reference: A later version (-03) exists of draft-seitz-ace-problem-description-00 == Outdated reference: A later version (-01) exists of draft-richardson-6tisch-idevid-cert-00 == Outdated reference: A later version (-04) exists of draft-wang-6tisch-6top-sublayer-00 == Outdated reference: A later version (-03) exists of draft-thubert-6lowpan-backbone-router-00 == Outdated reference: A later version (-06) exists of draft-kelsey-intarea-mesh-link-establishment-05 == Outdated reference: A later version (-03) exists of draft-piro-6tisch-security-issues-02 Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Richardson 3 Internet-Draft SSW 4 Intended status: Informational July 4, 2014 5 Expires: January 5, 2015 7 6tisch secure join using 6top 8 draft-richardson-6tisch--security-6top-00 10 Abstract 12 This document details a security architecture that permits a new 13 6tisch compliant node to join an 802.15.4e network. The process 14 bootstraps the new node authenticating the node to the network, and 15 the network to the node, and configuring the new node with the 16 required 6tisch schedule. Any resemblance to WirelessHART/IEC62591 17 is entirely intentional. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 23 "OPTIONAL" in this document are to be interpreted as described in RFC 24 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 5, 2015. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology and Roles . . . . . . . . . . . . . . . . . . . . 4 63 3. Architectural requirements of join protocol . . . . . . . . . 4 64 3.1. prefixes to use for join traffic . . . . . . . . . . . . 8 65 4. security requirements . . . . . . . . . . . . . . . . . . . . 8 66 4.1. threat model . . . . . . . . . . . . . . . . . . . . . . 8 67 4.2. implementation cost . . . . . . . . . . . . . . . . . . . 8 68 4.3. denial of service . . . . . . . . . . . . . . . . . . . . 8 69 5. protocol requirements/constraints/assumptions . . . . . . . . 8 70 5.1. inline/offline . . . . . . . . . . . . . . . . . . . . . 8 71 6. time sequence diagram . . . . . . . . . . . . . . . . . . . . 8 72 6.1. explanation of each step . . . . . . . . . . . . . . . . 9 73 6.1.1. step (1): enhanced beacon . . . . . . . . . . . . . . 10 74 6.1.2. step (1B): send router solicitation . . . . . . . . . 10 75 6.1.3. step (1C): receive router advertisement . . . . . . . 10 76 6.1.4. step (2): acquire authorizer key . . . . . . . . . . 10 77 6.1.5. step (3): receive authorizer key . . . . . . . . . . 10 78 6.1.6. step (4): join request . . . . . . . . . . . . . . . 11 79 6.1.7. step (5): NS duplicate address request (DAR) . . . . 11 80 6.1.8. step (7): 6LBR informs JCE of new node . . . . . . . 11 81 6.1.9. step (8): JCE informs/acks to 6LBR of new node . . . 11 82 6.1.10. step (9): NS duplicate address confirmation (DAC) . . 11 83 6.1.11. step (10): JCE initiates connection to joining node . 11 84 6.1.12. step (11): Join Assistant forwards packet to joining 85 node . . . . . . . . . . . . . . . . . . . . . . . . 11 86 6.1.13. step (12): Joining node replies . . . . . . . . . . . 11 87 6.1.14. step (13): Join Assistant forwards reply to JCE . . . 11 88 6.2. size of each packet . . . . . . . . . . . . . . . . . . . 12 89 7. resulting security properties obtained from this process . . 12 90 8. deployment scenarios underlying protocol requirements . . . . 12 91 9. device identification . . . . . . . . . . . . . . . . . . . . 12 92 9.1. PCE/Proxy vs Node identification . . . . . . . . . . . . 12 93 9.2. Time source authentication / time validation . . . . . . 12 94 9.3. description of certificate contents . . . . . . . . . . . 12 95 9.4. privacy aspects . . . . . . . . . . . . . . . . . . . . . 12 97 10. slotframes to be used during join . . . . . . . . . . . . . . 12 98 11. configuration aspects . . . . . . . . . . . . . . . . . . . . 12 99 12. authorization aspects . . . . . . . . . . . . . . . . . . . . 12 100 12.1. how to determine a proxy/PCE from a end node . . . . . . 12 101 12.2. security considerations . . . . . . . . . . . . . . . . 13 102 13. security architecture . . . . . . . . . . . . . . . . . . . . 13 103 14. Posture Maintenance . . . . . . . . . . . . . . . . . . . . . 13 104 15. Security Considerations . . . . . . . . . . . . . . . . . . . 13 105 16. Other Related Protocols . . . . . . . . . . . . . . . . . . . 13 106 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 107 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 108 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 109 19.1. Normative references . . . . . . . . . . . . . . . . . . 13 110 19.2. Informative references . . . . . . . . . . . . . . . . . 14 111 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 113 1. Introduction 115 A challenging part with constructing an LLN with nodes from multiple 116 vendors is providing enough security context to each node such that 117 the network communication can form and remain secure. Most LLNs are 118 small and have no operator interfaces at all, and even if they have 119 debug interfaces (such as JTAG) with personnel trained to use that, 120 doing any kind of interaction involving electrical connections in a 121 dirty environment such as a factory or refinery is hopeless. 123 It is necessary to have a way to introduce new nodes into a 6tisch 124 network that does not involve any direct manipulation of the nodes 125 themselves. This act has been called "zero-touch" provisioning, and 126 it does not occur by chance, but requires coordination between the 127 manufacturer of the node, the service operator running the LLN, and 128 the installers actually taking the devices out of the shipping boxes. 130 1.1. Assumptions 132 For the process described in this document to work, some assumptions 133 about available infrastructure are made. These are perhaps more than 134 assumptions, but rather architectural requirements; the exact 135 operation of said infrastructure to be defined in a subsequent 136 document. 138 In the diagrams and text that follows entities are named (and defined 139 in the terminology section). Unless otherwise stated these are 140 roles, not actual machines/systems. The roles are seperated by 141 network protocols in order that they roles can be performed by 142 different systems, not because they have to be. Different 143 deployments will have different scaling requirements for those 144 entities. Smaller deployments might co-located many roles together 145 into a single ruggedized platform, while other deployments might 146 operate all of the roles on distinct, multiply-redundant server 147 classes located in a fully equipped datacentre. 149 2. Terminology and Roles 151 Most terminology should be taken from [I-D.ietf-6tisch-architecture] 152 and from [I-D.ietf-6tisch-6top-interface] and 153 [I-D.wang-6tisch-6top-sublayer]. As well, many terms are taken from 154 [RFC6775]. 156 The following roles/things are defined: 158 PCE the Path Computation Engine. This entity reaches 159 out to each of the nodes in the LLN, and 160 configures an appropriate schedule using 6top. 162 Authz Server/ACE the Authorization Server. This offloads 163 calculation of access control lists and other 164 access control decisions for constrainted nodes. 165 See [I-D.seitz-ace-problem-description] 167 JCE the Join Coordination Entity. This acronym is 168 chosen to parallel the PCE. 170 802.1AR a certificate created according the specification 171 in [IEEE.802.1AR] 173 joining node The newly unboxed constrained node that needs to 174 join a network. 176 join assistant A constrained node near the joining node that 177 will act as it's first 6LR, and will relay 178 traffic to/from the joining node. 180 join network A 802.15.4e network whose encryption and 181 authentication key is "JOIN6TISCH". 183 production network A 802.15.4e network whose encryption/ 184 authentication keys are determined by some 185 algorithm. There may have network-wide group 186 keys, or per-link keys. 188 3. Architectural requirements of join protocol 190 This section works from the ultimate goal, and goes backwards to 191 prerequisit actions. Section 6 presents the protocol from beginning 192 to end order. 194 The ultimate goal of the join protocol is to provide a new node with 195 enough locally significant security credentials that it is able to 196 take part in the network directly. The credentials may vary by 197 deployment. They can be: 199 1) a network-wide shared symmetric key 201 2) a locally significant (one-level only) 802.11AR type DevID 202 certificate 204 Given one of the the above, there are a number of possible protocols 205 that can be used to generate layer-2 sessions keys for the node, 206 including: 208 1) Mesh Link Exchange [I-D.kelsey-intarea-mesh-link-establishment] 210 2) work in 802.15.9 212 3) Security Framework and Key Management Protocol Requirements for 213 6TiSCH [I-D.ohba-6tisch-security] (this document provides the 214 phase 0 required) 216 4) Layer-2 security aspects for the IEEE 802.15.4e MAC 217 [I-D.piro-6tisch-security-issues] 219 The intermediate goal of the join protocol is to enable a Join 220 Coordination Entity (JCE) to reach out to the new node, and install 221 the credentials detailed above. The JCE must authenticate itself to 222 the joining node so that the joining node will know that it has 223 joined the correct network, and the joining node must authenticate 224 itself to the JCE so that the JCE will know that this node belongs in 225 the network. This two way authentication occurs in the 6top/CoAP/ 226 DTLS session that is established between the JCE and the joining 227 node. 229 [I-D.ietf-6tisch-6top-interface] presents a way to interface to a 230 6top MIB. [I-D.ietf-6tisch-coap] explains how to access that MIB 231 using CoAP. That model is to be extended to include security 232 attributes for the network. The JCE would therefore reach out to the 233 joining node and simply provision appropriate security properties 234 into the joining node, much like the PCE will provision schedules. 236 This 6top-based secure join protocol has defined a push model for 237 security provisioning by the JCE. This has been done for three 238 reasons: 240 1) 6tisch nodes already have to have a 6top CoAP server for schedule 241 provising 243 2) this permits the JCE to manage how many nodes are trying to join 244 at the same time, and limit how much bandwidth/energy is used for 245 the join operation, and also for the JCE to prioritize the join 246 order for nodes. 248 3) making the JCE initiate the DTLS connection significantly 249 simplies the certificate chains that must be exchanged as the 250 most constrained side (the joining node) provides it's 251 credentials first, and lets the much richer JCE figure out what 252 kind of certificate chain will be required to authenticate the 253 JCE. In EAP-TLS/802.1x situations, the TLS channel is created in 254 the opposite direction, and it would have to complete in a 255 tentative way, and then further authorization occur in-band. 257 In order for a 6top/DTLS/CoAP connection to occur between the JCE and 258 the joining node, there needs to be end-to-end IPv6 connectivity 259 between those two entities. The joining node will not participate in 260 the route-over RPL mesh, but rather will be seen by the network as 261 being a 6lowpan only leaf-node. 263 There are some alternatives to having full end to end connectivity 264 which are discussed in the security considerations section. 266 The specific mechanism to enable end to end connectivity with the JCE 267 are still open but will consist of one of: 269 (1) IPIP tunnel between Join Assistant and JCE 271 (2) using straight RPL routing: the Join Assistant sends a DAO 273 (3) using a separate RPL DODAG for join traffic 275 (4) establishing a specific multi-hop 6tisch track for join traffic 276 for each Join Assistant 278 Of these mechanisms, the only one which does not require additional 279 state on the Join Assistant (which is also a constrained device) is 280 (1) and (2). Mechanism (2) additionally requires no specific state 281 on the Join Assistant. Mechanism (2), in a non-storing DODAG 282 requires additional state on the DODAG root (6LBR) only; while 283 mechanism (1) requires a similar amount of state on the JCE. For 284 deployments where the JCE is part of the 6LBR, the amount of state is 285 similar, but in any case, the 6LBR is assumed to be a non-constrained 286 node. 288 As long as the Join Assistant does not do any kind of stateful 289 firewalling, the IPIP tunnel and the DAO (2) method can be done by 290 the Join Assistant statelessly. Upward traffic from the Join Network 291 must be restricted to a 6tisch slotframe(s) to which join traffic is 292 welcome, no tunnelling is necessary as the upwards routes are all in 293 place. A destination address ACL on traffic from the Join Network 294 restricts the Joining Nodes to sending traffic only to the address of 295 the JCE. (If JCE and 6LBR are colocated, then this is the address in 296 the ABRO, if they are not colocated, then this address needs to have 297 been provisioning in the Join Assistant when it joined, or could be 298 carried in a new RA option) 300 When using option (2), networks that have storing mode DODAGs will 301 consume routing resources on all intermediate nodes between the Join 302 Assistant and the DODAG root. This resource will be depleted without 303 any authentication, and this threat is detailed below. 305 Continuing to work backwards, in order the JCE reach out to provision 306 the Joining Node, it needs to know that the new node is present. 307 This is done by taking advantage of the 6lowPAN Address Resolution 308 Option (ARO) (section 4.1 [RFC6775]). The ARO causes the new address 309 to also be sent up to the 6LBR for duplicate detection using the DAR/ 310 DAC mechanism. The 6LBR simply needs to tell the JCE about this 311 using a protocol that needs to be defined, but could be either DAR or 312 NS. 314 In addition to needing to know the joining devices address from the 315 DAR/NS, the JCE also needs to know the joining node' IDevID. If the 316 IDevID is less than 64 bits, then it is possible that it could be 317 placed into the EUI-64 option of the ARO, or the OUI of the 318 [I-D.thubert-6lowpan-backbone-router] EARO. The JCE needs to know 319 the joining node's IDevID to know if this is device that it should 320 even attempt to provision; and if so, it may need to retrieve an 321 appropriate certificate chain (see 322 [I-D.richardson-6tisch-idevid-cert]) from the Factory in order for 323 the JCE to prove it is the legitimate owner of the joining node. 325 Prior to being able to announce itself in a NS, the joining node 326 needs to find the Join Network. This is done by listening to an 327 extended beacon which are broadcast in designated slotframes by Join 328 Assistants. The Extended Beacon provides a way for the Joining Node 329 to synchronize itself to the overall timeslot schedule and provides 330 an Aloha period in which the Joining Node can send a Router 331 Soliticiation, and receive an appropriate Router Advertisement giving 332 the Joining Node a prefix and default route to which to send join 333 traffic. 335 It may be possible to eliminate a message exchange if space for a 336 Router Advertisement can be found as part of the Join Network 337 Extended Beacon. This Enhanced Beacon would be distinct to the Join 338 Network, and would be encrypted with the well-known Join Network key. 340 3.1. prefixes to use for join traffic 342 What prefix would the joining node for communication? There are 343 three options: 345 (1) just use link-local addresses (requires all traffic be tunneled) 347 (2) use a prefix specifically for join traffic (may be easier with a 348 join-only DODAG) 350 (3) use the same prefix as the rest of the traffic (may require more 351 complex ACLs, and leaks information to attackers) 353 4. security requirements 355 4.1. threat model 357 There are three kinds of threats that a join process must deal with: 358 a joining 360 4.2. implementation cost 362 (storage of security material, computational cost) 364 4.3. denial of service 366 other communication impacts of security protocol mechanics 368 5. protocol requirements/constraints/assumptions 370 5.1. inline/offline 372 dependencies on centralized or external functionality, inline and 373 offline 375 6. time sequence diagram 376 +-----+ +------+ +----------+ +-----------+ 377 | | | | | JOIN | | Joining | 378 | JCE | | 6LBR | | Assistant| | Node | 379 +-----+ +------+ | (proxy) | | | 380 | | +----------+ +-----------+ 381 | | | | 382 | | |-------BEACON (1)---------->| 383 | | | | 384 | | |<----Router Solicitation----| 385 | | |---Router Advertisement---->| 386 | | | | 387 | | |<------CERTIFICATE----------| 388 | | | REQUEST (2) | 389 | | | | 390 | | | | 391 | | |-------CERTIFICATE--------->| 392 | | | RESPONSE (multiple) | 393 | | | (packets) | 394 | | | | 395 | | |<-----JOIN REQUEST (4) -----| 396 | | | (NS w/ARO ) | 397 | | | | 398 | |<---NS (DAR) (5)-----| | 399 |<--??(6)-| | | 400 | | | | 401 |--??(7)->| | | 402 | | | | 403 | |----NS (DAC)-(8)---->| | 404 | | +------+ | | 405 | || | 407 | | ACK +------+ | | 408 | | |-------JOIN ACK (9)-------->| 409 | | | | 410 | | | | 411 |================(10)==========>|----------6top----(11)----->| 412 | | | DTLS | 413 |<===============(13)===========|<---------CoAP----(12)------| 414 | | | (many packets) | 416 Figure 1: Message sequence for JOIN message 418 6.1. explanation of each step 419 6.1.1. step (1): enhanced beacon 421 A 6tisch join/synchronization beacon is broadcast periodically, and 422 is authenticated with a symmetric "beacon key": 424 well known JOIN key, such "JOIN6TISCH" 426 another key, provisioned in advance (OOB) 428 a shared symmetric key derived from public part of top level 429 certificate (a closely held "secret") 431 The purpose of this key is not to provide a high level of assurance, 432 but rather to filter out 6tisch traffic from another random traffic 433 that may be sharing the same radio frequencies. 435 These beacons are used for JOIN purpose only, and are not related to 436 the Enhanced Beacons used in the rest of 6tisch. 438 6.1.2. step (1B): send router solicitation 440 The joining node sends a router solicitation during the Aloha period 441 of the beacon. 443 6.1.3. step (1C): receive router advertisement 445 The joining node receives a router advertisement from the Join 446 Assistant. It could include 6CO options to help compress packets, 447 and should contain a prefix appropriate for join traffic. 449 6.1.4. step (2): acquire authorizer key 451 Step (4) will involve doing a public key encryption to node 452 performing the authorization management role. In order to do this, 453 the new node needs to know the public key of the manager, and so in 454 this step it requests that certificate from the neighbour that that 455 it received the beacon from. 457 This step is optional, and it's benefit has not been demonstrated by 458 a real world use case, but has been retained for now 460 6.1.5. step (3): receive authorizer key 462 the proxy neighbour sends the key in one or more messages, along with 463 the address of the authorizing server. The address of the 464 authorization server could be an attribute of the certificate that is 465 received. 467 6.1.6. step (4): join request 469 A regular Neighbour Solicitation is sent. This should contain an ARO 470 (or EARO) option containing the Joining Nodes' IDevID. The ARO/EARO 471 will be proxied by the Join Assistant as part of normal 6LowPAN 472 processing for leaf nodes (non-RPL nodes) upwards to the 6LBR 474 6.1.7. step (5): NS duplicate address request (DAR) 476 6.1.8. step (7): 6LBR informs JCE of new node 478 6.1.9. step (8): JCE informs/acks to 6LBR of new node 480 The JCE could reply in the negative, and this would cause a DAC 481 failure, TBD 483 6.1.10. step (9): NS duplicate address confirmation (DAC) 485 6.1.11. step (10): JCE initiates connection to joining node 487 The double lines indicate that an IPIP tunnel operation may be 488 required. If a straight DAO or seperate Join DODAG is used, then 489 this is just a straight forwarding root to leaf node forwarding 490 operation, and involves either using source routes (non-storing), or 491 just forwarding for storing DODAGs. 493 A specific bandwidth allocation would be used for this join traffic 495 The production network encryption keys would be used for the join 496 traffic 498 6.1.12. step (11): Join Assistant forwards packet to joining node 500 The JOIN Assistant would forward traffic to the Joining Node. 501 Recognizing that this traffic the JOIN Network, the JOIN Assistant 502 would use the JOIN Network key. 504 6.1.13. step (12): Joining node replies 506 The joining node replies, using JOIN Network key. 508 6.1.14. step (13): Join Assistant forwards reply to JCE 510 The JOIN Assistant, recognizing that the traffic came from the JOIN 511 Network, restricts the destination that can be reached to the the JCE 512 only. It can do this in a stateless way, and it does NOT need to 513 track the traffic at (10) to open pinhole, etc. 515 Recognizing that the traffic came from the JOIN Network, the traffic 516 would be placed into a bandwidth allocation (track?) that allows such 517 traffic. 519 6.2. size of each packet 521 and number of frames needed to contain it. 523 7. resulting security properties obtained from this process 525 8. deployment scenarios underlying protocol requirements 527 9. device identification 529 The JCE authenticates the joining node using a certificate chain 530 provided inline during the DTLS negotiation. The certificate chain 531 is rooted in a vendor certificate that the JCE must have preloaded, 532 and is a statement as to the node's 802.1AR IDevID. The joining node 533 authenticates the 535 9.1. PCE/Proxy vs Node identification 537 9.2. Time source authentication / time validation 539 Note: RPL Root authentication is a chartered item 541 9.3. description of certificate contents 543 9.4. privacy aspects 545 10. slotframes to be used during join 547 how is this communicated in the (extended) beacon. 549 11. configuration aspects 551 (allocation of slotframes after join, network statistics, 552 neighboetc.) 554 12. authorization aspects 556 lifecycle (key management, trust management) 558 12.1. how to determine a proxy/PCE from a end node 559 12.2. security considerations 561 what prevents a node from transmitting when it is not their turn 562 (part one: jamming) 564 can a node successfully communicate with a peer at a time when not 565 supposed to, may be tied to link layer security, or will it be 566 policed by receiver? 568 13. security architecture 570 security architecture and fit of e.g. join protocol and provisioning 571 into this 573 14. Posture Maintenance 575 (SACM related work) 577 15. Security Considerations 579 16. Other Related Protocols 581 17. IANA Considerations 583 18. Acknowledgements 585 19. References 587 19.1. Normative references 589 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 590 Requirement Levels", BCP 14, RFC 2119, March 1997. 592 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 593 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 594 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 595 Lossy Networks", RFC 6550, March 2012. 597 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 598 "Neighbor Discovery Optimization for IPv6 over Low-Power 599 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 600 November 2012. 602 [IEEE.802.1AR] 603 Institute of Electrical and Electronics Engineers, "Secure 604 Device Identity", IEEE 802.1AR, 2009, 605 . 607 [I-D.ietf-6tisch-coap] 608 Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and 609 Interaction using CoAP", draft-ietf-6tisch-coap-00 (work 610 in progress), May 2014. 612 [I-D.ietf-6tisch-6top-interface] 613 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 614 Operation Sublayer (6top) Interface", draft-ietf-6tisch- 615 6top-interface-00 (work in progress), March 2014. 617 [I-D.ietf-6tisch-architecture] 618 Thubert, P., Watteyne, T., and R. Assimiti, "An 619 Architecture for IPv6 over the TSCH mode of IEEE 620 802.15.4e", draft-ietf-6tisch-architecture-01 (work in 621 progress), February 2014. 623 [I-D.seitz-ace-problem-description] 624 Seitz, L. and G. Selander, "Problem Description for 625 Authorization in Constrained Environments", draft-seitz- 626 ace-problem-description-00 (work in progress), May 2014. 628 [I-D.richardson-6tisch-idevid-cert] 629 Richardson, M., "X509.v3 certificate extension for 630 authorization of device ownership", draft-richardson- 631 6tisch-idevid-cert-00 (work in progress), May 2014. 633 [I-D.wang-6tisch-6top-sublayer] 634 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 635 Operation Sublayer (6top)", draft-wang-6tisch-6top- 636 sublayer-00 (work in progress), February 2014. 638 19.2. Informative references 640 [I-D.thubert-6lowpan-backbone-router] 641 Thubert, P., "LoWPAN Backbone Router", draft-thubert- 642 6lowpan-backbone-router-00 (work in progress), March 2008. 644 [I-D.kelsey-intarea-mesh-link-establishment] 645 Kelsey, R., "Mesh Link Establishment", draft-kelsey- 646 intarea-mesh-link-establishment-05 (work in progress), 647 February 2013. 649 [I-D.ohba-6tisch-security] 650 Chasko, S., Das, S., Lopez, R., Ohba, Y., Thubert, P., and 651 A. Yegin, "Security Framework and Key Management Protocol 652 Requirements for 6TiSCH", draft-ohba-6tisch-security-01 653 (work in progress), March 2014. 655 [I-D.piro-6tisch-security-issues] 656 Piro, G., Boggia, G., and L. Grieco, "Layer-2 security 657 aspects for the IEEE 802.15.4e MAC", draft-piro-6tisch- 658 security-issues-02 (work in progress), June 2014. 660 Author's Address 662 Michael C. Richardson 663 Sandelman Software Works 664 470 Dawson Avenue 665 Ottawa, ON K1Z 5V7 666 CA 668 Email: mcr+ietf@sandelman.ca 669 URI: http://www.sandelman.ca/