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]