idnits 2.17.1 draft-kelsey-intarea-mesh-link-establishment-05.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 (February 21, 2013) is 4075 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 Silicon Labs 4 Intended status: Standards Track February 21, 2013 5 Expires: August 25, 2013 7 Mesh Link Establishment 8 draft-kelsey-intarea-mesh-link-establishment-05 10 Abstract 12 This document defines the mesh link establishment (MLE) protocol for 13 establishing and configuring secure radio links in IEEE 802.15.4 14 radio mesh networks. MLE extends IEEE 802.15.4 for use in multihop 15 mesh networks by adding three capabilities: 1) dynamically 16 configuring and securing radio links, 2) enabling network-wide 17 changes to radio parameters, and 3) detecting neighboring devices. 18 MLE operates below the routing layer, insulating it from the details 19 of configuring, securing, and maintaining individual radio links 20 within a larger mesh network. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 25, 2013. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4.1. Link Configuration . . . . . . . . . . . . . . . . . . . . 6 62 4.2. Parameter Dissemination . . . . . . . . . . . . . . . . . 6 63 4.3. Neighbor Detection . . . . . . . . . . . . . . . . . . . . 7 64 5. Security Formats . . . . . . . . . . . . . . . . . . . . . . . 8 65 6. Command Format . . . . . . . . . . . . . . . . . . . . . . . . 9 66 7. TLV Formats . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 7.1. Source Address . . . . . . . . . . . . . . . . . . . . . . 10 68 7.2. Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 7.3. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 7.4. Challenge . . . . . . . . . . . . . . . . . . . . . . . . 11 71 7.5. Response . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 7.6. Link-layer Frame Counter . . . . . . . . . . . . . . . . . 11 73 7.7. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 11 74 7.8. Network Parameter . . . . . . . . . . . . . . . . . . . . 13 75 7.9. MLE Frame Counter . . . . . . . . . . . . . . . . . . . . 14 76 8. Message transmission . . . . . . . . . . . . . . . . . . . . . 15 77 9. Processing of incoming messages . . . . . . . . . . . . . . . 17 78 10. Link Configuration . . . . . . . . . . . . . . . . . . . . . . 18 79 11. Parameter Dissemination . . . . . . . . . . . . . . . . . . . 19 80 12. Neighbor Detection . . . . . . . . . . . . . . . . . . . . . . 20 81 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 82 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 83 14.1. Security Suites . . . . . . . . . . . . . . . . . . . . . 22 84 14.2. Command Types . . . . . . . . . . . . . . . . . . . . . . 22 85 14.3. TLV Types . . . . . . . . . . . . . . . . . . . . . . . . 22 86 14.4. Network Parameters . . . . . . . . . . . . . . . . . . . . 23 87 15. Security Considerations . . . . . . . . . . . . . . . . . . . 24 88 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 89 16.1. Normative References . . . . . . . . . . . . . . . . . . . 25 90 16.2. Informative References . . . . . . . . . . . . . . . . . . 25 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 93 1. Introduction 95 The configuration of individual links in IEEE 802.15.4 mesh networks 96 falls into a gap between standards. The IEEE 802.15.4 standard 97 provides for static point-to-point and star topologies while the 98 routing (L3) protocols used in multi-hop mesh networks assume that 99 the L2 links are already up and running. Effective mesh networking 100 using IEEE 802.15.4 requires identifying, configuring, and securing 101 usable links to neighboring devices as the network's membership and 102 physical environment change. Newly usable links need to be 103 identified and configured automatically, where configuration values 104 can include link-layer addresses, transmit and receive modes, 105 security parameters, and so forth. 107 Security configuration is particularly important, as IEEE 802.15.4's 108 replay protection applies only between a joining device and the IEEE 109 802.15.4 coordinator via which it joins the network. Replay 110 protection with other neighbors requires a synchronization step that 111 is not specified by IEEE 802.15.4. 113 MLE can also be used to distribute configuration values that are 114 shared across a network, such as the channel and PAN ID. Network- 115 wide configuration uses multicasts and requires some form of multi- 116 hop multicast forwarding. These messages are sent infrequently, so 117 forwarding with simple flooding is sufficient. 119 One of the most important properties of a radio link, how reliably 120 the two neighbors can communicate, often cannot be determined 121 unilaterally by either neighbor. Many 802.15.4 links are asymmetric, 122 where messages traveling one way across the link are received more or 123 less reliably than messages traveling in the opposite direction. 124 There is a chicken and egg problem here. It is a waste of effort to 125 configure a link that does not have sufficient two-way reliability to 126 be useful, but the two-way reliability cannot be determined without 127 exchanging messages over the link. MLE resolves this by allowing a 128 node to periodically multicast an estimate of the quality of its 129 links. This allows a node to determine if it has a usable radio link 130 to a neighbor without first configuring that link. 132 1.1. Requirements Language 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in 137 [RFC2119]. 139 2. Terminology 141 ETX Expected Transmission Count [RFC6551]; the number 142 of transmission attempts required to send a 143 packet over a particular link. Defined to be the 144 product of the IDR values for both directions. A 145 perfect link has an ETX of 1, less than perfect 146 links have higher ETX values. 148 Frame counter A value that is incremented with each new secured 149 message and used to detect replayed messages. 151 IDR Inverse Delivery Ratio; the number of 152 transmission attempts divided by the number of 153 successful transmissions in a given direction 154 over a link. Used in computing the ETX value for 155 a link. 157 3. Applicability 159 This protocol extends IEEE 802.15.4 with additional capabilities 160 needed for multi-hop mesh networks. The protocol is designed to be 161 easily extended to add additional features or to be adapted for use 162 with other radio standards. 164 4. Overview 166 MLE adds three capabilities to IEEE 802.15.4: 168 o Dynamically configuring and securing radio links. 170 o Enabling network-wide changes to radio parameters. 172 o Detecting neighboring devices. 174 The first two are mutually independent; either one can be used 175 without the other. The purpose of the third, detecting neighboring 176 devices, is to make link management more efficient by detecting 177 unreliable links before any effort is spent configuring them. 179 All MLE messages are sent using UDP. While UDP is not an obvious 180 choice for a protocol used for L2 configuration, it was chosen to 181 simplify integration of MLE into existing systems. 183 4.1. Link Configuration 185 Link configuration is done using link-local unicasts to exchange IEEE 186 802.15.4 radio parameters (addresses, node capabilities, frame 187 counters) between neighbors. Link configuration messages are either 188 a request that the link be configured, or an acceptance or rejection 189 of such a request. 191 IEEE 802.15.4 security uses frame counters to detect replayed 192 messages. MLE uses a two-message challenge and response protocol to 193 ensure that the MLE message containing a neighbor's frame counter is 194 not itself a replayed message. 196 4.2. Parameter Dissemination 198 Network-wide changes to radio parameters, such as moving the network 199 to a new channel, is done by multicasting the new value(s) to all 200 devices in the network. Along with the values themselves, the 201 multicast messages include a delay value indicating when the new 202 value takes effect. The delay avoids having the parameters change 203 while the multicast is still propagating. 205 In addition to network wide dissemination, a device that does not 206 have the current network values, either because it has just joined 207 the network or for any other reason, can send a unicast request to a 208 neighbor. The neighbor will respond by sending the current network 209 values. 211 4.3. Neighbor Detection 213 802.15.4 links can be asymmetric in that a link between neighboring 214 devices may be much more reliable in one direction than in the other. 215 This limits the usefulness of unilateral link quality detection: a 216 link that looks strong to one device may not be usable because it 217 works poorly in the other direction. To avoid wasting effort 218 configuring unusable links, devices can use MLE to send link-local 219 multicasts containing their local link quality estimates. 220 Neighboring nodes can then form an estimate of the two-way quality of 221 their link to the sender. 223 5. Security Formats 225 One of the main functions of MLE is to initialize link-layer 226 security. This means that MLE itself cannot rely on link-layer 227 security. To avoid the cost and complexity of adding a second 228 security suite, MLE reuses that of 802.15.4. This document describes 229 two security suites, one with no security and the other using 230 Advanced Encryption Standard 128 [AES] in Counter with CBC-MAC Mode 231 [CCM] as described in [IEEE802154]. Later extensions may include 232 other security suites for use with other radio standards. 234 An MLE message begins with single byte indicating the security suite 235 used in that message. If that initial byte is "255" no security is 236 used and the messages has no additional security data. An initial 237 byte of "0" indicates that the message is secured as described in 238 [IEEE802154] (all codes are to be confirmed by IANA; see Section 14). 239 MLE messages thus have one of the two following formats: 241 +-----+------------+---------+-----+ 242 | 0 | Aux Header | Command | MIC | 243 +-----+------------+---------+-----+ 244 +-----+---------+ 245 | 255 | Command | 246 +-----+---------+ 248 Aux Header Auxiliary Security Header as described in [IEEE802154]. 250 Command MLE command; see Section 6. 252 MIC Message Integrity Code as described in [IEEE802154]. 254 If MLE security is in use each device MUST maintain an outgoing MLE 255 frame counter for use in securing outgoing packets in compliance with 256 [CCM]. This MAY be the same frame counter used for securing 802.15.4 257 frames; in this case the same counter value MUST NOT be used for 258 securing both an 802.15.4 message and an MLE message. 260 MLE security MUST NOT use any key that is being used by the link (or 261 any other) layer. Other than the above requirements, the 262 distribution or derivation of the key(s) used for MLE security is 263 outside the scope of this document. 265 6. Command Format 267 MLE messages consist of a command type and a series of type-length- 268 value parameters. 270 +--------------+-----+-----+-----+ 271 | Command Type | TLV | ... | TLV | 272 +--------------+-----+-----+-----+ 274 Command Type An eight-bit unsigned integer identifying the type of 275 message. This document defines the following commands 276 (all codes are to be confirmed by IANA, see Section 14): 278 0 Link Request. A request to establish a link to a 279 neighbor. 281 1 Link Accept. Accept a requested link. 283 2 Link Accept and Request. Accept a requested link 284 and request a link with the sender of the original 285 request. 287 3 Link Reject. Reject a link request. 289 4 Advertisement. Inform neighbors of a device's link 290 state. 292 5 Update. Informs of changes to link parameters 293 shared by all nodes in a network. 295 6 Update Request. Request that an Update message be 296 sent. 298 The first four (Link Request, Link Accept, Link Accept 299 and Request, and Link Reject) are collectively referred 300 to as link configuration messages. 302 TLVs Zero or more TLV frames. These are described in 303 Section 7. 305 7. TLV Formats 307 Values are encoded using a type-length-value format, where the type 308 and length are one byte each and the length field contains the length 309 of the value in bytes. There are no alignment requirements and no 310 padding. 312 0 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Type | Length | Value ... 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 Type An eight-bit unsigned integer giving the type of 319 the value, from IANA registry Section 14.3. 321 Length An eight-bit unsigned integer giving the length 322 of the Value field in bytes. 324 Value Length bytes of value, formatted as defined for 325 the Type. 327 With the exceptions of the Source Address TLV and Parameter TLV, an 328 MLE message MUST NOT contain two or more TLVs of the same type. To 329 allow devices to have multiple source addresses, an MLE message MAY 330 contain two or more Source Address TLVs. 332 7.1. Source Address 334 The Source Address TLV (TLV Type 0) has a Value containing a byte 335 string representing a link-layer address assigned to the source of 336 the message. A given radio interface may have multiple link-layer 337 addresses. This TLV is used to communicate any source address(es) 338 that is not included in the message by the link layer itself. 340 7.2. Mode 342 The Mode TLV (TLV Type 1) has a Value containing a byte string 343 representing the mode in which this link is used by the source of the 344 message. The format of the value is that of the Capability 345 Information field in the 802.15.4 Associate command as described in 346 [IEEE802154]. 348 7.3. Timeout 350 The Timeout TLV (TLV Type 2) has a Value containing a 32-bit unsigned 351 integer, most significant byte first. The value is the expected 352 maximum interval between transmissions by the sender, in seconds. 353 This allows the receiver to more accurately timeout a link to a 354 neighbor that polls for its incoming messages. 356 7.4. Challenge 358 The Challenge TLV (TLV Type 3) has a Value containing a randomly- 359 chosen byte string that is used to determine the freshness of any 360 reply to this message. The recommendations in [RFC4086] apply with 361 regard to generation of the challenge value. A new value MUST be 362 chosen for each Challenge TLV transmitted. An important part of 363 replay protection is determining if a newly-heard neighbor is 364 actually present or is a set of recorded messages. This is done by 365 sending a random challenge value to the neighbor and then receiving 366 that same value in a Response TLV sent by the neighbor. 368 7.5. Response 370 The Response TLV (TLV Type 4) has a Value containing a byte string 371 copied from a Challenge TLV. 373 7.6. Link-layer Frame Counter 375 The Link-layer Frame Counter TLV (TLV Type 5) has a Value containing 376 the sender's current outgoing link-layer Frame Counter, encoded as an 377 N-bit unsigned integer, most significant byte first. For 802.15.4 378 this is a 32-bit value. 380 7.7. Link Quality 382 The Link Quality TLV (TLV Type 6) reports the sender's measured link 383 quality for messages received from its neighbors. The format of the 384 Link Quality value is as follows: 386 0 1 2 387 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 |C| Res | Size | Neighbor Data ... 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 C Complete: "1" if the message includes all 393 neighboring routers for which the source has link 394 quality data. Multicast Link Quality TLVs 395 normally contain complete information; a unicast 396 to a particular neighbor would normally contain 397 only that neighbor's link quality and would have 398 the C flag set to "0". 400 Res Reserved; MUST be set to 000 and SHOULD be 401 ignored on receipt. 403 Size The size in bytes of the included neighbor link- 404 layer addresses, minus 1. This supports 405 addresses of lengths 1 to 16 bytes. 407 Neighbor Data A sequence of neighbor records, each containing 408 receive and transmit state flags, the estimated 409 incoming link reliability (IDR), and the 410 neighbor's link-layer address. 412 The neighbor data in a Link Quality TLV is formatted as follows: 414 0 1 2 3 415 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 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 |I|O|P|reserved | Incoming IDR | Neighbor Address ... 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 I(ncoming) "1" if the sender's Receive State for this 421 neighbor is true, "0" if not. 423 O(utgoing) "1" if the sender's Transmit State for this 424 neighbor is true, "0" if not. 426 P(riority) "1" if the sender expects to use this link for 427 sending messages, "0" if not. Given limited 428 resources, the P flag MAY be used in deciding 429 which links should be maintained. 431 Incoming IDR The estimated inverse delivery ratio of messages 432 sent by the neighbor to the source of this 433 message. This is an eight-bit unsigned integer. 434 To allow for fractional IDR, the value encoded is 435 multiplied by 32. A perfect link, with an actual 436 IDR of 1, would have an Incoming IDR of 0x20. A 437 value of 0xFF indicates that the link is 438 unusable. 440 Address A link-layer address of a neighbor. 442 The I and O flags are used to facilitate the two-way use of links 443 between neighboring routers. 445 A node that does not have a link configured to a neighbor but 446 receives a Link Quality TLV from that neighbor with the node's O flag 447 set to "1" SHOULD send an MLE message with a Link Quality TLV with 448 that neighbor's I bit set to "0". This message may either be a 449 regular multicast Advertisement or a unicast to that neighbor 450 containing only a single Neighbor Data record. 452 7.8. Network Parameter 454 The Parameter TLV (TLV Type 7) specifies the value of a link-layer 455 parameter shared across the network (as opposed to a parameter 456 specific to a particular link). The Value contains three fields: 458 0 1 2 3 459 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 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Parameter ID | Delay 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Value ... 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 Parameter ID The ID of the parameter to be changed. 468 Delay The delay before setting the parameter, in 469 milliseconds. This is a four-byte unsigned 470 integer, most significant byte first. Having a 471 delay gives time for the new value to propagate 472 throughout the network. It may also be used for 473 limiting the time a particular parameter setting 474 is in use, by including two different values for 475 a single parameter, with two different delays. 477 Value A byte string containing the new value of the 478 parameter. The format of this value is 479 determined by the particular parameter 481 Update messages SHOULD contain only Network Parameter TLVs. Update 482 messages with new parameter settings SHOULD be multicast to the 483 entire MLE domain. They MAY also be unicast to nodes that have just 484 joined the network or otherwise do not have up-to-data parameter 485 information. 487 The defined Network Parameters are: 489 0 Channel 490 1 PAN ID 492 2 Permit Joining 494 3 Beacon Payload 496 (values to be confirmed by IANA) 498 7.9. MLE Frame Counter 500 The MLE Frame Counter TLV (TLV Type 8) has a Value containing the 501 sender's current outgoing MLE Frame Counter, encoded as an 32-bit 502 unsigned integer, most significant byte first. 504 8. Message transmission 506 MLE messages SHOULD be sent using the assigned UDP port number 507 (19788) as both the source and destination port. Link configuration 508 and advertisement messages MUST be sent with an IP Hop Limit of 255, 509 either to a link-local unicast address or to the link-local all-nodes 510 (FF02::1) or all-routers (FF02::2) multicast addresses. Update 511 messages MAY be sent as above, or MAY be sent to a site-local all- 512 MLE-nodes multicast address (to be assigned by IANA). 514 Outgoing link configuration and advertisement messages SHOULD be 515 secured using the procedure specified in [AES] and [CCM] using the 516 auxiliary security header as described in [IEEE802154]. Key choice 517 is outside the scope of this document. The authenticated data 518 consists of the following three values concatenated together: 520 IP source address 521 IP destination address 522 auxiliary security header 524 The secured data consists of the messages body following the 525 auxiliary security header (the command ID and TLVs). The security 526 suite identifier is not included in either the authenticated data or 527 the secured data. 529 In order to allow update messages to be forwarded multiple hops, 530 outgoing update messages, SHOULD be secured at the link layer and 531 SHOULD NOT be secured by MLE. 533 A message sent in response to a multicast request, such as a 534 multicast Link Request, MUST be delayed by a random time between 0 535 and MAX_RESPONSE_DELAY_TIME seconds. 537 MAX_RESPONSE_DELAY_TIME 1 second 539 If no response is received to a request, the request MAY be 540 retransmitted. Because MLE messages do not require complex 541 processing and are not relayed, a simple timeout scheme is used for 542 retransmitting. This is based on the retransmission mechanism used 543 in DHCPv6 RFC 3315 [RFC3315], simplified to use a single, fixed 544 timeout. 546 Parameter Default Description 547 ------------------------------------------------------- 548 URT 1 sec Unicast Retransmission timeout. 550 MRT 5 sec Multicast Retransmission timeout. 551 MRC 3 Maximum retransmission count. 553 For each transmission the appropriate URT or MRT value is multiplied 554 by a random number chosen with a uniform distribution between 0.9 and 555 1.1. The randomization factor is included to minimize 556 synchronization of messages transmitted. 558 9. Processing of incoming messages 560 Any incoming link configuration or advertisement message, or an 561 incoming update sent to a link-local address, whose IP Hop Limit is 562 not 255 may have been forwarded by a router and MUST be discarded. 564 Incoming Update messages that contain TLVs other than Network 565 Parameter TLVs SHOULD be ignored. Incoming Update Request messages 566 that contain any TLVs SHOULD be ignored. 568 Unsecured incoming messages SHOULD be ignored. Secured incoming 569 messages are decrypted and authenticated using the procedures 570 specified in [AES] and [CCM], with security material obtained from 571 the auxiliary security header as described in [IEEE802154]. The key 572 source may be obtained either from the link layer source address or 573 from the auxiliary security header. 575 A device SHOULD maintain a separate incoming MLE frame counter for 576 each neighbor. Any MLE message received with a frame counter the 577 same or lower than that of a previously received and authenticated 578 message from the same source MUST be discarded. Messages for which 579 no previous frame counter are available are not discarded and the 580 counter value SHOULD be saved for comparison with later messages. 582 10. Link Configuration 584 The values that may need to be communicated to configure an 802.15.4 585 link are: 587 o Long (64-bit) and short (16-bit) addresses. 589 o Capability Information, as in the 802.15.4 Association command in 590 [IEEE802154], especially the Device Type and Receiver On When Idle 591 fields. 593 o Initialization of AES-CCM frame counters. 595 A device wishing to establish a link to a neighbor SHOULD send a Link 596 Request message containing the following: 598 o Source Address TLV, containing the sender's short (16-bit) MAC 599 address. The sender's long (64-bit) MAC address MUST used as the 600 MAC source address of the message. 602 o Mode TLV, containing the sender's Capability data byte. 604 o Timeout TLV, if the sender is an rxOffWhenIdle device. 606 o Challenge TLV, whose size is determined by the network 607 configuration. 609 If the neighbor has sufficient resources to maintain an additional 610 link, it SHOULD respond with a Link Accept message containing the 611 same TLVs (with its own values), but with a Response TLV in place of 612 the Challenge TLV and with added Link-layer Frame Counter and MLE 613 Frame Counter TLVs. The MLE Frame Counter TLV MAY be omitted if the 614 sender uses the same counter for both MLE and 802.15.4 messages. If 615 the neighbor also required a liveness check, it MAY include its own 616 challenge, and use the Link Accept And Request message type. 618 If a node receives a secured 802.15.4 unicast from a neighbor for 619 whom it does not have link configuration data, the receiving node 620 SHOULD respond with a Link Reject message to inform the neighbor that 621 the link is not configured. 623 Link Configuration messages are used to establish 802.15.4 security 624 and so SHOULD NOT be secured at the 802.15.4 layer. 626 11. Parameter Dissemination 628 Update messages may be sent to change the channel, PAN ID, and/or 629 permit joining flags on all nodes. Determining when these values 630 should be changed is beyond the scope of this document. 632 To make a network-wide change to one of these parameters, an MLE 633 update messages SHOULD be sent to an appropriate multicast address, 634 such as the site-local all-node, all-routers or all-MLE-nodes 635 multicast address (to be assigned by IANA). This requires some form 636 of multi-hop multicast forwarding; these messages are sent 637 infrequently, so forwarding with simple flooding is sufficient. 639 A single update message MAY contain multiple values for the same 640 parameter with different time delays. In particular, the permit 641 joining flag can be enabled for a limited time by including both on 642 and off values in a single update message. 644 A device that does not have the current network values, either 645 because it has just joined the network or for any other reason, MAY 646 send a unicast Update Request to a neighbor. The neighbor responds 647 by sending an Update message containing the current values of the 648 parameters. 650 12. Neighbor Detection 652 Nodes MAY send out periodic advertisements containing the incoming 653 IDR values for their neighbors. The primary purpose of these 654 messages is to allow nodes to choose likely candidates for link 655 establishment. They can also be used to determine if existing links 656 continue to provide sufficient two-way reliability. 658 A node maintains two boolean values for each known neighbor: 660 Receive State True if the node will accept incoming non-MLE messages 661 from that neighbor. 663 Transmit State A local cache of the neighbor's Receive State 664 corresponding to this node. 666 Both values default to false. 668 The Receive State is set to true when the node receives a valid 669 incoming link accept from the neighbor, and set to false when the 670 link configuration information is discarded for any reason (link 671 failure or timeout, for example). 673 The Transmit State is set to true when a link accept message is sent 674 to the neighbor. When an advertisement message is received from the 675 neighbor the Transmit State is set to the Receive State as reported 676 in the advertisement. If the advertisement's C flag is 1 and the 677 receiving node's address is not included in the advertisement, the 678 recipient's Transmit State for the sender is set to false. 680 These states are advisory only; a node may send a message to a 681 neighbor regardless of its Transmit State for that neighbor. 682 Similarly, a node may unilaterally change its Receive State (and 683 discard any link configuration data) without first informing the 684 neighbor of its intention. The change in Receive State will be 685 reflected in the next advertisement sent by the node. 687 Advertisement messages are used prior to establishing 802.15.4 688 security and thus SHOULD NOT be secured at the 802.15.4 layer. 690 13. Acknowledgements 692 The author would like to acknowledge the helpful comments of Thomas 693 Clausen, Robert Cragie, Colin O'Flynn, Edward Hill, Matteo Paris, 694 Kundok Park, Joseph Reddy, and Dario Tedeschi, which greatly improved 695 the document. 697 14. IANA Considerations 699 IANA has assigned UDP port 19788 to MLE. 701 IANA is requested to establish a new top-level registry, called "MLE: 702 Mesh Link Establishment", to contain all MLE objects, codepoints, and 703 sub-registries. 705 The allocation policy for each new registry is by IETF review: new 706 values are assigned through the IETF review process . 708 14.1. Security Suites 710 IANA is requested to create a subregistry, called "Security Suites". 711 Values range from 0 to 255. 713 Value Meaning Reference 714 0 802.15.4 Security This document 715 255 No Security This document 717 Values 1-254 are currently unassigned. 719 14.2. Command Types 721 IANA is requested to create a subregistry, called "Command Types". 722 Values range from 0 to 255. 724 Value Meaning Reference 725 0 Link Request This document 726 1 Link Accept This document 727 2 Link Accept and Request This document 728 3 Link Reject This document 729 4 Advertisement This document 730 5 Update This document 731 6 Update Request This document 733 Values 6-255 are currently unassigned. 735 14.3. TLV Types 737 IANA is requested to create a subregistry, called "TLV Types". 738 Values range from 0 to 255. 740 Value Meaning Reference 741 0 Source Address This document 742 1 Mode This document 743 2 Timeout This document 744 3 Challenge This document 745 4 Response This document 746 5 Link-layer Frame Counter This document 747 6 Link Quality This document 748 7 Network Parameter This document 749 8 MLE Frame Counter This document 751 Values 8-255 are currently unassigned. 753 14.4. Network Parameters 755 IANA is requested to create a subregistry, called "Network 756 Parameters". Values range from 0 to 255. 758 Value Meaning Reference 759 0 Channel This document 760 1 PAN ID This document 761 2 Permit Joining This document 762 3 Beacon Payload This document 764 Values 4-255 are currently unassigned. 766 15. Security Considerations 768 In general MLE has the strengths and weaknesses of the link layer 769 security that it inherits. The one exception is that MLE's operation 770 requires accepting and acting on incoming Advertisements and Link 771 Requests messages for which the receiver has no prior knowledge of 772 the sender's MLE frame counter. Because of this, implementers must 773 be careful in how they use information obtained from these possibly- 774 replayed messages. For example, information from unsecured messages 775 should not be used to modify any stored information obtained from 776 secured messages. 778 The Hop Limit field of received packets other than multihop update 779 messages is verified to contain 255, the maximum legal value. 780 Because routers decrement the Hop Limit on all packets they forward, 781 received packets containing a Hop Limit of 255 must have originated 782 from a neighbor. This technique is borrowed from IPv6 ND [RFC4861]. 784 16. References 786 16.1. Normative References 788 [AES] National Institute of Standards and Technology, 789 "Specification for the Advanced Encryption Standard 790 (AES)", FIPS 197, November 2001. 792 [CCM] National Institute of Standards and Technology, 793 "Recommendation for Block Cipher Modes of Operation: The 794 CCM Mode for Authentication and Confidentiality", SP 800- 795 38C, May 2004. 797 [IEEE802154] 798 Institute of Electrical and Electronics Engineers, 799 "Wireless Personal Area Networks", IEEE Standard 802.15.4- 800 2006, 2006. 802 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 803 Requirement Levels", BCP 14, RFC 2119, March 1997. 805 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 806 Requirements for Security", BCP 106, RFC 4086, June 2005. 808 16.2. Informative References 810 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 811 and M. Carney, "Dynamic Host Configuration Protocol for 812 IPv6 (DHCPv6)", RFC 3315, July 2003. 814 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 815 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 816 September 2007. 818 [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. 819 Barthel, "Routing Metrics Used for Path Calculation in 820 Low-Power and Lossy Networks", RFC 6551, March 2012. 822 Author's Address 824 Richard Kelsey 825 Silicon Labs 826 25 Thomson Place 827 Boston, Massachusetts 02210 828 USA 830 Phone: +1 617 951 1225 831 Email: richard.kelsey@silabs.com