[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06

Internet Area WG                                               R. Kelsey
Internet-Draft                                         Ember Corporation
Intended status: Standards Track                            May 17, 2012
Expires: November 18, 2012


                        Mesh Link Establishment
            draft-kelsey-intarea-mesh-link-establishment-03

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 November 18, 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 November 18, 2012               [Page 1]


Internet-Draft           Mesh Link Establishment                May 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.  Replay Counter . . . . . . . . . . . . . . . . . . . . . .  9
     6.7.  Link Quality . . . . . . . . . . . . . . . . . . . . . . .  9
     6.8.  Network Parameter  . . . . . . . . . . . . . . . . . . . . 11
   7.  Message transmission . . . . . . . . . . . . . . . . . . . . . 12
   8.  Processing of incoming messages  . . . . . . . . . . . . . . . 14
   9.  Application to 802.15.4  . . . . . . . . . . . . . . . . . . . 15
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
     11.1. Security Suites  . . . . . . . . . . . . . . . . . . . . . 18
     11.2. Command Types  . . . . . . . . . . . . . . . . . . . . . . 18
     11.3. TLV Types  . . . . . . . . . . . . . . . . . . . . . . . . 18
     11.4. Network Parameters . . . . . . . . . . . . . . . . . . . . 19
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 21
     13.2. Informative References . . . . . . . . . . . . . . . . . . 21
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22











Kelsey                  Expires November 18, 2012               [Page 2]


Internet-Draft           Mesh Link Establishment                May 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 November 18, 2012               [Page 3]


Internet-Draft           Mesh Link Establishment                May 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.  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 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.

   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 November 18, 2012               [Page 4]


Internet-Draft           Mesh Link Establishment                May 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              A multicast that updates a shared configuration
                       value.

   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 (replay 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 November 18, 2012               [Page 5]


Internet-Draft           Mesh Link Establishment                May 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
   frame/replay counter for use in securing outgoing packets in
   compliance with [CCM].  MLE does not include a method for configuring
   its own frame counters and so does not provide complete protection
   against replayed MLE packets.

   MLE security MUST NOT use any key that is being used by the link (or
   any other) layer.  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 November 18, 2012               [Page 6]


Internet-Draft           Mesh Link Establishment                May 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 November 18, 2012               [Page 7]


Internet-Draft           Mesh Link Establishment                May 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 November 18, 2012               [Page 8]


Internet-Draft           Mesh Link Establishment                May 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.  Replay Counter

   The Replay Counter TLV (TLV Type 5) has a Value containing the
   sender's current outgoing link-layer Replay Counter, encoded as an
   N-bit unsigned integer, most significant byte first.  The size of the
   Replay Counter is determined the link layer in use.

6.7.  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 ...
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   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".







Kelsey                  Expires November 18, 2012               [Page 9]


Internet-Draft           Mesh Link Establishment                May 2012


   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.

   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| 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.

   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
                       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.





Kelsey                  Expires November 18, 2012              [Page 10]


Internet-Draft           Mesh Link Establishment                May 2012


6.8.  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.

   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.

   The defined Network Parameters are:

   0    Channel

   1    PAN ID

   2    Permit Joining

   3    Beacon Payload

   (values to be confirmed by IANA)











Kelsey                  Expires November 18, 2012              [Page 11]


Internet-Draft           Mesh Link Establishment                May 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).

   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



Kelsey                  Expires November 18, 2012              [Page 12]


Internet-Draft           Mesh Link Establishment                May 2012


   1.1.  The randomization factor is included to minimize
   synchronization of messages transmitted.

















































Kelsey                  Expires November 18, 2012              [Page 13]


Internet-Draft           Mesh Link Establishment                May 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 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 November 18, 2012              [Page 14]


Internet-Draft           Mesh Link Establishment                May 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 (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.

   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 November 18, 2012              [Page 15]


Internet-Draft           Mesh Link Establishment                May 2012


   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 the 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.













































Kelsey                  Expires November 18, 2012              [Page 16]


Internet-Draft           Mesh Link Establishment                May 2012


10.  Acknowledgements

   TODO.
















































Kelsey                  Expires November 18, 2012              [Page 17]


Internet-Draft           Mesh Link Establishment                May 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 November 18, 2012              [Page 18]


Internet-Draft           Mesh Link Establishment                May 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      Replay Counter                This document
        6      Link Quality                  This document
        7      Network Parameter             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 November 18, 2012              [Page 19]


Internet-Draft           Mesh Link Establishment                May 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 replay counter.  In other words, MLE lacks the
   security configuration that it provides for link-layer security.
   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 November 18, 2012              [Page 20]


Internet-Draft           Mesh Link Establishment                May 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 November 18, 2012              [Page 21]


Internet-Draft           Mesh Link Establishment                May 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 November 18, 2012              [Page 22]


Html markup produced by rfcmarkup 1.122, available from https://tools.ietf.org/tools/rfcmarkup/