draft-ietf-6tisch-minimal-security-10.txt   draft-ietf-6tisch-minimal-security-11.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: October 7, 2019 Analog Devices Expires: December 15, 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
April 05, 2019 June 13, 2019
Minimal Security Framework for 6TiSCH Minimal Security Framework for 6TiSCH
draft-ietf-6tisch-minimal-security-10 draft-ietf-6tisch-minimal-security-11
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 October 7, 2019. This Internet-Draft will expire on December 15, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 5, line 10 skipping to change at page 5, line 10
o join proxy (JP) o join proxy (JP)
o join registrar/coordinator (JRC) o join registrar/coordinator (JRC)
o enhanced beacon (EB) o enhanced beacon (EB)
o join protocol o join protocol
o join process o join process
The following terms defined in [RFC6775] are also used throughout The following terms defined in [RFC8505] are also used throughout
this document: this document:
o 6LoWPAN Border Router (6LBR) o 6LoWPAN Border Router (6LBR)
o 6LoWPAN Node (6LN) o 6LoWPAN Node (6LN)
The term "6LBR" is used interchangeably with the term "DODAG root" The term "6LBR" is used interchangeably with the term "DODAG root"
defined in [RFC6550], assuming the two entities are co-located, as defined in [RFC6550], assuming the two entities are co-located, as
recommended by [I-D.ietf-6tisch-architecture]. recommended by [I-D.ietf-6tisch-architecture].
skipping to change at page 9, line 13 skipping to change at page 9, line 13
that has sent the EB to the pledge acts as the JP. that has sent the EB to the pledge acts as the JP.
At this point, the pledge may proceed to step 2, or continue to At this point, the pledge may proceed to step 2, or continue to
listen for additional EBs. listen for additional EBs.
4.2. Step 2 - Neighbor Discovery 4.2. Step 2 - Neighbor Discovery
The pledge forms its link-local IPv6 address based on the interface The pledge forms its link-local IPv6 address based on the interface
identifier, as per [RFC4944]. The pledge MAY perform the Neighbor identifier, as per [RFC4944]. The pledge MAY perform the Neighbor
Solicitation / Neighbor Advertisement exchange with the JP, as per Solicitation / Neighbor Advertisement exchange with the JP, as per
Section 5.5.1 of [RFC6775]. The pledge and the JP use their link- Section 5.6 of [RFC8505]. The pledge and the JP use their link-local
local IPv6 addresses for all subsequent communication during the join IPv6 addresses for all subsequent communication during the join
process. process.
Note that Neighbor Discovery exchanges at this point are not Note that Neighbor Discovery exchanges at this point are not
protected with link-layer security as the pledge is not in possession protected with link-layer security as the pledge is not in possession
of the keys. How JP accepts these unprotected frames is discussed in of the keys. How JP accepts these unprotected frames is discussed in
Section 5. Section 5.
4.3. Step 3 - Constrained Join Protocol (CoJP) Execution 4.3. Step 3 - Constrained Join Protocol (CoJP) Execution
The pledge triggers the join exchange of the Constrained Join The pledge triggers the join exchange of the Constrained Join
skipping to change at page 11, line 19 skipping to change at page 11, line 19
the join process. Mixing neighbor entries belonging to pledges and the join process. Mixing neighbor entries belonging to pledges and
nodes that are part of the network opens up the JP to a DoS attack, nodes that are part of the network opens up the JP to a DoS attack,
as the attacker may fill JP's neighbor table and prevent the as the attacker may fill JP's neighbor table and prevent the
discovery of legitimate neighbors. discovery of legitimate neighbors.
Once the pledge obtains link-layer keys and becomes a joined node, it Once the pledge obtains link-layer keys and becomes a joined node, it
is able to securely communicate with its neighbors, obtain the is able to securely communicate with its neighbors, obtain the
network IPv6 prefix and form its global IPv6 address. The joined network IPv6 prefix and form its global IPv6 address. The joined
node then undergoes an independent process to bootstrap its neighbor node then undergoes an independent process to bootstrap its neighbor
cache entries, possibly with a node that formerly acted as a JP, cache entries, possibly with a node that formerly acted as a JP,
following [RFC6775]. From the point of view of the JP, there is no following [RFC8505]. From the point of view of the JP, there is no
relationship between the neighbor cache entry belonging to a pledge relationship between the neighbor cache entry belonging to a pledge
and the joined node that formerly acted as a pledge. and the joined node that formerly acted as a pledge.
The pledge does not communicate with the JRC at the network layer. The pledge does not communicate with the JRC at the network layer.
This allows the pledge to join without knowing the IPv6 address of This allows the pledge to join without knowing the IPv6 address of
the JRC. Instead, the pledge communicates with the JP at the network the JRC. Instead, the pledge communicates with the JP at the network
layer using link-local addressing, and with the JRC at the layer using link-local addressing, and with the JRC at the
application layer, as specified in Section 7. application layer, as specified in Section 7.
The JP communicates with the JRC over global IPv6 addresses. The JP The JP communicates with the JRC over global IPv6 addresses. The JP
skipping to change at page 13, line 14 skipping to change at page 13, line 14
Due to the convergecast nature of the DODAG, the 6LBR links are often Due to the convergecast nature of the DODAG, the 6LBR links are often
the most congested, and from that point down there is progressively the most congested, and from that point down there is progressively
less (or equal) congestion. If the 6LBR paces itself when sending less (or equal) congestion. If the 6LBR paces itself when sending
join response traffic then it ought to never exceed the bandwidth join response traffic then it ought to never exceed the bandwidth
allocated to the best effort traffic cells. If the 6LBR has the allocated to the best effort traffic cells. If the 6LBR has the
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. In case the
recommended behavior described in this section is not followed, the
network may become prone to the attack discussed in Section 6.1.
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) pledge acts as a CoAP [I-D.ietf-core-object-security]. The (6LBR) pledge acts as a CoAP
client; the JRC acts as a CoAP server. The JP implements CoAP client; the JRC acts as a CoAP server. The JP implements CoAP
forward proxy functionality [RFC7252]. Because the JP can also be a forward proxy functionality [RFC7252]. Because the JP can also be a
constrained device, it cannot implement a cache. constrained device, it cannot implement a cache.
skipping to change at page 39, line 32 skipping to change at page 39, line 32
Note to RFC Editor: Please replace all occurrences of "[[this Note to RFC Editor: Please replace all occurrences of "[[this
document]]" with the RFC number of this specification. document]]" with the RFC number of this specification.
This document allocates a well-known name under the .arpa name space This document allocates a well-known name under the .arpa name space
according to the rules given in [RFC3172]. The name "6tisch.arpa" is according to the rules given in [RFC3172]. The name "6tisch.arpa" is
requested. No subdomains are expected. No A, AAAA or PTR record is requested. No subdomains are expected. No A, AAAA or PTR record is
requested. requested.
11.1. CoJP Parameters Registry 11.1. CoJP Parameters Registry
This section defines a sub-registries within the "IPv6 over the TSCH This section defines a sub-registry within the "IPv6 over the TSCH
mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name
"Constrained Join Protocol Parameters Registry". "Constrained Join Protocol Parameters Registry".
The columns of the registry are: The columns of the registry are:
Name: This is a descriptive name that enables an easier reference to Name: This is a descriptive name that enables an easier reference to
the item. It is not used in the encoding. the item. It is not used in the encoding.
Label: The value to be used to identify this parameter. The label is Label: The value to be used to identify this parameter. The label is
an integer. an integer.
skipping to change at page 40, line 15 skipping to change at page 40, line 15
The amending formula for this sub-registry is: Different ranges of The amending formula for this sub-registry is: Different ranges of
values use different registration policies [RFC8126]. Integer values values use different registration policies [RFC8126]. Integer values
from -256 to 255 are designated as Standards Action. Integer values from -256 to 255 are designated as Standards Action. Integer values
from -65536 to -257 and from 256 to 65535 are designated as from -65536 to -257 and from 256 to 65535 are designated as
Specification Required. Integer values greater than 65535 are Specification Required. Integer values greater than 65535 are
designated as Expert Review. Integer values less than -65536 are designated as Expert Review. Integer values less than -65536 are
marked as Private Use. marked as Private Use.
11.2. CoJP Key Usage Registry 11.2. CoJP Key Usage Registry
This section defines a sub-registries within the "IPv6 over the TSCH This section defines a sub-registry within the "IPv6 over the TSCH
mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name
"Constrained Join Protocol Key Usage Registry". "Constrained Join Protocol Key Usage Registry".
The columns of this registry are: The columns of this registry are:
Name: This is a descriptive name that enables easier reference to the Name: This is a descriptive name that enables easier reference to the
item. The name MUST be unique. It is not used in the encoding. item. The name MUST be unique. It is not used in the encoding.
Value: This is the value used to identify the key usage setting. Value: This is the value used to identify the key usage setting.
These values MUST be unique. The value is an integer. These values MUST be unique. The value is an integer.
skipping to change at page 41, line 7 skipping to change at page 41, line 7
The amending formula for this sub-registry is: Different ranges of The amending formula for this sub-registry is: Different ranges of
values use different registration policies [RFC8126]. Integer values values use different registration policies [RFC8126]. Integer values
from -256 to 255 are designated as Standards Action. Integer values from -256 to 255 are designated as Standards Action. Integer values
from -65536 to -257 and from 256 to 65535 are designated as from -65536 to -257 and from 256 to 65535 are designated as
Specification Required. Integer values greater than 65535 are Specification Required. Integer values greater than 65535 are
designated as Expert Review. Integer values less than -65536 are designated as Expert Review. Integer values less than -65536 are
marked as Private Use. marked as Private Use.
11.3. CoJP Unsupported Configuration Code Registry 11.3. CoJP Unsupported Configuration Code Registry
This section defines a sub-registries within the "IPv6 over the TSCH This section defines a sub-registry within the "IPv6 over the TSCH
mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name
"Constrained Join Protocol Unsupported Configuration Code Registry". "Constrained Join Protocol Unsupported Configuration Code Registry".
The columns of this registry are: The columns of this registry are:
Name: This is a descriptive name that enables easier reference to the Name: This is a descriptive name that enables easier reference to the
item. The name MUST be unique. It is not used in the encoding. item. The name MUST be unique. It is not used in the encoding.
Value: This is the value used to identify the diagnostic code. These Value: This is the value used to identify the diagnostic code. These
values MUST be unique. The value is an integer. values MUST be unique. The value is an integer.
skipping to change at page 44, line 12 skipping to change at page 44, line 12
DOI 10.17487/RFC5869, May 2010, DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>. <https://www.rfc-editor.org/info/rfc5869>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>. <https://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,
<https://www.rfc-editor.org/info/rfc6775>.
[RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
Internet of Things (IoT): Problem Statement", RFC 7554, Internet of Things (IoT): Problem Statement", RFC 7554,
DOI 10.17487/RFC7554, May 2015, DOI 10.17487/RFC7554, May 2015,
<https://www.rfc-editor.org/info/rfc7554>. <https://www.rfc-editor.org/info/rfc7554>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016, RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>. <https://www.rfc-editor.org/info/rfc7721>.
skipping to change at page 44, line 39 skipping to change at page 44, line 33
[RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal
IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH)
Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180,
May 2017, <https://www.rfc-editor.org/info/rfc8180>. May 2017, <https://www.rfc-editor.org/info/rfc8180>.
[RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH [RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH
Operation Sublayer (6top) Protocol (6P)", RFC 8480, Operation Sublayer (6top) Protocol (6P)", RFC 8480,
DOI 10.17487/RFC8480, November 2018, DOI 10.17487/RFC8480, November 2018,
<https://www.rfc-editor.org/info/rfc8480>. <https://www.rfc-editor.org/info/rfc8480>.
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>.
Appendix A. Example Appendix A. Example
Figure 3 illustrates a successful join protocol exchange. The pledge Figure 3 illustrates a successful join protocol exchange. The pledge
instantiates the OSCORE context and derives the OSCORE keys and instantiates the OSCORE context and derives the OSCORE keys and
nonces from the PSK. It uses the instantiated context to protect the nonces from the PSK. It uses the instantiated context to protect the
Join Request addressed with a Proxy-Scheme option, the well-known Join Request addressed with a Proxy-Scheme option, the well-known
host name of the JRC in the Uri-Host option, and its EUI-64 as pledge host name of the JRC in the Uri-Host option, and its EUI-64 as pledge
identifier and OSCORE kid context. Triggered by the presence of a identifier and OSCORE kid context. Triggered by the presence of a
Proxy-Scheme option, the JP forwards the request to the JRC and sets Proxy-Scheme option, the JP forwards the request to the JRC and sets
the CoAP token to the internally needed state. The JP has learned the CoAP token to the internally needed state. The JP has learned
 End of changes. 13 change blocks. 
18 lines changed or deleted 20 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/