Internet DRAFT - draft-richardson-6tisch--security-6top
draft-richardson-6tisch--security-6top
Network Working Group M. Richardson
Internet-Draft SSW
Intended status: Informational November 20, 2015
Expires: May 23, 2016
6tisch secure join using 6top
draft-richardson-6tisch--security-6top-05
Abstract
This document details a security architecture that permits a new
6tisch compliant node to join an 802.15.4e network. The process
bootstraps the new node authenticating the node to the network, and
the network to the node, and configuring the new node with the
required 6tisch schedule. Any resemblance to WirelessHART/IEC62591
is entirely intentional.
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 RFC
2119 [RFC2119].
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 May 23, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
Richardson Expires May 23, 2016 [Page 1]
Internet-Draft 6tisch-6top November 2015
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Roles . . . . . . . . . . . . . . . . . . . . 4
3. Architectural requirements of join protocol . . . . . . . . . 6
3.1. Entities involves in the join processions . . . . . . . . 6
3.2. Join Protocol deliverables . . . . . . . . . . . . . . . 6
3.3. Join Protocol connection setup . . . . . . . . . . . . . 7
3.4. End to End considerations for Join Protocol . . . . . . . 8
3.4.1. Security Considerations: alternatives to source
routes . . . . . . . . . . . . . . . . . . . . . . . 9
3.5. Join node discovery mechanism . . . . . . . . . . . . . . 10
3.5.1. prefixes to use for join traffic . . . . . . . . . . 11
4. security requirements . . . . . . . . . . . . . . . . . . . . 12
4.1. threat model . . . . . . . . . . . . . . . . . . . . . . 12
4.1.1. threats to the joining node . . . . . . . . . . . . . 12
4.1.2. threats to the resources of the network . . . . . . . 13
4.1.3. threats to other joining nodes . . . . . . . . . . . 13
4.2. implementation cost . . . . . . . . . . . . . . . . . . . 14
4.3. denial of service . . . . . . . . . . . . . . . . . . . . 14
5. protocol requirements/constraints/assumptions . . . . . . . . 14
5.1. inline/offline . . . . . . . . . . . . . . . . . . . . . 14
6. time sequence diagram . . . . . . . . . . . . . . . . . . . . 14
6.1. explanation of each step . . . . . . . . . . . . . . . . 15
6.1.1. step (1): enhanced beacon . . . . . . . . . . . . . . 16
6.1.2. step (1B): send router solicitation . . . . . . . . . 16
6.1.3. step (1C): receive router advertisement . . . . . . . 16
6.1.4. step (2): certificate cache load . . . . . . . . . . 16
6.1.5. step (3): receive certificate cache . . . . . . . . . 16
6.1.6. step (4): join request . . . . . . . . . . . . . . . 17
6.1.7. step (5): NS duplicate address request (DAR) . . . . 17
6.1.8. step (7): 6LBR informs JCE of new node . . . . . . . 17
6.1.9. step (8): JCE informs/acks to 6LBR of new node . . . 17
6.1.10. step (9): NS duplicate address confirmation (DAC) . . 17
6.1.11. step (10): JCE initiates connection to joining node . 17
6.1.12. step (11): Join Assistant forwards packet to joining
node . . . . . . . . . . . . . . . . . . . . . . . . 17
Richardson Expires May 23, 2016 [Page 2]
Internet-Draft 6tisch-6top November 2015
6.1.13. step (12): Joining node replies . . . . . . . . . . . 17
6.1.14. step (13): Join Assistant forwards reply to JCE . . . 17
6.2. size of each packet . . . . . . . . . . . . . . . . . . . 18
7. resulting security properties obtained from this process . . 18
8. deployment scenarios underlying protocol requirements . . . . 18
9. device identification . . . . . . . . . . . . . . . . . . . . 18
9.1. PCE/Proxy vs Node identification . . . . . . . . . . . . 18
9.2. Time source authentication / time validation . . . . . . 18
9.3. description of certificate contents . . . . . . . . . . . 18
9.4. privacy aspects . . . . . . . . . . . . . . . . . . . . . 18
10. slotframes to be used during join . . . . . . . . . . . . . . 19
11. configuration aspects . . . . . . . . . . . . . . . . . . . . 19
12. authorization aspects . . . . . . . . . . . . . . . . . . . . 19
12.1. how to determine a proxy/PCE from a end node . . . . . . 19
12.2. security considerations . . . . . . . . . . . . . . . . 19
13. security architecture . . . . . . . . . . . . . . . . . . . . 19
14. Posture Maintenance . . . . . . . . . . . . . . . . . . . . . 19
15. Security Considerations . . . . . . . . . . . . . . . . . . . 19
16. Other Related Protocols . . . . . . . . . . . . . . . . . . . 19
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
19.1. Normative references . . . . . . . . . . . . . . . . . . 19
19.2. Informative references . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction
A challenging part with constructing an LLN with nodes from multiple
vendors is providing enough security context to each node such that
the network communication can form and remain secure. Most LLNs are
small and have no operator interfaces at all, and even if they have
debug interfaces (such as JTAG) with personnel trained to use that,
doing any kind of interaction involving electrical connections in a
dirty environment such as a factory or refinery is hopeless.
It is necessary to have a way to introduce new nodes into a 6tisch
network that does not involve any direct manipulation of the nodes
themselves. This act has been called "zero-touch" provisioning, and
it does not occur by chance, but requires coordination between the
manufacturer of the node, the service operator running the LLN, and
the installers actually taking the devices out of the shipping boxes.
1.1. Assumptions
For the process described in this document to work, some assumptions
about available infrastructure are made. These are perhaps more than
assumptions, but rather architectural requirements; the exact
Richardson Expires May 23, 2016 [Page 3]
Internet-Draft 6tisch-6top November 2015
operation of said infrastructure to be defined in a subsequent
document.
In the diagrams and text that follows entities are named (and defined
in the terminology section). Unless otherwise stated these are
roles, not actual machines/systems. The roles are seperated by
network protocols in order that they roles can be performed by
different systems, not because they have to be. Different
deployments will have different scaling requirements for those
entities. Smaller deployments might co-located many roles together
into a single ruggedized platform, while other deployments might
operate all of the roles on distinct, multiply-redundant server
classes located in a fully equipped datacentre.
2. Terminology and Roles
Most terminology should be taken from [I-D.ietf-6tisch-architecture]
and from [I-D.ietf-6tisch-6top-interface] and
[I-D.wang-6tisch-6top-sublayer]. As well, many terms are taken from
[RFC6775].
The following roles/things are defined:
PCE the Path Computation Engine. This entity reaches
out to each of the nodes in the LLN, and
configures an appropriate schedule using 6top.
Authz Server/ACE the Authorization Server. This offloads
calculation of access control lists and other
access control decisions for constrainted nodes.
See [I-D.seitz-ace-problem-description]
6top the 6top protocol is defined abstractly in
[I-D.ietf-6tisch-6top-interface] and mapped to
run over CoAP in [I-D.ietf-6tisch-coap]. The
6top protocol is defined primarily to provision
the 6TiSCH schedule; this document proposes to
extend it for also provisioning of layer-2
security parameters.
JCE the Join Coordination Entity. This acronym is
chosen to parallel the PCE.
joining node The newly unboxed constrained node that needs to
join a network.
join protocol the protocol which secures initial communication
between the joining node and the JCE
Richardson Expires May 23, 2016 [Page 4]
Internet-Draft 6tisch-6top November 2015
join assistant A constrained node near the joining node that
will act as it's first 6LR, and will relay
traffic to/from the joining node.
unique join key a key shared between a newly joining node, and
the JCE. This key supports smaller installations
for which asymmetric methods are considered too
large
production network A 802.15.4e network whose encryption/
authentication keys are determined by some
algorithm/protocol. There may have network-wide
group keys, or per-link keys.
production network key A L2-key known by all authorized nodes, used
for multicast messages
per-peer L2 key a key that results from an exchange (such as MLE)
that creates a pair-wise L2 key which is known
only to the two nodes involved,
[I-D.piro-6tisch-security-issues] calls this a
LinkKey
The following terms are used in this document and come from other
documents:
DevID [IEEE.802.1AR] defines the secure DEVice
IDentifier as a device identifier that is
cryptographically bound to the device and is
composed of the Secure Device Identifier Secret
and the Secure Device Identifier Credential.
IDevID The Initial secure DEVice IDentifier (IDevID) is
the Device Identifier which was installed on the
device by the manufacturer.
LDevID A Locally significant secure DEVice IDentifiers
(LDevIDs) is a Secure Device Identifier
credential that is unique in the local
administrative domain in which the device is
used. The LDevID is usually a new certificate
provisioned by some local means, such as the 6top
mechanism defined in this document.
CoAP The CoAP protocol, defined in [RFC7252] is an
HTTP-like resource access protocol. CoAP runs
over UDP.
Richardson Expires May 23, 2016 [Page 5]
Internet-Draft 6tisch-6top November 2015
DTLS The datagram version of TLS, defined in
[RFC6347], and which can be used to secure CoAP
in the same way that TLS secures HTTP.
ARO [RFC6775]defines a number of new Neighbor
Discovery options including the Address
Registration Option
DAR/DAC [RFC6775]defines the Duplicate Address Request
and Duplicate Address Confirmation options to
turn the multicasted Duplicate Address Detection
protocol into a client/server process
EARO [I-D.thubert-6lo-rfc6775-update-reqs]extends the
ARO option to include some additional fields
necessary to distinguish duplicate addresses from
nodes that have moved networks when there are
mulitple LLNs linked over a backbone.
3. Architectural requirements of join protocol
3.1. Entities involves in the join processions
The following actors are involved: there is a new joining node. It
is (radio) adjacent to the join assistant. The join assistant is
part of the production network, and participates in one or more
DODAGs, such that it is reachable from the 6LBR, and the JCE.
3.2. Join Protocol deliverables
This section works from the ultimate goal, and goes backwards to
prerequisite actions. (Section 6 presents the protocol from
beginning to end order)
The ultimate goal of the join protocol is to provide a new node with
a locally significant security credentials so that it is able to take
part in the network directly. The credentials may vary by
deployment. They can be one of:
1) a network-wide shared symmetric key (this is the production
network key, or MasterKey)
2) a locally significant (one-level only) 802.11AR type LDevID
certificate (which allows it to negotiate a pair-wise keys)
One of these two items is delivered by JCE to the joining node using
the 6top protocol. That is, the JCE provisions using a secure
Richardson Expires May 23, 2016 [Page 6]
Internet-Draft 6tisch-6top November 2015
"northbound" interface. The authentication of this interface the
subject of the Join Protocol as explained below.
The above credential are used for authentication to generate per-peer
L2, using a key exchange protocol. The choice of key exchange
protocol, and what kind of link and multicast keying needs to be done
is also provisioned by the JCE. There are a number of options for
doing this, such as:
1) Mesh Link Exchange [I-D.kelsey-intarea-mesh-link-establishment]
(IMPORTANT, a good option. Uses certificates from common CA)
2) work in 802.15.9 (uses certificates from common CA)
3) Security Framework and Key Management Protocol Requirements for
6TiSCH [I-D.ohba-6tisch-security] (this document provides the
phase 0 required, using the network-wide shared key)
4) Layer-2 security aspects for the IEEE 802.15.4e MAC
[I-D.piro-6tisch-security-issues]: the MasterKey is used to
derive per-peer L2 keys
Per-peer L2 keying is critical when doing peer-2-peer schedule
negotiation over 15.4 Information Elements. Therefore a network-wide
layer-2 key is inappropriate for the self-organizing networks, and a
protocol (MLE, 802.15.9) SHOULD be used to derive per-peer L2 keys.
For networks where there is a PCE present, it will do all schedule
computation. As a result the only trust relationship necessary is
between the individual node and the PCE, and it MAY be acceptable to
have a network-wide L2 key derived in ways such as
[I-D.piro-6tisch-security-issues] describes in section ?. The trust
relationship between the PCE and the joining node flows from the
LDevID certificate loaded by the JCE. When the PCE and JCE are co-
located, the existing 6top/DTLS security association could be reused.
3.3. Join Protocol connection setup
The intermediate level goal of the join protocol is to enable a Join
Coordination Entity (JCE) to reach out to the new node, and install
the credentials detailed above. The JCE must authenticate itself to
the joining node so that the joining node will know that it has
joined the correct network, and the joining node must authenticate
itself to the JCE so that the JCE will know that this node belongs in
the network. This two way authentication occurs in the 6top/CoAP/
DTLS session that is established between the JCE and the joining
node.
Richardson Expires May 23, 2016 [Page 7]
Internet-Draft 6tisch-6top November 2015
[I-D.ietf-6tisch-6top-interface] presents a way to interface to a
6top information model (defined in YANG). [I-D.ietf-6tisch-coap]
explains how to access that information model using CoAP. This
information model will include security attributes for the network.
The JCE would therefore reach out to the joining node and simply
provision appropriate security properties into the joining node, much
like the PCE will provision schedules.
This 6top-based secure join protocol has defined a push model for
security provisioning by the JCE. This has been done for three
reasons:
1) 6tisch nodes already have to have a 6top CoAP server for schedule
provising
2) this permits the JCE to manage how many nodes are trying to join
at the same time, and limit how much bandwidth/energy is used for
the join operation, and also for the JCE to prioritize the join
order for nodes.
3) making the JCE initiate the DTLS connection significantly
simplies the certificate chains that must be exchanged as the
most constrained side (the joining node) provides it's
credentials first, and lets the less constrained JCE figure out
what kind of certificate chain will be required to authenticate
the JCE to the joining node. In EAP-TLS/802.1x situations, the
TLS channel is created in the opposite direction, and it would
have to complete in a tentative way, and then further
authorization occur in-band.
3.4. End to End considerations for Join Protocol
In order for a 6top/DTLS/CoAP connection to occur between the JCE and
the joining node, there needs to be end-to-end IPv6 connectivity
between those two entities. The joining node will not participate in
the route-over RPL mesh, but rather will be seen by the network as
being a 6lowpan only leaf-node.
The joining node sends traffic to the join assistant, which forwards
it using the normal RPL DODAG upwards routes, and which will reach
the JCE using regular routing.
The challenge is getting connectivity from the JCE to the joining
node, as the DODAG and 6LBR root will have no information about this
node. Instead, the JCE will use loose-source routes (in the RH2) to
address packets first to the Join Assistant, which will then forward
to the joining node. This has an interaction with the (strict)
Richardson Expires May 23, 2016 [Page 8]
Internet-Draft 6tisch-6top November 2015
source routes used by non-storing DODAGs which would be used by the
6LBR to reach the Join Assistant.
There are some alternatives to having full end to end connectivity
which are discussed in the security considerations section.
3.4.1. Security Considerations: alternatives to source routes
This goes into security-considerations section
A number of alternatives were considered for creating end to end
connectivity between the joining node and the JCE, but were rejected.
(1) IPIP tunnel between Join Assistant and JCE
(2) using straight RPL routing: the Join Assistant sends a DAO
(3) using a separate RPL DODAG for join traffic
(4) establishing a specific multi-hop 6tisch track for join traffic
for each Join Assistant
3.4.1.1. IPIP tunnel
This mechanism requires 40 bytes overhead per packet, and may require
specific state to be created on the Join Assistant, or may open the
network up to a resource exhaustion by malicious join nodes.
This mechanism was rejected on due to byte count, because it would
require code only needed for join, and because doing it securely may
require a per-tunnel state to be maintained on the join assistant.
3.4.1.2. join existing DODAG
This mechanism is to just have the new node join the DODAG as a leaf
node. The join assistant would issue a DAO for the new node. If a
storing DODAG was used, this would directly cost state in all parent
nodes of the Join Assistant, subjecting the lower-rank parts of the
network to significant denial of service attacks.
On a non-storing DODAG the situation is significantly better: no
state is created by the presence of the leaf node except in the 6LBR,
where available resources may be higher.
This mechanism was rejected in favour of the loose source routed
option as this the loose source routed option always works even for
storing DODAGs, and is otherwise exactly equivalent in terms of
network bandwidth cost.
Richardson Expires May 23, 2016 [Page 9]
Internet-Draft 6tisch-6top November 2015
3.4.1.3. join a DODOAG for joining
One option to deal with the problem of resource consumption in the
storing DODAG case is to use a second DODAG.
This mechanism was rejected as it consumes resources in all nodes for
the second DODAG, and many implementations support on a single DODAG.
While storing DODAGs have a lighter network impact than non-storing
ones (due to the lack of source routes), the PCE can control how much
network bandwidth can be wasted by malicious join nodes using the
regular 6tisch mechanisms, and this can be tuned. A second DODAG
would be a sunk cost with no tuning possible.
3.4.1.4. create 6tisch track to form mesh-under
This mechanism would use 6tisch tracks so that traffic from the JCE
would be switched from 6LBR to join node. A track would be required
to each join assistant. This is an optimized form of source routing.
This mechanism was not rejected, rather it was observed that it may
be applied to any mechanism that uses source routing, and is an
optimization; it has a certain cost in the form of intermediary node
state, but that this state is not created by a malicious join node,
rather it is created by the PCE.
3.5. Join node discovery mechanism
Continuing to work backwards, in order the JCE reach out to provision
the Joining Node, it needs to know that the new node is present.
This is done by taking advantage of the 6lowPAN Address Resolution
Option (ARO) (section 4.1 [RFC6775]). The ARO causes the new address
to also be sent up to the 6LBR for duplicate detection using the DAR/
DAC mechanism. The 6LBR simply needs to tell the JCE about this. A
new protocol may be required for the situation where the JCE, PCE and
6LBR are not co-located; it may be that this protocol could be simply
a DAR in some encapsulation. The details of this are currently out
of scope for the architecture, as they affect interoperability
between different vendors of JCE/6LBR/PCE rather than
interoperability between the assistance/offload infrastructure, and
the contrained nodes. Future work may specify this part.
In addition to needing to know the joining devices address from the
DAR/NS, the JCE also needs to know the joining node's IDevID. This
is to determine if the node should even get any attention. At this
point, the IDevID can be forged, it will be authenticated during the
setup of the 6top control protocol in the DTLS certificate exchange.
If the serialNumber attribute of the IDevID is less than 64 bits,
then it is possible that it could be placed into the EUI-64 option of
Richardson Expires May 23, 2016 [Page 10]
Internet-Draft 6tisch-6top November 2015
the ARO, or the OUI of the [I-D.thubert-6lo-rfc6775-update-reqs]
EARO. The JCE needs to know the joining node's serialNumber to know
if this is device that it should even attempt to provision; and if
so, it may need to retrieve an appropriate certificate chain (see
[I-D.richardson-6tisch-idevid-cert]) from the Factory in order for
the JCE to prove it is the legitimate owner of the joining node.
Neither 802.1AR nor [RFC5280] provide any structure for the
serialNumber, except that they are positive integers of up-to 20
octets in size (numbers up to 2^160). This specification would
require that the serialNumber encoded in the IDevID be the same as
the EUI-64 used by the device. Some consideration needs to be given
as to whether there are privacy considerations to doing this: any
observer that can see the join traffic, can also see the source MAC
address of the node as well.
Prior to being able to announce itself in a NS, the joining node
needs to find the Join Network. This is done by listening to the
extended beacon which are broadcast in designated slotframes by the
network. These are the same extended beacons which are used by the
production network. The extended beacons are transmitted in "MIC-
only" (authentication only) mode. Nodes with the production network
key can authenticate the beacons. The newly joining node can not
authenticate the beacons, but it can read and process them, and can
use this as a way to synchronize to the network. During the Alpha
period, the joining node can send a Router Soliticiation, and receive
an appropriate Router Advertisement giving the Joining Node a prefix
and default route to which to send the join traffic (the ND DAD
mentioned above).
It may be possible to eliminate a message exchange if space for a
Router Advertisement can be found as part of the Join Network
Extended Beacon. This Enhanced Beacon would be distinct to the Join
Network, and would be encrypted with the well-known Join Network key.
3.5.1. prefixes to use for join traffic
What prefix would the joining node for communication? There are
three options:
(1) just use link-local addresses (this may require that some
traffic between 6LBR and JCE be IPIP tunneled)
(2) use a prefix specifically for join traffic (may be easier with a
join-only DODAG)
(3) use the same prefix as the rest of the traffic (may require more
complex ACLs, and leaks information to attackers)
Richardson Expires May 23, 2016 [Page 11]
Internet-Draft 6tisch-6top November 2015
It would be ideal to use link-local addresses, but they need to be
scoped to the radio interface of the join assistant which can
actually reach the joining node. It may be that this can be made to
work, but otherwise, the join assistant will have a ULA for each
radio on which it expects join traffic.
4. security requirements
4.1. threat model
There are three kinds of threats that a join process must deal with:
threats to the joining node, threats to the resources of the network,
and threats to other joining nodes.
4.1.1. threats to the joining node
A node may be taken out of it's box by a malicious entity and powered
on. This could happen during shipping, while being stored in a
warehouse. The device may be subject to physical theft, or the goal
of the attacker may be to turn the device into a trojan horse of some
kind. Physical protection of the device is out of scope for this
document; this document will henceforth assume that the device is
sealed in some tamper-evident way and this document deals with
attacks over the network.
An attacker may attempt to convince the joining node that it is the
legitimate Production Network; this is done by putting up a
legitimate looking Join Network, and following the protocol as
described in this document. The Joining Node can not know if it has
the corrrect Production Network until steps 11-13, when it attempts
to validate the ClientCertificate provided by the JCE.
When the joining node determines that this is the incorrect network,
it must remember the PANID of the network that it has attempted to
join, and then look for another network to try. It SHOULD have some
limit as the number of times it will try before going back to sleep,
or shutting down, and it SHOULD take care not to consume more than
some specified percentage of any battery it might have.
Should a malicious production network be present at the same time/
place as the legitimate production network, a the malicious agent
could intercept and replay various packets from the proper join
network, but ultimately this either results in a jamming-like denial
of service, and/or the the ClientCertificate will not validate.
It is a legitimate situation for there to be multiple possible join
networks, and the joining node may have to try each one before it
finds the network that it the right one for it. The incorrect, but
Richardson Expires May 23, 2016 [Page 12]
Internet-Draft 6tisch-6top November 2015
non-malicious networks will not attempt the 6top provisioning step,
and SHOULD return a negative result in steps 8/9, refusing the node's
NS. Those incorrect networks will be recognize that the node does
not belong to them, because they will be able to see the Joining
Node's IDevID in the ARO of step 4.
4.1.2. threats to the resources of the network
The production network has two important resources that may be
attacked by malicious Joining nodes: 1) energy/bandwidth, 2) memory
for routing entries.
A malicious joining node could send many NS messages to the Join
Assistant (from many made up addresses), which would send many NS/DAR
messages to the 6LBR, and this would consume bandwidth, and therefore
energy from the members of the mesh along the path to the 6LBR. This
can be mitigated by limited the total bandwidth available for
joining.
A malicious joining node could send many NS messages, and if the 6LBR
agreed to accept the new node (by IDevID), then the Join Assistant
would MAY inject routing information into mesh for the Joining node.
Non-storing DODAGs store are routing information in the DODAG Root
(probably the 6LBR), which is generally not a constrained node.
Storing DODAGs store routing entries at all nodes up to the DODAG,
and those are constrained nodes. Using a separate Join DODAG, and
having that DODAG be non-storing will reduce any impact on
intermediate nodes, but it does cause resources to be used for the
second DODAG, and it may have a code impact if the nodes otherwise
would not implement non-storing RPL.
4.1.3. threats to other joining nodes
A joining node (or the nodes of a malicious network, co-located near
the legitimate production network) may mount attacks on legitimate
nodes which have not yet joined.
The malicious nodes may attempt to perform 6top operations against
the joining node to keep it from being able to respond to the
legitimate 6top session from the legitimate JCE. During the Join
phase, the Joining node MUST have all other resources and protocols
turned off, even if they would normally be accessible as read-only
unauthenticated CoAP resources.
Malicious nodes could use the Join Network to mount various DTLS
based attacks against the joining node, such as sending very long
certificate chains to validate. One might think to limit the length
of such chains, but as shown in [I-D.richardson-6tisch-idevid-cert]
Richardson Expires May 23, 2016 [Page 13]
Internet-Draft 6tisch-6top November 2015
the chain may as a long as the supplier chain, plus may include
additional certificates due to resales of plants/equipment/etc.
Validating from a trusted certificate down to the specific
certificate which proves ownership would eliminate random certificate
chains, but the attacker could just feed the joining node legitimate
chains that it observed (and replayed) from the legitimate JCE. This
does no good; the Joining node finds that the DTLS connection is
invalid, but it may significantly run batteries down.
4.2. implementation cost
(storage of security material, computational cost)
4.3. denial of service
other communication impacts of security protocol mechanics
5. protocol requirements/constraints/assumptions
5.1. inline/offline
dependencies on centralized or external functionality, inline and
offline
6. time sequence diagram
Richardson Expires May 23, 2016 [Page 14]
Internet-Draft 6tisch-6top November 2015
+-----+ +------+ +----------+ +-----------+
| | | | | JOIN | | Joining |
| JCE | | 6LBR | | Assistant| | Node |
+-----+ +------+ | (proxy) | | |
| | +----------+ +-----------+
| | | |
| | |-------BEACON (1)---------->|
| | | |
| | |<----Router Solicitation----|
| | |---Router Advertisement---->|
| | | |
| | |<------CERT CACHE-----------|
| | | LOAD (2) |
| | | |
| | | |
| | |-------CERT CACHE---------->|
| | | RESPONSE (multiple) |
| | | (packets) |
| | | |
| | |<-----JOIN REQUEST (4) -----|
| | | (NS w/ARO ) |
| | | |
| |<---NS (DAR) (5)-----| |
|<--??(6)-| | |
| | | |
|--??(7)->| | |
| | | |
| |----NS (DAC)-(8)---->| |
| | +------+ | |
| |<DAO-| mesh |<--DAO--| |
| |-DAO-| node |--DACK->| |
| | ACK +------+ | |
| | |-------JOIN ACK (9)-------->|
| | | |
| | | |
|================(10)==========>|----------6top----(11)----->|
| | | DTLS |
|<===============(13)===========|<---------CoAP----(12)------|
| | | (many packets) |
Figure 1: Message sequence for JOIN message
6.1. explanation of each step
Richardson Expires May 23, 2016 [Page 15]
Internet-Draft 6tisch-6top November 2015
6.1.1. step (1): enhanced beacon
A 6tisch join/synchronization beacon is broadcast periodically, and
is authenticated with a symmetric "beacon key":
well known JOIN key, such "JOIN6TISCH"
another key, provisioned in advance (OOB)
a shared symmetric key derived from public part of top level
certificate (a closely held "secret")
The purpose of this key is not to provide a high level of assurance,
but rather to filter out 6tisch traffic from another random traffic
that may be sharing the same radio frequencies.
These beacons are used for JOIN purpose only, and are not related to
the Enhanced Beacons used in the rest of 6tisch.
6.1.2. step (1B): send router solicitation
The joining node sends a router solicitation during the Aloha period
of the beacon.
6.1.3. step (1C): receive router advertisement
The joining node receives a router advertisement from the Join
Assistant. It could include 6CO options to help compress packets,
and should contain a prefix appropriate for join traffic.
6.1.4. step (2): certificate cache load
At step 10, the JCE will need to present a certificate chain anchored
at a trusted CA built into the joining node. It has been speculated
that a significant amount of traffic could be avoided at step (10) if
the common parts of the certificate chains could be cached in the
join assistant.
This optional step involves the joining node asking for certificates
from the join assistant.
6.1.5. step (3): receive certificate cache
the proxy neighbour sends requested cached certificates to the
joining node
Richardson Expires May 23, 2016 [Page 16]
Internet-Draft 6tisch-6top November 2015
6.1.6. step (4): join request
A regular Neighbour Solicitation is sent. This should contain an ARO
(or EARO) option containing the Joining Nodes' IDevID. The ARO/EARO
will be proxied by the Join Assistant as part of normal 6LowPAN
processing for leaf nodes (non-RPL nodes) upwards to the 6LBR
6.1.7. step (5): NS duplicate address request (DAR)
6.1.8. step (7): 6LBR informs JCE of new node
6.1.9. step (8): JCE informs/acks to 6LBR of new node
The JCE could reply in the negative, and this would cause a DAC
failure, TBD
6.1.10. step (9): NS duplicate address confirmation (DAC)
6.1.11. step (10): JCE initiates connection to joining node
The double lines indicate that an IPIP tunnel operation may be
required. If a straight DAO or seperate Join DODAG is used, then
this is just a straight forwarding root to leaf node forwarding
operation, and involves either using source routes (non-storing), or
just forwarding for storing DODAGs.
A specific bandwidth allocation would be used for this join traffic
The production network encryption keys would be used for the join
traffic
6.1.12. step (11): Join Assistant forwards packet to joining node
The JOIN Assistant would forward traffic to the Joining Node.
Recognizing that this traffic the JOIN Network, the JOIN Assistant
would use the JOIN Network key.
6.1.13. step (12): Joining node replies
The joining node replies, using JOIN Network key.
6.1.14. step (13): Join Assistant forwards reply to JCE
The JOIN Assistant, recognizing that the traffic came from the JOIN
Network, restricts the destination that can be reached to the the JCE
only. It can do this in a stateless way, and it does NOT need to
track the traffic at (10) to open pinhole, etc.
Richardson Expires May 23, 2016 [Page 17]
Internet-Draft 6tisch-6top November 2015
Recognizing that the traffic came from the JOIN Network, the traffic
would be placed into a bandwidth allocation (track?) that allows such
traffic.
6.2. size of each packet
and number of frames needed to contain it.
7. resulting security properties obtained from this process
An end to end IPv6 CoAP/DTLS connection is created between the JCE
and the Joining Node. This connection carries 6top commands to
update security parameters. This results in either deployment of a
single-level, locally relevant certificate (LDevID), or deployment of
a network-wide symmetric "Master Key"
8. deployment scenarios underlying protocol requirements
9. device identification
The JCE authenticates the joining node using a certificate chain
provided inline during the DTLS negotiation. The certificate chain
is rooted in a vendor certificate that the JCE must have preloaded,
and is a statement as to the node's 802.1AR IDevID. The joining node
authenticates the
9.1. PCE/Proxy vs Node identification
9.2. Time source authentication / time validation
Note: RPL Root authentication is a chartered item
9.3. description of certificate contents
9.4. privacy aspects
The EUI-64 of the Joining node is transmitted using a Well Known
layer-2 encryption key. Within the ARO/EARO of the Neighbour
Solicitation is an OUI, which may be identical to the EUI-64 of the
Joining node, or it might be an unrelated IDevID.
An eavesdropper can therefore learn something about the manufacturer
of every device as it joins.
Richardson Expires May 23, 2016 [Page 18]
Internet-Draft 6tisch-6top November 2015
10. slotframes to be used during join
how is this communicated in the (extended) beacon.
11. configuration aspects
(allocation of slotframes after join, network statistics,
neighboetc.)
12. authorization aspects
lifecycle (key management, trust management)
12.1. how to determine a proxy/PCE from a end node
12.2. security considerations
what prevents a node from transmitting when it is not their turn
(part one: jamming)
can a node successfully communicate with a peer at a time when not
supposed to, may be tied to link layer security, or will it be
policed by receiver?
13. security architecture
security architecture and fit of e.g. join protocol and provisioning
into this
14. Posture Maintenance
(SACM related work)
15. Security Considerations
16. Other Related Protocols
17. IANA Considerations
18. Acknowledgements
19. References
19.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Richardson Expires May 23, 2016 [Page 19]
Internet-Draft 6tisch-6top November 2015
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/
RFC6550, March 2012,
<http://www.rfc-editor.org/info/rfc6550>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC
6775, DOI 10.17487/RFC6775, November 2012,
<http://www.rfc-editor.org/info/rfc6775>.
[IEEE.802.1AR]
Institute of Electrical and Electronics Engineers, "Secure
Device Identity", IEEE 802.1AR, 2009,
<http://www.ieee802.org/1/pages/802.1ar.html>.
[I-D.ietf-6tisch-coap]
Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and
Interaction using CoAP", draft-ietf-6tisch-coap-03 (work
in progress), March 2015.
[I-D.ietf-6tisch-6top-interface]
Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer
(6top) Interface", draft-ietf-6tisch-6top-interface-04
(work in progress), July 2015.
[I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-08 (work
in progress), May 2015.
[I-D.irtf-nmrg-autonomic-network-definitions]
Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
Networking - Definitions and Design Goals", draft-irtf-
nmrg-autonomic-network-definitions-07 (work in progress),
March 2015.
[I-D.seitz-ace-problem-description]
Seitz, L. and G. Selander, "Problem Description for
Authorization in Constrained Environments", draft-seitz-
ace-problem-description-03 (work in progress), March 2015.
Richardson Expires May 23, 2016 [Page 20]
Internet-Draft 6tisch-6top November 2015
[I-D.richardson-6tisch-idevid-cert]
Richardson, M., "X509.v3 certificate extension for
authorization of device ownership", draft-richardson-
6tisch-idevid-cert-01 (work in progress), March 2015.
[I-D.wang-6tisch-6top-sublayer]
Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer
(6top)", draft-wang-6tisch-6top-sublayer-04 (work in
progress), November 2015.
[I-D.thubert-6lo-rfc6775-update-reqs]
Thubert, P. and P. Stok, "Requirements for an update to
6LoWPAN ND", draft-thubert-6lo-rfc6775-update-reqs-06
(work in progress), January 2015.
19.2. Informative references
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, DOI 10.17487/
RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[I-D.thubert-6lowpan-backbone-router]
Thubert, P., "LoWPAN Backbone Router", draft-thubert-
6lowpan-backbone-router-00 (work in progress), March 2008.
[I-D.ietf-netconf-zerotouch]
Watsen, K., Clarke, J., and M. Abrahamsson, "Zero Touch
Provisioning for NETCONF Call Home", draft-ietf-netconf-
zerotouch-04 (work in progress), October 2015.
[I-D.kelsey-intarea-mesh-link-establishment]
Kelsey, R., "Mesh Link Establishment", draft-kelsey-
intarea-mesh-link-establishment-06 (work in progress), May
2014.
Richardson Expires May 23, 2016 [Page 21]
Internet-Draft 6tisch-6top November 2015
[I-D.ohba-6tisch-security]
Chasko, S., Das, S., Lopez, R., Ohba, Y., Thubert, P., and
A. Yegin, "Security Framework and Key Management Protocol
Requirements for 6TiSCH", draft-ohba-6tisch-security-01
(work in progress), March 2014.
[I-D.piro-6tisch-security-issues]
Piro, G., Boggia, G., and L. Grieco, "Layer-2 security
aspects for the IEEE 802.15.4e MAC", draft-piro-6tisch-
security-issues-03 (work in progress), December 2014.
Author's Address
Michael C. Richardson
Sandelman Software Works
470 Dawson Avenue
Ottawa, ON K1Z 5V7
CA
Email: mcr+ietf@sandelman.ca
URI: http://www.sandelman.ca/
Richardson Expires May 23, 2016 [Page 22]