draft-ietf-6tisch-minimal-security-08.txt   draft-ietf-6tisch-minimal-security-09.txt 
6TiSCH Working Group M. Vucinic, Ed. 6TiSCH Working Group M. Vucinic, Ed.
Internet-Draft Inria Internet-Draft Inria
Intended status: Standards Track J. Simon Intended status: Standards Track J. Simon
Expires: May 12, 2019 Analog Devices Expires: May 24, 2019 Analog Devices
K. Pister K. Pister
University of California Berkeley University of California Berkeley
M. Richardson M. Richardson
Sandelman Software Works Sandelman Software Works
November 08, 2018 November 20, 2018
Minimal Security Framework for 6TiSCH Minimal Security Framework for 6TiSCH
draft-ietf-6tisch-minimal-security-08 draft-ietf-6tisch-minimal-security-09
Abstract Abstract
This document describes the minimal framework required for a new This document describes the minimal framework required for a new
device, called "pledge", to securely join a 6TiSCH (IPv6 over the device, called "pledge", to securely join a 6TiSCH (IPv6 over the
TSCH mode of IEEE 802.15.4e) network. The framework requires that TSCH mode of IEEE 802.15.4e) network. The framework requires that
the pledge and the JRC (join registrar/coordinator, a central the pledge and the JRC (join registrar/coordinator, a central
entity), share a symmetric key. How this key is provisioned is out entity), share a symmetric key. How this key is provisioned is out
of scope of this document. Through a single CoAP (Constrained of scope of this document. Through a single CoAP (Constrained
Application Protocol) request-response exchange secured by OSCORE Application Protocol) request-response exchange secured by OSCORE
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 12, 2019. This Internet-Draft will expire on May 24, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 38 skipping to change at page 2, line 38
4.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . . 9 4.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . . 9
4.3. Step 3 - Constrained Join Protocol (CoJP) Execution . . . 9 4.3. Step 3 - Constrained Join Protocol (CoJP) Execution . . . 9
4.4. The Special Case of the 6LBR Pledge Joining . . . . . . . 10 4.4. The Special Case of the 6LBR Pledge Joining . . . . . . . 10
5. Link-layer Configuration . . . . . . . . . . . . . . . . . . 10 5. Link-layer Configuration . . . . . . . . . . . . . . . . . . 10
6. Network-layer Configuration . . . . . . . . . . . . . . . . . 11 6. Network-layer Configuration . . . . . . . . . . . . . . . . . 11
6.1. Identification of Unauthenticated Traffic . . . . . . . . 12 6.1. Identification of Unauthenticated Traffic . . . . . . . . 12
7. Application-level Configuration . . . . . . . . . . . . . . . 13 7. Application-level Configuration . . . . . . . . . . . . . . . 13
7.1. Statelessness of the JP . . . . . . . . . . . . . . . . . 13 7.1. Statelessness of the JP . . . . . . . . . . . . . . . . . 13
7.2. Recommended Settings . . . . . . . . . . . . . . . . . . 14 7.2. Recommended Settings . . . . . . . . . . . . . . . . . . 14
7.3. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.3. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Constrained Join Protocol (CoJP) . . . . . . . . . . . . . . 18 8. Constrained Join Protocol (CoJP) . . . . . . . . . . . . . . 17
8.1. Join Exchange . . . . . . . . . . . . . . . . . . . . . . 19 8.1. Join Exchange . . . . . . . . . . . . . . . . . . . . . . 19
8.2. Parameter Update Exchange . . . . . . . . . . . . . . . . 20 8.2. Parameter Update Exchange . . . . . . . . . . . . . . . . 20
8.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 22 8.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 22
8.4. CoJP Objects . . . . . . . . . . . . . . . . . . . . . . 24 8.4. CoJP Objects . . . . . . . . . . . . . . . . . . . . . . 24
8.5. Recommended Settings . . . . . . . . . . . . . . . . . . 35 8.5. Recommended Settings . . . . . . . . . . . . . . . . . . 35
9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 37 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 37
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
11.1. CoJP Parameters Registry . . . . . . . . . . . . . . . . 38 11.1. CoJP Parameters Registry . . . . . . . . . . . . . . . . 38
11.2. CoJP Key Usage Registry . . . . . . . . . . . . . . . . 39 11.2. CoJP Key Usage Registry . . . . . . . . . . . . . . . . 39
skipping to change at page 6, line 46 skipping to change at page 6, line 46
[IEEE802.15.4] is used as the network identifier. However, PAN ID [IEEE802.15.4] is used as the network identifier. However, PAN ID
is not considered a stable network identifier as it may change is not considered a stable network identifier as it may change
during network lifetime if a collision with another network is during network lifetime if a collision with another network is
detected. Companion documents can specify the use of a different detected. Companion documents can specify the use of a different
network identifier for join purposes, but this is out of scope of network identifier for join purposes, but this is out of scope of
this specification. Provisioning the network identifier is this specification. Provisioning the network identifier is
RECOMMENDED. However, due to operational constraints, the network RECOMMENDED. However, due to operational constraints, the network
identifier may not be known at the time when the provisioning is identifier may not be known at the time when the provisioning is
done. In case this parameter is not provisioned to the pledge, done. In case this parameter is not provisioned to the pledge,
the pledge attempts to join one advertised network at a time, the pledge attempts to join one advertised network at a time,
which significantly prolongs the join process. In case this which significantly prolongs the join process. This parameter
parameter is not provisioned to the 6LBR pledge, the 6LBR pledge MUST be provisioned to the 6LBR pledge.
can receive it from the JRC as part of the join protocol.
o Optionally, any non-default algorithms. The default algorithms o Optionally, any non-default algorithms. The default algorithms
are specified in Section 7.3.3. When algorithm identifiers are are specified in Section 7.3.3. When algorithm identifiers are
not exchanged, the use of these default algorithms is implied. not exchanged, the use of these default algorithms is implied.
Additionally, the 6LBR pledge that is not co-located with the JRC Additionally, the 6LBR pledge that is not co-located with the JRC
needs to be provisioned with: needs to be provisioned with:
o Global IPv6 address of the JRC. This address is used by the 6LBR o Global IPv6 address of the JRC. This address is used by the 6LBR
pledge to address the JRC during the join process. The 6LBR pledge to address the JRC during the join process. The 6LBR
skipping to change at page 10, line 17 skipping to change at page 10, line 17
The Join Response is sent by the JRC to the pledge, and is forwarded The Join Response is sent by the JRC to the pledge, and is forwarded
through the JP. The packet containing the Join Response travels from through the JP. The packet containing the Join Response travels from
the JRC to the JP using the operating routes in the network. The JP the JRC to the JP using the operating routes in the network. The JP
delivers it to the pledge. The JP operates as the application-layer delivers it to the pledge. The JP operates as the application-layer
proxy. proxy.
The Join Response contains different parameters needed by the pledge The Join Response contains different parameters needed by the pledge
to become a fully operational network node. These parameters include to become a fully operational network node. These parameters include
the link-layer key(s) currently in use in the network, the short the link-layer key(s) currently in use in the network, the short
address assigned to the pledge, the IPv6 address of the JRC needed by address assigned to the pledge, the IPv6 address of the JRC needed by
the pledge to operate as the JP, amoung others. the pledge to operate as the JP, among others.
4.4. The Special Case of the 6LBR Pledge Joining 4.4. The Special Case of the 6LBR Pledge Joining
The 6LBR pledge performs Section 4.3 of the join process described The 6LBR pledge performs Section 4.3 of the join process described
above, just as any other pledge, albeit over a different network above, just as any other pledge, albeit over a different network
interface. There is no JP intermediating the communication between interface. There is no JP intermediating the communication between
the 6LBR pledge and the JRC, as described in Section 6. The other the 6LBR pledge and the JRC, as described in Section 6. The other
steps of the described join process do not apply to the 6LBR pledge. steps of the described join process do not apply to the 6LBR pledge.
How the 6LBR pledge obtains an IPv6 address and triggers the How the 6LBR pledge obtains an IPv6 address and triggers the
execution of the CoJP protocol is out of scope of this document. execution of the CoJP protocol is out of scope of this document.
skipping to change at page 12, line 20 skipping to change at page 12, line 20
to overwhelm the network. to overwhelm the network.
When operating as part of a [RFC8180] 6TiSCH minimal network using When operating as part of a [RFC8180] 6TiSCH minimal network using
distributed scheduling algorithms, the traffic from unauthenticated distributed scheduling algorithms, the traffic from unauthenticated
pledges may cause intermediate nodes to request additional bandwidth. pledges may cause intermediate nodes to request additional bandwidth.
An attacker could use this property to cause the network to An attacker could use this property to cause the network to
overcommit bandwidth (and energy) to the join process. overcommit bandwidth (and energy) to the join process.
The Join Proxy is aware of what traffic originates from The Join Proxy is aware of what traffic originates from
unauthenticated pledges, and so can avoid allocating additional unauthenticated pledges, and so can avoid allocating additional
bandwidth itself. The Join Proxy implements a bandwidth cap on bandwidth itself. The Join Proxy implements a data cap on outgoing
outgoing join traffic through CoAP's congestion control mechanism. join traffic through CoAP's congestion control mechanism. This cap
This cap will not protect intermediate nodes as they can not tell will not protect intermediate nodes as they can not tell join traffic
join traffic from regular traffic. Despite the bandwidth cap from regular traffic. Despite the data cap implemented separately on
implemented separately on each Join Proxy, the aggregate join traffic each Join Proxy, the aggregate join traffic from many Join Proxies
from many Join Proxies may cause intermediate nodes to decide to may cause intermediate nodes to decide to allocate additional cells.
allocate additional cells. It is undesirable to do so in response to It is undesirable to do so in response to the traffic originated at
the traffic originated at unauthenticated pledges. In order to unauthenticated pledges. In order to permit the intermediate nodes
permit the intermediate nodes to avoid this, the traffic needs to be to avoid this, the traffic needs to be tagged. [RFC2597] defines a
tagged. [RFC2597] defines a set of per-hop behaviors that may be set of per-hop behaviors that may be encoded into the Diffserv Code
encoded into the Diffserv Code Points (DSCPs). Based on the DSCP, Points (DSCPs). Based on the DSCP, intermediate nodes can decide
intermediate nodes can decide whether to act on a given packet. whether to act on a given packet.
6.1.1. Traffic from JP to JRC 6.1.1. Traffic from JP to JRC
The Join Proxy SHOULD set the DSCP of packets that it produces as The Join Proxy SHOULD set the DSCP of packets that it produces as
part of the forwarding process to AF43 code point (See Section 6 of part of the forwarding process to AF43 code point (See Section 6 of
[RFC2597]). A Join Proxy that does not set the DSCP on traffic [RFC2597]). A Join Proxy that does not set the DSCP on traffic
forwarded should set it to zero so that it is compressed out. forwarded should set it to zero so that it is compressed out.
A Scheduling Function (SF) running on 6TiSCH nodes SHOULD NOT A Scheduling Function (SF) running on 6TiSCH nodes SHOULD NOT
allocate additional cells as a result of traffic with code point allocate additional cells as a result of traffic with code point
skipping to change at page 13, line 20 skipping to change at page 13, line 20
capacity (if it is not constrained) then it should provide some capacity (if it is not constrained) then it should provide some
buffers in order to satisfy the Assured Forwarding behavior. buffers in order to satisfy the Assured Forwarding behavior.
Companion SF documents SHOULD specify how traffic with code point Companion SF documents SHOULD specify how traffic with code point
AF42 is handled with respect to cell allocation. AF42 is handled with respect to cell allocation.
7. Application-level Configuration 7. Application-level Configuration
The CoJP join exchange in Figure 1 is carried over CoAP [RFC7252] and The CoJP join exchange in Figure 1 is carried over CoAP [RFC7252] and
the secure channel provided by OSCORE the secure channel provided by OSCORE
[I-D.ietf-core-object-security]. The (6LBR) acts as a CoAP client; [I-D.ietf-core-object-security]. The (6LBR) pledge acts as a CoAP
the JRC acts as a CoAP server. The JP implements CoAP forward proxy client; the JRC acts as a CoAP server. The JP implements CoAP
functionality [RFC7252]. Because the JP can also be a constrained forward proxy functionality [RFC7252]. Because the JP can also be a
device, it cannot implement a cache. constrained device, it cannot implement a cache.
The pledge designates a JP as a proxy by including the Proxy-Scheme The pledge designates a JP as a proxy by including the Proxy-Scheme
option in CoAP requests it sends to the JP. The pledge also includes option in CoAP requests it sends to the JP. The pledge also includes
in the requests the Uri-Host option with its value set to the well- in the requests the Uri-Host option with its value set to the well-
known JRC's alias, as specified in Section 8.1.1. known JRC's alias, as specified in Section 8.1.1.
The JP resolves the alias to the IPv6 address of the JRC that it The JP resolves the alias to the IPv6 address of the JRC that it
learned when it acted as a pledge, and joined the network. This learned when it acted as a pledge, and joined the network. This
allows the JP to reach the JRC at the network layer and forward the allows the JP to reach the JRC at the network layer and forward the
requests on behalf of the pledge. requests on behalf of the pledge.
skipping to change at page 14, line 13 skipping to change at page 14, line 13
[I-D.hartke-core-stateless], to transport the state object. Since [I-D.hartke-core-stateless], to transport the state object. Since
the CoAP token is echoed back in the response, the JP is able to the CoAP token is echoed back in the response, the JP is able to
decode the state object and configure the state needed to forward the decode the state object and configure the state needed to forward the
response to the pledge. The information that the JP needs to encode response to the pledge. The information that the JP needs to encode
in the state object to operate in a fully stateless manner with in the state object to operate in a fully stateless manner with
respect to a given pledge is implementation specific. respect to a given pledge is implementation specific.
It is RECOMMENDED that the JP operates in a stateless manner and It is RECOMMENDED that the JP operates in a stateless manner and
signals the per-pledge state within the CoAP token, for every request signals the per-pledge state within the CoAP token, for every request
it forwards into the network on behalf of unauthenticated pledges. it forwards into the network on behalf of unauthenticated pledges.
When operating in a stateles manner, the state object communicated in When operating in a stateless manner, the state object communicated
the token MUST be integrity protected, potentially with a key that is in the token MUST be integrity protected, potentially with a key that
known only to the JP, MUST include a freshness indicator, and MAY be is known only to the JP, MUST include a freshness indicator, and MAY
encrypted. Security considerations from [I-D.hartke-core-stateless] be encrypted. Security considerations from
apply. [I-D.hartke-core-stateless] apply.
When operating in a stateless manner, the type of the CoAP message When operating in a stateless manner, the type of the CoAP message
that the JP forwards on behalf of the pledge MUST be non-confirmable that the JP forwards on behalf of the pledge MUST be non-confirmable
(NON), regardless of the message type received from the pledge. The (NON), regardless of the message type received from the pledge. The
use of a non-confirmable message by the JP alleviates the JP from use of a non-confirmable message by the JP alleviates the JP from
keeping CoAP message exchange state. The retransmission burden is keeping CoAP message exchange state. The retransmission burden is
then entirely shifted to the pledge. A JP that operates in a then entirely shifted to the pledge. A JP that operates in a
stateless manner still needs to keep congestion control state with stateless manner still needs to keep congestion control state with
the JRC, see Section 9. Recommended values of CoAP settings for use the JRC, see Section 9. Recommended values of CoAP settings for use
during the join process, both by the pledge and the JP, are given in during the join process, both by the pledge and the JP, are given in
skipping to change at page 15, line 13 skipping to change at page 15, line 13
join process. join process.
+-------------------+-----------------------+-------------------+ +-------------------+-----------------------+-------------------+
| Name | Default Value: Pledge | Default Value: JP | | Name | Default Value: Pledge | Default Value: JP |
+-------------------+-----------------------+-------------------+ +-------------------+-----------------------+-------------------+
| ACK_TIMEOUT | 10 seconds | (10 seconds) | | ACK_TIMEOUT | 10 seconds | (10 seconds) |
| | | | | | | |
| ACK_RANDOM_FACTOR | 1.5 | (1.5) | | ACK_RANDOM_FACTOR | 1.5 | (1.5) |
| | | | | | | |
| MAX_RETRANSMIT | 4 | (4) | | MAX_RETRANSMIT | 4 | (4) |
| | | |
| NSTART | 1 | (3) |
| | | |
| PROBING_RATE | 4 byte/second | 12 byte/second |
+-------------------+-----------------------+-------------------+ +-------------------+-----------------------+-------------------+
Recommended CoAP settings. Values enclosed in () have no effect when Recommended CoAP settings. Values enclosed in () have no effect when
JP operates in a stateless manner. JP operates in a stateless manner.
These values may be configured to values specific to the deployment. These values may be configured to values specific to the deployment.
The default values have been chosen to accommodate a wide range of The default values have been chosen to accommodate a wide range of
deployments, taking into account dense networks. Increased values of deployments, taking into account dense networks.
NSTART and PROBING_RATE at the JP enable multiple pledges
(approximately 3 pledges by default) to concurrently join through the The PROBING_RATE value at the JP is controlled by the join rate
same JP. Following [RFC7252], the average data rate in sending to JP parameter, see Section 8.4.2. Following [RFC7252], the average data
or JRC must not exceed PROBING_RATE. For security reasons, the rate in sending to the JRC must not exceed PROBING_RATE. For
average data rate SHOULD be measured over a rather short window, e.g. security reasons, the average data rate SHOULD be measured over a
ACK_TIMEOUT, see Section 9. rather short window, e.g. ACK_TIMEOUT, see Section 9.
7.3. OSCORE 7.3. OSCORE
Before the (6LBR) pledge and the JRC start exchanging CoAP messages Before the (6LBR) pledge and the JRC start exchanging CoAP messages
protected with OSCORE, they need to derive the OSCORE security protected with OSCORE, they need to derive the OSCORE security
context from the provisioned parameters, as discussed in Section 3. context from the provisioned parameters, as discussed in Section 3.
The OSCORE security context MUST be derived as per Section 3 of The OSCORE security context MUST be derived as per Section 3 of
[I-D.ietf-core-object-security]. [I-D.ietf-core-object-security].
skipping to change at page 23, line 35 skipping to change at page 23, line 35
rejoined, the AEAD nonce reuse risk exists during the first Parameter rejoined, the AEAD nonce reuse risk exists during the first Parameter
Update exchange, as the new JRC does not possess the last Sender Update exchange, as the new JRC does not possess the last Sender
Sequence number used, and can only initialize it to zero. Since the Sequence number used, and can only initialize it to zero. Since the
sending of this first Parameter Update message by the new JRC results sending of this first Parameter Update message by the new JRC results
in AEAD nonce reuse, the JRC MUST set the payload to a randomly in AEAD nonce reuse, the JRC MUST set the payload to a randomly
generated byte string, at least 40 bytes long. generated byte string, at least 40 bytes long.
When such a message arrives at the joined node, the OSCORE When such a message arrives at the joined node, the OSCORE
implementation rejects it due to the Partial IV being largely below implementation rejects it due to the Partial IV being largely below
the acceptable replay window state and does not process the payload. the acceptable replay window state and does not process the payload.
When this is detected, the joined node MUST send an Error Response When this is detected, the joined node MUST send a 4.01 Unauthorized
message with error code set to "Significant OSCORE partial IV response, as per Section 7.4 of [I-D.ietf-core-object-security]. The
payload of the response MUST be the Error object specified in
Section 8.4.5, with error code set to "Significant OSCORE partial IV
mismatch" from Table 4 and Additional information set to the next mismatch" from Table 4 and Additional information set to the next
Partial IV it will expect. When protecting this error response by Partial IV the joined node will expect. When protecting this error
OSCORE, the joined node uses the value of its Sender Sequence number response by OSCORE, the joined node MUST use its Sender Sequence
to generate the Partial IV and includes it in the CoAP OSCORE option, number to generate a new nonce and include the corresponding Partial
as specified by [I-D.ietf-core-object-security]. Upon successful IV in the CoAP OSCORE option, as detailed in Section 8.3 of
OSCORE verification of the received CoJP message, the JRC processes [I-D.ietf-core-object-security]. Upon successful OSCORE verification
the error response and configures the Sender Sequence number to the of the received CoJP message, the JRC processes the error response
one indicated in the Additional information field. The next and configures the Sender Sequence number to the one indicated in the
Parameter Update exchange triggered by the JRC will therefore use the Additional information field. The next Parameter Update exchange
proper Sender Sequence number and will be accepted by the joined triggered by the JRC will therefore use the proper Sender Sequence
node. number and will be accepted by the joined node.
8.4. CoJP Objects 8.4. CoJP Objects
This section specifies the structure of CoJP CBOR objects that may be This section specifies the structure of CoJP CBOR objects that may be
carried as the payload of CoJP messages. Some of these objects may carried as the payload of CoJP messages. Some of these objects may
be received both as part of the CoJP join exchange when the device be received both as part of the CoJP join exchange when the device
operates as a (CoJP) pledge, or the parameter update exchange, when operates as a (CoJP) pledge, or the parameter update exchange, when
the device operates as a joined (6LBR) node. the device operates as a joined (6LBR) node.
8.4.1. Join Request Object 8.4.1. Join Request Object
skipping to change at page 24, line 28 skipping to change at page 24, line 28
summarized below. The labels can be found in the "CoJP Parameters" summarized below. The labels can be found in the "CoJP Parameters"
registry Section 11.1. registry Section 11.1.
o role: The identifier of the role that the pledge requests to play o role: The identifier of the role that the pledge requests to play
in the network once it joins, encoded as an unsigned integer. in the network once it joins, encoded as an unsigned integer.
Possible values are specified in Table 1. This parameter MAY be Possible values are specified in Table 1. This parameter MAY be
included. In case the parameter is omitted, the default value of included. In case the parameter is omitted, the default value of
0, i.e. the role "6TiSCH Node", MUST be assumed. 0, i.e. the role "6TiSCH Node", MUST be assumed.
o network identifier: The identifier of the network, as discussed in o network identifier: The identifier of the network, as discussed in
Section 3, encoded as a CBOR byte string. This parameter may Section 3, encoded as a CBOR byte string. When present in the
appear both in the Join_Request and in the Configuration objects. Join_Request, it hints to the JRC the network that the pledge is
When present in the Join_Request, it hints to the JRC the network requesting to join, enabling the JRC to manage multiple networks.
that the pledge is requesting to join, enabling the JRC to manage The pledge obtains the value of the network identifier from the
multiple networks. The pledge obtains the value of the network received EB frames. This parameter MUST be included in a
identifier from the received EB frames. This parameter MUST be Join_Request object regardless of the role parameter value.
included in a Join_Request object if the role parameter is set to
"6TiSCH Node". This parameter MAY be included if the role
parameter is set to "6LBR". The inclusion of this parameter by
the 6LBR pledge depends on whether the parameter was exchanged
during the provisioning phase, which in turn depends on the
operational constraints.
o response processing error: The identifier of the error from the o response processing error: The identifier of the error from the
previous join attempt, encoded as an Error object described in previous join attempt, encoded as an Error object described in
Section 8.4.5. This parameter MAY be included. If a (6LBR) Section 8.4.5. This parameter MAY be included. If a (6LBR)
pledge previously attempted to join and received a valid Join pledge previously attempted to join and received a valid Join
Response message over OSCORE, but failed to process its payload Response message over OSCORE, but failed to process its payload
(Configuration object), it SHOULD include this parameter to (Configuration object), it SHOULD include this parameter to
facilitate the debugging process. facilitate the debugging process.
The CDDL fragment that represents the text above for the Join_Request The CDDL fragment that represents the text above for the Join_Request
follows. follows.
Join_Request = { Join_Request = {
? 1 : uint, ; role ? 1 : uint, ; role
? 5 : bstr, ; network identifier ? 5 : bstr, ; network identifier
? 7 : Error, ; response processing error ? 8 : Error, ; response processing error
} }
+--------+-------+-------------------------------------+------------+ +--------+-------+-------------------------------------+------------+
| Name | Value | Description | Reference | | Name | Value | Description | Reference |
+--------+-------+-------------------------------------+------------+ +--------+-------+-------------------------------------+------------+
| 6TiSCH | 0 | The pledge requests to play the | [[this | | 6TiSCH | 0 | The pledge requests to play the | [[this |
| Node | | role of a regular 6TiSCH node, i.e. | document]] | | Node | | role of a regular 6TiSCH node, i.e. | document]] |
| | | non-6LBR node. | | | | | non-6LBR node. | |
| | | | | | | | | |
| 6LBR | 1 | The pledge requests to play the | [[this | | 6LBR | 1 | The pledge requests to play the | [[this |
| | | role of 6LoWPAN Border Router | document]] | | | | role of 6LoWPAN Border Router | document]] |
| | | (6LBR). | | | | | (6LBR). | |
skipping to change at page 26, line 41 skipping to change at page 26, line 35
string is different from 16, the parameter MUST be discarded. If string is different from 16, the parameter MUST be discarded. If
the JRC is not co-located with the 6LBR and has a different IPv6 the JRC is not co-located with the 6LBR and has a different IPv6
address than the 6LBR, this parameter MUST be included. In the address than the 6LBR, this parameter MUST be included. In the
special case where the JRC is co-located with the 6LBR and has the special case where the JRC is co-located with the 6LBR and has the
same IPv6 address as the 6LBR, this parameter MAY be included. If same IPv6 address as the 6LBR, this parameter MAY be included. If
the JRC address parameter is not present in the Configuration the JRC address parameter is not present in the Configuration
object, this indicates that the JRC has the same IPv6 address as object, this indicates that the JRC has the same IPv6 address as
the 6LBR. The joined node can then discover the IPv6 address of the 6LBR. The joined node can then discover the IPv6 address of
the JRC through network control traffic. See Section 6. the JRC through network control traffic. See Section 6.
o network identifier: the identifier of the network, as discussed in
Section 3, encoded as a byte string. When present in the
Configuration object, this parameter is only valid when received
by the 6LBR pledge. The parameter indicates to the 6LBR the value
of the network identifier it should advertise at the link layer.
This parameter MUST NOT be included in the Configuration object if
the role parameter from the corresponding Join_Request object
indicated 0, i.e. the role "6TiSCH Node". In the case where the
corresponding Join_Request object does not contain the network
identifier parameter, this parameter MUST be included. When the
corresponding Join_Request object does contain the network
identifier parameter, this parameter MAY be included in the
Configuration object. This may happen if the JRC decides to
overwrite the network identifier obtained during the provisioning
phase. The value of the network identifier parameter from the
Configuration object SHOULD take precedence over the value
obtained during the provisioning phase.
o blacklist: An array encompassing a list of pledge identifiers that o blacklist: An array encompassing a list of pledge identifiers that
are blacklisted by the JRC, with each pledge identifier encoded as are blacklisted by the JRC, with each pledge identifier encoded as
a byte string. The blacklist parameter MAY be included in a a byte string. The blacklist parameter MAY be included in a
Configuration object. When present, the blacklist parameter MUST Configuration object. When present, the array MUST contain zero
contain at least one pledge identifier. When the joined node or more byte strings encoding pledge identifiers. The joined node
receives this parameter, it MUST silently drop any link-layer MUST silently drop any link-layer frames originating from the
frames originating from the indicated pledge identifiers. This pledge identifiers enclosed in the blacklist parameter. When this
parameter allows the JRC to configure the node acting as a JP to parameter is received, its value MUST overwrite any previously set
filter out traffic from misconfigured or malicious pledges before values. This parameter allows the JRC to configure the node
their traffic is forwarded into the network. acting as a JP to filter out traffic from misconfigured or
malicious pledges before their traffic is forwarded into the
network. If the JRC decides to remove a given pledge identifier
from a blacklist, it omits the pledge identifier in the blacklist
parameter value it sends next.
o join rate: Average data rate of join traffic forwarded into the
network that should not be exceeded when a joined node operates as
a JP, encoded as an unsigned integer in bytes per second. The
join rate parameter MAY be included in a Configuration object.
This parameter allows the JRC to configure different nodes in the
network to operate as JP, and act in case of an attack by
throttling the rate at which JP forwards unauthenticated traffic
into the network. When this parameter is present in a
Configuration object, the value MUST be used to set the
PROBING_RATE of CoAP at the joined node for communication with the
JRC. In case this parameter is set to zero, a joined node MUST
silently drop any join traffic coming from unauthenticated
pledges. In case this parameter is omitted, the value of positive
infinity SHOULD be assumed. Node operating as a JP MAY use
another mechanism that is out of scope of this specification to
configure PROBING_RATE of CoAP in the absence of join rate
parameter from the Configuration object.
The CDDL fragment that represents the text above for the The CDDL fragment that represents the text above for the
Configuration follows. Structures Link_Layer_Key and Configuration follows. Structures Link_Layer_Key and
Short_Identifier are specified in Section 8.4.3 and Section 8.4.4. Short_Identifier are specified in Section 8.4.3 and Section 8.4.4.
Configuration = { Configuration = {
? 2 : [ +Link_Layer_Key ], ; link-layer key set ? 2 : [ +Link_Layer_Key ], ; link-layer key set
? 3 : Short_Identifier, ; short identifier ? 3 : Short_Identifier, ; short identifier
? 4 : bstr, ; JRC address ? 4 : bstr, ; JRC address
? 5 : bstr, ; network identifier ? 6 : [ *bstr ], ; blacklist
? 6 : [ +bstr ], ; blacklist ? 7 : uint ; join rate
} }
+------------+-------+----------+----------------------+------------+ +------------+-------+----------+----------------------+------------+
| Name | Label | CBOR | Description | Reference | | Name | Label | CBOR | Description | Reference |
| | | type | | | | | | type | | |
+------------+-------+----------+----------------------+------------+ +------------+-------+----------+----------------------+------------+
| role | 1 | unsigned | Identifies the role | [[this | | role | 1 | unsigned | Identifies the role | [[this |
| | | integer | parameter | document]] | | | | integer | parameter | document]] |
| | | | | | | | | | | |
| link-layer | 2 | array | Identifies the array | [[this | | link-layer | 2 | array | Identifies the array | [[this |
| key set | | | carrying one or more | document]] | | key set | | | carrying one or more | document]] |
skipping to change at page 28, line 30 skipping to change at page 28, line 30
| JRC | 4 | byte | Identifies the IPv6 | [[this | | JRC | 4 | byte | Identifies the IPv6 | [[this |
| address | | string | address of the JRC | document]] | | address | | string | address of the JRC | document]] |
| | | | | | | | | | | |
| network | 5 | byte | Identifies the | [[this | | network | 5 | byte | Identifies the | [[this |
| identifier | | string | network identifier | document]] | | identifier | | string | network identifier | document]] |
| | | | parameter | | | | | | parameter | |
| | | | | | | | | | | |
| blacklist | 6 | array | Identifies the | [[this | | blacklist | 6 | array | Identifies the | [[this |
| | | | blacklist parameter | document]] | | | | | blacklist parameter | document]] |
| | | | | | | | | | | |
| error | 7 | array | Identifies the error | [[this | | join rate | 7 | unsigned | Identifier the join | [[this |
| | | integer | rate parameter | document]] |
| | | | | |
| error | 8 | array | Identifies the error | [[this |
| | | | parameter | document]] | | | | | parameter | document]] |
+------------+-------+----------+----------------------+------------+ +------------+-------+----------+----------------------+------------+
Table 2: CoJP parameters map labels. Table 2: CoJP parameters map labels.
8.4.3. Link-Layer Key 8.4.3. Link-Layer Key
The Link_Layer_Key structure encompasses the parameters needed to The Link_Layer_Key structure encompasses the parameters needed to
configure the link-layer security module: the key identifier; the configure the link-layer security module: the key identifier; the
value of the cryptographic key; the link-layer algorithm identifier value of the cryptographic key; the link-layer algorithm identifier
skipping to change at page 36, line 46 skipping to change at page 36, line 46
of device serial numbers or their EUI-64 to generate "unique" PSKs. of device serial numbers or their EUI-64 to generate "unique" PSKs.
Without any secret information involved, the effort that the attacker Without any secret information involved, the effort that the attacker
needs to invest into breaking these unsafe derivation methods is needs to invest into breaking these unsafe derivation methods is
quite low, resulting in the possible impersonation of any device from quite low, resulting in the possible impersonation of any device from
the batch, without even needing to compromise a single device. The the batch, without even needing to compromise a single device. The
use of cryptographically secure random number generators to generate use of cryptographically secure random number generators to generate
the PSK is RECOMMENDED, see [NIST800-90A] for different mechanisms the PSK is RECOMMENDED, see [NIST800-90A] for different mechanisms
using deterministic methods. using deterministic methods.
The JP forwards the unauthenticated join traffic into the network. A The JP forwards the unauthenticated join traffic into the network. A
bandwidth cap on the JP prevents it from forwarding more traffic than data cap on the JP prevents it from forwarding more traffic than the
the network can handle. The bandwidth cap is configured through the network can handle. The data cap can be configured by the JRC by
CoAP's PROBING_RATE parameter. The default values recommended in including a join rate parameter in the Join Response and it is
this document allow 3 pledges to concurrently join through the same implemented through the CoAP's PROBING_RATE setting. The use of a
JP over a window ACK_TIMEOUT long. The use of a bandwidth cap at a data cap at a JP forces attackers to use more than one JP if they
JP forces attackers to use more than one JP if they wish to overwhelm wish to overwhelm the network. Marking the join traffic packets with
the network. Marking the join traffic packets with a non-zero DSCP a non-zero DSCP allows the network to carry the traffic if it has
allows the network to carry the traffic if it has capacity, but capacity, but encourages the network to drop the extra traffic rather
encourages the network to drop the extra traffic rather than add than add bandwidth due to that traffic.
bandwidth due to that traffic.
The shared nature of the "minimal" cell used for the join traffic The shared nature of the "minimal" cell used for the join traffic
makes the network prone to a DoS attack by congesting the JP with makes the network prone to a DoS attack by congesting the JP with
bogus traffic. Such an attacker is limited by its maximum transmit bogus traffic. Such an attacker is limited by its maximum transmit
power. The redundancy in the number of deployed JPs alleviates the power. The redundancy in the number of deployed JPs alleviates the
issue and also gives the pledge a possibility to use the best issue and also gives the pledge a possibility to use the best
available link for joining. How a network node decides to become a available link for joining. How a network node decides to become a
JP is out of scope of this specification. JP is out of scope of this specification.
At the beginning of the join process, the pledge has no means of At the beginning of the join process, the pledge has no means of
skipping to change at page 42, line 15 skipping to change at page 42, line 15
[I-D.ietf-6tisch-terminology] [I-D.ietf-6tisch-terminology]
Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
"Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e", "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e",
draft-ietf-6tisch-terminology-10 (work in progress), March draft-ietf-6tisch-terminology-10 (work in progress), March
2018. 2018.
[I-D.ietf-cbor-cddl] [I-D.ietf-cbor-cddl]
Birkholz, H., Vigano, C., and C. Bormann, "Concise data Birkholz, H., Vigano, C., and C. Bormann, "Concise data
definition language (CDDL): a notational convention to definition language (CDDL): a notational convention to
express CBOR and JSON data structures", draft-ietf-cbor- express CBOR and JSON data structures", draft-ietf-cbor-
cddl-05 (work in progress), August 2018. cddl-06 (work in progress), November 2018.
[IEEE802.15.4] [IEEE802.15.4]
IEEE standard for Information Technology, ., "IEEE Std IEEE standard for Information Technology, ., "IEEE Std
802.15.4 Standard for Low-Rate Wireless Networks", n.d.. 802.15.4 Standard for Low-Rate Wireless Networks", n.d..
[NIST800-90A] [NIST800-90A]
NIST Special Publication 800-90A, Revision 1, ., Barker, NIST Special Publication 800-90A, Revision 1, ., Barker,
E., and J. Kelsey, "Recommendation for Random Number E., and J. Kelsey, "Recommendation for Random Number
Generation Using Deterministic Random Bit Generators", Generation Using Deterministic Random Bit Generators",
2015. 2015.
 End of changes. 23 change blocks. 
106 lines changed or deleted 102 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/