One document matched: draft-kelsey-intarea-mesh-link-establishment-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3315 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="no" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-kelsey-intarea-mesh-link-establishment-01" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Mesh Link Establishment">Mesh Link Establishment</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Richard Kelsey" initials="R.K." surname="Kelsey">
<organization>Ember Corporation</organization>
<address>
<postal>
<street>25 Thomson Place</street>
<city>Boston</city>
<region>Massachusetts</region>
<code>02210</code>
<country>USA</country>
</postal>
<phone>+1 617 951 1225</phone>
<email>richard.kelsey@ember.com</email>
</address>
</author>
<date year="2012" />
<area>Internet Area</area>
<workgroup>Internet Area WG</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
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.
<!-- *** NUD and link timeout? *** -->
</t>
</abstract>
</front>
<!-- ================================================================ -->
<middle>
<section title="Introduction">
<t>
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.
<!-- *** NUD and link timeout, sleepies? *** -->
</t><t>
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.
</t><t>
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.
</t><t>
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.
</t>
<!-- *** 802.15.4? *** -->
<section title="Requirements Language">
<t>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 <xref target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section title="Terminology">
<t>
<list style="hanging" hangIndent="20">
<t hangText="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.
</t>
<t hangText="Frame counter">A value that is incremented
with each new secured message. Used with <xref target="CCM"></xref>
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.
</t>
<t hangText="Global configuration"> Configuration values
and messages that apply across a network. Global
configuration message are multicast messages forwarded
across multiple hops.
</t>
<t hangText="IDR"> Inverse Delivery Ration; the number
of transmission attempts divided by the number of
successful transmissions in a given direction over a link.
</t>
<t hangText="Local configuration"> Configuration values
and messages that apply only to a single hop. Local
configuration message are sent using link-local messages
and are not forwarded.
</t>
<t hangText="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. </t>
</list>
</t>
</section>
<section title="Overview">
<t>
MLE is a means of transmitting link configuration values.
An MLE message is one of:
<list style="hanging" hangIndent="20">
<t hangText="Link configuration">
A one-hop unicast sent as part of establishing a link with one
particular neighbor.</t>
<t hangText="Advertisement"> A one-hop multicast that
advertise a node's link quality estimates to its neighbors.</t>
<t hangText="Update">
A network-wide multicast that updates a shared configuration
value.</t>
</list>
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).
</t>
</section>
<section title="Message Formats">
<t>
MLE messages consist of a command and a series of type-length-value
parameters.
Unicast and advertisement messages, but not updates, can be secured
using
Advanced Encryption Standard 128
<xref target="AES"></xref> in Counter with CBC-MAC Mode
<xref target="CCM"></xref>
for data authentication and
encryption.
Updates are only sent over already-configured links and are
assumed to be secured using normal link-layer security
</t><t>
The security data is formatted as an auxiliary security header
as specified in <xref target="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 <xref target="IEEE802154"/>.
</t><t>
If MLE security is in use each device MUST maintain an
outgoing frame/replay counter for use in securing outgoing packets
in compliance with <xref target="CCM"></xref>.
MLE does not include a method for configuring its own frame
counters and so does not provide complete protection against
replayed MLE packets.
</t><t>
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.
</t>
<figure align="center">
<artwork align="center"><![CDATA[
<message> := <security-data>
<command-id>
<tlv>*
<mic>?
<security-data> := <security-control-field>
<frame-counter>?
<key-identifier>?
]]>
</artwork>
</figure>
<t>
The defined command IDs are:
<list style="hanging" hangIndent="5">
<t hangText="0">Link Request. A request to establish a
link to a neighbor. </t>
<t hangText="1">Link Accept. Accept a requested link.</t>
<t hangText="2">Link Accept and Request. Accept a requested
link and request initialization in the other direction. </t>
<t hangText="3">Link Reject. Reject a link request. </t>
<t hangText="4">Advertisement. Inform neighbors of
a device's link state.</t>
<t hangText="4">Update. Informs of changes to link parameters
shared by all nodes in a network.</t>
</list>
(values to be confirmed by IANA)
</t>
</section>
<section title="Values">
<t>
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.
<figure align="center">
<artwork align="center"><![CDATA[
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
</t>
<section title="Source Address">
<t>
<figure align="center">
<artwork align="center"><![CDATA[
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<list style="hanging" hangIndent="20">
<t hangText="Length">Length of the Address field
in octets.</t>
<t hangText="Source Address">A link-layer address assigned
to the source of the message.</t>
</list>
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.
</t>
</section>
<section title="Mode">
<t>
<figure align="center">
<artwork align="center"><![CDATA[
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<list style="hanging" hangIndent="20">
<t hangText="Length">Length of the Mode field
in octets.</t>
<t hangText="Mode">Mode configuration of this link.
The possible values are specific to the link layer in use.</t>
</list>
Mode information can include such things as the senders
listening schedule, whether it will poll for messages,
and so forth.
</t>
</section>
<section title="Timeout">
<t>
<figure align="center">
<artwork align="center"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<list style="hanging" hangIndent="20">
<t hangText="Length">4</t>
<t hangText="Timeout">The expected maximum interval between
transmissions by the sender in seconds.</t>
</list>
This allows the receiver to more accurately timeout a
link to a neighbor that polls for its incoming messages.
</t>
</section>
<section title="Challenge">
<t>
<figure align="center">
<artwork align="center"><![CDATA[
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<list style="hanging" hangIndent="20">
<t hangText="Length">Length of the Challenge field
in octets.</t>
<t hangText="Challenge">A random value used to determine
the freshness of any reply to this message.</t>
</list>
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.
</t>
</section>
<section title="Response">
<t>
<figure align="center">
<artwork align="center"><![CDATA[
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<list style="hanging" hangIndent="20">
<t hangText="Length">Length of the Response field
in octets.</t>
<t hangText="Response">The challenge value echoed back
to the original sender (in network order).
</t>
</list>
</t>
</section>
<section title="Replay Counter">
<t>
<figure align="center">
<artwork align="center"><![CDATA[
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<list style="hanging" hangIndent="20">
<t hangText="Length">Length of the Replay Counter field
in octets.</t>
<t hangText="Response">The sender's current outgoing
link-layer Replay Counter.
</t>
</list>
</t>
</section>
<section title="Link Quality">
<t>
<figure align="center">
<artwork align="center"><![CDATA[
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<list style="hanging" hangIndent="20">
<t hangText="Length">Length of following values
in octets (1 + (size + 3) * number-of-neighbors).</t>
<t hangText="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 not have the C flag set.
</t>
<t hangText="Res">Reserved.</t>
<t hangText="Size">The size in octets of the included
neighbor addresses, minus 1. This supports addresses
of lengths 1 to 16.</t>
<t hangText="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.</t>
</list>
<figure align="center">
<artwork align="center"><![CDATA[
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<list style="hanging" hangIndent="20">
<t hangText="I(ncoming)">Set if the sender has
configured its link with this neighbor and will
accept incoming messages from them.
</t>
<t hangText="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.
</t>
<t hangText="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.
</t>
<t hangText="Address">A link-layer address of a neighbor.</t>
</list>
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.
</t>
<t>
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.
</t>
</section>
<section title="Param">
<t>
<figure align="center">
<artwork align="center"><![CDATA[
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<list style="hanging" hangIndent="20">
<t hangText="Length">Length of the Value field in octets
plus 5.</t>
<t hangText="Parameter ID">The ID of the parameter to
be changed.</t>
<t hangText="Delay">The delay before setting
the parameter, in milliseconds. This gives time for
the Update message carrying the Param TLV to propagate
throughout the network.</t>
<t hangText="Value">The new value of the parameter.</t>
</list>
</t><t>
Update messages SHOULD contain only Param TLVs.
</t><t>
The defined Parameter IDs are:
<list style="hanging" hangIndent="5">
<t hangText="0">Channel</t>
<t hangText="1">PAN ID</t>
<t hangText="2">Permit Joining</t>
</list>
(values to be confirmed by IANA)
</t>
</section>
</section>
<section title="Message transmission">
<t>
Messages SHOULD be sent using UDP port XXXX
(value to be assigned by IANA).
Update messages SHOULD be sent to the
site-local all-routers multicast address (FF05::2).
Link configuration and advertisement messages MUST be sent with
an IP Hop Limit of 255.
</t><t>
Outgoing link configuration and advertisements messages
SHOULD be secured using the
procedure specified in <xref target="AES"></xref> and
<xref target="CCM"></xref> using the auxiliary security
header as described in <xref target="IEEE802154"/>.
Key choice is outside the scope of this document.
<!-- *** layering issues? *** -->
The authenticated data consists of
the following three values concatenated together:
<figure align="center">
<artwork align="center"><![CDATA[
IP source address
IP destination address
auxiliary security header
]]>
</artwork>
</figure>
The secured data consists of the messages body following the
auxiliary security header (the command ID and TLVs).
</t><t>
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.
<list style="hanging" hangIndent="5">
<t hangText="MAX_RESPONSE_DELAY_TIME"> 1 second </t>
</list>
</t><t>
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 <xref target="RFC3315">RFC 3315</xref>,
simplified to use a single, fixed timeout.
</t><t>
<figure align="left">
<artwork align="left"><![CDATA[
Parameter Default Description
-------------------------------------------------------
URT 1 sec Unicast Retransmission timeout.
MRT 5 sec Multicast Retransmission timeout.
MRC 3 Maximum retransmission count.
]]>
</artwork>
</figure>
</t><t>
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.
</t>
</section>
<section title="Processing of incoming messages">
<t>
Any incoming link configuration or advertisement message whose IP Hop Limit is not 255
may have been forwarded by a router and MUST be discarded.
</t><t>
Incoming update messages that contain TLVs other than Param
TLVs SHOULD be ignored.
</t><t>
Unsecured incoming link configuration and advertisement
messages SHOULD be ignored.
Secured incoming messages are decrypted and authenticated using the
procedures specified in <xref target="AES"></xref> and
<xref target="CCM"></xref>, with security material obtained
from the auxiliary security header as described in
<xref target="IEEE802154"/>.
The key source may be obtained either from the link layer source
address or from the auxiliary security header.
</t><t>
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.
</t>
</section>
<section title="Application to 802.15.4">
<t>
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:
<list style="symbols">
<t> Long (64-bit) and short (16-bit) addresses. </t>
<t> Capability data byte, especially the Device Type
and Receiver On When Idle fields. </t>
<t> Initialization of AES-CCM frame counters (which are
also used as replay counters). </t>
</list>
A device wishing to establish a link to a neighbor would
send a Link Request message containing the following:
<list style="symbols">
<t> 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.</t>
<t> Mode TLV, containing the sender's Capability data byte. </t>
<t> Timeout TLV, if the sender is an rxOffWhenIdle device. </t>
<t> Challenge TLV, whose size is determined by the network
configuration.</t>
</list>
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.
</t><t>
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.
</t><t>
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.
</t><t>
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.
</t><t>
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.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>TODO.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>TODO: UDP port and registries for the
command, TLV, and Parameter ID identifiers.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
IN PROGRESS
</t><t>
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.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
<reference anchor="CCM">
<front>
<title>Recommendation for
Block Cipher Modes of
Operation: The CCM Mode for
Authentication and
Confidentiality
</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="May" year="2004"></date>
</front>
<seriesInfo name="SP" value="800-38C"></seriesInfo>
</reference>
<reference anchor="AES">
<front>
<title>Specification for the Advanced Encryption Standard (AES)</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="November" year="2001"></date>
</front>
<seriesInfo name="FIPS" value="197"></seriesInfo>
</reference>
<reference anchor="IEEE802154">
<front>
<title>Wireless Personal Area Networks</title>
<author>
<organization>Institute of Electrical and Electronics Engineers</organization>
</author>
<date year="2006"></date>
</front>
<seriesInfo name="IEEE Standard" value="802.15.4-2006"></seriesInfo>
</reference>
</references>
<references title="Informative References">
&RFC3315;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 05:23:00 |