Internet Area WG R. Kelsey
Internet-Draft Ember Corporation
Intended status: Standards Track September 29, 2011
Expires: April 1, 2012
Mesh Link Establishment
draft-kelsey-intarea-mesh-link-establishment-00
Abstract
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.
Status of this Memo
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 April 1, 2012.
Copyright Notice
Copyright (c) 2011 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
Kelsey Expires April 1, 2012 [Page 1]
Internet-Draft Mesh Link Establishment September 2011
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 6
5. Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Source Address . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.4. Challenge . . . . . . . . . . . . . . . . . . . . . . . . 9
5.5. Response . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.6. Replay Counter . . . . . . . . . . . . . . . . . . . . . . 10
5.7. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 10
6. Message transmission . . . . . . . . . . . . . . . . . . . . . 13
7. Processing of incoming messages . . . . . . . . . . . . . . . 14
8. Application to 802.15.4 . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
Kelsey Expires April 1, 2012 [Page 2]
Internet-Draft Mesh Link Establishment September 2011
1. Introduction
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 is quite simple. It is assumed that any network-wide
configuration, including distribution of shared keys, occurs when a
device joins a network and is out of scope for this document. What
remains is any per-link configuration. Because the data is specific
to a single link, all MLE messages are sent only one hop using link-
local addressing.
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. Message are sent using UDP.
One of the most important properties of a radio link, how well the
two neighbors hear each other, often cannot be determined
unilaterally by the two endpoints. 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.
1.1. Requirements Language
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].
Kelsey Expires April 1, 2012 [Page 3]
Internet-Draft Mesh Link Establishment September 2011
2. Terminology
ETX Expected Transmission Count; the number of
transmission attempts required to send a packet
over a particular link. Defined to be the
product of the IDR values for both directions. A
perfect link has an ETX of 1, less than perfect
links have higher ETX values.
Frame counter A value that is incremented with each new secured
message. Used with [CCM] to ensure that no two
messages are secured using the same key and nonce
pair. In 802.15.4 the same counter is used as
both a frame counter and a replay counter.
IDR Inverse Delivery Ration; the number of
transmission attempts divided by the number of
successful transmissions in a given direction
over a link.
Replay counter A message value that is incremented with each new
transmission. Incoming messages whose counter
value is the same or lower as that in an earlier
message are discarded.
Kelsey Expires April 1, 2012 [Page 4]
Internet-Draft Mesh Link Establishment September 2011
3. Overview
MLE is a means of transmitting link configuration values between
neighboring nodes. An MLE message is either multicast, to advertise
a node's link quality estimates to its neighbors, or unicast, as part
of establishing a link with one particular neighbor. If negotiation
is required, establishment of a link may require an exchange of two
or more messages. The only multiple-message exchange in the core MLE
protocol performs liveness determination (replay counter
initialization).
Kelsey Expires April 1, 2012 [Page 5]
Internet-Draft Mesh Link Establishment September 2011
4. Message Formats
MLE messages consist of a command and a series of type-length-value
parameters. 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.
The distribution of the key(s) used for MLE security is outside the
scope of this document.
<message> := <security-data>
<command-id>
<tlv>*
<mic>?
<security-data> := <security-control-field>
<frame-counter>?
<key-identifier>?
The defined command IDs are:
0 Link Request. A request to establish a link to a neighbor.
1 Link Accept. Accept a requested link.
2 Link Accept and Request. Accept a requested link and request
initialization in the other direction.
Kelsey Expires April 1, 2012 [Page 6]
Internet-Draft Mesh Link Establishment September 2011
3 Link Reject. Reject a link request.
4 Advertisement. Inform neighbors of a device's link state.
(values to be confirmed by IANA)
Kelsey Expires April 1, 2012 [Page 7]
Internet-Draft Mesh Link Establishment September 2011
5. Values
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 | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.1. Source Address
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Length of the Address field in octets.
Source Address A link-layer address assigned to the source of
the message.
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.
5.2. Mode
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Length of the Mode field in octets.
Kelsey Expires April 1, 2012 [Page 8]
Internet-Draft Mesh Link Establishment September 2011
Mode Mode configuration of this link. The possible
values are specific to the link layer in use.
Mode information can include such things as the senders listening
schedule, whether it will poll for messages, and so forth.
5.3. Timeout
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length 2
Timeout The expected maximum interval between
transmissions by the sender in seconds.
This allows the receiver to more accurately timeout a link to a
neighbor that polls for its incoming messages.
5.4. Challenge
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Length of the Challenge field in octets.
Challenge A random value used to determine the freshness of
any reply to this message.
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.
Kelsey Expires April 1, 2012 [Page 9]
Internet-Draft Mesh Link Establishment September 2011
5.5. 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 = 4 | Length | Response ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Length of the Response field in octets.
Response The challenge value echoed back to the original
sender (in network order).
5.6. 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 = 5 | Length | Replay Counter ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Length of the Replay Counter field in octets.
Response The sender's current outgoing link-layer Replay
Counter.
5.7. Link Quality
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Length of following values in octets (1 + (size +
3) * number-of-neighbors).
C Complete: 1 if the message includes all
neighboring routers for which the source has link
quality data. Multicast Link Quality TLVs
normally contain complete information; a unicast
to a particular neighbor would normally contain
Kelsey Expires April 1, 2012 [Page 10]
Internet-Draft Mesh Link Establishment September 2011
only that neighbor's link quality and would not
have the C flag set.
Res Reserved.
Size The size in octets of the included neighbor
addresses, minus 1. This supports addresses of
lengths 1 to 16.
Neighbor Data A sequence of neighbor records, each containing
an "established" flag, the estimated incoming
link reliability (IDR), and the neighbor's link-
layer address.
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I(ncoming) Set if the sender has configured its link with
this neighbor and will accept incoming messages
from them.
O(utgoing) Set if the sender believes that the neighbor has
configured its link with the sender and will
accept incoming messages from the sender. This
flag is set if the sender has sent a Link Accept
message to the neighbor and cleared if the sender
has subsequently received a Link Quality TLV from
the neighbor with the sender's I flag cleared.
Incoming IDR The estimated inverse delivery ratio of messages
sent by the neighbor to the source of this
message. To allow for fractional IDR, the value
encoded is multiplied by 32. A perfect link,
with an actual IDR of 1, would have an Incoming
IDR of 0x20. A value of 0xFF indicates that the
link is unusable.
Address A link-layer address of a neighbor.
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
Kelsey Expires April 1, 2012 [Page 11]
Internet-Draft Mesh Link Establishment September 2011
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.
Kelsey Expires April 1, 2012 [Page 12]
Internet-Draft Mesh Link Establishment September 2011
6. Message transmission
Messages SHOULD be sent using UDP port XXXX (value to be assigned by
IANA).
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:
IP source address
IP destination address
auxiliary security header
The secured data consists of the messages body following the
auxiliary security header (the command ID and TLVs).
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.
MAX_RESPONSE_DELAY_TIME 1 second
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.
Kelsey Expires April 1, 2012 [Page 13]
Internet-Draft Mesh Link Establishment September 2011
7. Processing of incoming messages
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.
Kelsey Expires April 1, 2012 [Page 14]
Internet-Draft Mesh Link Establishment September 2011
8. Application to 802.15.4
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:
o Long (64-bit) and short (16-bit) addresses.
o Capability data byte, especially the Device Type and Receiver On
When Idle fields.
o Initialization of AES-CCM frame counters (which are also used as
replay counters).
A device wishing to establish a link to a neighbor would send a Link
Request message containing the following:
o Source Address TLV, containing the sender's short (16-bit) MAC
address. It is assumed that the sender's long (64-bit) MAC
address is used as the MAC source address of the message.
o Mode TLV, containing the sender's Capability data byte.
o Timeout TLV, if the sender is an rxOffWhenIdle device.
o Challenge TLV, whose size is determined by the network
configuration.
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.
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 MLE is used to establish 802.15.4 security, MLE packets are
not secured at the 802.15.4 layer. MLE security can use a key
derived from the 802.15.4 key using a cryptographic hash.
Kelsey Expires April 1, 2012 [Page 15]
Internet-Draft Mesh Link Establishment September 2011
9. Acknowledgements
TODO.
Kelsey Expires April 1, 2012 [Page 16]
Internet-Draft Mesh Link Establishment September 2011
10. IANA Considerations
TODO: UDP port and registries for the command and TLV identifiers.
Kelsey Expires April 1, 2012 [Page 17]
Internet-Draft Mesh Link Establishment September 2011
11. Security Considerations
TODO.
Kelsey Expires April 1, 2012 [Page 18]
Internet-Draft Mesh Link Establishment September 2011
12. References
12.1. Normative References
[AES] National Institute of Standards and Technology,
"Specification for the Advanced Encryption Standard
(AES)", FIPS 197, November 2001.
[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.
[IEEE802154]
Institute of Electrical and Electronics Engineers,
"Wireless Personal Area Networks", IEEE Standard 802.15.4-
2006, 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
12.2. Informative References
[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.
Kelsey Expires April 1, 2012 [Page 19]
Internet-Draft Mesh Link Establishment September 2011
Author's Address
Richard Kelsey
Ember Corporation
25 Thomson Place
Boston, Massachusetts 02210
USA
Phone: +1 617 951 1225
Email: richard.kelsey@ember.com
Kelsey Expires April 1, 2012 [Page 20]