idnits 2.17.1 draft-kelsey-intarea-mesh-link-establishment-03.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 (May 17, 2012) is 4359 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 May 17, 2012 5 Expires: November 18, 2012 7 Mesh Link Establishment 8 draft-kelsey-intarea-mesh-link-establishment-03 10 Abstract 12 This document defines the mesh link establishment (MLE) protocol for 13 establishing and configuring secure links in an ad hoc mesh radio 14 network. Effective mesh networking using radio links requires 15 identifying, configuring, and securing usable links to neighboring 16 devices. In an ad hoc mesh network a device's neighbors may come and 17 go as the network's membership and physical environment change. 18 Newly usable links need to be identified and configured 19 automatically, where configuration values can include link-layer 20 addresses, transmit and receive modes, security parameters, and so 21 forth. MLE includes the option of securing the configuration 22 messages themselves, as link-layer security is typically not 23 available prior to configuration. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 18, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Security Formats . . . . . . . . . . . . . . . . . . . . . . . 6 64 5. Command Format . . . . . . . . . . . . . . . . . . . . . . . . 7 65 6. Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 6.1. Source Address . . . . . . . . . . . . . . . . . . . . . . 8 67 6.2. Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 6.3. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 6.4. Challenge . . . . . . . . . . . . . . . . . . . . . . . . 9 70 6.5. Response . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 6.6. Replay Counter . . . . . . . . . . . . . . . . . . . . . . 9 72 6.7. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 9 73 6.8. Network Parameter . . . . . . . . . . . . . . . . . . . . 11 74 7. Message transmission . . . . . . . . . . . . . . . . . . . . . 12 75 8. Processing of incoming messages . . . . . . . . . . . . . . . 14 76 9. Application to 802.15.4 . . . . . . . . . . . . . . . . . . . 15 77 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 78 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 79 11.1. Security Suites . . . . . . . . . . . . . . . . . . . . . 18 80 11.2. Command Types . . . . . . . . . . . . . . . . . . . . . . 18 81 11.3. TLV Types . . . . . . . . . . . . . . . . . . . . . . . . 18 82 11.4. Network Parameters . . . . . . . . . . . . . . . . . . . . 19 83 12. Security Considerations . . . . . . . . . . . . . . . . . . . 20 84 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 85 13.1. Normative References . . . . . . . . . . . . . . . . . . . 21 86 13.2. Informative References . . . . . . . . . . . . . . . . . . 21 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 89 1. Introduction 91 The configuration of individual links in an ad hoc mesh network can 92 fall into a gap between standards. Link layer standards typically 93 deal with individual links and networking standards assume that the 94 links are up and running. In an ad hoc mesh network a device's 95 neighbors may come and go as the network's membership and physical 96 environment change, requiring that new links be configured 97 automatically. The required configuration information can include 98 link layer addressing, transmit and receive modes, wake/sleep cycles, 99 and so on. 101 Security configuration is particularly important, as the link layer 102 may not be able to secure packets until after the link itself has 103 been configured. Existing IETF neighbor discovery protocols, such as 104 IPv6 ND [RFC4861] and NHDP [RFC6130] either require (IPv6 ND) or 105 recommend (NHDP) that their messages be sent over secured links. 106 While there are some similarities between these protocols and MLE, 107 they are actually complementary: MLE is entirely concerned with link- 108 layer configuration, including security, while IPv6 ND and NHDP use 109 already-configured links to discover IP properties of their 110 neighbors. 112 MLE can be used to configure individual links and to distribute 113 configuration values that are shared across a network. Per-link 114 configuration uses one-hop messages with link-local addresses. 115 Network-wide configuration uses multicasts and requires some form of 116 multi-hop multicast forwarding. 118 One of the most important properties of a radio link, how reliably 119 the two neighbors can communicate, often cannot be determined 120 unilaterally by either node. Many radio links are asymmetric, where 121 messages traveling one way across the link are received more or less 122 reliably than messages traveling in the opposite direction. There is 123 a chicken and egg problem here. It is a waste of effort to configure 124 a link that does not have sufficient two-way reliability to be 125 useful, but the two-way reliability cannot be determined without 126 exchanging messages over the link. MLE resolves this by allowing a 127 node to periodically multicast an estimate of the quality of its 128 links. This allows a node to determine if it has a usable radio link 129 to a neighbor without first configuring that link. 131 1.1. Requirements Language 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in 136 [RFC2119]. 138 2. Terminology 140 ETX Expected Transmission Count [RFC6551]; the number 141 of transmission attempts required to send a 142 packet over a particular link. Defined to be the 143 product of the IDR values for both directions. A 144 perfect link has an ETX of 1, less than perfect 145 links have higher ETX values. 147 Frame counter A value that is incremented with each new secured 148 message. Used with [CCM] to ensure that no two 149 messages are secured using the same key and nonce 150 pair. In 802.15.4 the same counter is used as 151 both a frame counter and a replay counter. 153 IDR Inverse Delivery Ratio; the number of 154 transmission attempts divided by the number of 155 successful transmissions in a given direction 156 over a link. Used in computing the ETX value for 157 a link. 159 Replay counter A message value that is incremented with each new 160 transmission. Incoming messages whose counter 161 value is the same or lower as that in an earlier 162 message are discarded. 164 3. Overview 166 MLE provides a means of transmitting link configuration values. An 167 MLE message is one of: 169 Link configuration A one-hop unicast sent as part of establishing a 170 link with one particular neighbor. Link 171 configuration messages are either a request that 172 the link be configured, or an acceptance or 173 rejection of such a request. 175 Advertisement A one-hop multicast that advertise a node's link 176 quality estimates to its neighbors. 178 Update A multicast that updates a shared configuration 179 value. 181 If additional negotiation is required, establishment of a link may 182 require an exchange of two or more unicast messages. The only 183 multiple-message exchange in MLE protocol as described in this 184 document performs liveness determination (replay counter 185 initialization). 187 MLE messages are sent using UDP. 189 A node maintains two boolean values for each neighbor: 191 Receive State True if the node will accept incoming non-MLE messages 192 from that neighbor. 194 Transmit State A local cache of the neighbor's Receive State 195 corresponding to this node. 197 Both values default to false. The Receive State is set to true when 198 the node accepts an incoming link request from the neighbor, and set 199 to false when the link configuration information is discarded for any 200 reason (link failure or timeout, for example). The Transmit State is 201 set to true when a link accept message is received from the neighbor. 202 When an advertisement message is received from the neighbor the 203 Transmit State is set to the neighbor's Receive State as reported, 204 either implicitly or explicitly, in that message. 206 These states are advisory only; a node may send a message to a 207 neighbor regardless of the Transmit State of that neighbor. 208 Similarly, a node may unilaterally change its Receive State (and 209 discard any link configuration data) without first informing the 210 neighbor of its intention. The change in Receive State will be 211 reflected in the next advertisement sent by the node. 213 4. Security Formats 215 One of the main functions of MLE is to initialize link-layer 216 security. This means that MLE itself cannot rely on link-layer 217 security. To avoid the cost and complexity of adding a second 218 security suite, MLE reuses that of the link layer. This document 219 describes two security suites, one with no security and the other 220 using Advanced Encryption Standard 128 [AES] in Counter with CBC-MAC 221 Mode [CCM] as described in [IEEE802154]. Later extensions may 222 include other security suites for use with other types of links. 224 An MLE message begins with single byte indicating the security suite 225 used in that message. If that initial byte is "255" no security is 226 used and the messages has no additional security data. An initial 227 byte of "0" indicates that the message is secured as described in 228 [IEEE802154] (all codes are to be confirmed by IANA; see Section 11). 229 MLE messages thus have one of the two following formats: 231 +-----+------------+---------+-----+ 232 | 0 | Aux Header | Command | MIC | 233 +-----+------------+---------+-----+ 234 +-----+---------+ 235 | 255 | Command | 236 +-----+---------+ 238 Aux Header Auxiliary Security Header as described in [IEEE802154]. 240 Command MLE command; see Section 5. 242 MIC Message Integrity Code as described in [IEEE802154]. 244 If MLE security is in use each device MUST maintain an outgoing 245 frame/replay counter for use in securing outgoing packets in 246 compliance with [CCM]. MLE does not include a method for configuring 247 its own frame counters and so does not provide complete protection 248 against replayed MLE packets. 250 MLE security MUST NOT use any key that is being used by the link (or 251 any other) layer. Other than the above requirements, the 252 distribution or derivation of the key(s) used for MLE security is 253 outside the scope of this document. 255 5. Command Format 257 MLE messages consist of a command type and a series of type-length- 258 value parameters. 260 +--------------+-----+-----+-----+ 261 | Command Type | TLV | ... | TLV | 262 +--------------+-----+-----+-----+ 264 Command Type An eight-bit unsigned integer identifying the type of 265 message. This document defines the following commands 266 (all codes are to be confirmed by IANA, see Section 11): 268 0 Link Request. A request to establish a link to a 269 neighbor. 271 1 Link Accept. Accept a requested link. 273 2 Link Accept and Request. Accept a requested link 274 and request a link with the sender of the original 275 request. 277 3 Link Reject. Reject a link request. 279 4 Advertisement. Inform neighbors of a device's link 280 state. 282 5 Update. Informs of changes to link parameters 283 shared by all nodes in a network. 285 The first four (Link Request, Link Accept, Link Accept 286 and Request, and Link Reject) are collectively referred 287 to as link configuration messages. 289 TLVs Zero or more TLV frames. These are described in 290 Section 6. 292 6. Values 294 Values are encoded using a type-length-value format, where the type 295 and length are one byte each and the length field contains the length 296 of the value in bytes. There are no alignment requirements and no 297 padding. 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Type | Length | Value ... 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Type An eight-bit unsigned integer giving the type of 306 the value. 308 Length An eight-bit unsigned integer giving the length 309 of the Value field in bytes. 311 Value Length bytes of value, formatted as defined for 312 the Type. 314 6.1. Source Address 316 The Source Address TLV (TLV Type 0) has a Value containing a byte 317 string representing a link-layer address assigned to the source of 318 the message. A given radio interface may have multiple link-layer 319 addresses. This TLV is used to communicate any source address(es) 320 that is not included in the message by the link layer itself. 322 6.2. Mode 324 The Mode TLV (TLV Type 1) has a Value containing a byte string 325 representing the mode in which this link is used by the source of the 326 message. The format and interpretation of the mode value are 327 specific to the link layer in use. Mode information can include such 328 things as the sender's listening schedule, whether it will poll for 329 messages, and so forth. 331 6.3. Timeout 333 The Timeout TLV (TLV Type 2) has a Value containing a 32-bit unsigned 334 integer, most significant byte first. The value is the expected 335 maximum interval between transmissions by the sender, in seconds. 336 This allows the receiver to more accurately timeout a link to a 337 neighbor that polls for its incoming messages. 339 6.4. Challenge 341 The Challenge TLV (TLV Type 3) has a Value containing a randomly- 342 chosen byte string that is used to determine the freshness of any 343 reply to this message. The recommendations in [RFC4086] apply with 344 regard to generation of the challenge value. A new value MUST be 345 chose for each Challenge TLV transmitted. An important part of 346 replay protection is determining if a newly-heard neighbor is 347 actually present or is a set of recorded messages. This is done by 348 sending a random challenge value to the neighbor and then receiving 349 that same value in a Response TLV sent by the neighbor. 351 6.5. Response 353 The Response TLV (TLV Type 4) has a Value containing a byte string 354 copied from a Challenge TLV. 356 6.6. Replay Counter 358 The Replay Counter TLV (TLV Type 5) has a Value containing the 359 sender's current outgoing link-layer Replay Counter, encoded as an 360 N-bit unsigned integer, most significant byte first. The size of the 361 Replay Counter is determined the link layer in use. 363 6.7. Link Quality 365 The Link Quality TLV (TLV Type 6) reports the sender's measured link 366 quality for messages received from its neighbors. The format of the 367 Link Quality value is as follows: 369 0 1 2 370 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 |C| Res | Size | Neighbor Data ... 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 C Complete: "1" if the message includes all 376 neighboring routers for which the source has link 377 quality data. Multicast Link Quality TLVs 378 normally contain complete information; a unicast 379 to a particular neighbor would normally contain 380 only that neighbor's link quality and would have 381 the C flag of "0". 383 Res Reserved. 385 Size The size in bytes of the included neighbor link- 386 layer addresses, minus 1. This supports 387 addresses of lengths 1 to 16. 389 Neighbor Data A sequence of neighbor records, each containing 390 receive and transmit state flags, the estimated 391 incoming link reliability (IDR), and the 392 neighbor's link-layer address. 394 The neighbor data in a Link Quality TLV is formatted as follows: 396 0 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 |I|O| reserved | Incoming IDR | Neighbor Address ... 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 I(ncoming) "1" if the sender's Receive State for this 403 neighbor is true, "0" if not. 405 O(utgoing) "1" if the sender's Transmit State for this 406 neighbor is true, "0" if not. 408 Incoming IDR The estimated inverse delivery ratio of messages 409 sent by the neighbor to the source of this 410 message. This is an eight-bit unsigned integer. 411 To allow for fractional IDR, the value encoded is 412 multiplied by 32. A perfect link, with an actual 413 IDR of 1, would have an Incoming IDR of 0x20. A 414 value of 0xFF indicates that the link is 415 unusable. 417 Address A link-layer address of a neighbor. 419 The I and O flags are used to facilitate the two-way use of links 420 between neighboring routers. 422 A node that does not have a link configured to a neighbor but 423 receives a Link Quality TLV from that neighbor with the node's O flag 424 set to "1" SHOULD send an MLE message with a Link Quality TLV with 425 that neighbor's I bit set to "0". This message may either be a 426 regular multicast Advertisement or a unicast to that neighbor 427 containing only a single Neighbor Data record. 429 6.8. Network Parameter 431 The Parameter TLV (TLV Type 7) specifies the value of a link-layer 432 parameter shared across the network (as opposed to a parameter 433 specific to a particular link). The Value contains three fields: 435 0 1 2 3 436 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 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Parameter ID | Delay 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Value ... 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 Parameter ID The ID of the parameter to be changed. 445 Delay The delay before setting the parameter, in 446 milliseconds. This is a four-byte unsigned 447 integer, most significant byte first. Having a 448 delay gives time for the new value to propagate 449 throughout the network. 451 Value A byte string containing the new value of the 452 parameter. The format of this value is 453 determined by the particular parameter 455 Update messages SHOULD contain only Network Parameter TLVs. 457 The defined Network Parameters are: 459 0 Channel 461 1 PAN ID 463 2 Permit Joining 465 3 Beacon Payload 467 (values to be confirmed by IANA) 469 7. Message transmission 471 Messages SHOULD be sent using UDP port X (value to be assigned by 472 IANA). Link configuration and advertisement messages MUST be sent 473 with an IP Hop Limit of 255, either to a link-local unicast address 474 or to the link-local all-nodes (FF02::1) or all-routers (FF02::2) 475 multicast addresses. Update messages MAY be sent as above, or MAY be 476 sent to a site-local all-MLE-nodes multicast address (to be assigned 477 by IANA). 479 Outgoing messages SHOULD be secured using the procedure specified in 480 [AES] and [CCM] using the auxiliary security header as described in 481 [IEEE802154]. Key choice is outside the scope of this document. The 482 authenticated data consists of the following three values 483 concatenated together: 485 IP source address 486 IP destination address 487 auxiliary security header 489 The secured data consists of the messages body following the 490 auxiliary security header (the command ID and TLVs). 492 A message sent in response to a multicast request, such as a 493 multicast Link Request, MUST be delayed by a random time between 0 494 and MAX_RESPONSE_DELAY_TIME seconds. 496 MAX_RESPONSE_DELAY_TIME 1 second 498 If no response is received to a request, the request MAY be 499 retransmitted. Because MLE messages do not require complex 500 processing and are not relayed, a simple timeout scheme is used for 501 retransmitting. This is based on the retransmission mechanism used 502 in DHCPv6 RFC 3315 [RFC3315], simplified to use a single, fixed 503 timeout. 505 Parameter Default Description 506 ------------------------------------------------------- 507 URT 1 sec Unicast Retransmission timeout. 508 MRT 5 sec Multicast Retransmission timeout. 509 MRC 3 Maximum retransmission count. 511 For each transmission the appropriate URT or MRT value is multiplied 512 by a random number chosen with a uniform distribution between 0.9 and 513 1.1. The randomization factor is included to minimize 514 synchronization of messages transmitted. 516 8. Processing of incoming messages 518 Any incoming link configuration or advertisement message, or an 519 incoming update sent to a link-local address, whose IP Hop Limit is 520 not 255 may have been forwarded by a router and MUST be discarded. 522 Incoming update messages that contain TLVs other than Network 523 Parameter TLVs SHOULD be ignored. 525 Unsecured incoming messages SHOULD be ignored. Secured incoming 526 messages are decrypted and authenticated using the procedures 527 specified in [AES] and [CCM], with security material obtained from 528 the auxiliary security header as described in [IEEE802154]. The key 529 source may be obtained either from the link layer source address or 530 from the auxiliary security header. 532 A device SHOULD maintain a separate incoming frame/replay counter for 533 each neighbor. Any message received with a frame/replay counter the 534 same or lower than that of a previously received and authenticated 535 message from the same source MUST be discarded. Messages for which 536 no previous frame/replay counter are available are not discarded and 537 the counter value SHOULD be saved for comparison with later messages. 539 9. Application to 802.15.4 541 This section describes how MLE could be used in an 802.15.4-based 542 LoWPAN. This section is not normative. The values that may need to 543 be communicated to configure an 802.15.4 include: 545 o Long (64-bit) and short (16-bit) addresses. 547 o Capability data byte, especially the Device Type and Receiver On 548 When Idle fields. 550 o Initialization of AES-CCM frame counters (which are also used as 551 replay counters). 553 A device wishing to establish a link to a neighbor would send a Link 554 Request message containing the following: 556 o Source Address TLV, containing the sender's short (16-bit) MAC 557 address. It is assumed that the sender's long (64-bit) MAC 558 address is used as the MAC source address of the message. 560 o Mode TLV, containing the sender's Capability data byte. 562 o Timeout TLV, if the sender is an rxOffWhenIdle device. 564 o Challenge TLV, whose size is determined by the network 565 configuration. 567 If the neighbor has sufficient resources to maintain an additional 568 link, it would respond with a Link Accept message containing the same 569 TLVs (with its own values), but with a Response TLV in place of the 570 Challenge TLV and with an added Replay Counter TLV. If the neighbor 571 also required a liveness check, it would include its own challenge, 572 and use the Link Accept And Request message type. 574 If a node receives a secured 802.15.4 unicast from a neighbor for 575 whom it does not have link configuration data, the receiving node 576 should respond with a Link Reject message to inform the neighbor that 577 the link is not configured. 579 Nodes could also send out periodic advertisements containing the 580 incoming IDR values for their neighbors. These would be used to 581 choose likely candidates for link establishment and to determine if 582 existing links continued to provide sufficient two-way reliability. 584 Because link configuration and advertisement messages are used to 585 establish 802.15.4 security they should not be secured at the 586 802.15.4 layer. 588 Update messages may be sent to change the channel, PAN ID, and/or 589 permit joining flags on all nodes. The permit joining flag normally 590 defaults to false; to avoid permanently enabling joining, the value 591 of the permit joining parameter should be the number of seconds for 592 which the permit joining flag should be turned on, and not just true 593 or false. 595 10. Acknowledgements 597 TODO. 599 11. IANA Considerations 601 TODO: UDP port 603 IANA is requested to establish a new top-level registry, called "MLE: 604 Mesh Link Establishment", to contain all MLE objects, codepoints, and 605 sub-registries. 607 The allocation policy for each new registry is by IETF review: new 608 values are assigned through the IETF review process . 610 11.1. Security Suites 612 IANA is requested to create a subregistry, called "Security Suites". 613 Values range from 0 to 255. 615 Value Meaning Reference 616 0 802.15.4 Security This document 617 255 No Security This document 619 Values 1-254 are currently unassigned. 621 11.2. Command Types 623 IANA is requested to create a subregistry, called "Command Types". 624 Values range from 0 to 255. 626 Value Meaning Reference 627 0 Link Request This document 628 1 Link Accept This document 629 2 Link Accept and Request This document 630 3 Link Reject This document 631 4 Advertisement This document 632 5 Update This document 634 Values 6-255 are currently unassigned. 636 11.3. TLV Types 638 IANA is requested to create a subregistry, called "TLV Types". 639 Values range from 0 to 255. 641 Value Meaning Reference 642 0 Source Address This document 643 1 Mode This document 644 2 Timeout This document 645 3 Challenge This document 646 4 Response This document 647 5 Replay Counter This document 648 6 Link Quality This document 649 7 Network Parameter This document 651 Values 8-255 are currently unassigned. 653 11.4. Network Parameters 655 IANA is requested to create a subregistry, called "Network 656 Parameters". Values range from 0 to 255. 658 Value Meaning Reference 659 0 Channel This document 660 1 PAN ID This document 661 2 Permit Joining This document 662 3 Beacon Payload This document 664 Values 4-255 are currently unassigned. 666 12. Security Considerations 668 In general MLE has the strengths and weaknesses of the link layer 669 security that it inherits. The one exception is that MLE's operation 670 requires accepting and acting on incoming Advertisements and Link 671 Requests messages for which the receiver has no prior knowledge of 672 the sender's MLE replay counter. In other words, MLE lacks the 673 security configuration that it provides for link-layer security. 674 Because of this, implementers must be careful in how they use 675 information obtained from these possibly-replayed messages. For 676 example, information from unsecured messages should not be used to 677 modify any stored information obtained from secured messages. 679 The Hop Limit field of all received packets is verified to contain 680 255, the maximum legal value. Because routers decrement the Hop 681 Limit on all packets they forward, received packets containing a Hop 682 Limit of 255 must have originated from a neighbor. This technique is 683 borrowed from IPv6 ND [RFC4861]. 685 13. References 687 13.1. Normative References 689 [AES] National Institute of Standards and Technology, 690 "Specification for the Advanced Encryption Standard 691 (AES)", FIPS 197, November 2001. 693 [CCM] National Institute of Standards and Technology, 694 "Recommendation for Block Cipher Modes of Operation: The 695 CCM Mode for Authentication and Confidentiality", SP 800- 696 38C, May 2004. 698 [IEEE802154] 699 Institute of Electrical and Electronics Engineers, 700 "Wireless Personal Area Networks", IEEE Standard 802.15.4- 701 2006, 2006. 703 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 704 Requirement Levels", BCP 14, RFC 2119, March 1997. 706 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 707 Requirements for Security", BCP 106, RFC 4086, June 2005. 709 13.2. Informative References 711 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 712 and M. Carney, "Dynamic Host Configuration Protocol for 713 IPv6 (DHCPv6)", RFC 3315, July 2003. 715 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 716 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 717 September 2007. 719 [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc 720 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 721 RFC 6130, April 2011. 723 [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. 724 Barthel, "Routing Metrics Used for Path Calculation in 725 Low-Power and Lossy Networks", RFC 6551, March 2012. 727 Author's Address 729 Richard Kelsey 730 Ember Corporation 731 25 Thomson Place 732 Boston, Massachusetts 02210 733 USA 735 Phone: +1 617 951 1225 736 Email: richard.kelsey@ember.com