Mesh Link Establishment
draft-kelsey-intarea-mesh-link-establishment-04
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Richard Kelsey | ||
| Last updated | 2012-10-19 (Latest revision 2012-06-28) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
GENART Last Call review
(of
-05)
by Ben Campbell
Almost ready
|
||
| Stream | WG state | (None) | |
| Document shepherd | (None) | ||
| IESG | IESG state | AD Evaluation | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Ralph Droms | ||
| IESG note | |||
| Send notices to | richard.kelsey@ember.com, draft-kelsey-intarea-mesh-link-establishment@tools.ietf.org, robert.cragie@gridmerge.com |
draft-kelsey-intarea-mesh-link-establishment-04
Internet Area WG R. Kelsey
Internet-Draft Ember Corporation
Intended status: Standards Track June 28, 2012
Expires: December 30, 2012
Mesh Link Establishment
draft-kelsey-intarea-mesh-link-establishment-04
Abstract
This document defines the mesh link establishment (MLE) protocol for
establishing and configuring secure 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 is typically not
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 December 30, 2012.
Copyright Notice
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
Kelsey Expires December 30, 2012 [Page 1]
Internet-Draft Mesh Link Establishment June 2012
(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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Security Formats . . . . . . . . . . . . . . . . . . . . . . . 6
5. Command Format . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Source Address . . . . . . . . . . . . . . . . . . . . . . 8
6.2. Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.3. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.4. Challenge . . . . . . . . . . . . . . . . . . . . . . . . 9
6.5. Response . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.6. Link-layer Frame Counter . . . . . . . . . . . . . . . . . 9
6.7. MLE Frame Counter . . . . . . . . . . . . . . . . . . . . 9
6.8. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 9
6.9. Network Parameter . . . . . . . . . . . . . . . . . . . . 11
6.10. Network Parameter Request . . . . . . . . . . . . . . . . 12
7. Message transmission . . . . . . . . . . . . . . . . . . . . . 13
8. Processing of incoming messages . . . . . . . . . . . . . . . 15
9. Application to 802.15.4 . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
11.1. Security Suites . . . . . . . . . . . . . . . . . . . . . 19
11.2. Command Types . . . . . . . . . . . . . . . . . . . . . . 19
11.3. TLV Types . . . . . . . . . . . . . . . . . . . . . . . . 19
11.4. Network Parameters . . . . . . . . . . . . . . . . . . . . 20
12. Security Considerations . . . . . . . . . . . . . . . . . . . 21
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
13.1. Normative References . . . . . . . . . . . . . . . . . . . 22
13.2. Informative References . . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
Kelsey Expires December 30, 2012 [Page 2]
Internet-Draft Mesh Link Establishment June 2012
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. Existing IETF neighbor discovery protocols, such as
IPv6 ND [RFC4861] and NHDP [RFC6130] either require (IPv6 ND) or
recommend (NHDP) that their messages be sent over secured links.
While there are some similarities between these protocols and MLE,
they are actually complementary: MLE is entirely concerned with link-
layer configuration, including security, while IPv6 ND and NHDP use
already-configured links to discover IP properties of their
neighbors.
MLE can be used to configure individual links and to distribute
configuration values that are shared across a network. 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.
One of the most important properties of a radio link, how reliably
the two neighbors can communicate, 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.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
Kelsey Expires December 30, 2012 [Page 3]
Internet-Draft Mesh Link Establishment June 2012
2. Terminology
ETX Expected Transmission Count [RFC6551]; 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 and used to detect replayed messages.
IDR Inverse Delivery Ratio; the number of
transmission attempts divided by the number of
successful transmissions in a given direction
over a link. Used in computing the ETX value for
a link.
Kelsey Expires December 30, 2012 [Page 4]
Internet-Draft Mesh Link Establishment June 2012
3. Overview
MLE provides a means of transmitting link configuration values. An
MLE message is one of:
Link configuration A one-hop unicast sent as part of establishing a
link with one particular neighbor. Link
configuration messages are either a request that
the link be configured, or an acceptance or
rejection of such a request.
Advertisement A one-hop multicast that advertise a node's link
quality estimates to its neighbors.
Update Messages that updates a shared configuration
value. These may be multicast or unicast.
If additional negotiation is required, establishment of a link may
require an exchange of two or more unicast messages. The only
multiple-message exchange in MLE protocol as described in this
document performs liveness determination (frame counter
initialization).
MLE messages are sent using UDP.
A node maintains two boolean values for each neighbor:
Receive State True if the node will accept incoming non-MLE messages
from that neighbor.
Transmit State A local cache of the neighbor's Receive State
corresponding to this node.
Both values default to false. The Receive State is set to true when
the node accepts an incoming link request from the neighbor, and set
to false when the link configuration information is discarded for any
reason (link failure or timeout, for example). The Transmit State is
set to true when a link accept message is received from the neighbor.
When an advertisement message is received from the neighbor the
Transmit State is set to the neighbor's Receive State as reported,
either implicitly or explicitly, in that message.
These states are advisory only; a node may send a message to a
neighbor regardless of the Transmit State of that neighbor.
Similarly, a node may unilaterally change its Receive State (and
discard any link configuration data) without first informing the
neighbor of its intention. The change in Receive State will be
reflected in the next advertisement sent by the node.
Kelsey Expires December 30, 2012 [Page 5]
Internet-Draft Mesh Link Establishment June 2012
4. Security Formats
One of the main functions of MLE is to initialize link-layer
security. This means that MLE itself cannot rely on link-layer
security. To avoid the cost and complexity of adding a second
security suite, MLE reuses that of the link layer. This document
describes two security suites, one with no security and the other
using Advanced Encryption Standard 128 [AES] in Counter with CBC-MAC
Mode [CCM] as described in [IEEE802154]. Later extensions may
include other security suites for use with other types of links.
An MLE message begins with single byte indicating the security suite
used in that message. If that initial byte is "255" no security is
used and the messages has no additional security data. An initial
byte of "0" indicates that the message is secured as described in
[IEEE802154] (all codes are to be confirmed by IANA; see Section 11).
MLE messages thus have one of the two following formats:
+-----+------------+---------+-----+
| 0 | Aux Header | Command | MIC |
+-----+------------+---------+-----+
+-----+---------+
| 255 | Command |
+-----+---------+
Aux Header Auxiliary Security Header as described in [IEEE802154].
Command MLE command; see Section 5.
MIC Message Integrity Code as described in [IEEE802154].
If MLE security is in use each device MUST maintain an outgoing MLE
frame counter for use in securing outgoing packets in compliance with
[CCM].
MLE security MUST NOT use any key that is being used by the link (or
any other) 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.
Kelsey Expires December 30, 2012 [Page 6]
Internet-Draft Mesh Link Establishment June 2012
5. Command Format
MLE messages consist of a command type and a series of type-length-
value parameters.
+--------------+-----+-----+-----+
| Command Type | TLV | ... | TLV |
+--------------+-----+-----+-----+
Command Type An eight-bit unsigned integer identifying the type of
message. This document defines the following commands
(all codes are to be confirmed by IANA, see Section 11):
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 a link with the sender of the original
request.
3 Link Reject. Reject a link request.
4 Advertisement. Inform neighbors of a device's link
state.
5 Update. Informs of changes to link parameters
shared by all nodes in a network.
The first four (Link Request, Link Accept, Link Accept
and Request, and Link Reject) are collectively referred
to as link configuration messages.
TLVs Zero or more TLV frames. These are described in
Section 6.
Kelsey Expires December 30, 2012 [Page 7]
Internet-Draft Mesh Link Establishment June 2012
6. 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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type An eight-bit unsigned integer giving the type of
the value.
Length An eight-bit unsigned integer giving the length
of the Value field in bytes.
Value Length bytes of value, formatted as defined for
the Type.
6.1. Source Address
The Source Address TLV (TLV Type 0) has a Value containing a byte
string representing 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.
6.2. Mode
The Mode TLV (TLV Type 1) has a Value containing a byte string
representing the mode in which this link is used by the source of the
message. The format and interpretation of the mode value are
specific to the link layer in use. Mode information can include such
things as the sender's listening schedule, whether it will poll for
messages, and so forth.
6.3. Timeout
The Timeout TLV (TLV Type 2) has a Value containing a 32-bit unsigned
integer, most significant byte first. The value is 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.
Kelsey Expires December 30, 2012 [Page 8]
Internet-Draft Mesh Link Establishment June 2012
6.4. Challenge
The Challenge TLV (TLV Type 3) has a Value containing a randomly-
chosen byte string that is used to determine the freshness of any
reply to this message. The recommendations in [RFC4086] apply with
regard to generation of the challenge value. A new value MUST be
chose for each Challenge TLV transmitted. 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.
6.5. Response
The Response TLV (TLV Type 4) has a Value containing a byte string
copied from a Challenge TLV.
6.6. Link-layer Frame Counter
The Link-layer Frame Counter TLV (TLV Type 5) has a Value containing
the sender's current outgoing link-layer Frame Counter, encoded as an
N-bit unsigned integer, most significant byte first. The size of the
Frame Counter is determined the link layer in use.
6.7. MLE Frame Counter
The MLE Frame Counter TLV (TLV Type 9) has a Value containing the
sender's current outgoing MLE Frame Counter, encoded as an N-bit
unsigned integer, most significant byte first. The size of the Frame
Counter is determined the security suite in use.
6.8. Link Quality
The Link Quality TLV (TLV Type 6) reports the sender's measured link
quality for messages received from its neighbors. The format of the
Link Quality value is as follows:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| Res | Size | Neighbor Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kelsey Expires December 30, 2012 [Page 9]
Internet-Draft Mesh Link Establishment June 2012
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
only that neighbor's link quality and would have
the C flag of "0".
Res Reserved.
Size The size in bytes of the included neighbor link-
layer addresses, minus 1. This supports
addresses of lengths 1 to 16.
Neighbor Data A sequence of neighbor records, each containing
receive and transmit state flags, the estimated
incoming link reliability (IDR), and the
neighbor's link-layer address.
An MLE message SHOULD NOT contain more than one Link Quality TLV.
The neighbor data in a Link Quality TLV is formatted as follows:
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|P|reserved | Incoming IDR | Neighbor Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I(ncoming) "1" if the sender's Receive State for this
neighbor is true, "0" if not.
O(utgoing) "1" if the sender's Transmit State for this
neighbor is true, "0" if not.
P(riority) "1" if the sender's expects to use this link for
sending messages, "0" if not. Given limited
resources, the P flag MAY be used in deciding
which links should be maintained.
Incoming IDR The estimated inverse delivery ratio of messages
sent by the neighbor to the source of this
message. This is an eight-bit unsigned integer.
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
Kelsey Expires December 30, 2012 [Page 10]
Internet-Draft Mesh Link Establishment June 2012
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.
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 to "1" SHOULD send an MLE message with a Link Quality TLV with
that neighbor's I bit set to "0". This message may either be a
regular multicast Advertisement or a unicast to that neighbor
containing only a single Neighbor Data record.
6.9. Network Parameter
The Parameter TLV (TLV Type 7) specifies the value of a link-layer
parameter shared across the network (as opposed to a parameter
specific to a particular link). The Value contains three fields:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter ID | Delay
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter ID The ID of the parameter to be changed.
Delay The delay before setting the parameter, in
milliseconds. This is a four-byte unsigned
integer, most significant byte first. Having a
delay gives time for the new value to propagate
throughout the network. It may also be used for
limiting the time a particular parameter setting
is in use, by including two different values for
a single parameter, with two different delays.
Value A byte string containing the new value of the
parameter. The format of this value is
determined by the particular parameter
Update messages SHOULD contain only Network Parameter TLVs. Update
messages with new parameter settings SHOULD be multicast to the
entire MLE domain. They MAY also be unicast to nodes that have just
joined the network or otherwise do not have up-to-data parameter
Kelsey Expires December 30, 2012 [Page 11]
Internet-Draft Mesh Link Establishment June 2012
information.
The defined Network Parameters are:
0 Channel
1 PAN ID
2 Permit Joining
3 Beacon Payload
(values to be confirmed by IANA)
6.10. Network Parameter Request
The Parameter Request TLV (TLV Type 9) requests that the recipient
send the current network parameter values to the sender of the
request. This is sent by devices that have just joined a network or
are otherwise unaware of the current network parameter values. It
has no Value.
Kelsey Expires December 30, 2012 [Page 12]
Internet-Draft Mesh Link Establishment June 2012
7. Message transmission
Messages SHOULD be sent using UDP port X (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::1) or all-routers (FF02::2)
multicast addresses. Update messages MAY be sent as above, or MAY be
sent to a site-local all-MLE-nodes multicast address (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). The security
suite identifier is not included in either the authenticated data or
the secured data.
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.
Kelsey Expires December 30, 2012 [Page 13]
Internet-Draft Mesh Link Establishment June 2012
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 December 30, 2012 [Page 14]
Internet-Draft Mesh Link Establishment June 2012
8. Processing of incoming messages
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 Network
Parameter 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 MLE frame counter for
each neighbor. Any MLE message received with a frame 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 counter are available are not discarded and the
counter value SHOULD be saved for comparison with later messages.
Kelsey Expires December 30, 2012 [Page 15]
Internet-Draft Mesh Link Establishment June 2012
9. 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.
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 Link-layer Frame 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 IDR 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.
Kelsey Expires December 30, 2012 [Page 16]
Internet-Draft Mesh Link Establishment June 2012
Update messages may be sent to change the channel, PAN ID, and/or
permit joining flags on all nodes.
Kelsey Expires December 30, 2012 [Page 17]
Internet-Draft Mesh Link Establishment June 2012
10. Acknowledgements
TODO.
Kelsey Expires December 30, 2012 [Page 18]
Internet-Draft Mesh Link Establishment June 2012
11. IANA Considerations
TODO: UDP port
IANA is requested to establish a new top-level registry, called "MLE:
Mesh Link Establishment", to contain all MLE objects, codepoints, and
sub-registries.
The allocation policy for each new registry is by IETF review: new
values are assigned through the IETF review process .
11.1. Security Suites
IANA is requested to create a subregistry, called "Security Suites".
Values range from 0 to 255.
Value Meaning Reference
0 802.15.4 Security This document
255 No Security This document
Values 1-254 are currently unassigned.
11.2. Command Types
IANA is requested to create a subregistry, called "Command Types".
Values range from 0 to 255.
Value Meaning Reference
0 Link Request This document
1 Link Accept This document
2 Link Accept and Request This document
3 Link Reject This document
4 Advertisement This document
5 Update This document
Values 6-255 are currently unassigned.
11.3. TLV Types
IANA is requested to create a subregistry, called "TLV Types".
Values range from 0 to 255.
Kelsey Expires December 30, 2012 [Page 19]
Internet-Draft Mesh Link Establishment June 2012
Value Meaning Reference
0 Source Address This document
1 Mode This document
2 Timeout This document
3 Challenge This document
4 Response This document
5 Link-layer Frame Counter This document
6 Link Quality This document
7 Network Parameter This document
8 Network Parameter Request This document
9 MLE Frame Counter This document
Values 8-255 are currently unassigned.
11.4. Network Parameters
IANA is requested to create a subregistry, called "Network
Parameters". Values range from 0 to 255.
Value Meaning Reference
0 Channel This document
1 PAN ID This document
2 Permit Joining This document
3 Beacon Payload This document
Values 4-255 are currently unassigned.
Kelsey Expires December 30, 2012 [Page 20]
Internet-Draft Mesh Link Establishment June 2012
12. Security Considerations
In general MLE has the strengths and weaknesses of the link layer
security that it inherits. The one exception is that MLE's operation
requires accepting and acting on incoming Advertisements and Link
Requests messages for which the receiver has no prior knowledge of
the sender's MLE frame counter. Because of this, implementers must
be careful in how they use information obtained from these possibly-
replayed messages. For example, information from unsecured messages
should not be used to modify any stored information obtained from
secured messages.
The Hop Limit field of all received packets is verified to contain
255, the maximum legal value. Because routers decrement the Hop
Limit on all packets they forward, received packets containing a Hop
Limit of 255 must have originated from a neighbor. This technique is
borrowed from IPv6 ND [RFC4861].
Kelsey Expires December 30, 2012 [Page 21]
Internet-Draft Mesh Link Establishment June 2012
13. References
13.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.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
13.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.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)",
RFC 6130, April 2011.
[RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D.
Barthel, "Routing Metrics Used for Path Calculation in
Low-Power and Lossy Networks", RFC 6551, March 2012.
Kelsey Expires December 30, 2012 [Page 22]
Internet-Draft Mesh Link Establishment June 2012
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 December 30, 2012 [Page 23]