| Internet Area WG | R.K. Kelsey |
| Internet-Draft | Ember Corporation |
| Intended status: Standards Track | March 07, 2012 |
| Expires: September 06, 2012 |
Mesh Link Establishment
draft-kelsey-intarea-mesh-link-establishment-02
This document defines the mesh link establishment (MLE) protocol for establishing and configuring links in an ad hoc mesh radio network. Effective mesh networking using radio links requires identifying, configuring, and securing usable links to neighboring devices. In an ad hoc mesh network a device's neighbors may come and go as the network's membership and physical environment change. Newly usable links need to be identified and configured automatically, where configuration values can include link-layer addresses, transmit and receive modes, security parameters, and so forth. MLE includes the option of securing the configuration messages themselves, as link-layer security may not be available prior to configuration.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 06, 2012.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The configuration of individual links in an ad hoc mesh network can fall into a gap between standards. Link layer standards typically deal with individual links and networking standards assume that the links are up and running. In an ad hoc mesh network a device's neighbors may come and go as the network's membership and physical environment change, requiring that new links be configured automatically. The required configuration information can include link layer addressing, transmit and receive modes, wake/sleep cycles, and so on. Security configuration is particularly important, as the link layer may not be able to secure packets until after the link itself has been configured.
MLE can be used to configure individual links and to distribute configuration values that are shared across a network. MLE messages are sent using UDP. Per-link configuration uses one-hop messages with link-local addresses. Network-wide configuration uses multicasts and requires some form of multi-hop multicast forwarding.
Link parameters can be unicast between two neighboring nodes, as when configuring a particular link, or multicast to all neighbors, in order to advertise to new neighbors or to efficiently transmit updated values.
One of the most important properties of a radio link, how well the two neighbors hear each other, often cannot be determined unilaterally by either node. Many radio links are asymmetric, where messages traveling one way across the link are received more or less reliably than messages traveling in the opposite direction. There is a chicken and egg problem here. It is a waste of effort to configure a link that does not have sufficient two-way reliability to be useful, but the two-way reliability cannot be determined without exchanging messages over the link. MLE resolves this by allowing a node to periodically multicast an estimate of the quality of its links. This allows a node to determine if it has a usable radio link to a neighbor without first configuring that link.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
MLE is a means of transmitting link configuration values. An MLE message is one of:
If negotiation is required, establishment of a link may require an exchange of two or more unicast messages. The only multiple-message exchange in the MLE protocol performs liveness determination (replay counter initialization).
MLE messages consist of a command and a series of type-length-value parameters. MLE messages can be secured using Advanced Encryption Standard 128 [AES] in Counter with CBC-MAC Mode [CCM] for data authentication and encryption.
The security data is formatted as an auxiliary security header as specified in [IEEE802154]. There are two exceptions to this: a security header with security level of 0 does not contain a frame counter, and when frame counters are included they are in big-endian form. This first exception avoids the need to include a frame counter when security is being provided by the link layer. The second is to conform with normal IETF practice. Otherwise, the presence and length of the frame counter, key identifier, and MIC follow [IEEE802154].
If MLE security is in use each device MUST maintain an outgoing frame/replay counter for use in securing outgoing packets in compliance with [CCM]. MLE does not include a method for configuring its own frame counters and so does not provide complete protection against replayed MLE packets.
MLE security MUST NOT use any key that is being used by the link (or any other) layer MLE security MAY use a key derived using a cryptographic hash from a key being used at the link layer. Other than the above requirements, the distribution or derivation of the key(s) used for MLE security is outside the scope of this document.
<message> := <version>
<security-data>
<command-id>
<tlv>*
<mic>?
<security-data> := <security-control-field>
<frame-counter>?
<key-identifier>?
The version field is one byte in length and has the value 0.
The defined command IDs are:
(values to be confirmed by IANA) The first four (Link Request, Link Accept, Link Accept and Request, and Link Reject) are collectively referred to as link configuration messages.
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Values are encoded using a type-length-value format, where the type and length are one byte each and the length field contains the length of the value in bytes. There are no alignment requirements and no padding.
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0 | Length | Source Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A given radio interface may have multiple link-layer addresses. This TLV is used to communicate any source address(es) that is not included in the message by the link layer itself.
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Length | Mode ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mode information can include such things as the senders listening schedule, whether it will poll for messages, and so forth.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Length | Timeout
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This allows the receiver to more accurately timeout a link to a neighbor that polls for its incoming messages.
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 | Length | Challenge ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An important part of replay protection is determining if a newly-heard neighbor is actually present or is a set of recorded messages. This is done by sending a random challenge value to the neighbor and then receiving that same value in a Response TLV sent by the neighbor.
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 4 | Length | Response ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 5 | Length | Replay Counter ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 6 | Length |C| Res | Size | Neighbor Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I|O| reserved | Incoming IDR | Neighbor Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The I and O flags are used to facilitate the two-way use of links between neighboring routers. They are advisory only; a node may send a message to a neighbor regardless of the state of the most recently seen corresponding I bit from that neighbor. Similarly, a node may unilaterally discard a configured link without informing the neighbor of its intention.
A node that does not have a link configured to a neighbor but receives a Link Quality TLV from that neighbor with the node's O flag set SHOULD send an MLE message with a Link Quality TLV with that neighbor's I bit cleared. This message may either be a regular multicast Advertisement or a unicast to that neighbor containing only a single Neighbor Data record.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 7 | Length | Parameter ID | Delay
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Update messages SHOULD contain only Param TLVs.
The defined Parameter IDs are:
(values to be confirmed by IANA)
Messages SHOULD be sent using UDP port XXXX (value to be assigned by IANA). Link configuration and advertisement messages MUST be sent with an IP Hop Limit of 255, either to a link-local unicast address or to the link-local all-nodes (FF02::2) or all-routers (FF02::1) multicast addresses. Update messages MAY be sent as are link configuration or advertisement messages, or MAY be sent to a site-local all-MLE-nodes multicast address (to be assigned by IANA).
IP source address IP destination address auxiliary security header
Outgoing messages SHOULD be secured using the procedure specified in [AES] and [CCM] using the auxiliary security header as described in [IEEE802154]. Key choice is outside the scope of this document. The authenticated data consists of the following three values concatenated together:
A message sent in response to a multicast request, such as a multicast Link Request, MUST be delayed by a random time between 0 and MAX_RESPONSE_DELAY_TIME seconds.
If no response is received to a request, the request MAY be retransmitted. Because MLE messages do not require complex processing and are not relayed, a simple timeout scheme is used for retransmitting. This is based on the retransmission mechanism used in DHCPv6 RFC 3315 [RFC3315], simplified to use a single, fixed timeout.
Parameter Default Description ------------------------------------------------------- URT 1 sec Unicast Retransmission timeout. MRT 5 sec Multicast Retransmission timeout. MRC 3 Maximum retransmission count.
For each transmission the appropriate URT or MRT value is multiplied by a random number chosen with a uniform distribution between 0.9 and 1.1. The randomization factor is included to minimize synchronization of messages transmitted.
Any incoming link configuration or advertisement message, or an incoming update sent to a link-local address, whose IP Hop Limit is not 255 may have been forwarded by a router and MUST be discarded.
Incoming update messages that contain TLVs other than Param TLVs SHOULD be ignored.
Unsecured incoming messages SHOULD be ignored. Secured incoming messages are decrypted and authenticated using the procedures specified in [AES] and [CCM], with security material obtained from the auxiliary security header as described in [IEEE802154]. The key source may be obtained either from the link layer source address or from the auxiliary security header.
A device SHOULD maintain a separate incoming frame/replay counter for each neighbor. Any message received with a frame/replay counter the same or lower than that of a previously received and authenticated message from the same source MUST be discarded. Messages for which no previous frame/replay counter are available are not discarded and the counter value SHOULD be saved for comparison with later messages.
This section describes how MLE could be used in an 802.15.4-based LoWPAN. This section is not normative. The values that may need to be communicated to configure an 802.15.4 include:
A device wishing to establish a link to a neighbor would send a Link Request message containing the following:
If the neighbor has sufficient resources to maintain an additional link, it would respond with a Link Accept message containing the same TLVs (with its own values), but with a Response TLV in place of the Challenge TLV and with an added Replay Counter TLV. If the neighbor also required a liveness check, it would include its own challenge, and use the Link Accept And Request message type.
If a node receives a secured 802.15.4 unicast from a neighbor for whom it does not have link configuration data, the receiving node should respond with a Link Reject message to inform the neighbor that the link is not configured.
Nodes could also send out periodic advertisements containing the incoming and outgoing ETX values for their neighbors. These would be used to choose likely candidates for link establishment and to determine if existing links continued to provide sufficient two-way reliability.
Because link configuration and advertisement messages are used to establish 802.15.4 security they should not be secured at the 802.15.4 layer.
Update messages may be sent to change the channel, PAN ID, and/or permit joining flags on all nodes. The permit joining flag normally defaults to false; to avoid permanently enabling joining, the value of permit joining parameter should be the number of seconds for which the permit joining flag should be turned on, and not just true or false.
TODO.
TODO: UDP port and registries for the command, TLV, and Parameter ID identifiers.
IN PROGRESS
Some MLE messages are necessarily sent unsecured. Implementations must take care to use information data from unsecured messages appropriately. In particular, information from unsecured messages should not be used to modify any stored information obtained from secured messages.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [CCM] | National Institute of Standards and Technology, "Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality ", SP 800-38C, May 2004. |
| [AES] | National Institute of Standards and Technology, "Specification for the Advanced Encryption Standard (AES)", FIPS 197, November 2001. |
| [IEEE802154] | Institute of Electrical and Electronics Engineers, "Wireless Personal Area Networks", IEEE Standard 802.15.4-2006, 2006. |
| [RFC3315] | Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. |