6tisch                                                         R. Struik
Internet-Draft                               Struik Security Consultancy
Intended status: Informational                           January 9, 2015
Expires: July 13, 2015

              6TiSCH Security Architectural Considerations


   This document describes 6TiSCH security architectural elements with
   high level requirements and the security framework that are relevant
   for the design of the 6TiSCH security solution.

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 July 13, 2015.

Copyright Notice

   Copyright (c) 2015 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
   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.

Struik                    Expires July 13, 2015                 [Page 1]

Internet-Draft       6tisch-security-considerations         January 2015

Table of Contents

   1.  Join Protocol Behavior  . . . . . . . . . . . . . . . . . . .   2
     1.1.  MAC Behavior  . . . . . . . . . . . . . . . . . . . . . .   2
     1.2.  MAC Security Considerations . . . . . . . . . . . . . . .   4
     1.3.  Join Protocol Behavior  . . . . . . . . . . . . . . . . .   7
       1.3.1.  Device Enrollment Phases  . . . . . . . . . . . . . .   7
       1.3.2.  Join protocol description . . . . . . . . . . . . . .   9
       1.3.3.  Remarks . . . . . . . . . . . . . . . . . . . . . . .  12
     1.4.  Routing Behavior  . . . . . . . . . . . . . . . . . . . .  15
   2.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   3.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  15
   4.  Normative References  . . . . . . . . . . . . . . . . . . . .  15
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Join Protocol Behavior

1.1.  MAC Behavior

   1.  The joining node has to transgress from the so-called "embryonic
       stage", where it does not have shared keying material with any
       network nodes yet, to the stage where it has shared keying
       material with the security manager of the network (who hands out
       a network wide key, amongst other things).  In many cases, the
       security manager will be the PAN coordinator.

   2.  Initially, the joining node listens to an enhanced beacon sent by
       its neighbor node.  If this beacon is secured, it can still
       extract the visible portion of the enhanced beacon frame (which
       includes all frame fields before these were secured by the
       neighbor node if the frame was authenticated and which includes
       only the header fields, including potential header information
       elements, otherwise).  With 802.15.4-2011, the passive scan
       procedure supports this (see  In either case, the
       joining node stores the PAN Descriptor.  Note that it cannot rely
       on the authenticity of the PAN Descriptor, since the beacon frame
       is either not secured, or it was secured and the joining node did
       not have a shared key.  Either way, it has to accept the PAN
       Descriptor "on face value".

   3.  The neighbor node, if it operates securely, normally does not
       accept incoming frames from the joining node, since these would
       not be properly secured with the correct keying material.
       However, the 802.15.4 specification allows one exception to this:
       it also accepts incoming messages from specifically identified
       devices that have diplomatic immunity (have so-called "exempt
       status").  This mechanism can be used to facilitate communication
       between a joining node and a neighbor node till they have

Struik                    Expires July 13, 2015                 [Page 2]

Internet-Draft       6tisch-security-considerations         January 2015

       established shared keying material (whereby the joining node can
       emerge out of its initial embryonic stage).  This can be done as

       *  The neighbor node can temporarily give the joining node
          "exempt status", e.g., after failed incoming security
          processing (thereby, allowing subsequent unsecured data frames
          from this joining node to be accepted *from this specific
          device*).  It can also populate the table with exempt devices
          via other means.

       *  The higher layer can switch on/off this "exempt status"
          facility for specific joining nodes based on local criteria
          (one joining node at the time; device open for enrollment of
          devices or not, pre-populated table, etc.)

       *  The higher layer of the neighbor node should ensure that this
          facility is only used for MAC data frames that correspond to
          initial join messages.

       *  The higher layer can use this "exempt status" flag for
          outgoing messages back to the joining node (where this
          indicates "please send message unsecured" (since message to
          newbee joining node with diplomatic immunity status).

   4.  Once the joining node and the neighbor node have established a
       shared key, the neighbor node can lift the diplomatic immunity
       status of the joining node (by removing the "exempt status" flag
       corresponding to this device), after which it may only accept
       incoming messages from the joining node if these are properly
       secured.  Conversely, the joining node can now update its
       security policy settings, after which it may only accept properly
       secured messages received from the neighbor node.  Note that from
       that moment on, the communications between the joining node and
       the neighbor node can all be authenticated, including time
       corrections that are very important for proper operation of TSCH
       (where, e.g., neighbor node is time "clock tower" for joining

   5.  Conceptually, the use of the "exempt flag" could be considered as
       a mechanism for forming a temporary two-node "join network"
       (consisting of the joining node and its neighbor node), in which
       join-related messages are allowed to flow unsecurely.  This does
       not mean, however, that these nodes operate in a separate PAN,
       though, since incoming frame processing relies on filtering on a
       single destination PAN Identifier (see 802.15.4-2011,,
       which implies that the neighbor node can only be part of a single
       PAN (802.15.4-2011 does not know the concept of "multiple PAN

Struik                    Expires July 13, 2015                 [Page 3]

Internet-Draft       6tisch-security-considerations         January 2015

       instances").  This also implies that there is no mechanism within
       802.15.4 to designate frames for "join" purposes or other special
       uses (as Wireless HART seems to do with enhanced beacon frames).
       Of course, there are ways to still artificially realize this,
       e.g., based on context information (overloading semantics of
       schedules) or based on yet-to-be-defined information elements (so
       as to make these act as frame "sub-types"), should one wish to
       emulate this behavior.  Emulating any of this would require
       changes to 802.15.4 security processing.  Currently, there does
       not seem to be a need for this additional complexity.)

1.2.  MAC Security Considerations

   1.  With 802.15.4-2011, incoming security processing requires access
       to device-specific information of the originating device (stored
       on the recipient device in the so-called device descriptor
       table).  This includes the extended address of the originating
       device, the "lowest" unseen frame counter for that device, and
       its "exempt status".  Successful incoming security processing of
       a secured frame results in a state change of this device-specific
       information (since this updates, e.g., the frame counter).

   2.  Successful incoming security processing of a secured or unsecured
       frame may result in other state changes as well if only because
       the device simply "acts" on the received frame or, e.g., due to
       side effects of the successful receipt hereof.  Examples of such
       side effects include actions triggered by information elements
       contained in the received frame, such as time corrections to the
       local clock (which are very important for proper operation of

   3.  802.15.4-2011 uses the AEAD scheme CCM for frame security, where
       the nonce is derived from the frame counter and other
       information.  The security of this scheme (or other nonce-based
       authenticated encryption scheme) is void if nonces are ever
       reused with the same key.  We give an example illustrating how
       nonce reuse breaks confidentiality: one can derive from two
       ciphertexts the xor of the corresponding plaintext (or the
       segment with the size of the shorter ciphertext).  From this
       information and side information on the plaintext (e.g.,
       redundancy), one can often recover both plaintexts (with
       virtually no remaining ambiguity).

   4.  Since successful incoming security processing induces a state
       change, it is imperative that all cryptographic keys used are,
       indeed, real keys.  In particular, this implies that one shall
       never use 802.15.4 with "default" keys (fake keys with an easy to
       guess, low-entropy value).

Struik                    Expires July 13, 2015                 [Page 4]

Internet-Draft       6tisch-security-considerations         January 2015

   5.  If a device wants to communicate with a corresponding party with
       which it does not share cryptographic keying material yet (e.g.,
       because it is a joining node in embryonic stage), it should send
       unsecured frames and *not* frames *obscured* (via security
       through obscurity techniques) using "fake" keys, if only because
       of avoidance of undesirable side effects: if a recipient accepts
       an unsecured frame (e.g, because the originator has "exempt
       status"), this does *not* trigger a state change of security-
       relevant parameters, whereas if a recipient accepts an obscured
       frame (secured using a "fake" key), this *does* trigger a state
       change of security-relevant parameters.

   6.  TSCH security with 802.15.4e-2012 relies on nonces that are
       derived from the absolute slot number (ASN), rather than from the
       frame counter in the device descriptor.  Successul processing of
       a secured incoming frame depends on both originator and recipient
       of the frame having synchronized "world views" of the ASN entry.
       The ASN is also used for communication purposes, since indicates
       scheduling information.  This "mixed" use (both for communication
       and security) is somewhat problematic, since changes to this
       parameter for either use has spill-over effects on the other use:
       any changes to the ASN as a communication parameter now might
       have side effects on security-critical parameters that could,
       worst case, entirely break security; conversely, any changes to
       the ASN as a security parameter, e.g., resulting from its
       inadverent use with a compromised key (or, equivalently, a "fake"
       key), could result in unreliability of this parameter for
       indicating scheduling information.  Impact of ASN manipulation on
       security may include reuse of nonces (resulting in compromise of
       the AEAD cipher's properties), denial-of-service attacks on
       sender or recipient (e.g., due to putting the ASN entry "out-of-
       sync" on either end), or frame counter reuse (since
       802.15.4e-2012 does not inspect the frame counter in the device
       descriptor, but solely relies on the ASN entry).  Thus, ASN
       entries are very fragile and their use should happen with extreme

   7.  As already mentioned, ASN anomalies may seriously impact
       security.  If any device's ASN state is out-of-synch with other
       devices, this may result in that device not being able to
       communicate in the network any more.  With network-wide keys, the
       remedy may include a combination of rekeying all devices (a
       costly proposition) and resetting ASN entries of the impacted

   8.  The security provisions in 802.15.4-2011 and 802.15.4e-2012 leave
       some room for potential Denial of Service (DoS) attacks.  We only
       discuss "accidental" DoS attacks for now, which we define as

Struik                    Expires July 13, 2015                 [Page 5]

Internet-Draft       6tisch-security-considerations         January 2015

       those triggered without active involvement of an adversarial
       network element (active DoS attacks are considered separately).

       *  If a device acts on an incoming frame that is
          cryptographically secured, it has assurances that this frame
          originated from a device with access to the key.  Here,
          processing a frame with a key provides a mechanism for network
          segregation, since proper incoming security processing (and
          assuming non-compromised locally stored security-relevant
          material and processes) allows one to draw conclusions as to
          whether originator and recipient belong to the same "group"
          (the key-sharing group).  This propery holds if the incoming
          frame has an authenticity tag; in some cases, this may also
          hold if the frame was only encrypted, but not authenticated.
          This "network segregation" property holds independent of
          whether the key was actually a real key (cryptographic key);
          the number of groups created depends on the number of these
          group keys (perhaps, more properly termed "group identifiers"
          if of no cryptographic use) used.

       *  A joining node must make its decision to join the network
          based on information derived from processing an enhanced
          beacon.  Since it is in embryonic stage, it has to take this
          information at face value (no matter whether this beacon was
          cryptographically secured or not).  In theory, this may give
          rise to dilemmas of choice, i.e., how is a joining node to
          pick which beacon to act upon?  As already said, one could
          realize network segregation using a "default" key, whereby the
          joining node and the beaconing device would be able to check
          membership of the same loosely defined group (this is the
          mechanism Wireless HART uses).  However, as mentioned before,
          this could potentially adversely impact 802.15.4-2011 and
          802.15.4e-2012 security.  Even if one discards security
          concerns, this only establishes membership of a very crudely
          defined group (e.g., if one uses as "default" key the fixed
          value "6tisch-default-join", this would have any joining node
          accept any 6tisch-beacon).  The same filtering mechanism could
          also, without any possible security side effects, be realized
          by partitioning the "language of well-formed frames" and,
          e.g., filtering enhanced beacons on the data object "6tisch-
          default-join" (e.g., when including this tag as a Header
          Information Element with the beacon).  If one does not use
          such explicit "tags", one could conceivable also accept beacon
          frames that implement an alien protocol, rather than
          802.15.4e-2012.  It is, however, quite unlikely that a random
          alien frame will pass incoming frame filtering, since 802.15.4
          incoming frame processing checks for well-formedness.
          Checking some built-in redundancy of well-formed frames

Struik                    Expires July 13, 2015                 [Page 6]

Internet-Draft       6tisch-security-considerations         January 2015

          thereby most likely filters out virtually all unwanted alien
          frame types.  Such filtering could, e.g., include a "language
          check" as to fixed fields in information elements.  For
          enhanced beacon frames for TSCH, e.g., the header fields of
          the synchronization IE, timeslot IE, and header IE contained
          herein have fixed 2-octet values 0x1a06, 0x1c01, and 0x1d01,
          respectively, thereby providing up to 48 bits of redundancy.
          This provides similar filtering functionality as the explicit
          "6tisch-default-join" tag mentioned before, but without the
          need to introduce an explicit tag or to communicate this
          separately over the air.

       It should be emphasized (again) that none of the mechanisms above
       protects against active attacks.

1.3.  Join Protocol Behavior

1.3.1.  Device Enrollment Phases

   The join protocol consists of three phases, viz.

   1.  Device Authentication: The joining node and proxy network node
       authenticate each other and establish a shared key, so as to
       ensure on-going authenticated communications.  This may involve a
       server as a third party.

   2.  Authorization: The proxy network node decides on whether/how to
       authorize a joining node (if denied, this may result in loss of
       bandwidth).  Authorization decisions may involve other nodes in
       the network.

   3.  Configuration/Parameterization: The proxy network node
       distributes configuration information to the joined node, such as
       scheduling information, IP address assignment information, and
       network policies.  This may originate from other network devices,
       for which it acts as proxy.  This step may also include
       distribution of information from the joining node to the network
       node and other nodes in the network and, more generally,
       synchronization of information between these entities.

   The device enrollment process is depicted in Figure Figure 1, where
   it is assumed that devices have access to certificates and where
   entities have access to the root CA keys of their communicating
   parties (initial set-up requirement).  Under these assumptions, the
   authentication step of the device enrollment process does not require
   online involvement of a third party.  Mutual authentication is
   performed between the joining node and the proxy using their
   certificates, which also results in a shared key between these two

Struik                    Expires July 13, 2015                 [Page 7]

Internet-Draft       6tisch-security-considerations         January 2015

   entities.  The proxy assists the joining node in mutual
   authentication with the server, which also results in a shared (end-
   to-end) key between those two entities.  The server may arbitrage
   network authorization of the joining node (where the proxy will deny
   bandwidth if authorization is not successful) and may distribute
   network-specific configuration parameters (including network-wide
   keys) to the joining node.  In its turn, the joining node may provide
   distribute/synchronize information (including, e.g., network
   statistics) to the server node.

   The server functionality is a role and may be implemented with one
   device (centralized) or with multiple entities (distributed).  In
   either case, mutual authentication is established with each physical
   server entity with which a role is implemented.  Note that in the
   above description, the proxy does not solely act as a relay node.
   For more detailed rationale, see the relevant detailed descriptions
   further in this document.  This also provides some insight into what
   happens in case the initial set-up requirements are not met or some
   other out-of-sync behavior occurs and suggest some optimization in
   case server-related information is already available with the proxy
   node (caching).

   When a device rejoins the network in the same authorization domain,
   the authorization step could be omitted if the server distributes the
   authorization state for the device to the proxys when the device
   initially joined the network.  However, this generally still requires
   the exchange of updated configuration information, e.g., related to
   time schedules and bandwidth allocation.

Struik                    Expires July 13, 2015                 [Page 8]

Internet-Draft       6tisch-security-considerations         January 2015

{joining node}      {neighbor}                 {server, etc.}
+---------+         +---------+                 +---------+
|  Node   |         |  Proxy  |              +--|    CA   |e.g., certificate
|    A    |         |    B    |              |  +---------+       issuance
+---------+         +---------+              |  +---------+
    |                    |                   +--|Authoriz.|e.g., membership
    |<----Beaconing------|                   |  +---------+         test
    |                    |                   |  +---------+
    |<--Authentication-->|                   +--| Routing |e.g., IP address
    |                    |<--Authorization-->|  +---------+       assignment
    |<-------------------|                   |  +---------+
    |                    |                   +--| Gateway |e.g., backbone,
    |------------------->|                   |  +---------+      cloud
    |                    |<--Configuration-->|  +---------+
    |<-------------------|                   +--|Bandwidth|e.g., PCE
                                                +---------+      schedule
    .                    .                   .
    .                    .                   .

     Figure 1: Network joining, with only authorization by third party

1.3.2.  Join protocol description

   NOTE: the description below considers the scenario where devices have
   credentials on board and where the neighbor does not simply act as a
   relay node only.  Other scenarios will be considered in future
   versions of this draft.

   1.   Upon hearing the enhanced beacon, the joining node stores the
        PAN descriptor.

   2.   The joining node uses local criteria, including information
        contained in the PAN desciptor, to determine whether it wishes
        to join the network.

   3.   The joining node sends the first join protocol message to the
        neighbor node.  This message corresponds to one or more
        unsecured MAC data frames.  This message includes the joining
        node's key contribution and credentials.

   4.   The neighbor node processes the incoming join message from the
        joining node and, depending on local criteria (including a check
        that this is a join message), grants the joining node temporary
        diplomatic immunity status ("exempt stauts") from a MAC
        perspective (if not granted, this simply results in a rejected
        incoming frame at the MAC layer).

Struik                    Expires July 13, 2015                 [Page 9]

Internet-Draft       6tisch-security-considerations         January 2015

   5.   The neighbor node performs some checks on the incoming message.
        If successful, it sends a first return join protocol message to
        the joining node.  This message corresponds to one or more
        unsecured MAC data frames.  This message includes the neighbor
        node's key contribution and credentials.  It may also include
        the server's cached first return join protocol message info.  At
        this point, the neighbor node is capable of deriving the shared
        key with the joining node based on inputs received and locally
        maintained status information.

   6.   The joining node performs some checks on the incoming message
        (including that it received this message from the neighbor node
        and that this is a join message).  If succesful, it derives a
        shared key with the neighbor node and may derive a shared key
        with the server (it may also postpone the latter till required
        ["lazy evaluation"]).

   7.   The joining node sends a second join protocol message (a key
        confirmation message) to the neighbor node and may include some
        other information (so-called piggy-backed info).  The piggy-
        backed information includes configuration information to be
        passed from the joining node to the neighbor node.  This message
        corresponds to one or more unsecured MAC data frames.

   8.   The joining node sends a similar second join protocol message
        (another key confirmation message, including piggy-backed
        information) to the server.  The piggy-backed information
        includes configuration information to be passed from the joining
        node to the server that allows the server to check the joining
        node's true credentials and some network-relevant parameters
        (including the ASN number and the joining node's local schedule
        maintained with the neighbor node).  This message corresponds to
        one or more unsecured MAC data frames.  This message may be
        combined with the message sent to the neighor node, since it
        travels along the same initial communication path.

   9.   The neighbor node checks the received second join protocol
        message (the key confirmation message and received piggy-backed
        info), including that this message originated from the same
        device as the previous join protocol message and that this
        message is a join message.  If successful, it clears the "exempt
        status" attribute of the joining node in the DeviceDescriptor
        (thereby, lifting diplomatic immunity status for the joining
        device) and adds the {data key, joining node} pair to its
        KeyDescriptor list.  It also stores policy-related attributes
        for this key.  It may update some additional state, based on the
        piggy-backed info received from the joining device.  The
        clearing of the "exempt status" flag means that it will only

Struik                    Expires July 13, 2015                [Page 10]

Internet-Draft       6tisch-security-considerations         January 2015

        accept incoming secured frames from the joining node from that
        moment onwards.

   10.  The server checks the received second join protocol message (key
        confirmation message and received piggy-backed info).  If
        successful, it adds the {data key, joining node} pair to its
        locally maintained list of end-to-end keying material and
        includes policy-related attributes for this key.  It sends its
        own second return join protocol message (another key
        confirmation message, including piggy-backed configuration
        information) to the joining node.  This is actually sent to the
        neighbor node it received the first join protocol message from,
        who in turn forwards this to the joining node (here, the
        neighbor node acts in storing mode and knows the local network
        topology the server may not know (yet)).  NOTE: this requires
        the neighbor node to remember some information pertaining to the
        joining node (mainly, the {data key, joining node} pair of the
        KeyDescriptor and the local communication schedule with the
        joining node).  This may include an explicit notification to the
        neighbor node that the joining node is authorized to join the
        network.  If so, this authorization part of this message is
        secured, using end-to-end security between the server and the
        neighbor node.

   11.  The neighbor node checks the authorization-related info, if
        indeed contained in this message (if denied, it may clear the
        joining node related info from its tables).  If successful, it
        forwards this information along with its own second return join
        protocol message (key confirmation message and piggy-backed
        info) to the joining node.  Obviously, this can be done
        separately as well, but travels over the same (single hop)
        communication path.

   12.  The joining node checks the received second join protocol
        message (the key confirmation and piggy-backed info) from its
        neighbor node.  If successful, it adds the {data key, neighbor
        node} pair to its KeyDescriptor list.  It also stores policy-
        related attributes for this key.  If not successful, it clears
        its local table with info pertaining to the neighbor node.

   13.  The joining node checks the received second join protocol
        message (the key confirmation and piggy-backed info) from the
        server.  If successful, it adds the {data key, server node} pair
        to its locally maintained list of end-to-end keying material and
        includes policy-related attributes for this.  It may also update
        its local state, based on information contained in the piggy-
        backed info received from the server.  Updates of local state
        may be subject to additional local criteria, such as consistency

Struik                    Expires July 13, 2015                [Page 11]

Internet-Draft       6tisch-security-considerations         January 2015

        of status information obtained from neighbor node and server
        node (e.g., pertaining to the ASN field, PAN identifier, or
        scheduling information).  This may give rise to triggered
        alerts.  If not successful, it clears its local table with info
        pertaining to the server node.  Depending on local criteria, it
        may clear the table with info pertaining to the neighbor node.

1.3.3.  Remarks

   1.   The join protocol above can be optimized in various ways,
        including first handling mutual authentication of local
        communication channels, prior to engaging in non-local
        communications so as to reduce time latencies in case of failure
        conditions.  This is realized by having the neighbor node
        authenticate itself to the joining node before initiating non-
        local communications from the joining node to the server node
        along the communication path via the neighbor node (rather than
        at the end of this non-local communications).  Since 10-hop
        communications may take roughly 2.5 minutes on a TSCH network
        and local communication time latencies take roughly 15 seconds,
        this could present a significant time saving (and reduced
        requirement on keeping state and energy consumption on the
        joining device).

   2.   The join protocol above takes only one non-local communication
        between the neighbor node and the server node.  This assumes
        that the neighbor node is able to cache security-related
        information from the server.  Since this includes certificate-
        related information of the server node (which may require more
        than one classical 802.15.4 MAC frame to carry), this may
        present significant communication time latency savings.
        Obviously, an additional long-haul round trip may be required
        should this cached information be stale (keeping this
        information in sync is a responsibility of the neighbor node).
        With caching, this turns the join protocol described above into
        the most efficient possible, in terms of communication time
        latencies involved.  At the same time, this protocol has very
        strong security properties, unmatched by legacy protocols [...].

   3.   The join protocol above assumes authentication of the joining
        node to the neighbor node, before non-local traffic takes place.
        This assists in thwarting denial-of-service attacks on "das
        Hinterland" of the neighbor node triggered by joining nodes with
        improper credentials (unparsable certs).  While this check is an
        authentication check only and *not* a fine-grained authorization
        check, this could be complemented by additional local "sanity
        checks" on the neighbor node (device white listing, etc.), thus
        allowing extensibility to more fine-grained authorization

Struik                    Expires July 13, 2015                [Page 12]

Internet-Draft       6tisch-security-considerations         January 2015

        filtering mechanisms.  (Further details are outside scope of
        this document, but may be described later.)

   4.   The join protocol above assumes authentication of the neighbor
        node to the joining node (i.e., the neighbor node is not simply
        a relay node).  This potentially assists in thwarting denial of
        service attacks on the joining node itself, primarily since it
        may allow the joining node to conclude it joined an improper
        network based on local communications only (if the neighbor node
        presented an unparsable cert or did not properly authenticate),
        rather than having to await a nonlocal verdict via the server
        that may take a long time to materialize.  Here, again, more
        fine-grained authorization checks may be realized in scenarios
        where the joining node has more local intelligence to draw from.
        (Again, further details are outside scope of this document for

   5.   The join protocol above includes mutual authentication between
        the joining node and the neighbor node and establishment of a
        shared "link key" (to use 802.15.4 parlance) between these two
        devices.  This may be useful in case one wishes to trigger time
        synchronization between the joining node and the neighbor node
        contingent on frames secured using this pair-wise key only.
        This would strengthen TSCH security compared to that provided by
        the current 802.15.4e-2012 specification (which allows time
        synchronization to be also triggered by frames secured using a
        network-wide key, thereby opening the network to attacks by a
        single random compromised node, rather than a specific
        compromised node [the "clock tower" node] only.)

   6.   The join protocol above can also be "weakened", e.g., by
        removing authentication of the neighbor node to the joining node
        or vice-versa.  As already said, this might open the protocol to
        wide-spread denial of service attacks on the network (in case
        the neighbor node simply forwards any joining node traffic,
        without inspection) or denial of service attacks on the joining
        node (in case the neighbor node is a bogus node or a node of an
        alien network).  In some settings, though, practical trade-offs
        may favor such a "weakened" approach, e.g., if one wishes to
        "sprinkle" in sufficiently many neighbor nodes to guarantee
        connectivity to the server during initial deployment.  If so,
        one should still have a fall-back strategy in place should
        denial of service attacks become a reality.  (NOTE: These
        "weakened" versions will be analyzed in more detail in a later
        version of this draft.)

   7.   The join protocol above does not impose requirements on the
        security of the communication path between the neighbor node and

Struik                    Expires July 13, 2015                [Page 13]

Internet-Draft       6tisch-security-considerations         January 2015

        the server, except that "it should be there" (i.e., there is
        connectivity) although there may be additional requirements to
        counter, e.g., denial of service attacks on communications
        between neighbor node and server.  (An exception here is if the
        server returns authorization-related information to the neighbor
        node [which we required to be secured], but which we will ignore
        for now.)  Such minimization of dependencies between the join
        protocol and the routing protocol may be beneficial for use
        cases where one wishes to facilitate "random" installation
        process flows.  Obviously, once a node is part of the network,
        it should be able to route packets (but that is not part of the
        join protocol itself, but next-stage phase).

   8.   The join protocol above tries to embrace a design where the
        order of joining would be mostly orthogonal to routing protocol
        topology considerations, if it all possible.  In particular, it
        is aimed to take into account that not all installations follow
        the pattern where one has an operational network and where all
        non-local communications during the join protocol not of the
        type {joining node - neighbor router} are within the operational
        network (i.e., one would like to facilitate scenarios other than
        a tree-like structure, where network is built from tree root up
        onwards [this is highly relevant in building control settings]).

   9.   The join protocol above exchanges piggy-backed information
        between joining node, neighbor node, and server.  This
        conceptually would allow very agressive implementations of the
        routing protocol, where one intertwines routing and join
        processes, by including some of the routing-related attributes
        as opaque strings in the piggy-backed fields.  It should be
        noted that the join protocol already supports the routing tree
        of the existing network and the "new tree branch" {joining node
        - neighbor node}, so all "upwards routes" to the pre-existing
        tree roots are inherited right away.  The only routes that may
        need defining are those towards the newbee joining node.  For
        reliability reasons, this does require the joining node to have
        successfully concluded the join protocol first.  As such, there
        seems to be no technical reason to intertwine these protocols:
        one should simply perform routing-related operations only
        *after* the join protocol ran its full course.

   10.  The join protocol above allows the neighbor node to influence
        with which server the joining node communicates, thus allowing a
        distributed implementation of the server.

   11.  The join protocol above assumes that the server arbitrages the
        correct value of supposedly common network parameters, such as
        the PAN identifier and ASN field.  Here, one should note that

Struik                    Expires July 13, 2015                [Page 14]

Internet-Draft       6tisch-security-considerations         January 2015

        the neighbor node can indicate, e.g., any PAN identifier and any
        ASN entry to its liking in its beacon, which does not
        necessarily correspond to the "common world view" hereof by the

   12.  The join protocol above could in theory result in a node joining
        the network only locally (i.e., forming a two-node network with
        the neighbor node only), without the server or any other nodes
        becoming aware of this.  This scenario could arrise if the
        joining node is unaware of some server-related context
        information and if the neighbor node simply usurps the server
        role itself.  The impact of this "hidden node" type scenario
        depends on higher-layer, end-to-end design details.  From a MAC
        perspective, this could simply mean that the two-node {joining
        node, neighbor node} network is conceptually represented by this
        neighbor node, where the internal structure of this two-node
        network remains hidden for other nodes.

1.4.  Routing Behavior


2.  IANA Considerations

   There is no IANA action required for this document.

3.  Acknowledgments

   TBD.  Kris Pister provided the filtering example details for enhanced
   beacon frames.  Yoshi Ohba, Subir Das, Giuseppe Piro, Pascal Thubert,
   and Kris Pister kindly provided feeback on previous versions of this

4.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

              Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
              "Terminology in IPv6 over the TSCH mode of IEEE
              802.15.4e", draft-ietf-6tisch-terminology-02 (work in
              progress), July 2014.

Struik                    Expires July 13, 2015                [Page 15]

Internet-Draft       6tisch-security-considerations         January 2015

Author's Address

   Rene Struik
   Struik Security Consultancy

   Email: rstruik.ext@gmail.com

Struik                    Expires July 13, 2015                [Page 16]