idnits 2.17.1 draft-kelsey-intarea-mesh-link-establishment-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 (March 1, 2012) is 4411 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'CCM' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802154' -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Area WG R. Kelsey 3 Internet-Draft Ember Corporation 4 Intended status: Standards Track March 1, 2012 5 Expires: September 2, 2012 7 Mesh Link Establishment 8 draft-kelsey-intarea-mesh-link-establishment-01 10 Abstract 12 This document defines the mesh link establishment (MLE) protocol for 13 establishing and configuring links in an ad hoc mesh radio network. 14 Effective mesh networking using radio links requires identifying, 15 configuring, and securing usable links to neighboring devices. In an 16 ad hoc mesh network a device's neighbors may come and go as the 17 network's membership and physical environment change. Newly usable 18 links need to be identified and configured automatically, where 19 configuration values can include link-layer addresses, transmit and 20 receive modes, security parameters, and so forth. MLE includes the 21 option of securing the configuration messages themselves, as link- 22 layer security may not be available prior to configuration. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 2, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 6 63 5. Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 5.1. Source Address . . . . . . . . . . . . . . . . . . . . . . 8 65 5.2. Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 5.3. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 5.4. Challenge . . . . . . . . . . . . . . . . . . . . . . . . 9 68 5.5. Response . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 5.6. Replay Counter . . . . . . . . . . . . . . . . . . . . . . 10 70 5.7. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 10 71 5.8. Param . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 6. Message transmission . . . . . . . . . . . . . . . . . . . . . 13 73 7. Processing of incoming messages . . . . . . . . . . . . . . . 14 74 8. Application to 802.15.4 . . . . . . . . . . . . . . . . . . . 15 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 76 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 77 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 78 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 79 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 80 12.2. Informative References . . . . . . . . . . . . . . . . . . 20 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 83 1. Introduction 85 The configuration of individual links in an ad hoc mesh network can 86 fall into a gap between standards. Link layer standards typically 87 deal with individual links and networking standards assume that the 88 links are up and running. In an ad hoc mesh network a device's 89 neighbors may come and go as the network's membership and physical 90 environment change, requiring that new links be configured 91 automatically. The required configuration information can include 92 link layer addressing, transmit and receive modes, wake/sleep cycles, 93 and so on. Security configuration is particularly important, as the 94 link layer may not be able to secure packets until after the link 95 itself has been configured. 97 MLE can be used to configure individual links and to distribute 98 configuration values that are shared across a network. MLE messages 99 are sent using UDP. Per-link configuration uses one-hop messages 100 with link-local addresses. Network-wide configuration uses 101 multicasts and requires some form of multi-hop multicast forwarding. 103 Link parameters can be unicast between two neighboring nodes, as when 104 configuring a particular link, or multicast to all neighbors, in 105 order to advertise to new neighbors or to efficiently transmit 106 updated values. 108 One of the most important properties of a radio link, how well the 109 two neighbors hear each other, often cannot be determined 110 unilaterally by either node. Many radio links are asymmetric, where 111 messages traveling one way across the link are received more or less 112 reliably than messages traveling in the opposite direction. There is 113 a chicken and egg problem here. It is a waste of effort to configure 114 a link that does not have sufficient two-way reliability to be 115 useful, but the two-way reliability cannot be determined without 116 exchanging messages over the link. MLE resolves this by allowing a 117 node to periodically multicast an estimate of the quality of its 118 links. This allows a node to determine if it has a usable radio link 119 to a neighbor without first configuring that link. 121 1.1. Requirements Language 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 2. Terminology 129 ETX Expected Transmission Count; the number of 130 transmission attempts required to send a packet 131 over a particular link. Defined to be the 132 product of the IDR values for both directions. A 133 perfect link has an ETX of 1, less than perfect 134 links have higher ETX values. 136 Frame counter A value that is incremented with each new secured 137 message. Used with [CCM] to ensure that no two 138 messages are secured using the same key and nonce 139 pair. In 802.15.4 the same counter is used as 140 both a frame counter and a replay counter. 142 Global configuration Configuration values and messages that apply 143 across a network. Global configuration message 144 are multicast messages forwarded across multiple 145 hops. 147 IDR Inverse Delivery Ration; the number of 148 transmission attempts divided by the number of 149 successful transmissions in a given direction 150 over a link. 152 Local configuration Configuration values and messages that apply only 153 to a single hop. Local configuration message are 154 sent using link-local messages and are not 155 forwarded. 157 Replay counter A message value that is incremented with each new 158 transmission. Incoming messages whose counter 159 value is the same or lower as that in an earlier 160 message are discarded. 162 3. Overview 164 MLE is a means of transmitting link configuration values. An MLE 165 message is one of: 167 Link configuration A one-hop unicast sent as part of establishing a 168 link with one particular neighbor. 170 Advertisement A one-hop multicast that advertise a node's link 171 quality estimates to its neighbors. 173 Update A network-wide multicast that updates a shared 174 configuration value. 176 If negotiation is required, establishment of a link may require an 177 exchange of two or more unicast messages. The only multiple-message 178 exchange in the MLE protocol performs liveness determination (replay 179 counter initialization). 181 4. Message Formats 183 MLE messages consist of a command and a series of type-length-value 184 parameters. Unicast and advertisement messages, but not updates, can 185 be secured using Advanced Encryption Standard 128 [AES] in Counter 186 with CBC-MAC Mode [CCM] for data authentication and encryption. 187 Updates are only sent over already-configured links and are assumed 188 to be secured using normal link-layer security 190 The security data is formatted as an auxiliary security header as 191 specified in [IEEE802154]. There are two exceptions to this: a 192 security header with security level of 0 does not contain a frame 193 counter, and when frame counters are included they are in big-endian 194 form. This first exception avoids the need to include a frame 195 counter when security is being provided by the link layer. The 196 second is to conform with normal IETF practice. Otherwise, the 197 presence and length of the frame counter, key identifier, and MIC 198 follow [IEEE802154]. 200 If MLE security is in use each device MUST maintain an outgoing 201 frame/replay counter for use in securing outgoing packets in 202 compliance with [CCM]. MLE does not include a method for configuring 203 its own frame counters and so does not provide complete protection 204 against replayed MLE packets. 206 MLE security MUST NOT use any key that is being used by the link (or 207 any other) layer MLE security MAY use a key derived using a 208 cryptographic hash from a key being used at the link layer. Other 209 than the above requirements, the distribution or derivation of the 210 key(s) used for MLE security is outside the scope of this document. 212 := 213 214 * 215 ? 217 := 218 ? 219 ? 221 The defined command IDs are: 223 0 Link Request. A request to establish a link to a neighbor. 225 1 Link Accept. Accept a requested link. 227 2 Link Accept and Request. Accept a requested link and request 228 initialization in the other direction. 230 3 Link Reject. Reject a link request. 232 4 Advertisement. Inform neighbors of a device's link state. 234 4 Update. Informs of changes to link parameters shared by all 235 nodes in a network. 237 (values to be confirmed by IANA) 239 5. Values 241 Values are encoded using a type-length-value format, where the type 242 and length are one byte each and the length field contains the length 243 of the value in bytes. There are no alignment requirements and no 244 padding. 246 0 1 2 3 247 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 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Type | Length | Value ... 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 5.1. Source Address 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Type = 0 | Length | Source Address ... 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 Length Length of the Address field in octets. 262 Source Address A link-layer address assigned to the source of 263 the message. 265 A given radio interface may have multiple link-layer addresses. This 266 TLV is used to communicate any source address(es) that is not 267 included in the message by the link layer itself. 269 5.2. Mode 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Type = 1 | Length | Mode ... 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Length Length of the Mode field in octets. 279 Mode Mode configuration of this link. The possible 280 values are specific to the link layer in use. 282 Mode information can include such things as the senders listening 283 schedule, whether it will poll for messages, and so forth. 285 5.3. Timeout 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Type = 2 | Length | Timeout 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 Length 4 297 Timeout The expected maximum interval between 298 transmissions by the sender in seconds. 300 This allows the receiver to more accurately timeout a link to a 301 neighbor that polls for its incoming messages. 303 5.4. Challenge 305 0 1 2 3 306 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 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Type = 3 | Length | Challenge ... 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Length Length of the Challenge field in octets. 313 Challenge A random value used to determine the freshness of 314 any reply to this message. 316 An important part of replay protection is determining if a newly- 317 heard neighbor is actually present or is a set of recorded messages. 318 This is done by sending a random challenge value to the neighbor and 319 then receiving that same value in a Response TLV sent by the 320 neighbor. 322 5.5. Response 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Type = 4 | Length | Response ... 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 Length Length of the Response field in octets. 332 Response The challenge value echoed back to the original 333 sender (in network order). 335 5.6. Replay Counter 337 0 1 2 3 338 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 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Type = 5 | Length | Replay Counter ... 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 Length Length of the Replay Counter field in octets. 345 Response The sender's current outgoing link-layer Replay 346 Counter. 348 5.7. Link Quality 350 0 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Type = 6 | Length |C| Res | Size | Neighbor Data ... 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 Length Length of following values in octets (1 + (size + 357 3) * number-of-neighbors). 359 C Complete: 1 if the message includes all 360 neighboring routers for which the source has link 361 quality data. Multicast Link Quality TLVs 362 normally contain complete information; a unicast 363 to a particular neighbor would normally contain 364 only that neighbor's link quality and would not 365 have the C flag set. 367 Res Reserved. 369 Size The size in octets of the included neighbor 370 addresses, minus 1. This supports addresses of 371 lengths 1 to 16. 373 Neighbor Data A sequence of neighbor records, each containing 374 an "established" flag, the estimated incoming 375 link reliability (IDR), and the neighbor's link- 376 layer address. 378 0 1 2 3 379 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 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 |I|O| reserved | Incoming IDR | Neighbor Address ... 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 I(ncoming) Set if the sender has configured its link with 385 this neighbor and will accept incoming messages 386 from them. 388 O(utgoing) Set if the sender believes that the neighbor has 389 configured its link with the sender and will 390 accept incoming messages from the sender. This 391 flag is set if the sender has sent a Link Accept 392 message to the neighbor and cleared if the sender 393 has subsequently received a Link Quality TLV from 394 the neighbor with the sender's I flag cleared. 396 Incoming IDR The estimated inverse delivery ratio of messages 397 sent by the neighbor to the source of this 398 message. To allow for fractional IDR, the value 399 encoded is multiplied by 32. A perfect link, 400 with an actual IDR of 1, would have an Incoming 401 IDR of 0x20. A value of 0xFF indicates that the 402 link is unusable. 404 Address A link-layer address of a neighbor. 406 The I and O flags are used to facilitate the two-way use of links 407 between neighboring routers. They are advisory only; a node may send 408 a message to a neighbor regardless of the state of the most recently 409 seen corresponding I bit from that neighbor. Similarly, a node may 410 unilaterally discard a configured link without informing the neighbor 411 of its intention. 413 A node that does not have a link configured to a neighbor but 414 receives a Link Quality TLV from that neighbor with the node's O flag 415 set SHOULD send an MLE message with a Link Quality TLV with that 416 neighbor's I bit cleared. This message may either be a regular 417 multicast Advertisement or a unicast to that neighbor containing only 418 a single Neighbor Data record. 420 5.8. Param 422 0 1 2 3 423 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 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Type = 7 | Length | Parameter ID | Delay 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Value ... 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 Length Length of the Value field in octets plus 5. 432 Parameter ID The ID of the parameter to be changed. 434 Delay The delay before setting the parameter, in 435 milliseconds. This gives time for the Update 436 message carrying the Param TLV to propagate 437 throughout the network. 439 Value The new value of the parameter. 441 Update messages SHOULD contain only Param TLVs. 443 The defined Parameter IDs are: 445 0 Channel 447 1 PAN ID 449 2 Permit Joining 451 (values to be confirmed by IANA) 453 6. Message transmission 455 Messages SHOULD be sent using UDP port XXXX (value to be assigned by 456 IANA). Update messages SHOULD be sent to the site-local all-routers 457 multicast address (FF05::2). Link configuration and advertisement 458 messages MUST be sent with an IP Hop Limit of 255. 460 Outgoing link configuration and advertisements messages SHOULD be 461 secured using the procedure specified in [AES] and [CCM] using the 462 auxiliary security header as described in [IEEE802154]. Key choice 463 is outside the scope of this document. The authenticated data 464 consists of the following three values concatenated together: 466 IP source address 467 IP destination address 468 auxiliary security header 470 The secured data consists of the messages body following the 471 auxiliary security header (the command ID and TLVs). 473 A message sent in response to a multicast request, such as a 474 multicast Link Request, MUST be delayed by a random time between 0 475 and MAX_RESPONSE_DELAY_TIME seconds. 477 MAX_RESPONSE_DELAY_TIME 1 second 479 If no response is received to a request, the request MAY be 480 retransmitted. Because MLE messages do not require complex 481 processing and are not relayed, a simple timeout scheme is used for 482 retransmitting. This is based on the retransmission mechanism used 483 in DHCPv6 RFC 3315 [RFC3315], simplified to use a single, fixed 484 timeout. 486 Parameter Default Description 487 ------------------------------------------------------- 488 URT 1 sec Unicast Retransmission timeout. 489 MRT 5 sec Multicast Retransmission timeout. 490 MRC 3 Maximum retransmission count. 492 For each transmission the appropriate URT or MRT value is multiplied 493 by a random number chosen with a uniform distribution between 0.9 and 494 1.1. The randomization factor is included to minimize 495 synchronization of messages transmitted. 497 7. Processing of incoming messages 499 Any incoming link configuration or advertisement message whose IP Hop 500 Limit is not 255 may have been forwarded by a router and MUST be 501 discarded. 503 Incoming update messages that contain TLVs other than Param TLVs 504 SHOULD be ignored. 506 Unsecured incoming link configuration and advertisement messages 507 SHOULD be ignored. Secured incoming messages are decrypted and 508 authenticated using the procedures specified in [AES] and [CCM], with 509 security material obtained from the auxiliary security header as 510 described in [IEEE802154]. The key source may be obtained either 511 from the link layer source address or from the auxiliary security 512 header. 514 A device SHOULD maintain a separate incoming frame/replay counter for 515 each neighbor. Any message received with a frame/replay counter the 516 same or lower than that of a previously received and authenticated 517 message from the same source MUST be discarded. Messages for which 518 no previous frame/replay counter are available are not discarded and 519 the counter value SHOULD be saved for comparison with later messages. 521 8. Application to 802.15.4 523 This section describes how MLE could be used in an 802.15.4-based 524 LoWPAN. This section is not normative. The values that may need to 525 be communicated to configure an 802.15.4 include: 527 o Long (64-bit) and short (16-bit) addresses. 529 o Capability data byte, especially the Device Type and Receiver On 530 When Idle fields. 532 o Initialization of AES-CCM frame counters (which are also used as 533 replay counters). 535 A device wishing to establish a link to a neighbor would send a Link 536 Request message containing the following: 538 o Source Address TLV, containing the sender's short (16-bit) MAC 539 address. It is assumed that the sender's long (64-bit) MAC 540 address is used as the MAC source address of the message. 542 o Mode TLV, containing the sender's Capability data byte. 544 o Timeout TLV, if the sender is an rxOffWhenIdle device. 546 o Challenge TLV, whose size is determined by the network 547 configuration. 549 If the neighbor has sufficient resources to maintain an additional 550 link, it would respond with a Link Accept message containing the same 551 TLVs (with its own values), but with a Response TLV in place of the 552 Challenge TLV and with an added Replay Counter TLV. If the neighbor 553 also required a liveness check, it would include its own challenge, 554 and use the Link Accept And Request message type. 556 If a node receives a secured 802.15.4 unicast from a neighbor for 557 whom it does not have link configuration data, the receiving node 558 should respond with a Link Reject message to inform the neighbor that 559 the link is not configured. 561 Nodes could also send out periodic advertisements containing the 562 incoming and outgoing ETX values for their neighbors. These would be 563 used to choose likely candidates for link establishment and to 564 determine if existing links continued to provide sufficient two-way 565 reliability. 567 Because link configuration and advertisement messages are used to 568 establish 802.15.4 security they should not be secured at the 569 802.15.4 layer. 571 Update messages may be sent to change the channel, PAN ID, and/or 572 permit joining flags on all nodes. The permit joining flag normally 573 defaults to false; to avoid permanently enabling joining, the value 574 of permit joining parameter should be the number of seconds for which 575 the permit joining flag should be turned on, and not just true or 576 false. 578 9. Acknowledgements 580 TODO. 582 10. IANA Considerations 584 TODO: UDP port and registries for the command, TLV, and Parameter ID 585 identifiers. 587 11. Security Considerations 589 IN PROGRESS 591 Some MLE messages are necessarily sent unsecured. Implementations 592 must take care to use information data from unsecured messages 593 appropriately. In particular, information from unsecured messages 594 should not be used to modify any stored information obtained from 595 secured messages. 597 12. References 599 12.1. Normative References 601 [AES] National Institute of Standards and Technology, 602 "Specification for the Advanced Encryption Standard 603 (AES)", FIPS 197, November 2001. 605 [CCM] National Institute of Standards and Technology, 606 "Recommendation for Block Cipher Modes of Operation: The 607 CCM Mode for Authentication and Confidentiality", SP 800- 608 38C, May 2004. 610 [IEEE802154] 611 Institute of Electrical and Electronics Engineers, 612 "Wireless Personal Area Networks", IEEE Standard 802.15.4- 613 2006, 2006. 615 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 616 Requirement Levels", BCP 14, RFC 2119, March 1997. 618 12.2. Informative References 620 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 621 and M. Carney, "Dynamic Host Configuration Protocol for 622 IPv6 (DHCPv6)", RFC 3315, July 2003. 624 Author's Address 626 Richard Kelsey 627 Ember Corporation 628 25 Thomson Place 629 Boston, Massachusetts 02210 630 USA 632 Phone: +1 617 951 1225 633 Email: richard.kelsey@ember.com