rfc9031xml2.original.xml   rfc9031.xml 
<?xml version="1.0" encoding="us-ascii"?> <?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.12 --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
ipr="trust200902"
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ docName="draft-ietf-6tisch-minimal-security-15"
<!ENTITY RFC7554 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere number="9031"
nce.RFC.7554.xml"> category="std"
<!ENTITY RFC8180 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere obsoletes=""
nce.RFC.8180.xml"> updates=""
<!ENTITY RFC8613 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere submissionType="IETF"
nce.RFC.8613.xml"> consensus="true"
<!ENTITY RFC7252 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere xml:lang="en"
nce.RFC.7252.xml"> tocInclude="true"
<!ENTITY RFC7049 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere sortRefs="true"
nce.RFC.7049.xml"> symRefs="true"
<!ENTITY RFC8152 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere tocDepth="2"
nce.RFC.8152.xml"> version="3">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8174.xml">
<!ENTITY RFC2597 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.2597.xml">
<!ENTITY RFC3172 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.3172.xml">
<!ENTITY RFC8126 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8126.xml">
<!ENTITY I-D.ietf-core-stateless SYSTEM "https://xml2rfc.tools.ietf.org/public/r
fc/bibxml3/reference.I-D.ietf-core-stateless.xml">
<!ENTITY RFC8505 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8505.xml">
<!ENTITY I-D.ietf-6tisch-architecture SYSTEM "https://xml2rfc.tools.ietf.org/pub
lic/rfc/bibxml3/reference.I-D.ietf-6tisch-architecture.xml">
<!ENTITY RFC7320 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.7320.xml">
<!ENTITY RFC8085 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8085.xml">
<!ENTITY RFC5869 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.5869.xml">
<!ENTITY I-D.ietf-6tisch-msf SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/b
ibxml3/reference.I-D.ietf-6tisch-msf.xml">
<!ENTITY I-D.ietf-cbor-cddl SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bi
bxml3/reference.I-D.ietf-cbor-cddl.xml">
<!ENTITY I-D.ietf-cbor-sequence SYSTEM "https://xml2rfc.tools.ietf.org/public/rf
c/bibxml3/reference.I-D.ietf-cbor-sequence.xml">
<!ENTITY RFC8480 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8480.xml">
<!ENTITY RFC5785 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.5785.xml">
<!ENTITY RFC7721 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.7721.xml">
<!ENTITY RFC4944 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.4944.xml">
<!ENTITY RFC6550 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.6550.xml">
<!ENTITY RFC4231 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.4231.xml">
<!ENTITY RFC8415 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8415.xml">
<!ENTITY I-D.ietf-anima-grasp SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/
bibxml3/reference.I-D.ietf-anima-grasp.xml">
<!ENTITY RFC6762 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.6762.xml">
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc tocdepth="2"?>
<rfc ipr="trust200902" docName="draft-ietf-6tisch-minimal-security-15" category=
"std">
<!-- xml2rfc v2v3 conversion 2.46.0 -->
<front> <front>
<title>Constrained Join Protocol (CoJP) for 6TiSCH</title>
<author initials="M." surname="Vucinic" fullname="Malisa Vucinic" role="edit <title abbrev="CoJP for 6TiSCH">Constrained Join Protocol (CoJP) for 6TiSCH<
or"> /title>
<seriesInfo name="RFC" value="9031"/>
<author initials="M." surname="Vučinić" fullname="Mališa Vučinić" role="edit
or">
<organization>Inria</organization> <organization>Inria</organization>
<address> <address>
<postal> <postal>
<street>2 Rue Simone Iff</street> <street>2 Rue Simone Iff</street>
<city>Paris</city> <city>Paris</city>
<code>75012</code> <code>75012</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>malisa.vucinic@inria.fr</email> <email>malisa.vucinic@inria.fr</email>
</address> </address>
</author> </author>
<author initials="J." surname="Simon" fullname="Jonathan Simon"> <author initials="J." surname="Simon" fullname="Jonathan Simon">
<organization>Analog Devices</organization> <organization>Analog Devices</organization>
<address> <address>
<postal> <postal>
<street>32990 Alvarado-Niles Road, Suite 910</street> <street>32990 Alvarado-Niles Road, Suite 910</street>
<city>Union City, CA</city> <city>Union City</city>
<region>CA</region>
<code>94587</code> <code>94587</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>jonathan.simon@analog.com</email> <email>jonathan.simon@analog.com</email>
</address> </address>
</author> </author>
<author initials="K." surname="Pister" fullname="Kris Pister"> <author initials="K." surname="Pister" fullname="Kris Pister">
<organization>University of California Berkeley</organization> <organization>University of California Berkeley</organization>
<address> <address>
<postal> <postal>
<street>512 Cory Hall</street> <street>512 Cory Hall</street>
<city>Berkeley, CA</city> <city>Berkeley</city>
<region>CA</region>
<code>94720</code> <code>94720</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>pister@eecs.berkeley.edu</email> <email>pister@eecs.berkeley.edu</email>
</address> </address>
</author> </author>
<author initials="M." surname="Richardson" fullname="Michael Richardson"> <author initials="M." surname="Richardson" fullname="Michael Richardson">
<organization>Sandelman Software Works</organization> <organization>Sandelman Software Works</organization>
<address> <address>
<postal> <postal>
<street>470 Dawson Avenue</street> <street>470 Dawson Avenue</street>
<city>Ottawa, ON</city> <city>Ottawa</city>
<region>ON</region>
<code>K1Z5V7</code> <code>K1Z5V7</code>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>mcr+ietf@sandelman.ca</email> <email>mcr+ietf@sandelman.ca</email>
</address> </address>
</author> </author>
<date year="2021" month="May"/>
<date year="2019" month="December" day="10"/>
<area>Internet</area> <area>Internet</area>
<workgroup>6TiSCH Working Group</workgroup> <workgroup>6TiSCH</workgroup>
<keyword>Internet-Draft</keyword> <keyword>bootstrapping</keyword>
<keyword>onboarding</keyword>
<keyword>oscore</keyword>
<abstract> <abstract>
<t>This document describes the minimal framework required for
<t>This document describes the minimal framework required for a new device, call a new device, called a "pledge", to securely join a 6TiSCH (IPv6 over
ed "pledge", to securely join a 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4 the Time-Slotted Channel Hopping mode of IEEE 802.15.4) network.
e) network. The framework requires that the pledge and the JRC (Join Registrar/Coordinator,
The framework requires that the pledge and the JRC (join registrar/coordinator, a central entity), share a symmetric key.
a central entity), share a symmetric key.
How this key is provisioned is out of scope of this document. How this key is provisioned is out of scope of this document.
Through a single CoAP (Constrained Application Protocol) request-response exchan Through a single CoAP (Constrained Application Protocol) request-response
ge secured by OSCORE (Object Security for Constrained RESTful Environments), the exchange secured by OSCORE (Object Security for Constrained RESTful Environments
pledge requests admission into the network and the JRC configures it with link- ),
layer keying material and other parameters. the pledge requests admission into the network, and the JRC configures it with l
ink-layer keying material and other parameters.
The JRC may at any time update the parameters through another request-response e xchange secured by OSCORE. The JRC may at any time update the parameters through another request-response e xchange secured by OSCORE.
This specification defines the Constrained Join Protocol and its CBOR (Concise B This specification defines the Constrained Join Protocol and its CBOR
inary Object Representation) data structures, and describes how to configure the (Concise Binary Object Representation) data structures, and it describes
rest of the 6TiSCH communication stack for this join process to occur in a secu how to configure the rest of the 6TiSCH communication stack for this join proces
re manner. s to occur in a secure manner.
Additional security mechanisms may be added on top of this minimal framework.</t > Additional security mechanisms may be added on top of this minimal framework.</t >
</abstract> </abstract>
</front> </front>
<middle> <middle>
<!-- ====================================================================== --> <section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name>
<section anchor="introduction" title="Introduction"> <t>This document defines a "secure join" solution for a new device,
called a "pledge", to securely join a 6TiSCH network.
<t>This document defines a "secure join" solution for a new device, called "pled The term "secure join" refers to network access authentication, authorization,
ge", to securely join a 6TiSCH network. and parameter distribution as defined in <xref target="RFC9030" format="default"
The term "secure join" refers to network access authentication, authorization an />.
d parameter distribution, as defined in <xref target="I-D.ietf-6tisch-architectu
re"/>.
The Constrained Join Protocol (CoJP) defined in this document handles parameter distribution needed for a pledge to become a joined node. The Constrained Join Protocol (CoJP) defined in this document handles parameter distribution needed for a pledge to become a joined node.
Mutual authentication during network access and implicit authorization are achie Mutual authentication during network access and implicit authorization are
ved through the use of a secure channel, as configured by this document. achieved through the use of a secure channel as configured according to this doc
ument.
This document also specifies a configuration of different layers of the 6TiSCH p rotocol stack that reduces the Denial of Service (DoS) attack surface during the join process.</t> This document also specifies a configuration of different layers of the 6TiSCH p rotocol stack that reduces the Denial of Service (DoS) attack surface during the join process.</t>
<t>This document presumes a 6TiSCH network as described by
<t>This document presumes a 6TiSCH network as described by <xref target="RFC7554" format="default"/> and
<xref target="RFC7554"/> and <xref target="RFC8180" format="default"/>.
<xref target="RFC8180"/>. By design, nodes in a 6TiSCH network <xref target="RFC7554" format="default"/>
By design, nodes in a 6TiSCH network <xref target="RFC7554"/> have their radio t have their radio turned off most of the time in order to conserve energy.
urned off most of the time, to conserve energy. As a consequence, the link used by a new device for joining the network has limi
As a consequence, the link used by a new device for joining the network has limi ted bandwidth <xref target="RFC8180" format="default"/>.
ted bandwidth <xref target="RFC8180"/>.
The secure join solution defined in this document therefore keeps the number of over-the-air exchanges to a minimum.</t> The secure join solution defined in this document therefore keeps the number of over-the-air exchanges to a minimum.</t>
<t>The microcontrollers at the heart of 6TiSCH nodes have small
<t>The micro-controllers at the heart of 6TiSCH nodes have a small amount of cod amounts of code memory.
e memory.
It is therefore paramount to reuse existing protocols available as part of the 6 TiSCH stack. It is therefore paramount to reuse existing protocols available as part of the 6 TiSCH stack.
At the application layer, the 6TiSCH stack already relies on CoAP <xref target=" At the application layer, the 6TiSCH stack already relies on
RFC7252"/> for web transfer, and on OSCORE <xref target="RFC8613"/> for its end- CoAP <xref target="RFC7252" format="default"/> for web transfer and
to-end security. on OSCORE <xref target="RFC8613" format="default"/> for its end-to-end security.
The secure join solution defined in this document therefore reuses those two pro tocols as its building blocks.</t> The secure join solution defined in this document therefore reuses those two pro tocols as its building blocks.</t>
<t>CoJP is a generic protocol that can be used as-is in all modes
<t>CoJP is a generic protocol that can be used as-is in all modes of IEEE Std 80 of IEEE Std 802.15.4 <xref target="IEEE802.15.4" format="default"/>, including
2.15.4 <xref target="IEEE802.15.4"/>, including the Time-Slotted Channel Hopping the Time-Slotted Channel Hopping (TSCH) mode on which 6TiSCH is based.
(TSCH) mode 6TiSCH is based on. CoJP may also be used in other (low-power) networking technologies where
CoJP may as well be used in other (low-power) networking technologies where effi efficiency in terms of communication overhead and code footprint is important.
ciency in terms of communication overhead and code footprint is important. In such a case, it may be necessary to define through companion documents
In such a case, it may be necessary to define configuration parameters specific the configuration parameters specific to the technology in question.
to the technology in question, through companion documents. The overall process is described in <xref target="join-process-overview" format=
The overall process described in <xref target="join-process-overview"/> and the "default"/>,
configuration of the stack is specific to 6TiSCH.</t> and the configuration of the stack is specific to 6TiSCH.</t>
<t>CoJP assumes the presence of a Join Registrar/Coordinator (JRC), a cent
<t>CoJP assumes the presence of a Join Registrar/Coordinator (JRC), a central en ral entity.
tity.
The configuration defined in this document assumes that the pledge and the JRC s hare a unique symmetric cryptographic key, called PSK (pre-shared key). The configuration defined in this document assumes that the pledge and the JRC s hare a unique symmetric cryptographic key, called PSK (pre-shared key).
The PSK is used to configure OSCORE to provide a secure channel to CoJP. The PSK is used to configure OSCORE to provide a secure channel to CoJP.
How the PSK is installed is out of scope of this document: this may happen durin g the provisioning phase or by a key exchange protocol that may precede the exec ution of CoJP.</t> How the PSK is installed is out of scope of this document: this may happen durin g the provisioning phase or by a key exchange protocol that may precede the exec ution of CoJP.</t>
<t>When the pledge seeks admission to a 6TiSCH network, it first
<t>When the pledge seeks admission to a 6TiSCH network, it first synchronizes to synchronizes to it by initiating the passive scan defined in
it, by initiating the passive scan defined in <xref target="IEEE802.15.4"/>. <xref target="IEEE802.15.4" format="default"/>.
The pledge then exchanges CoJP messages with the JRC; for this end-to-end commun The pledge then exchanges CoJP messages with the JRC; for this end-to-end
ication to happen, messages are forwarded by nodes already part of the 6TiSCH ne communication to happen, the messages are forwarded by nodes, called Join Proxie
twork, called Join Proxies. s,
The messages exchanged allow the JRC and the pledge to mutually authenticate, ba that are already part of the 6TiSCH network.
sed on the properties provided by OSCORE. The messages exchanged allow the JRC and the pledge to mutually
They also allow the JRC to configure the pledge with link-layer keying material, authenticate based on the properties provided by OSCORE.
short identifier and other parameters. They also allow the JRC to configure the pledge with link-layer
After this secure join process successfully completes, the joined node can inter keying material, a short identifier, and other parameters.
act with its neighbors to request additional bandwidth using the 6top Protocol < After this secure join process successfully completes, the joined node
xref target="RFC8480"/> and start sending application traffic.</t> can interact with its neighbors to request additional bandwidth using
the 6TiSCH Operation Sublayer (6top) Protocol <xref target="RFC8480" format="def
<!-- ====================================================================== --> ault"/>
and can start sending application traffic.</t>
</section> </section>
<section anchor="terminology" title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this d
ocument are to be interpreted as described in BCP14 <xref target="RFC2119"/> <xr
ef target="RFC8174"/> when, and only when, they appear in all capitals, as shown
here.</t>
<t>The reader is expected to be familiar with the terms and concepts defined in
<xref target="I-D.ietf-6tisch-architecture"/>,
<xref target="RFC7252"/>,
<xref target="RFC8613"/>, and
<xref target="RFC8152"/>.</t>
<t>The specification also includes a set of informative specifications using the <section anchor="terminology" numbered="true" toc="default">
Concise data definition language (CDDL) <xref target="I-D.ietf-cbor-cddl"/>.</t <name>Terminology</name>
>
<t>The following terms defined in <xref target="I-D.ietf-6tisch-architecture"/>
are used extensively throughout this document:</t>
<t><list style="symbols">
<t>pledge</t>
<t>joined node</t>
<t>join proxy (JP)</t>
<t>join registrar/coordinator (JRC)</t>
<t>enhanced beacon (EB)</t>
<t>join protocol</t>
<t>join process</t>
</list></t>
<t>The following terms defined in <xref target="RFC8505"/> are also used through
out this document:</t>
<t><list style="symbols">
<t>6LoWPAN Border Router (6LBR)</t>
<t>6LoWPAN Node (6LN)</t>
</list></t>
<t>The term "6LBR" is used interchangeably with the term "DODAG root" defined in <t>
<xref target="RFC6550"/>, on the assumption that the two entities are co-locate The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
d, as recommended by <xref target="I-D.ietf-6tisch-architecture"/>.</t> "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP 14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
<t>The term "pledge", as used throughout the document, explicitly denotes non-6L <t>The reader is expected to be familiar with the terms and concepts defin
BR devices attempting to join the network using their IEEE Std 802.15.4 network ed in
interface. <xref target="RFC9030" format="default"/>,
<xref target="RFC7252" format="default"/>,
<xref target="RFC8613" format="default"/>, and
<xref target="RFC8152" format="default"/>.</t>
<t>The specification also includes a set of informative specifications usi
ng the Concise Data Definition Language (CDDL) <xref target="RFC8610" format="de
fault"/>.</t>
<t>The following terms defined in <xref target="RFC9030" format="default"/
>
are used extensively throughout this document:</t>
<ul spacing="normal">
<li>pledge</li>
<li>joined node</li>
<li>Join Proxy (JP)</li>
<li>Join Registrar/Coordinator (JRC)</li>
<li>Enhanced Beacon (EB)</li>
<li>join protocol</li>
<li>join process</li>
</ul>
<t>The following terms defined in <xref target="RFC8505" format="default"/
> are also used throughout this document:</t>
<ul spacing="normal">
<li>6LoWPAN Border Router (6LBR)</li>
<li>6LoWPAN Node (6LN)</li>
</ul>
<t>The term "6LBR" is used interchangeably with the term "DODAG root"
defined in <xref target="RFC6550" format="default"/> on the assumption that
the two entities are co-located, as recommended by
<xref target="RFC9030" format="default"/>.</t>
<t>The term "pledge", as used throughout the document, explicitly denotes
non-6LBR devices attempting to join the network using their IEEE Std 802.15.4 ne
twork interface.
The device that attempts to join as the 6LBR of the network and does so over ano ther network interface is explicitly denoted as the "6LBR pledge". The device that attempts to join as the 6LBR of the network and does so over ano ther network interface is explicitly denoted as the "6LBR pledge".
When the text equally applies to the pledge and the 6LBR pledge, the "(6LBR) ple When the text applies equally to the pledge and the 6LBR pledge,
dge" form is used.</t> the "(6LBR) pledge" form is used.</t>
<t>In addition, we use generic terms "pledge identifier" and "network iden
<t>In addition, we use generic terms "pledge identifier" and "network identifier tifier".
". See <xref target="provisioning" format="default"/>.</t>
See <xref target="provisioning"/>.</t>
<!-- ====================================================================== -->
</section> </section>
<section anchor="provisioning" title="Provisioning Phase"> <section anchor="provisioning" numbered="true" toc="default">
<name>Provisioning Phase</name>
<t>The (6LBR) pledge is provisioned with certain parameters before attempting to <t>The (6LBR) pledge is provisioned with certain parameters before attempt
join the network, and the same parameters are provisioned to the JRC. ing to join the network, and the same parameters are provisioned to the JRC.
There are many ways by which this provisioning can be done. There are many ways by which this provisioning can be done.
Physically, the parameters can be written into the (6LBR) pledge using a number Physically, the parameters can be written into the (6LBR) pledge with a number o
of mechanisms, such as f mechanisms, such as
a JTAG interface, using a JTAG (Joint Test Action Group) interface,
a serial (craft) console interface, using a serial (craft) console interface,
pushing buttons simultaneously on different devices, pushing buttons simultaneously on different devices,
over-the-air configuration in a Faraday cage, etc. configuring over-the-air in a Faraday cage, etc.
The provisioning can be done by the vendor, the manufacturer, the integrator, et c.</t> The provisioning can be done by the vendor, the manufacturer, the integrator, et c.</t>
<t>Details of how this provisioning is done are out of scope of this docum
<t>Details of how this provisioning is done is out of scope of this document. ent.
What is assumed is that there can be a secure, private conversation between the JRC and the (6LBR) pledge, and that the two devices can exchange the parameters. </t> What is assumed is that there can be a secure, private conversation between the JRC and the (6LBR) pledge, and that the two devices can exchange the parameters. </t>
<t>Parameters that are provisioned to the (6LBR) pledge include:</t>
<t>Parameters that are provisioned to the (6LBR) pledge include:</t> <dl spacing="normal">
<dt>pledge identifier:</dt>
<t><list style="symbols"> <dd>The pledge identifier identifies the (6LBR) pledge.
<t>pledge identifier. The pledge identifier <bcp14>MUST</bcp14> be unique in the set of all pledge ide
The pledge identifier identifies the (6LBR) pledge. ntifiers managed by a JRC.
The pledge identifier MUST be unique in the set of all pledge identifiers manage The pledge identifier uniqueness is an important security requirement,
d by a JRC. as discussed in <xref target="sec_considerations" format="default"/>.
The pledge identifier uniqueness is an important security requirement, as discus The pledge identifier is typically the globally unique 64-bit Extended
sed in <xref target="sec_considerations"/>. Unique Identifier (EUI-64) of the IEEE Std 802.15.4 device, in which
The pledge identifier is typically the globally unique 64-bit Extended Unique Id case it is provisioned by the hardware manufacturer. The pledge
entifier (EUI-64) of the IEEE Std 802.15.4 device, in which case it is provision identifier is used to generate the IPv6 addresses of the (6LBR)
ed by the hardware manufacturer. pledge and to identify it during the execution of the join protocol.
The pledge identifier is used to generate the IPv6 addresses of the (6LBR) pledg Depending on the configuration, the pledge identifier may also be
e and to identify it during the execution of the join protocol. used after the join process to identify the joined node.
Depending on the configuration, the pledge identifier may also be used after the For privacy reasons (see <xref target="privacy_considerations" format="default"/
join process to identify the joined node. >),
For privacy reasons (see <xref target="privacy_considerations"/>), it is possibl it is possible to use a pledge identifier different from the EUI-64.
e to use a pledge identifier different from the EUI-64. For example, a pledge identifier may be a random byte string,
For example, a pledge identifier may be a random byte string, but care needs to but care needs to be taken that such a string meets the uniqueness requirement.<
be taken that such a string meets the uniqueness requirement.</t> /dd>
<t>Pre-Shared Key (PSK). <dt>Pre-Shared Key (PSK):</dt>
A symmetric cryptographic key shared between the (6LBR) pledge and the JRC. <dd>A symmetric cryptographic key shared between the (6LBR) pledge and the JRC.
To look up the PSK for a given pledge, the JRC additionally needs to store the c To look up the PSK for a given pledge, the JRC additionally needs to store
orresponding pledge identifier. the corresponding pledge identifier.
Each (6LBR) pledge MUST be provisioned with a unique PSK. Each (6LBR) pledge <bcp14>MUST</bcp14> be provisioned with a unique PSK.
The PSK MUST be a cryptographically strong key, with at least 128 bits of entrop The PSK <bcp14>MUST</bcp14> be a cryptographically strong key, with at
y, indistinguishable by feasible computation from a random uniform string of the least 128 bits of entropy, indistinguishable by feasible computation
same length. from a random uniform string of the same length.
How the PSK is generated and/or provisioned is out of scope of this specificatio n. How the PSK is generated and/or provisioned is out of scope of this specificatio n.
This could be done during a provisioning step or companion documents can specify This could be done during a provisioning step, or companion documents
the use of a key agreement protocol. can specify the use of a key-agreement protocol.
Common pitfalls when generating PSKs are discussed in <xref target="sec_consider Common pitfalls when generating PSKs are discussed in
ations"/>. <xref target="sec_considerations" format="default"/>.
In case of device re-commissioning to a new owner, the PSK MUST be changed. In the case of recommissioning a device to a new owner, the PSK <bcp14>MUST</bcp
Note that the PSK is different from the link-layer keys K1 and K2 specified in < 14> be changed.
xref target="RFC8180"/>. Note that the PSK is different from the link-layer keys K1 and K2
The PSK is a long-term secret used to protect the execution of the secure join p specified in <xref target="RFC8180" format="default"/>.
rotocol specified in this document whose one output are link-layer keys.</t> The PSK is a long-term secret used to protect the execution of the secure
<t>Optionally, a network identifier. join protocol specified in this document; the link-layer keys are transported as
The network identifier identifies the 6TiSCH network. part of the secure join protocol.</dd>
The network identifier MUST be carried within Enhanced Beacon (EB) frames. <dt>Optionally, a network identifier:</dt>
Typically, the 16-bit Personal Area Network Identifier (PAN ID) defined in <xref <dd>The network identifier identifies the 6TiSCH network.
target="IEEE802.15.4"/> is used as the network identifier. The network identifier <bcp14>MUST</bcp14> be carried within Enhanced Beacon (EB
However, PAN ID is not considered a stable network identifier as it may change d ) frames.
uring network lifetime if a collision with another network is detected. Typically, the 16-bit Personal Area Network Identifier (PAN ID)
Companion documents can specify the use of a different network identifier for jo defined in <xref target="IEEE802.15.4" format="default"/> is used as the network
in purposes, but this is out of scope of this specification. identifier.
Provisioning the network identifier to a pledge is RECOMMENDED. However, PAN ID is not considered a stable network identifier as it may change d
However, due to operational constraints, the network identifier may not be known uring network
at the time when the provisioning is done. lifetime if a collision with another network is detected.
In case this parameter is not provisioned to the pledge, the pledge attempts to Companion documents can specify the use of a different network identifier for jo
join one advertised network at a time, which significantly prolongs the join pro in purposes,
cess. but this is out of scope of this specification.
This parameter MUST be provisioned to the 6LBR pledge.</t> Provisioning the network identifier to a pledge is <bcp14>RECOMMENDED</bcp14>.
<t>Optionally, any non-default algorithms. However, due to operational constraints, the network identifier may not be
The default algorithms are specified in <xref target="mti_algos"/>. known at the time of provisioning.
When algorithm identifiers are not provisioned, the use of these default algorit If this parameter is not provisioned to the pledge, the pledge
hms is implied.</t> will attempt to join one advertised network at a time, which significantly prolo
</list></t> ngs the join process.
This parameter <bcp14>MUST</bcp14> be provisioned to the 6LBR pledge.</dd>
<t>Additionally, the 6LBR pledge that is not co-located with the JRC needs to be <dt>Optionally, any non-default algorithms:</dt>
provisioned with:</t> <dd>The default algorithms are specified in <xref target="mti_algos" format="def
ault"/>.
<t><list style="symbols"> When algorithm identifiers are not provisioned, the use of these default algorit
<t>Global IPv6 address of the JRC. hms is implied.</dd>
This address is used by the 6LBR pledge to address the JRC during the join proce </dl>
ss. <t>Additionally, the 6LBR pledge that is not co-located
The 6LBR pledge may also obtain the IPv6 address of the JRC through other availa with the JRC needs to be provisioned with the following:</t>
ble mechanisms, such as DHCPv6 <xref target="RFC8415"/>, GRASP <xref target="I-D <dl spacing="normal">
.ietf-anima-grasp"/>, mDNS <xref target="RFC6762"/>, the use of which is out of <dt>Global IPv6 address of the JRC:</dt>
scope of this document. <dd>This address is used by the 6LBR pledge to address the JRC during the join p
Pledges do not need to be provisioned with this address as they discover it dyna rocess.
mically through CoJP.</t> The 6LBR pledge may also obtain the IPv6 address of the JRC through other availa
</list></t> ble
mechanisms, such as DHCPv6 <xref target="RFC8415" format="default"/>,
<!-- ====================================================================== --> Generic Autonomic Signaling Protocol (GRASP) <xref target="RFC8990" format="defa
ult"/>,
or Multicast DNS (mDNS) <xref target="RFC6762" format="default"/>;
the use of these mechanisms is out of scope of this document.
Pledges do not need to be provisioned with this address as they
discover it dynamically through CoJP.</dd>
</dl>
</section> </section>
<section anchor="join-process-overview" title="Join Process Overview"> <section anchor="join-process-overview" numbered="true" toc="default">
<name>Join Process Overview</name>
<t>This section describes the steps taken by a pledge in a 6TiSCH network. <t>This section describes the steps taken by a pledge in a 6TiSCH network.
When a pledge seeks admission to a 6TiSCH network, the following exchange occurs :</t> When a pledge seeks admission to a 6TiSCH network, the following exchange occurs :</t>
<ol spacing="normal" type="1">
<t><list style="numbers"> <li>The pledge listens for an Enhanced Beacon (EB) frame <xref target="I
<t>The pledge listens for an Enhanced Beacon (EB) frame <xref target="IEEE802. EEE802.15.4" format="default"/>.
15.4"/>. This frame provides network synchronization information,
This frame provides network synchronization information, and tells the device wh telling the device when it can send a frame to the node
en it can send a frame to the node sending the beacons, which acts as a Join Pro sending the beacons, which acts as a Join Proxy (JP) for the pledge,
xy (JP) for the pledge, and when it can expect to receive a frame. and when it can expect to receive a frame.
The Enhanced Beacon provides the link-layer address of the JP and it may also pr The EB provides the link-layer address of the JP,
ovide its link-local IPv6 address.</t> and it may also provide its link-local IPv6 address.</li>
<t>The pledge configures its link-local IPv6 address and advertises it to the <li>The pledge configures its link-local IPv6 address and advertises it
JP using Neighbor Discovery. to the JP using Neighbor Discovery.
The advertisement step may be omitted if the link-local address has been derived The advertisement step may be omitted if the link-local address has been derived
from a known unique interface identifier, such as an EUI-64 address.</t> from a known unique interface identifier, such as an EUI-64 address.</li>
<t>The pledge sends a Join Request to the JP in order to securely identify its <li>The pledge sends a Join Request to the JP in order to securely ident
elf to the network. ify itself to the network.
The Join Request is forwarded to the JRC.</t> The Join Request is forwarded to the JRC.</li>
<t>In case of successful processing of the request, the pledge receives a Join <li>In the case of successful processing of the request, the pledge rece
Response from the JRC (via the JP). ives a Join Response from the JRC (via the JP).
The Join Response contains configuration parameters necessary for the pledge to The Join Response contains configuration parameters necessary for the pledge to
join the network.</t> join the network.</li>
</list></t> </ol>
<t>From the pledge's perspective, joining is a local phenomenon --
<t>From the pledge's perspective, joining is a local phenomenon &#8211; the pled the pledge only interacts with the JP, and it needs not know how far it
ge only interacts with the JP, and it needs not know how far it is from the 6LBR is from the 6LBR or how to route to the JRC.
, or how to route to the JRC.
Only after establishing one or more link-layer keys does it need to know about t he particulars of a 6TiSCH network.</t> Only after establishing one or more link-layer keys does it need to know about t he particulars of a 6TiSCH network.</t>
<t>The join process is shown as a transaction diagram in <xref target="fig
<t>The join process is shown as a transaction diagram in <xref target="fig_overv _overview_diagram" format="default"/>:</t>
iew_diagram"/>:</t> <figure anchor="fig_overview_diagram">
<name>Overview of a successful join process.</name>
<figure title="Overview of a successful join process." anchor="fig_overview_diag <artwork align="center" name="" type="" alt=""><![CDATA[
ram"><artwork align="center"><![CDATA[
+--------+ +-------+ +--------+ +--------+ +-------+ +--------+
| pledge | | JP | | JRC | | pledge | | JP | | JRC |
| | | | | | | | | | | |
+--------+ +-------+ +--------+ +--------+ +-------+ +--------+
| | | | | |
|<---Enhanced Beacon (1)---| | |<---Enhanced Beacon (1)---| |
| | | | | |
|<-Neighbor Discovery (2)->| | |<-Neighbor Discovery (2)->| |
| | | | | |
|-----Join Request (3a)----|----Join Request (3a)---->| \ |-----Join Request (3a)----|----Join Request (3a)---->| \
| | | | CoJP | | | | CoJP
|<----Join Response (3b)---|----Join Response (3b)----| / |<----Join Response (3b)---|----Join Response (3b)----| /
| | | | | |
]]></artwork></figure> ]]></artwork>
</figure>
<t>As for other nodes in the network, the 6LBR node may act as the JP. <t>As for other nodes in the network, the 6LBR node may act as the JP.
The 6LBR may in addition be co-located with the JRC.</t> The 6LBR may in addition be co-located with the JRC.</t>
<t>The details of each step are described in the following sections.</t>
<t>The details of each step are described in the following sections.</t> <section anchor="step-eb" numbered="true" toc="default">
<name>Step 1 - Enhanced Beacon</name>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> <t>The pledge synchronizes to the network by listening for,
and receiving, an EB sent by a node already in the network.
<section anchor="step-eb" title="Step 1 - Enhanced Beacon"> This process is entirely defined by <xref target="IEEE802.15.4" format="default"
/>
<t>The pledge synchronizes to the network by listening for, and receiving, an En and described in <xref target="RFC7554" format="default"/>.</t>
hanced Beacon (EB) sent by a node already in the network. <t>Once the pledge hears an EB, it synchronizes to the joining schedule
This process is entirely defined by <xref target="IEEE802.15.4"/>, and described using the cells contained in the EB.
in <xref target="RFC7554"/>.</t> The pledge can hear multiple EBs; the selection of which EB to use
is out of the scope for this document and is discussed in <xref target="RFC7554"
<t>Once the pledge hears an EB, it synchronizes to the joining schedule using th format="default"/>.
e cells contained in the EB. Implementers should make use of information such as the following:
The pledge can hear multiple EBs; the selection of which EB to use is out of the which network identifier the EB contains,
scope for this document, and is discussed in <xref target="RFC7554"/>.
Implementers should make use of information such as:
what network identifier the EB contains,
the value of the Join Metric field within EBs, the value of the Join Metric field within EBs,
whether the source link-layer address of the EB has been tried before, whether the source link-layer address of the EB has been tried before,
what signal strength the different EBs were received at, etc. at which signal strength the different EBs were received, etc.
In addition, the pledge may be pre-configured to search for EBs with a specific In addition, the pledge may be preconfigured to search for EBs with a specific n
network identifier.</t> etwork identifier.</t>
<t>If the pledge is not provisioned with the network identifier,
<t>If the pledge is not provisioned with the network identifier, it attempts to it attempts to join one network at a time, as described in <xref target="join_re
join one network at a time, as described in <xref target="join_request"/>.</t> quest" format="default"/>.</t>
<t>Once the pledge selects the EB, it synchronizes to it and transitions
<t>Once the pledge selects the EB, it synchronizes to it and transitions into a into a low-power mode.
low-power mode. It follows the schedule information contained in the EB,
It follows the schedule information contained in the EB which indicates the slot which indicates the slots that the pledge may use for the join process.
s that the pledge may use for the join process.
During the remainder of the join process, the node that has sent the EB to the p ledge acts as the JP.</t> During the remainder of the join process, the node that has sent the EB to the p ledge acts as the JP.</t>
<t>At this point, the pledge may either proceed to step 2 or
<t>At this point, the pledge may proceed to step 2, or continue to listen for ad continue to listen for additional EBs.</t>
ditional EBs.</t>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
</section> </section>
<section anchor="step-nd" title="Step 2 - Neighbor Discovery"> <section anchor="step-nd" numbered="true" toc="default">
<name>Step 2 - Neighbor Discovery</name>
<t>The pledge forms its link-local IPv6 address based on the interface identifie <t>The pledge forms its link-local IPv6 address based on
r, as per <xref target="RFC4944"/>. the interface identifier per <xref target="RFC4944" format="default"/>.
The pledge MAY perform the Neighbor Solicitation / Neighbor Advertisement exchan The pledge <bcp14>MAY</bcp14> perform the Neighbor Solicitation / Neighbor Adver
ge with the JP, as per Section 5.6 of <xref target="RFC8505"/>. tisement
As per <xref target="RFC8505"/>, there is no need to perform duplicate address d exchange with the JP per <xref target="RFC8505" section="5.6" sectionFormat="of"
etection for the link-local address. format="default"/>.
Per <xref target="RFC8505" format="default"/>, there is no need to perform dupli
cate address detection for the link-local address.
The pledge and the JP use their link-local IPv6 addresses for all subsequent com munication during the join process.</t> The pledge and the JP use their link-local IPv6 addresses for all subsequent com munication during the join process.</t>
<t>Note that Neighbor Discovery exchanges at this point are not protecte
<t>Note that Neighbor Discovery exchanges at this point are not protected with l d with link-layer security as the pledge is not in possession of the keys.
ink-layer security as the pledge is not in possession of the keys. How the JP accepts these unprotected frames is discussed in <xref target="llreq"
How the JP accepts these unprotected frames is discussed in <xref target="llreq" format="default"/>.</t>
/>.</t>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
</section> </section>
<section anchor="step-cojp" title="Step 3 - Constrained Join Protocol (CoJP) Exe <section anchor="step-cojp" numbered="true" toc="default">
cution"> <name>Step 3 - Constrained Join Protocol (CoJP) Execution</name>
<t>The pledge triggers the join exchange of the Constrained Join Protoco
<t>The pledge triggers the join exchange of the Constrained Join Protocol (CoJP) l (CoJP).
. The join exchange consists of two messages: the Join Request message
The join exchange consists of two messages: the Join Request message (Step 3a), (<xref target="step-join-request">Step 3a</xref>)
and the Join Response message conditioned on the successful security processing and the Join Response message, conditioned on the successful security
of the request (Step 3b).</t> processing of the request (<xref target="step-join-response">Step 3b</xref>).</t
>
<t>All CoJP messages are exchanged over a secure end-to-end channel that provide <t>All CoJP messages are exchanged over a secure end-to-end
s confidentiality, data authenticity and replay protection. channel that provides confidentiality, data authenticity, and replay protection.
Frames carrying CoJP messages are not protected with link-layer security when ex changed between the pledge and the JP as the pledge is not in possession of the link-layer keys in use. Frames carrying CoJP messages are not protected with link-layer security when ex changed between the pledge and the JP as the pledge is not in possession of the link-layer keys in use.
How JP and pledge accept these unprotected frames is discussed in <xref target=" llreq"/>. How the JP and pledge accept these unprotected frames is discussed in <xref targ et="llreq" format="default"/>.
When frames carrying CoJP messages are exchanged between nodes that have already joined the network, the link-layer security is applied according to the securit y configuration used in the network.</t> When frames carrying CoJP messages are exchanged between nodes that have already joined the network, the link-layer security is applied according to the securit y configuration used in the network.</t>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> <section anchor="step-join-request" numbered="true" toc="default">
<name>Step 3a - Join Request</name>
<section anchor="step-join-request" title="Step 3a - Join Request"> <t>The Join Request is a message sent from the pledge to the JP,
and which the JP forwards to the JRC.
<t>The Join Request is a message sent from the pledge to the JP, and which the J
P forwards to the JRC.
The pledge indicates in the Join Request the role it requests to play in the net work, as well as the identifier of the network it requests to join. The pledge indicates in the Join Request the role it requests to play in the net work, as well as the identifier of the network it requests to join.
The JP forwards the Join Request to the JRC on the existing links. The JP forwards the Join Request to the JRC on the existing links.
How exactly this happens is out of scope of this document; some networks may wis How exactly this happens is out of scope of this document; some networks
h to dedicate specific link layer resources for this join traffic.</t> may wish to dedicate specific link-layer resources for this join traffic.</t>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
</section> </section>
<section anchor="step-join-response" title="Step 3b - Join Response"> <section anchor="step-join-response" numbered="true" toc="default">
<name>Step 3b - Join Response</name>
<t>The Join Response is sent by the JRC to the pledge, and is forwarded through <t>The Join Response is sent by the JRC to the pledge, and it is forwa
the JP. rded through the JP.
The packet containing the Join Response travels from the JRC to the JP using the operating routes in the network. The packet containing the Join Response travels from the JRC to the JP using the operating routes in the network.
The JP delivers it to the pledge. The JP delivers it to the pledge.
The JP operates as an application-layer proxy, see <xref target="join_proxy"/>.< The JP operates as an application-layer proxy, see <xref target="join_proxy" for
/t> mat="default"/>.</t>
<t>The Join Response contains various parameters needed by
<t>The Join Response contains different parameters needed by the pledge to becom the pledge to become a fully operational network node.
e a fully operational network node.
These parameters include 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 the pledge to operate as the JP, among others.</t> These parameters include 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 the pledge to operate as the JP, among others.</t>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
</section> </section>
</section> </section>
<section anchor="the-special-case-of-the-6lbr-pledge-joining" title="The Special <section anchor="the-special-case-of-the-6lbr-pledge-joining" numbered="tr
Case of the 6LBR Pledge Joining"> ue" toc="default">
<name>The Special Case of the 6LBR Pledge Joining</name>
<t>The 6LBR pledge performs <xref target="step-cojp"/> of the join process descr <t>The 6LBR pledge performs <xref target="step-cojp" format="default"/>
ibed above, just as any other pledge, albeit over a different network interface. of the join process just like any other pledge, albeit over a different network
There is no JP intermediating the communication between the 6LBR pledge and the interface.
JRC, as described in <xref target="netreq"/>. There is no JP intermediating the communication between the 6LBR pledge and the
JRC, as described in <xref target="netreq" format="default"/>.
The other steps of the described join process do not apply to the 6LBR pledge. The other steps of the described join process do not apply to the 6LBR pledge.
How the 6LBR pledge obtains an IPv6 address and triggers the execution of the Co How the 6LBR pledge obtains an IPv6 address and triggers the execution
JP protocol is out of scope of this document.</t> of CoJP is out of scope of this document.</t>
<!-- ====================================================================== -->
</section> </section>
</section> </section>
<section anchor="llreq" title="Link-layer Configuration"> <section anchor="llreq" numbered="true" toc="default">
<name>Link-Layer Configuration</name>
<t>In an operational 6TiSCH network, all frames use link-layer frame security <x <t>In an operational 6TiSCH network, all frames use link-layer frame secur
ref target="RFC8180"/>. ity <xref target="RFC8180" format="default"/>.
The IEEE Std 802.15.4 security attributes include frame authenticity, and option The IEEE Std 802.15.4 security attributes include frame authenticity
ally frame confidentiality (i.e. encryption).</t> and optionally frame confidentiality (i.e., encryption).</t>
<t>Any node sending EB frames <bcp14>MUST</bcp14> be prepared to act as a
<t>Any node sending EB frames MUST be prepared to act as a JP for potential pled JP for potential pledges.</t>
ges.</t> <t>The pledge does not initially perform an authenticity check of the EB f
rames
<t>The pledge does not initially do any authenticity check of the EB frames, as because it does not possess the link-layer key(s) in use.
it does not possess the link-layer key(s) in use. The pledge is still able to parse the contents of the received EBs and
The pledge is still able to parse the contents of the received EBs and synchroni synchronize to the network, as EBs are not encrypted <xref target="RFC8180" form
ze to the network, as EBs are not encrypted <xref target="RFC8180"/>.</t> at="default"/>.</t>
<t>When sending frames during the join process, the pledge sends unencrypt
<t>When sending frames during the join process, the pledge sends unencrypted and ed and unauthenticated frames at the link layer.
unauthenticated frames at the link layer.
In order for the join process to be possible, the JP must accept these unsecured frames for the duration of the join process. In order for the join process to be possible, the JP must accept these unsecured frames for the duration of the join process.
This behavior may be implemented by setting the "secExempt" attribute in the IEE E Std 802.15.4 security configuration tables. This behavior may be implemented by setting the "secExempt" attribute in the IEE E Std 802.15.4 security configuration tables.
It is expected that the lower layer provides an interface to indicate to the upp It is expected that the lower layer provides an interface to indicate to
er layer that unsecured frames are being received from a device, and that the up the upper layer that unsecured frames are being received from a device.
per layer can use that information to make a determination that a join process i The upper layer can use that information to determine that a join process
s in place and the unsecured frames should be processed. is in place and that the unsecured frames should be processed.
How the JP makes such a determination and interacts with the lower layer is out of scope of this specification. How the JP makes such a determination and interacts with the lower layer is out of scope of this specification.
The JP can additionally make use of information such as the value of the join ra The JP can additionally use information such as the value of the
te parameter (<xref target="configuration_object"/>) set by the JRC, physical bu join rate parameter (<xref target="configuration_object" format="default"/>)
tton press, etc.</t> set by the JRC, physical button press, etc.</t>
<t>When the pledge initially synchronizes with the network,
<t>When the pledge initially synchronizes to the network, it has no means of ver it has no means of verifying the authenticity of EB frames.
ifying the authenticity of EB frames. Because an attacker can craft a frame that looks like a legitimate EB frame,
As an attacker can craft a frame that looks like a legitimate EB frame this open this opens up a DoS vector, as discussed in <xref target="sec_considerations" fo
s up a DoS vector, as discussed in <xref target="sec_considerations"/>.</t> rmat="default"/>.</t>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<section anchor="timedistribution" title="Distribution of Time">
<t>Nodes in a 6TiSCH network keep a global notion of time known as the absolute <section anchor="timedistribution" numbered="true" toc="default">
slot number. <name>Distribution of Time</name>
Absolute slot number is used in the construction of the link-layer nonce, as def <t>Nodes in a 6TiSCH network keep a global notion of time
ined in <xref target="IEEE802.15.4"/>. known as the Absolute Slot Number.
The pledge initially synchronizes to the EB frame sent by the JP, and uses the v The Absolute Slot Number is used in the construction of the
alue of the absolute slot number found in the TSCH Synchronization Information E link-layer nonce, as defined in <xref target="IEEE802.15.4" format="default"/>.
lement. The pledge initially synchronizes with the EB frame sent by the JP
and uses the value of the Absolute Slot Number found in the
TSCH Synchronization Information Element.
At the time of the synchronization, the EB frame can neither be authenticated no r its freshness verified. At the time of the synchronization, the EB frame can neither be authenticated no r its freshness verified.
During the join process, the pledge sends frames that are unprotected at the lin k-layer and protected end-to-end instead. During the join process, the pledge sends frames that are unprotected at the lin k-layer and protected end-to-end instead.
The pledge does not obtain the time information as the output of the join proces s as this information is local to the network and may not be known at the JRC.</ t> The pledge does not obtain the time information as the output of the join proces s as this information is local to the network and may not be known at the JRC.</ t>
<t>This enables an attack on the pledge where the attacker replays to th
<t>This enables an attack on the pledge where the attacker replays to the pledge e pledge legitimate EB frames obtained from the network and acts as a man-in-the
legitimate EB frames obtained from the network and acts as a man-in-the-middle -middle between the pledge and the JP.
between the pledge and the JP. The EB frames will make the pledge believe that the replayed Absolute Slot Numbe
The EB frames will make the pledge believe that the replayed absolute slot numbe r value is the current notion of time in the network.
r value is the current notion of time in the network.
By forwarding the join traffic to the legitimate JP, the attacker enables the pl edge to join the network. By forwarding the join traffic to the legitimate JP, the attacker enables the pl edge to join the network.
Under different conditions relating to the reuse of the pledge's short address b y the JRC or its attempt to rejoin the network, this may cause the pledge to reu se the link-layer nonce in the first frame it sends protected after the join pro cess is completed.</t> Under different conditions relating to the reuse of the pledge's short address b y the JRC or its attempt to rejoin the network, this may cause the pledge to reu se the link-layer nonce in the first frame it sends protected after the join pro cess is completed.</t>
<t>For this reason, all frames originated at the JP and
<t>For this reason, all frames originated at the JP and destined to the pledge d destined to the pledge during the join process <bcp14>MUST</bcp14>
uring the join process MUST be authenticated at the link-layer using the key tha be authenticated at the link layer using the key that is normally in use in the
t is normally in use in the network. network.
Link-layer security processing at the pledge for these frames will fail as the p ledge is not yet in possession of the key. Link-layer security processing at the pledge for these frames will fail as the p ledge is not yet in possession of the key.
The pledge acknowledges these frames without link-layer security, and JP accepts the unsecured acknowledgment due to the secExempt attribute set for the pledge. The pledge acknowledges these frames without link-layer security, and JP accepts the unsecured acknowledgment due to the secExempt attribute set for the pledge.
The frames should be passed to the upper layer for processing using the promiscu The frames should be passed to the upper layer for processing using the promiscu
ous mode of <xref target="IEEE802.15.4"/> or another appropriate mechanism. ous mode of <xref target="IEEE802.15.4" format="default"/> or another appropriat
When the upper layer processing on the pledge is completed and the link-layer ke e mechanism.
ys are configured, the upper layer MUST trigger the security processing of the c When the upper-layer processing on the pledge is completed,
orresponding frame. and the link-layer keys are configured, the upper layer <bcp14>MUST</bcp14>
Once the security processing of the frame carrying the Join Response message is trigger the security processing of the corresponding frame.
successful, the current absolute slot number kept locally at the pledge SHALL be Once the security processing of the frame carrying the Join Response
declared as valid.</t> message is successful, the current Absolute Slot Number kept locally
at the pledge <bcp14>SHALL</bcp14> be declared as valid.</t>
<!-- ====================================================================== -->
</section> </section>
</section> </section>
<section anchor="netreq" title="Network-layer Configuration"> <section anchor="netreq" numbered="true" toc="default">
<name>Network-Layer Configuration</name>
<t>The pledge and the JP SHOULD keep a separate neighbor cache for untrusted ent <t>The pledge and the JP <bcp14>SHOULD</bcp14> keep a separate neighbor ca
ries and use it to store each other's information during the join process. che for untrusted entries and use it to store each other's information during th
Mixing neighbor entries belonging to pledges and nodes that are part of the netw e join process.
ork opens up the JP to a DoS attack, as the attacker may fill JP's neighbor tabl Mixing neighbor entries belonging to pledges and nodes that are
e and prevent the discovery of legitimate neighbors.</t> part of the network opens up the JP to a DoS attack, as the attacker
may fill the JP's neighbor table and prevent the discovery of legitimate neighbo
<t>Once the pledge obtains link-layer keys and becomes a joined node, it is able rs.</t>
to securely communicate with its neighbors, obtain the network IPv6 prefix and <t>Once the pledge obtains link-layer keys and becomes a joined node,
form its global IPv6 address. it is able to securely communicate with its neighbors,
The joined node then undergoes an independent process to bootstrap its neighbor obtain the network IPv6 prefix, and form its global IPv6 address.
cache entries, possibly with a node that formerly acted as a JP, following <xref The joined node then undergoes an independent process to bootstrap its neighbor
target="RFC8505"/>. cache entries, possibly with a node that formerly acted as a JP, following <xref
target="RFC8505" format="default"/>.
From the point of view of the JP, there is no relationship between the neighbor cache entry belonging to a pledge and the joined node that formerly acted as a p ledge.</t> From the point of view of the JP, there is no relationship between the neighbor cache entry belonging to a pledge and the joined node that formerly acted as a p ledge.</t>
<t>The pledge does not communicate with the JRC at the network layer.
<t>The pledge does not communicate with the JRC at the network layer.
This allows the pledge to join without knowing the IPv6 address of the JRC. This allows the pledge to join without knowing the IPv6 address of the JRC.
Instead, the pledge communicates with the JP at the network layer using link-loc Instead, the pledge communicates with the JP at the network layer using link-loc
al addressing, and with the JRC at the application layer, as specified in <xref al addressing, and with the JRC at the application layer, as specified in <xref
target="join_proxy"/>.</t> target="join_proxy" format="default"/>.</t>
<t>The JP communicates with the JRC over global IPv6 addresses.
<t>The JP communicates with the JRC over global IPv6 addresses.
The JP discovers the network IPv6 prefix and configures its global IPv6 address upon successful completion of the join process and the obtention of link-layer k eys. The JP discovers the network IPv6 prefix and configures its global IPv6 address upon successful completion of the join process and the obtention of link-layer k eys.
The pledge learns the IPv6 address of the JRC from the Join Response, as specifi The pledge learns the IPv6 address of the JRC from the Join Response, as specifi
ed in <xref target="join_response"/>; it uses it once joined in order to operate ed in <xref target="join_response" format="default"/>; it uses it once joined in
as a JP.</t> order to operate as a JP.</t>
<t>As a special case, the 6LBR pledge may have an additional
<t>As a special case, the 6LBR pledge may have an additional network interface t network interface that it uses in order to obtain the configuration
hat it uses in order to obtain the configuration parameters from the JRC and sta parameters from the JRC and to start advertising the 6TiSCH network.
rt advertising the 6TiSCH network. This additional interface needs to be configured with a global IPv6 address,
This additional interface needs to be configured with a global IPv6 address, by by a mechanism that is out of scope of this document.
a mechanism that is out of scope of this document.
The 6LBR pledge uses this interface to directly communicate with the JRC using g lobal IPv6 addressing.</t> The 6LBR pledge uses this interface to directly communicate with the JRC using g lobal IPv6 addressing.</t>
<t>The JRC can be co-located on the 6LBR.
<t>The JRC can be co-located on the 6LBR.
In this special case, the IPv6 address of the JRC can be omitted from the Join R esponse message for space optimization. In this special case, the IPv6 address of the JRC can be omitted from the Join R esponse message for space optimization.
The 6LBR then MUST set the DODAGID field in the RPL DIOs <xref target="RFC6550"/ The 6LBR then <bcp14>MUST</bcp14> set the DODAGID field in the RPL
> to its IPv6 address. DODAG Information Objects (DIOs) <xref target="RFC6550" format="default"/> to it
The pledge learns the address of the JRC once joined and upon the reception of t s IPv6 address.
he first RPL DIO message, and uses it to operate as a JP.</t> The pledge learns the address of the JRC once joined and upon the
reception of the first RPL DIO message, and uses it to operate as a JP.</t>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<section anchor="traffic_join_request" title="Identification of Unauthenticated
Traffic">
<t>The traffic that is proxied by the Join Proxy (JP) comes from unauthenticated <section anchor="traffic_join_request" numbered="true" toc="default">
pledges, and there may be an arbitrary amount of it. <name>Identification of Unauthenticated Traffic</name>
<t>The traffic that is proxied by the JP comes from unauthenticated pled
ges, and there may be an arbitrary amount of it.
In particular, an attacker may send fraudulent traffic in an attempt to overwhel m the network.</t> In particular, an attacker may send fraudulent traffic in an attempt to overwhel m the network.</t>
<t>When operating as part of a 6TiSCH minimal network
<t>When operating as part of a <xref target="RFC8180"/> 6TiSCH minimal network u <xref target="RFC8180" format="default"/> using distributed scheduling algorithm
sing distributed scheduling algorithms, the traffic from unauthenticated pledges s,
may cause intermediate nodes to request additional bandwidth. the traffic from unauthenticated pledges may cause intermediate nodes to request
additional bandwidth.
An attacker could use this property to cause the network to overcommit bandwidth (and energy) to the join process.</t> An attacker could use this property to cause the network to overcommit bandwidth (and energy) to the join process.</t>
<t>The JP is aware of what traffic originates from unauthenticated pledg
<t>The Join Proxy is aware of what traffic originates from unauthenticated pledg es, and so can avoid allocating additional bandwidth itself.
es, and so can avoid allocating additional bandwidth itself. The JP implements a data cap on outgoing join traffic by
The Join Proxy implements a data cap on outgoing join traffic by implementing th implementing the recommendation of 1 packet per 3 seconds in
e recommendation of 1 packet per 3 seconds in Section 3.1.3 of <xref target="RFC <xref target="RFC8085" section="3.1.3" sectionFormat="of" format="default"/>.
8085"/>. This can be achieved with the congestion control mechanism
This can be achieved with the congestion control mechanism specified in Section specified in <xref target="RFC7252" section="4.7" sectionFormat="of" format="def
4.7 of <xref target="RFC7252"/>. ault"/>.
This cap will not protect intermediate nodes as they can not tell join traffic f This cap will not protect intermediate nodes as they cannot tell join traffic fr
rom regular traffic. om regular traffic.
Despite the data cap implemented separately on each Join Proxy, the aggregate jo Despite the data cap implemented separately on each JP,
in traffic from many Join Proxies may cause intermediate nodes to decide to allo the aggregate join traffic from many JPs may cause intermediate nodes to decide
cate additional cells. to allocate additional cells.
It is undesirable to do so in response to the traffic originated at unauthentica It is undesirable to do so in response to the traffic originated from unauthenti
ted pledges. cated pledges.
In order to permit the intermediate nodes to avoid this, the traffic needs to be tagged. In order to permit the intermediate nodes to avoid this, the traffic needs to be tagged.
<xref target="RFC2597"/> defines a set of per-hop behaviors that may be encoded <xref target="RFC2597" format="default"/> defines a set of
into the Diffserv Code Points (DSCPs). per-hop behaviors that may be encoded into the Diffserv Code Points (DSCPs).
Based on the DSCP, intermediate nodes can decide whether to act on a given packe t.</t> Based on the DSCP, intermediate nodes can decide whether to act on a given packe t.</t>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> <section anchor="traffic-from-jp-to-jrc" numbered="true" toc="default">
<name>Traffic from JP to JRC</name>
<section anchor="traffic-from-jp-to-jrc" title="Traffic from JP to JRC"> <t>The JP <bcp14>SHOULD</bcp14> set the DSCP of packets that it
produces as part of the forwarding process to AF43 code point
<t>The Join Proxy SHOULD set the DSCP of packets that it produces as part of the (See <xref target="RFC2597" section="6" sectionFormat="of" format="default"/>).
forwarding process to AF43 code point (See Section 6 of <xref target="RFC2597"/ A JP that does not require a specific DSCP value on forwarded traffic
>). should set it to zero so that it is compressed out.</t>
A Join Proxy that does not require a specific DSCP value on traffic forwarded sh <t>A Scheduling Function (SF) running on 6TiSCH nodes <bcp14>SHOULD NO
ould set it to zero so that it is compressed out.</t> T</bcp14> allocate additional cells as a result of traffic with code point AF43.
Companion SF documents <bcp14>SHOULD</bcp14> specify how this recommended behavi
<t>A Scheduling Function (SF) running on 6TiSCH nodes SHOULD NOT allocate additi or is achieved.</t>
onal cells as a result of traffic with code point AF43.
Companion SF documents SHOULD specify how this recommended behavior is achieved.
One example is the 6TiSCH Minimal Scheduling Function <xref target="I-D.ietf-6ti
sch-msf"/>.</t>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
</section> </section>
<section anchor="traffic-from-jrc-to-jp" title="Traffic from JRC to JP"> <section anchor="traffic-from-jrc-to-jp" numbered="true" toc="default">
<name>Traffic from JRC to JP</name>
<t>The JRC SHOULD set the DSCP of join response packets addressed to the Join Pr <t>The JRC <bcp14>SHOULD</bcp14> set the DSCP of
oxy to AF42 code point. Join Response packets addressed to the JP to the AF42 code point.
AF42 has lower drop probability than AF43, giving this traffic priority in buffe rs over the traffic going towards the JRC.</t> AF42 has lower drop probability than AF43, giving this traffic priority in buffe rs over the traffic going towards the JRC.</t>
<t>The 6LBR links are often the most congested within a DODAG,
<t>The 6LBR links are often the most congested within a DODAG, and from that poi and from that point down, there is progressively less (or equal) congestion.
nt down there is progressively less (or equal) congestion. If the 6LBR paces itself when sending Join Response traffic,
If the 6LBR paces itself when sending join response traffic then it ought to nev then it ought to never exceed the bandwidth allocated to the best effort traffic
er exceed the bandwidth allocated to the best effort traffic cells. cells.
If the 6LBR has the capacity (if it is not constrained) then it should provide s If the 6LBR has the capacity (if it is not constrained), then it
ome buffers in order to satisfy the Assured Forwarding behavior.</t> should provide some buffers in order to satisfy the Assured Forwarding behavior.
</t>
<t>Companion SF documents SHOULD specify how traffic with code point AF42 is han <t>Companion SF documents <bcp14>SHOULD</bcp14> specify how traffic wi
dled with respect to cell allocation. th code point AF42 is handled with respect to cell allocation.
In case the recommended behavior described in this section is not followed, the If the recommended behavior described in this section is not followed,
network may become prone to the attack discussed in <xref target="traffic_join_r the network may become prone to the attack discussed in <xref target="traffic_jo
equest"/>.</t> in_request" format="default"/>.</t>
<!-- ====================================================================== -->
</section> </section>
</section> </section>
</section> </section>
<section anchor="join_proxy" title="Application-level Configuration"> <section anchor="join_proxy" numbered="true" toc="default">
<name>Application-Layer Configuration</name>
<t>The CoJP join exchange in <xref target="fig_overview_diagram"/> is carried ov <t>The CoJP join exchange in <xref target="fig_overview_diagram" format="d
er CoAP <xref target="RFC7252"/> and the secure channel provided by OSCORE <xref efault"/> is carried over CoAP <xref target="RFC7252" format="default"/> and the
target="RFC8613"/>. secure channel provided by OSCORE <xref target="RFC8613" format="default"/>.
The (6LBR) pledge acts as a CoAP client; the JRC acts as a CoAP server. The (6LBR) pledge acts as a CoAP client; the JRC acts as a CoAP server.
The JP implements CoAP forward proxy functionality <xref target="RFC7252"/>. The JP implements CoAP forward proxy functionality <xref target="RFC7252" format ="default"/>.
Because the JP can also be a constrained device, it cannot implement a cache.</t > Because the JP can also be a constrained device, it cannot implement a cache.</t >
<t>The pledge designates a JP as a proxy by including the
<t>The pledge designates a JP as a proxy by including the Proxy-Scheme option in Proxy-Scheme option in the CoAP requests that it sends to the JP.
CoAP requests it sends to the JP. The pledge also includes in the requests the Uri-Host option with
The pledge also includes in the requests the Uri-Host option with its value set its value set to the well-known JRC's alias, as specified in <xref target="join_
to the well-known JRC's alias, as specified in <xref target="join_request"/>.</t request" format="default"/>.</t>
> <t>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.
<t>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 allows the JP to reach the JRC at the network layer and forward the request s on behalf of the pledge.</t> This allows the JP to reach the JRC at the network layer and forward the request s on behalf of the pledge.</t>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> <section anchor="statelessness-of-the-jp" numbered="true" toc="default">
<name>Statelessness of the JP</name>
<section anchor="statelessness-of-the-jp" title="Statelessness of the JP"> <t>The CoAP proxy defined in <xref target="RFC7252" format="default"/>
keeps per-client state information in order to forward the response towards the
<t>The CoAP proxy defined in <xref target="RFC7252"/> keeps per-client state inf originator of the request.
ormation in order to forward the response towards the originator of the request.
This state information includes at least This state information includes at least
the CoAP token, the CoAP token,
the IPv6 address of the client, and the IPv6 address of the client, and
the UDP source port number. the UDP source port number.
Since the JP can be a constrained device that acts as a CoAP proxy, memory limit Since the JP can be a constrained device that acts as a CoAP proxy,
ations make it prone to a Denial-of-Service (DoS) attack.</t> memory limitations make it prone to a DoS attack.</t>
<t>This DoS vector on the JP can be mitigated by making the JP act as a
<t>This DoS vector on the JP can be mitigated by making the JP act as a stateles stateless CoAP proxy, where "state" encompasses the information related to indiv
s CoAP proxy, where "state" encompasses the information related to individual pl idual pledges.
edges.
The JP can wrap the state it needs to keep for a given pledge throughout the net work stack in a "state object" and include it as a CoAP token in the forwarded r equest to the JRC. The JP can wrap the state it needs to keep for a given pledge throughout the net work stack in a "state object" and include it as a CoAP token in the forwarded r equest to the JRC.
The JP may use the CoAP token as defined in <xref target="RFC7252"/>, if the siz The JP may use the CoAP token as defined in <xref target="RFC7252" format="defau
e of the serialized state object permits, or use the extended CoAP token defined lt"/>,
in <xref target="I-D.ietf-core-stateless"/>, to transport the state object. if the size of the serialized state object permits, or use the extended
The JRC and any other potential proxy on the JP - JRC path MUST support extended CoAP token defined in <xref target="RFC8974" format="default"/>
token lengths, as defined in <xref target="I-D.ietf-core-stateless"/>. to transport the state object.
The JRC and any other potential proxy on the JP-JRC path <bcp14>MUST</bcp14>
support extended token lengths, as defined in <xref target="RFC8974" format="def
ault"/>.
Since the CoAP token is echoed back in the response, the JP is able to decode th e state object and configure the state needed to forward the response to the ple dge. Since the CoAP token is echoed back in the response, the JP is able to decode th e state object and configure the state needed to forward the response to the ple dge.
The information that the JP needs to encode in the state object to operate in a The information that the JP needs to encode in the state object to operate
fully stateless manner with respect to a given pledge is implementation specific in a fully stateless manner with respect to a given pledge is implementation spe
.</t> cific.</t>
<t>It is <bcp14>RECOMMENDED</bcp14> that the JP operates in a
<t>It is RECOMMENDED that the JP operates in a stateless manner and signals the stateless manner and signals the per-pledge state within the CoAP token
per-pledge state within the CoAP token, for every request it forwards into the n for every request that it forwards into the network on behalf of unauthenticated
etwork on behalf of unauthenticated pledges. pledges.
When the JP is operating in a stateless manner, the security considerations from When the JP is operating in a stateless manner, the security considerations from
<xref target="I-D.ietf-core-stateless"/> apply and the type of the CoAP message <xref target="RFC8974" format="default"/> apply, and the type of the CoAP messag
that the JP forwards on behalf of the pledge MUST be non-confirmable (NON), reg e that the JP forwards on behalf of the pledge <bcp14>MUST</bcp14> be non-confir
ardless of the message type received from the pledge. mable (NON), regardless of the message type received from the pledge.
The use of a non-confirmable message by the JP alleviates the JP from keeping Co AP message exchange state. The use of a non-confirmable message by the JP alleviates the JP from keeping Co AP message exchange state.
The retransmission burden is then entirely shifted to the pledge. The retransmission burden is then entirely shifted to the pledge.
A JP that operates in a stateless manner still needs to keep congestion control A JP that operates in a stateless manner still needs to keep congestion control
state with the JRC, see <xref target="sec_considerations"/>. state with the JRC, see <xref target="sec_considerations" format="default"/>.
Recommended values of CoAP settings for use during the join process, both by the Recommended values of CoAP settings for use during the join process, both by the
pledge and the JP, are given in <xref target="parameters"/>.</t> pledge and the JP, are given in <xref target="parameters" format="default"/>.</
t>
<t>Note that in some networking stack implementations, a fully (per-pledge) stat <t>Note that in some networking stack implementations, a fully (per-pled
eless operation of the JP may be challenging from the implementation's point of ge) stateless operation of the JP may be challenging from the implementation's p
view. oint of view.
In those cases, the JP may operate as a statefull proxy that stores the per-pled In those cases, the JP may operate as a stateful proxy that stores
ge state until the response is received or timed out, but this comes at a price the per-pledge state until the response is received or timed out, but this comes
of a DoS vector.</t> at a price of a DoS vector.</t>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
</section> </section>
<section anchor="parameters" title="Recommended Settings"> <section anchor="parameters" numbered="true" toc="default">
<name>Recommended Settings</name>
<t>This section gives RECOMMENDED values of CoAP settings during the join proces <t>This section gives <bcp14>RECOMMENDED</bcp14> values of CoAP settings
s.</t> during the join process.</t>
<table align="center">
<texttable title="Recommended CoAP settings."> <name>Recommended CoAP settings.</name>
<ttcol align='right'>Name</ttcol> <thead>
<ttcol align='left'>Default Value</ttcol> <tr>
<c>ACK_TIMEOUT</c> <th>Name</th>
<c>10 seconds</c> <th>Default Value</th>
<c>ACK_RANDOM_FACTOR</c> </tr>
<c>1.5</c> </thead>
<c>MAX_RETRANSMIT</c> <tbody>
<c>4</c> <tr>
<c>NSTART</c> <td>ACK_TIMEOUT</td>
<c>1</c> <td>10 seconds</td>
<c>DEFAULT_LEISURE</c> </tr>
<c>5 seconds</c> <tr>
<c>PROBING_RATE</c> <td>ACK_RANDOM_FACTOR</td>
<c>1 byte/second</c> <td>1.5</td>
</texttable> </tr>
<tr>
<t>These values may be configured to values specific to the deployment. <td>MAX_RETRANSMIT</td>
<td>4</td>
</tr>
<tr>
<td>NSTART</td>
<td>1</td>
</tr>
<tr>
<td>DEFAULT_LEISURE</td>
<td>5 seconds</td>
</tr>
<tr>
<td>PROBING_RATE</td>
<td>1 byte/second</td>
</tr>
</tbody>
</table>
<t>These values may be configured to values specific to the deployment.
The default values have been chosen to accommodate a wide range of deployments, taking into account dense networks.</t> The default values have been chosen to accommodate a wide range of deployments, taking into account dense networks.</t>
<t>The PROBING_RATE value at the JP is controlled by the join rate param
<t>The PROBING_RATE value at the JP is controlled by the join rate parameter, se eter, see <xref target="configuration_object" format="default"/>.
e <xref target="configuration_object"/>. Following <xref target="RFC7252" format="default"/>, the average data rate in se
Following <xref target="RFC7252"/>, the average data rate in sending to the JRC nding to the JRC must not exceed PROBING_RATE.
must not exceed PROBING_RATE. For security reasons, the average data rate <bcp14>SHOULD</bcp14>
For security reasons, the average data rate SHOULD be measured over a rather sho be measured over a rather short window, e.g., ACK_TIMEOUT,
rt window, e.g. ACK_TIMEOUT, see <xref target="sec_considerations"/>.</t> see <xref target="sec_considerations" format="default"/>.</t>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
</section> </section>
<section anchor="oscore_sec_context" title="OSCORE"> <section anchor="oscore_sec_context" numbered="true" toc="default">
<name>OSCORE</name>
<t>Before the (6LBR) pledge and the JRC start exchanging CoAP messages protected <t>Before the (6LBR) pledge and the JRC start exchanging CoAP messages p
with OSCORE, they need to derive the OSCORE security context from the provision rotected with OSCORE, they need to derive the OSCORE security context from the p
ed parameters, as discussed in <xref target="provisioning"/>.</t> rovisioned parameters, as discussed in <xref target="provisioning" format="defau
lt"/>.</t>
<t>The OSCORE security context MUST be derived as per Section 3 of <xref target= <t>The OSCORE security context <bcp14>MUST</bcp14> be derived per
"RFC8613"/>.</t> <xref target="RFC8613" section="3" sectionFormat="of" format="default"/>.</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The Master Secret <bcp14>MUST</bcp14> be the PSK.</li>
<t>the Master Secret MUST be the PSK.</t> <li>The Master Salt <bcp14>MUST</bcp14> be the empty byte string.</li>
<t>the Master Salt MUST be the empty byte string.</t> <li>The ID Context <bcp14>MUST</bcp14> be set to the pledge identifier
<t>the ID Context MUST be set to the pledge identifier.</t> .</li>
<t>the ID of the pledge MUST be set to the empty byte string. <li>The ID of the pledge <bcp14>MUST</bcp14> be set to the empty byte
This identifier is used as the OSCORE Sender ID of the pledge in the security co string.
ntext derivation, since the pledge initially acts as a CoAP client.</t> This identifier is used as the OSCORE Sender ID of the pledge in the security co
<t>the ID of the JRC MUST be set to the byte string 0x4a5243 ("JRC" in ASCII). ntext derivation, since the pledge initially acts as a CoAP client.</li>
This identifier is used as the OSCORE Recipient ID of the pledge in the security <li>The ID of the JRC <bcp14>MUST</bcp14> be set to the byte string 0x
context derivation, as the JRC initially acts as a CoAP server.</t> 4a5243 ("JRC" in ASCII).
<t>the Algorithm MUST be set to the value from <xref target="RFC8152"/>, agree This identifier is used as the OSCORE Recipient ID of the pledge in the security
d out-of-band by the same mechanism used to provision the PSK. context derivation, as the JRC initially acts as a CoAP server.</li>
The default is AES-CCM-16-64-128.</t> <li>The Algorithm <bcp14>MUST</bcp14> be set to the value
<t>the Key Derivation Function MUST be agreed out-of-band by the same mechanis from <xref target="RFC8152" format="default"/>, agreed to out-of-band
m used to provision the PSK. by the same mechanism used to provision the PSK.
Default is HKDF SHA-256 <xref target="RFC5869"/>.</t> The default is AES-CCM-16-64-128.</li>
</list></t> <li>The key derivation function <bcp14>MUST</bcp14> be agreed out-of-b
and by the same mechanism used to provision the PSK.
<t>Since the pledge's OSCORE Sender ID is the empty byte string, when constructi Default is HKDF SHA-256 <xref target="RFC5869" format="default"/>.</li>
ng the OSCORE option, the pledge sets the k bit in the OSCORE flag byte, but ind </ul>
icates a 0-length kid. <t>Since the pledge's OSCORE Sender ID is the empty byte string,
The pledge transports its pledge identifier within the kid context field of the when constructing the OSCORE option, the pledge sets the 'kid' flag in the
OSCORE option. OSCORE flag bits but indicates a 0-length 'kid'.
The derivation in <xref target="RFC8613"/> results in OSCORE keys and a common I The pledge transports its pledge identifier within the 'kid context' field of th
V for each side of the conversation. e OSCORE option.
Nonces are constructed by XOR'ing the common IV with the current sequence number The derivation in <xref target="RFC8613" format="default"/> results in OSCORE ke
. ys and a Common Initialization Vector (IV) for each side of the conversation.
For details on nonce and OSCORE option construction, refer to <xref target="RFC8 Nonces are constructed by XORing the Common IV with the current sequence number.
613"/>.</t> For details on nonce and OSCORE option construction, refer to <xref target="RFC8
613" format="default"/>.</t>
<t>Implementations MUST ensure that multiple CoAP requests, including to differe <t>Implementations <bcp14>MUST</bcp14> ensure that multiple CoAP request
nt JRCs, are properly incrementing the sequence numbers, so that the same sequen s, including to different JRCs, are properly incrementing the sequence numbers,
ce number is never reused in distinct requests protected under the same PSK. so that the same sequence number is never reused in distinct requests protected
under the same PSK.
The pledge typically sends requests to different JRCs if it is not provisioned w ith the network identifier and attempts to join one network at a time. The pledge typically sends requests to different JRCs if it is not provisioned w ith the network identifier and attempts to join one network at a time.
Failure to comply will break the security guarantees of the Authenticated Encryp tion with Associated Data (AEAD) algorithm because of nonce reuse.</t> Failure to comply will break the security guarantees of the Authenticated Encryp tion with Associated Data (AEAD) algorithm because of nonce reuse.</t>
<t>This OSCORE security context is used for the
<t>This OSCORE security context is used for
initial joining of the (6LBR) pledge, where the (6LBR) pledge acts as a CoAP client, initial joining of the (6LBR) pledge, where the (6LBR) pledge acts as a CoAP client,
as well as for any later parameter updates, where the JRC acts as a CoAP cli as well as for any later parameter updates, where the JRC acts as a CoAP cli
ent and the joined node as a CoAP server, as discussed in <xref target="update"/ ent and the joined node as a CoAP server, as discussed in <xref target="update"
>. format="default"/>.
Note that when the (6LBR) pledge and the JRC change roles between CoAP client an Note that when the (6LBR) pledge and the JRC change roles between
d CoAP server, the same OSCORE security context as initially derived remains in CoAP client and CoAP server, the same OSCORE security context as
use and the derived parameters are unchanged, for example Sender ID when sending initially derived remains in use, and the derived parameters are unchanged,
and Recipient ID when receiving (see Section 3.1 of <xref target="RFC8613"/>). for example, Sender ID when sending and Recipient ID when receiving
(see <xref target="RFC8613" section="3.1" sectionFormat="of" format="default"/>)
.
A (6LBR) pledge is expected to have exactly one OSCORE security context with the JRC.</t> A (6LBR) pledge is expected to have exactly one OSCORE security context with the JRC.</t>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> <section anchor="persistency" numbered="true" toc="default">
<name>Replay Window and Persistency</name>
<section anchor="persistency" title="Replay Window and Persistency"> <t>Both the (6LBR) pledge and the JRC <bcp14>MUST</bcp14>
implement a replay-protection mechanism.
<t>Both (6LBR) pledge and the JRC MUST implement a replay protection mechanism. The use of the default OSCORE replay-protection mechanism specified in
The use of the default OSCORE replay protection mechanism specified in Section 3 <xref target="RFC8613" section="3.2.2" sectionFormat="of" format="default"/> is
.2.2 of <xref target="RFC8613"/> is RECOMMENDED.</t> <bcp14>RECOMMENDED</bcp14>.</t>
<t>Implementations <bcp14>MUST</bcp14> ensure that mutable OSCORE cont
<t>Implementations MUST ensure that mutable OSCORE context parameters (Sender Se ext parameters (Sender Sequence Number, Replay Window) are stored in persistent
quence Number, Replay Window) are stored in persistent memory. memory.
A technique detailed in Appendix B.1.1 of <xref target="RFC8613"/> that prevents A technique detailed in <xref target="RFC8613" section="B.1.1" sectionFormat="of
reuse of sequence numbers MUST be implemented. " format="default"/>
Each update of the OSCORE Replay Window MUST be written to persistent memory.</t that prevents reuse of sequence numbers <bcp14>MUST</bcp14> be implemented.
> Each update of the OSCORE Replay Window <bcp14>MUST</bcp14> be written to persis
tent memory.</t>
<t>This is an important security requirement in order to guarantee nonce uniquen <t>This is an important security requirement in order to guarantee non
ess and resistance to replay attacks across reboots and rejoins. ce uniqueness and resistance to replay attacks across reboots and rejoins.
Traffic between the (6LBR) pledge and the JRC is rare, making security outweigh the cost of writing to persistent memory.</t> Traffic between the (6LBR) pledge and the JRC is rare, making security outweigh the cost of writing to persistent memory.</t>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
</section> </section>
<section anchor="oscore_error_handling" title="OSCORE Error Handling"> <section anchor="oscore_error_handling" numbered="true" toc="default">
<name>OSCORE Error Handling</name>
<t>Errors raised by OSCORE during the join process MUST be silently dropped, wit <t>Errors raised by OSCORE during the join process <bcp14>MUST</bcp14>
h no error response being signaled. be silently dropped, with no error response being signaled.
The pledge MUST silently discard any response not protected with OSCORE, includi The pledge <bcp14>MUST</bcp14> silently discard any response not protected with
ng error codes.</t> OSCORE, including error codes.</t>
<t>Such errors may happen for a number of reasons, including
<t>Such errors may happen for a number of reasons, including failed lookup of an appropriate security context (e.g., the pledge attemptin
failed lookup of an appropriate security context (e.g. the pledge attempting g to join a wrong network),
to join a wrong network),
failed decryption, failed decryption,
positive replay window lookup, positive Replay Window lookup,
formatting errors (possibly due to malicious alterations in transit). formatting errors (possibly due to malicious alterations in transit).
Silently dropping OSCORE messages prevents a DoS attack on the pledge where the attacker could send bogus error responses, forcing the pledge to attempt joining one network at a time, until all networks have been tried.</t> Silently dropping OSCORE messages prevents a DoS attack on the pledge where the attacker could send bogus error responses, forcing the pledge to attempt joining one network at a time, until all networks have been tried.</t>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
</section> </section>
<section anchor="mti_algos" title="Mandatory to Implement Algorithms"> <section anchor="mti_algos" numbered="true" toc="default">
<name>Mandatory-to-Implement Algorithms</name>
<t>The mandatory to implement AEAD algorithm for use with OSCORE is AES-CCM-16-6 <t>The mandatory-to-implement AEAD algorithm for use with OSCORE is AE
4-128 from <xref target="RFC8152"/>. S-CCM-16-64-128 from <xref target="RFC8152" format="default"/>.
This is the algorithm used for securing IEEE Std 802.15.4 frames, and hardware a cceleration for it is present in virtually all compliant radio chips. This is the algorithm used for securing IEEE Std 802.15.4 frames, and hardware a cceleration for it is present in virtually all compliant radio chips.
With this choice, CoAP messages are protected with an 8-byte CCM authentication tag, and the algorithm uses 13-byte long nonces.</t> With this choice, CoAP messages are protected with an 8-byte CCM authentication tag, and the algorithm uses 13-byte long nonces.</t>
<t>The mandatory-to-implement hash algorithm is SHA-256 <xref target="
RFC4231" format="default"/>.
The mandatory-to-implement key derivation function is HKDF <xref target="RFC5869
" format="default"/>, instantiated with a SHA-256 hash.
See <xref target="lightweight" format="default"/> for implementation guidance wh
en code footprint is important.</t>
<t>The mandatory to implement hash algorithm is SHA-256 <xref target="RFC4231"/>
.
The mandatory to implement key derivation function is HKDF <xref target="RFC5869
"/>, instantiated with a SHA-256 hash.
See <xref target="lightweight"/> for implementation guidance when code footprint
is important.</t>
<!-- ====================================================================== -->
</section>
</section>
</section> </section>
<section anchor="join_protocol" title="Constrained Join Protocol (CoJP)"> </section>
</section>
<t>The Constrained Join Protocol (CoJP) is a lightweight protocol over CoAP <xre <section anchor="join_protocol" numbered="true" toc="default">
f target="RFC7252"/> and a secure channel provided by OSCORE <xref target="RFC86 <name>Constrained Join Protocol (CoJP)</name>
13"/>. <t>The Constrained Join Protocol (CoJP) is a lightweight protocol over CoA
P <xref target="RFC7252" format="default"/> and a secure channel provided by OSC
ORE <xref target="RFC8613" format="default"/>.
CoJP allows a (6LBR) pledge to request admission into a network managed by the J RC. CoJP allows a (6LBR) pledge to request admission into a network managed by the J RC.
It enables the JRC to configure the pledge with the necessary parameters. It enables the JRC to configure the pledge with the necessary parameters.
The JRC may update the parameters at any time, by reaching out to the joined nod e that formerly acted as a (6LBR) pledge. The JRC may update the parameters at any time, by reaching out to the joined nod e that formerly acted as a (6LBR) pledge.
For example, network-wide rekeying can be implemented by updating the keying mat erial on each node.</t> For example, network-wide rekeying can be implemented by updating the keying mat erial on each node.</t>
<t>CoJP relies on the security properties provided by OSCORE.
<t>CoJP relies on the security properties provided by OSCORE.
This includes end-to-end confidentiality, data authenticity, replay protection, and a secure binding of responses to requests.</t> This includes end-to-end confidentiality, data authenticity, replay protection, and a secure binding of responses to requests.</t>
<figure anchor="fig-stack">
<figure title="Abstract layering of CoJP." anchor="fig-stack"><artwork align="ce <name>Abstract layering of CoJP.</name>
nter"><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
+-----------------------------------+ +-----------------------------------+
| Constrained Join Protocol (CoJP) | | Constrained Join Protocol (CoJP) |
+-----------------------------------+ +-----------------------------------+
+-----------------------------------+ \ +-----------------------------------+ \
| Requests / Responses | | | Requests / Responses | |
|-----------------------------------| | |-----------------------------------| |
| OSCORE | | CoAP | OSCORE | | CoAP
|-----------------------------------| | |-----------------------------------| |
| Messaging Layer | | | Messaging Layer | |
+-----------------------------------+ / +-----------------------------------+ /
+-----------------------------------+ +-----------------------------------+
| UDP | | UDP |
+-----------------------------------+ +-----------------------------------+
]]></artwork></figure> ]]></artwork>
</figure>
<t>When a (6LBR) pledge requests admission to a given network, it undergoes the <t>When a (6LBR) pledge requests admission to a given network, it undergoe
CoJP join exchange that consists of:</t> s the CoJP join exchange that consists of:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The Join Request message, sent by the (6LBR) pledge to the JRC, pote
<t>the Join Request message, sent by the (6LBR) pledge to the JRC, potentially ntially proxied by the JP.
proxied by the JP. The Join Request message and its mapping to CoAP is specified in <xref target="j
The Join Request message and its mapping to CoAP is specified in <xref target="j oin_request" format="default"/>.</li>
oin_request"/>.</t> <li>The Join Response message, sent by the JRC to the (6LBR) pledge, if
<t>the Join Response message, sent by the JRC to the (6LBR) pledge, if the JRC the JRC successfully processes the Join Request using OSCORE and it determines t
successfully processes the Join Request using OSCORE and it determines through hrough a mechanism that is out of scope of this specification that the (6LBR) pl
a mechanism that is out of scope of this specification that the (6LBR) pledge is edge is authorized to join the network.
authorized to join the network.
The Join Response message is potentially proxied by the JP. The Join Response message is potentially proxied by the JP.
The Join Response message and its mapping to CoAP is specified in <xref target=" The Join Response message and its mapping to CoAP is specified in <xref target="
join_response"/>.</t> join_response" format="default"/>.</li>
</list></t> </ul>
<t>When the JRC needs to update the parameters of a joined node
<t>When the JRC needs to update the parameters of a joined node that formerly ac that formerly acted as a (6LBR) pledge, it executes the CoJP parameter update ex
ted as a (6LBR) pledge, it executes the CoJP parameter update exchange that cons change
ists of:</t> that consists of the following:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The Parameter Update message, sent by the JRC to the joined node tha
<t>the Parameter Update message, sent by the JRC to the joined node that forme t formerly acted as a (6LBR) pledge.
rly acted as a (6LBR) pledge. The Parameter Update message and its mapping to CoAP is specified in <xref targe
The Parameter Update message and its mapping to CoAP is specified in <xref targe t="parameter_update" format="default"/>.</li>
t="parameter_update"/>.</t> </ul>
</list></t> <t>The payload of CoJP messages is encoded with CBOR <xref target="RFC8949
" format="default"/>.
<t>The payload of CoJP messages is encoded with CBOR <xref target="RFC7049"/>. The CBOR data structures that may appear as the payload of different CoJP messag
The CBOR data structures that may appear as the payload of different CoJP messag es are specified in <xref target="cbor_objects" format="default"/>.</t>
es are specified in <xref target="cbor_objects"/>.</t>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<section anchor="join" title="Join Exchange">
<t>This section specifies the messages exchanged when the (6LBR) pledge requests
admission and configuration parameters from the JRC.</t>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<section anchor="join_request" title="Join Request Message">
<t>The Join Request message that the (6LBR) pledge sends SHALL be mapped to a Co
AP request:</t>
<t><list style="symbols">
<t>The request method is POST.</t>
<t>The type is Confirmable (CON).</t>
<t>The Proxy-Scheme option is set to "coap".</t>
<t>The Uri-Host option is set to "6tisch.arpa".
This is an anycast type of identifier of the JRC that is resolved to its IPv6 ad
dress by the JP or the 6LBR pledge.</t>
<t>The Uri-Path option is set to "j".</t>
<t>The OSCORE option SHALL be set according to <xref target="RFC8613"/>.
The OSCORE security context used is the one derived in <xref target="oscore_se
c_context"/>.
The OSCORE kid context allows the JRC to retrieve the security context for a g
iven pledge.</t>
<t>The payload is a Join_Request CBOR object, as defined in <xref target="join
_request_object"/>.</t>
</list></t>
<t>Since the Join Request is a confirmable message, the transmission at (6LBR) p
ledge will be controlled by CoAP's retransmission mechanism.
The JP, when operating in a stateless manner, forwards this Join Request as a no
n-confirmable (NON) CoAP message, as specified in <xref target="join_proxy"/>.
If the CoAP implementation at (6LBR) pledge declares the message transmission as
failure, the (6LBR) pledge SHOULD attempt to join a 6TiSCH network advertised w
ith a different network identifier.
See <xref target="parameters"/> for recommended values of CoAP settings to use d
uring the join exchange.</t>
<t>If all join attempts to advertised networks have failed, the (6LBR) pledge SH
OULD signal the presence of an error condition, through some out-of-band mechani
sm.</t>
<t>BCP190 <xref target="RFC7320"/> provides guidelines on URI design and ownersh <section anchor="join" numbered="true" toc="default">
ip. <name>Join Exchange</name>
It recommends that whenever a third party wants to mandate a URL to web authorit <t>This section specifies the messages exchanged when the (6LBR) pledge
y that it SHOULD go under "/.well-known" (as per <xref target="RFC5785"/>). requests admission and configuration parameters from the JRC.</t>
In the case of CoJP, the Uri-Host option is always set to "6tisch.arpa", and bas
ed upon the recommendations in the Introduction of <xref target="RFC7320"/>, it
is asserted that this document is the owner of the CoJP service.
As such, the concerns of <xref target="RFC7320"/> do not apply, and thus the Uri
-Path is only "/j".</t>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> <section anchor="join_request" numbered="true" toc="default">
<name>Join Request Message</name>
<t>The Join Request message that the (6LBR) pledge sends <bcp14>SHALL<
/bcp14> be mapped to a CoAP request:</t>
<ul spacing="normal">
<li>The request method is POST.</li>
<li>The type is Confirmable (CON).</li>
<li>The Proxy-Scheme option is set to "coap".</li>
<li>The Uri-Host option is set to "6tisch.arpa".
This is an anycast type of identifier of the JRC that is resolved to its IPv6 ad
dress by the JP or the 6LBR pledge.</li>
<li>The Uri-Path option is set to "j".</li>
<li>The OSCORE option <bcp14>SHALL</bcp14> be set according to <xref
target="RFC8613" format="default"/>.
The OSCORE security context used is the one derived in <xref target="oscore_se
c_context" format="default"/>.
The OSCORE 'kid context' allows the JRC to retrieve the security context for a
given pledge.</li>
<li>The payload is a Join_Request CBOR object, as defined in <xref t
arget="join_request_object" format="default"/>.</li>
</ul>
<t>Since the Join Request is a confirmable message, the transmission a
t (6LBR) pledge will be controlled by CoAP's retransmission mechanism.
The JP, when operating in a stateless manner, forwards this Join Request as a no
n-confirmable (NON) CoAP message, as specified in <xref target="join_proxy" form
at="default"/>.
If the CoAP implementation at the (6LBR) pledge declares the
message transmission a failure, the (6LBR) pledge <bcp14>SHOULD</bcp14>
attempt to join a 6TiSCH network advertised with a different network identifier.
See <xref target="parameters" format="default"/> for recommended values of CoAP
settings to use during the join exchange.</t>
<t>If all join attempts to advertised networks have failed, the (6LBR)
pledge <bcp14>SHOULD</bcp14> signal the presence of an error condition, through
some out-of-band mechanism.</t>
<t>BCP 190 <xref target="RFC8820" format="default"/>
provides guidelines on URI design and ownership. It recommends that
whenever a third party wants to mandate a URI to web authority that
it <bcp14>SHOULD</bcp14> go under "/.well-known" (per <xref target="RFC8615" for
mat="default"/>).
In the case of CoJP, the Uri-Host option is always set to "6tisch.arpa",
and based upon the recommendations in <xref target="RFC8820" section="1" section
Format="of" format="default"/>,
it is asserted that this document is the owner of the CoJP service.
As such, the concerns of <xref target="RFC8820" format="default"/> do not apply,
and thus the Uri-Path is only "j".</t>
</section> </section>
<section anchor="join_response" title="Join Response Message"> <section anchor="join_response" numbered="true" toc="default">
<name>Join Response Message</name>
<t>The Join Response message that the JRC sends SHALL be mapped to a CoAP respon <t>The Join Response message that the JRC sends <bcp14>SHALL</bcp14> b
se:</t> e mapped to a CoAP response:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The Response Code is 2.04 (Changed).</li>
<t>The response Code is 2.04 (Changed).</t> <li>The payload is a Configuration CBOR object, as defined in <xref
<t>The payload is a Configuration CBOR object, as defined in <xref target="con target="configuration_object" format="default"/>.</li>
figuration_object"/>.</t> </ul>
</list></t>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
</section> </section>
</section> </section>
<section anchor="update" title="Parameter Update Exchange"> <section anchor="update" numbered="true" toc="default">
<name>Parameter Update Exchange</name>
<t>During the network lifetime, parameters returned as part of the Join Response <t>During the network lifetime, parameters returned as part of the Join
may need to be updated. Response may need to be updated.
One typical example is the update of link-layer keying material for the network, a process known as rekeying. One typical example is the update of link-layer keying material for the network, a process known as rekeying.
This section specifies a generic mechanism when this parameter update is initiat ed by the JRC.</t> This section specifies a generic mechanism when this parameter update is initiat ed by the JRC.</t>
<t>At the time of the join, the (6LBR) pledge acts as a
<t>At the time of the join, the (6LBR) pledge acts as a CoAP client and requests CoAP client and requests the network parameters through a representation
the network parameters through a representation of the "/j" resource, exposed b of the "/j" resource exposed by the JRC.
y the JRC.
In order for the update of these parameters to happen, the JRC needs to asynchro nously contact the joined node. In order for the update of these parameters to happen, the JRC needs to asynchro nously contact the joined node.
The use of the CoAP Observe option for this purpose is not feasible due to the c hange in the IPv6 address when the pledge becomes the joined node and obtains a global address.</t> The use of the CoAP Observe option for this purpose is not feasible due to the c hange in the IPv6 address when the pledge becomes the joined node and obtains a global address.</t>
<t>Instead, once the (6LBR) pledge receives and successfully validates t
<t>Instead, once the (6LBR) pledge receives and successfully validates the Join he Join Response and so becomes a joined node, it becomes a CoAP server.
Response and so becomes a joined node, it becomes a CoAP server.
The joined node creates a CoAP service at the Uri-Host value of "6tisch.arpa", a nd the joined node exposes the "/j" resource that is used by the JRC to update t he parameters. The joined node creates a CoAP service at the Uri-Host value of "6tisch.arpa", a nd the joined node exposes the "/j" resource that is used by the JRC to update t he parameters.
Consequently, the JRC operates as a CoAP client when updating the parameters. Consequently, the JRC operates as a CoAP client when updating the parameters.
The request/response exchange between the JRC and the (6LBR) pledge happens over the already-established OSCORE secure channel.</t> The request/response exchange between the JRC and the (6LBR) pledge happens over the already-established OSCORE secure channel.</t>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> <section anchor="parameter_update" numbered="true" toc="default">
<name>Parameter Update Message</name>
<section anchor="parameter_update" title="Parameter Update Message"> <t>The Parameter Update message that the JRC sends to the joined node
<bcp14>SHALL</bcp14> be mapped to a CoAP request:</t>
<t>The Parameter Update message that the JRC sends to the joined node SHALL be m <ul spacing="normal">
apped to a CoAP request:</t> <li>The request method is POST.</li>
<li>The type is Confirmable (CON).</li>
<t><list style="symbols"> <li>The Uri-Host option is set to "6tisch.arpa".</li>
<t>The request method is POST.</t> <li>The Uri-Path option is set to "j".</li>
<t>The type is Confirmable (CON).</t> <li>The OSCORE option <bcp14>SHALL</bcp14> be set according to <xref
<t>The Uri-Host option is set to "6tisch.arpa".</t> target="RFC8613" format="default"/>.
<t>The Uri-Path option is set to "j".</t> The OSCORE security context used is the one derived in <xref target="oscore_se
<t>The OSCORE option SHALL be set according to <xref target="RFC8613"/>. c_context" format="default"/>.
The OSCORE security context used is the one derived in <xref target="oscore_se When a joined node receives a request with the Sender ID set to 0x4a5243 (ID o
c_context"/>. f the JRC), it is able to correctly retrieve the security context with the JRC.<
When a joined node receives a request with the Sender ID set to 0x4a5243 (ID o /li>
f the JRC), it is able to correctly retrieve the security context with the JRC.< <li>The payload is a Configuration CBOR object, as defined in <xref
/t> target="configuration_object" format="default"/>.</li>
<t>The payload is a Configuration CBOR object, as defined in <xref target="con </ul>
figuration_object"/>.</t> <t>The JRC has implicit knowledge of the global IPv6 address
</list></t> of the joined node, as it knows the pledge identifier that the joined
node used when it acted as a pledge and the IPv6 network prefix.
<t>The JRC has implicit knowledge on the global IPv6 address of the joined node,
as it knows the pledge identifier that the joined node used when it acted as a
pledge, and the IPv6 network prefix.
The JRC uses this implicitly derived IPv6 address of the joined node to directly address CoAP messages to it.</t> The JRC uses this implicitly derived IPv6 address of the joined node to directly address CoAP messages to it.</t>
<t>If the JRC does not receive a response to a
Parameter Update message, it attempts multiple retransmissions as
configured by the underlying CoAP retransmission mechanism triggered for confirm
able messages.
Finally, if the CoAP implementation declares the transmission a failure,
the JRC may consider this as a hint that the joined node is no longer in the net
work.
How the JRC decides when to stop attempting to contact a previously
joined node is out of scope of this specification, but the security
considerations on the reuse of assigned resources apply, as discussed
in <xref target="sec_considerations" format="default"/>.</t>
<t>In case the JRC does not receive a response to a Parameter Update message, it
attempts multiple retransmissions, as configured by the underlying CoAP retrans
mission mechanism triggered for confirmable messages.
Finally, if the CoAP implementation declares the transmission as failure, the JR
C may consider this as a hint that the joined node is no longer in the network.
How the JRC decides when to stop attempting to contact a previously joined node
is out of scope of this specification but security considerations on the reuse o
f assigned resources apply, as discussed in <xref target="sec_considerations"/>.
</t>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
</section>
</section> </section>
<section anchor="error-handling" title="Error Handling"> </section>
<section anchor="error-handling" numbered="true" toc="default">
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> <name>Error Handling</name>
<section anchor="cojp_error_handling" title="CoJP CBOR Object Processing">
<t>CoJP CBOR objects are transported within both CoAP requests and responses.
This section describes handling in case certain CoJP CBOR object parameters are
not supported by the implementation or their processing fails.
See <xref target="oscore_error_handling"/> for the handling of errors that may b
e raised by the underlying OSCORE implementation.</t>
<t>When such a parameter is detected in a CoAP request (Join Request message, Pa
rameter Update message), a Diagnostic Response message MUST be returned.
A Diagnostic Response message maps to a CoAP response and is specified in <xref
target="error_response_message"/>.</t>
<t>When a parameter that cannot be acted upon is encountered while processing a <section anchor="cojp_error_handling" numbered="true" toc="default">
CoJP object in a CoAP response (Join Response message), a (6LBR) pledge SHOULD r <name>CoJP CBOR Object Processing</name>
eattempt to join. <t>CoJP CBOR objects are transported within both CoAP requests and res
In this case, the (6LBR) pledge SHOULD include the Unsupported Configuration CBO ponses.
R object within the Join Request object in the following Join Request message. This section describes handling the cases in which certain CoJP CBOR object
parameters are not supported by the implementation or their processing fails.
See <xref target="oscore_error_handling" format="default"/> for the handling of
errors that may be raised by the underlying OSCORE implementation.</t>
<t>When such a parameter is detected in a CoAP request (Join Request m
essage, Parameter Update message), a Diagnostic Response message <bcp14>MUST</bc
p14> be returned.
A Diagnostic Response message maps to a CoAP response and is specified in <xref
target="error_response_message" format="default"/>.</t>
<t>When a parameter that cannot be acted upon is encountered while pro
cessing a CoJP object in a CoAP response (Join Response message), a (6LBR) pledg
e <bcp14>SHOULD</bcp14> reattempt to join.
In this case, the (6LBR) pledge <bcp14>SHOULD</bcp14> include the Unsupported Co
nfiguration CBOR object within the Join Request object in the following Join Req
uest message.
The Unsupported Configuration CBOR object is self-contained and enables the (6LB R) pledge to signal any parameters that the implementation of the networking sta ck may not support. The Unsupported Configuration CBOR object is self-contained and enables the (6LB R) pledge to signal any parameters that the implementation of the networking sta ck may not support.
A (6LBR) pledge MUST NOT attempt more than COJP_MAX_JOIN_ATTEMPTS number of atte A (6LBR) pledge <bcp14>MUST NOT</bcp14> attempt more than COJP_MAX_JOIN_ATTEMPTS
mpts to join if the processing of the Join Response message fails each time. number of attempts to join if the processing of the Join Response message fails
If COJP_MAX_JOIN_ATTEMPTS number of attempts is reached without success, the (6L each time.
BR) pledge SHOULD signal the presence of an error condition, through some out-of If the COJP_MAX_JOIN_ATTEMPTS number of attempts is reached without
-band mechanism.</t> success, the (6LBR) pledge <bcp14>SHOULD</bcp14> signal the presence
of an error condition through some out-of-band mechanism.</t>
<t>Note that COJP_MAX_JOIN_ATTEMPTS relates to the application-level handling of <t>Note that COJP_MAX_JOIN_ATTEMPTS relates to the
the CoAP response and is different from CoAP's MAX_RETRANSMIT setting that driv application-layer handling of the CoAP response and is different from
es the retransmission mechanism of the underlying CoAP message.</t> CoAP's MAX_RETRANSMIT setting, which drives the retransmission mechanism
of the underlying CoAP message.</t>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
</section> </section>
<section anchor="error_response_message" title="Diagnostic Response Message"> <section anchor="error_response_message" numbered="true" toc="default">
<name>Diagnostic Response Message</name>
<t>The Diagnostic Response message is returned for any CoJP request when the pro <t>The Diagnostic Response message is returned for any CoJP request wh
cessing of the payload failed. en the processing of the payload failed.
The Diagnostic Response message is protected by OSCORE as any other CoJP protoco The Diagnostic Response message is protected by OSCORE as any other CoJP messag
l message.</t> e.</t>
<t>The Diagnostic Response message <bcp14>SHALL</bcp14> be mapped to a
<t>The Diagnostic Response message SHALL be mapped to a CoAP response:</t> CoAP response:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The Response Code is 4.00 (Bad Request).</li>
<t>The response Code is 4.00 (Bad Request).</t> <li>The payload is an Unsupported Configuration CBOR object,
<t>The payload is an Unsupported Configuration CBOR object, as defined in <xre as defined in <xref target="unsupported_configuration_object" format="default"/>
f target="unsupported_configuration_object"/>, containing more information about ,
the parameter that triggered the sending of this message.</t> containing more information about the parameter that triggered the sending of th
</list></t> is message.</li>
</ul>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
</section> </section>
<section anchor="failure_handling" title="Failure Handling"> <section anchor="failure_handling" numbered="true" toc="default">
<name>Failure Handling</name>
<t>The Parameter Update exchange may be triggered at any time during the network <t>The parameter update exchange may be triggered at any time
lifetime, which may span several years. during the network lifetime, which may span several years.
During this period, it may occur that a joined node or the JRC experience unexpe During this period, a joined node or the JRC may experience unexpected
cted events such as reboots or complete failures.</t> events such as reboots or complete failures.</t>
<t>This document mandates that the mutable parameters in the
<t>This document mandates that the mutable parameters in the security context ar security context are written to persistent memory (see
e written to persistent memory (see <xref target="persistency"/>) by both the JR <xref target="persistency" format="default"/>) by both the JRC and pledges
C and pledges (joined nodes). (joined nodes).
As the joined node (pledge) is typically a constrained device that handles the w As the pledge (joined node) is typically a constrained device that handles
rite operations to persistent memory in a predictable manner, the retrieval of m the write operations to persistent memory in a predictable manner, the
utable security context parameters is feasible across reboots such that there is retrieval of mutable security-context parameters is feasible across reboots
no risk of AEAD nonce reuse due to reinitialized Sender Sequence numbers, or of such that there is no risk of AEAD nonce reuse due to reinitialized
a replay attack due to the reinitialized replay window. Sender Sequence Numbers or of a replay attack due to the reinitialized Replay Wi
JRC may be hosted on a generic machine where the write operation to persistent m ndow.
emory may lead to unpredictable delays due to caching. The JRC may be hosted on a generic machine where the write operation to
In case of a reboot event at JRC occurring before the cached data is written to persistent memory may lead to unpredictable delays due to caching.
persistent memory, the loss of mutable security context parameters is likely whi If a reboot event occurs at the JRC before the cached data is written
ch consequently poses the risk of AEAD nonce reuse.</t> to persistent memory, the loss of mutable security-context parameters
is likely, which consequently poses the risk of AEAD nonce reuse.</t>
<t>In the event of a complete device failure, where the mutable security context <t>In the event of a complete device failure, where the mutable
parameters cannot be retrieved, it is expected that a failed joined node is rep security-context parameters cannot be retrieved, it is expected that a
laced with a new physical device, using a new pledge identifier and a PSK. failed joined node will be replaced with a new physical device, using
When such a failure event occurs at the JRC, it is possible that the static info a new pledge identifier and a PSK.
rmation on provisioned pledges, like PSKs and pledge identifiers, can be retriev When such a failure event occurs at the JRC, it is possible that the
ed through available backups. static information on provisioned pledges, like PSKs and pledge identifiers,
However, it is likely that the information about joined nodes, their assigned sh can be retrieved through available backups.
ort identifiers and mutable security context parameters is lost. However, it is likely that the information about joined nodes, their
If this is the case, during the process of JRC reinitialization, the network adm assigned short identifiers and mutable security-context parameters,
inistrator MUST force through out-of-band means all the networks managed by the is lost.
failed JRC to rejoin, through e.g. the reinitialization of the 6LBR nodes and fr If this is the case, the network administrator <bcp14>MUST</bcp14> force
eshly generated dynamic cryptographic keys and other parameters that have influe all the networks managed by the failed JRC to rejoin through out-of-band
nce on the security properties of the network.</t> means during the process of JRC reinitialization, e.g.,
reinitialize the 6LBR nodes and freshly generate dynamic
<t>In order to recover from such a failure event, the reinitialized JRC can trig cryptographic keys and other parameters that influence the
ger the renegotiation of the OSCORE security context through the procedure descr security properties of the network.</t>
ibed in Appendix B.2 of <xref target="RFC8613"/>. <t>In order to recover from such a failure event, the reinitialized JR
Aware of the failure event, the reinitialized JRC responds to the first join req C can trigger the renegotiation of the OSCORE security context through the proce
uest of each pledge it is managing with a 4.01 Unauthorized error and a random n dure described in
once. <xref target="RFC8613" section="B.2" sectionFormat="of" format="default"/>.
Aware of the failure event, the reinitialized JRC responds to the first
Join Request of each pledge it is managing with a 4.01 (Unauthorized)
error and a random nonce.
The pledge verifies the error response and then initiates the CoJP join exchange using a new OSCORE security context derived from an ID Context consisting of th e concatenation of two nonces, one that it received from the JRC and the other t hat the pledge generates locally. The pledge verifies the error response and then initiates the CoJP join exchange using a new OSCORE security context derived from an ID Context consisting of th e concatenation of two nonces, one that it received from the JRC and the other t hat the pledge generates locally.
After verifying the join request with the new ID Context and the derived OSCORE After verifying the Join Request with the new ID Context and the
security context, the JRC should consequently take action in mapping the new ID derived OSCORE security context, the JRC should consequently map
Context with the previously used pledge identifier. the new ID Context to the previously used pledge identifier.
How JRC handles this mapping is out of scope of this document.</t> How the JRC handles this mapping is out of scope of this document.</t>
<t>The use of the procedure specified in
<t>The described procedure is specified in Appendix B.2 of <xref target="RFC8613 <xref target="RFC8613" section="B.2" sectionFormat="of" format="default"/>
"/> and is RECOMMENDED in order to handle the failure events or any other event is <bcp14>RECOMMENDED</bcp14> in order to handle the failure events or
that may lead to the loss of mutable security context parameters. any other event that may lead to the loss of mutable security-context parameters
The length of nonces exchanged using this procedure MUST be at least 8 bytes.</t .
> The length of nonces exchanged using this procedure <bcp14>MUST</bcp14> be at le
ast 8 bytes.</t>
<t>The procedure does require both the pledge and the JRC to have good sources o <t>The procedure requires both the pledge and the JRC
f randomness. to have good sources of randomness.
While this is typically not an issue at the JRC side, the constrained device hos While this is typically not an issue at the JRC side, the constrained
ting the pledge may pose limitations in this regard. device hosting the pledge may pose limitations in this regard.
If the procedure outlined in Appendix B.2 of <xref target="RFC8613"/> is not sup If the procedure outlined in
ported by the pledge, the network administrator MUST take action in reprovisioni <xref target="RFC8613" section="B.2" sectionFormat="of" format="default"/>
ng the concerned devices with freshly generated parameters, through out-of-band is not supported by the pledge, the network administrator <bcp14>MUST</bcp14>
means.</t> reprovision the concerned devices with freshly generated parameters
through out-of-band means.</t>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
</section> </section>
</section> </section>
<section anchor="cbor_objects" title="CoJP Objects"> <section anchor="cbor_objects" numbered="true" toc="default">
<name>CoJP Objects</name>
<t>This section specifies the structure of CoJP CBOR objects that may be carried <t>This section specifies the structure of CoJP CBOR objects
as the payload of CoJP messages. that may be carried as the payload of CoJP messages.
Some of these objects may be received both as part of the CoJP join exchange whe Some of these objects may be received both as part of the
n the device operates as a (CoJP) pledge, or the parameter update exchange, when CoJP join exchange when the device operates as a (CoJP) pledge or
the device operates as a joined (6LBR) node.</t> as part of the parameter update exchange when the device operates
as a joined (6LBR) node.</t>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<section anchor="join_request_object" title="Join Request Object">
<t>The Join_Request structure is built on a CBOR map object.</t>
<t>The set of parameters that can appear in a Join_Request object is summarized
below.
The labels can be found in the "CoJP Parameters" registry <xref target="iana_coj
p_registry"/>.</t>
<t><list style="symbols"> <section anchor="join_request_object" numbered="true" toc="default">
<t>role: The identifier of the role that the pledge requests to play in the ne <name>Join Request Object</name>
twork once it joins, encoded as an unsigned integer. <t>The Join_Request structure is built on a CBOR map object.</t>
Possible values are specified in <xref target="table_role_values"/>. <t>The set of parameters that can appear in a Join_Request object is s
This parameter MAY be included. ummarized below.
In case the parameter is omitted, the default value of 0, i.e. the role "6TiSCH The labels can be found in the "Constrained Join Protocol (CoJP) Parameters" reg
Node", MUST be assumed.</t> istry,
<t>network identifier: The identifier of the network, as discussed in <xref ta <xref target="iana_cojp_registry" format="default"/>.</t>
rget="provisioning"/>, encoded as a CBOR byte string. <dl spacing="normal">
When present in the Join_Request, it hints to the JRC the network that the pledg <dt>role:</dt>
e is requesting to join, enabling the JRC to manage multiple networks. <dd>The identifier of the role that the pledge requests
to play in the network once it joins, encoded as an unsigned integer.
Possible values are specified in <xref target="table_role_values" format="defaul
t"/>.
This parameter <bcp14>MAY</bcp14> be included.
If the parameter is omitted, the default value of 0,
i.e., the role "6TiSCH Node", <bcp14>MUST</bcp14> be assumed.</dd>
<dt>network identifier:</dt>
<dd>The identifier of the network, as discussed in
<xref target="provisioning" format="default"/>, encoded as a CBOR byte string.
When present in the Join_Request, it hints to the JRC which network
the pledge is requesting to join, enabling the JRC to manage multiple networks.
The pledge obtains the value of the network identifier from the received EB fram es. The pledge obtains the value of the network identifier from the received EB fram es.
This parameter MUST be included in a Join_Request object regardless of the role This parameter <bcp14>MUST</bcp14> be included in a Join_Request object
parameter value.</t> regardless of the role parameter value.</dd>
<t>unsupported configuration: The identifier of the parameters that are not su <dt>unsupported configuration:</dt>
pported by the implementation, encoded as an Unsupported_Configuration object de <dd>The identifier of the parameters that are not supported by
scribed in <xref target="unsupported_configuration_object"/>. the implementation, encoded as an Unsupported_Configuration object described in
This parameter MAY be included. <xref target="unsupported_configuration_object" format="default"/>.
If a (6LBR) pledge previously attempted to join and received a valid Join Respon This parameter <bcp14>MAY</bcp14> be included.
se message over OSCORE, but failed to act on its payload (Configuration object), If a (6LBR) pledge previously attempted to join and received a valid
it SHOULD include this parameter to facilitate the recovery and debugging.</t> Join Response message over OSCORE but failed to act on its payload
</list></t> (Configuration object), it <bcp14>SHOULD</bcp14> include this parameter
to facilitate the recovery and debugging.</dd>
<t><xref target="table_join_req_params"/> summarizes the parameters that may app </dl>
ear in a Join_Request object.</t> <t><xref target="table_join_req_params" format="default"/>
summarizes the parameters that may appear in a Join_Request object.</t>
<texttable title="Summary of Join_Request parameters." anchor="table_join_req_pa <table anchor="table_join_req_params" align="center">
rams"> <name>Summary of Join_Request parameters.</name>
<ttcol align='right'>Name</ttcol> <thead>
<ttcol align='left'>Label</ttcol> <tr>
<ttcol align='right'>CBOR Type</ttcol> <th>Name</th>
<c>role</c> <th>Label</th>
<c>1</c> <th>CBOR Type</th>
<c>unsigned integer</c> </tr>
<c>network identifier</c> </thead>
<c>5</c> <tbody>
<c>byte string</c> <tr>
<c>unsupported configuration</c> <td>role</td>
<c>8</c> <td>1</td>
<c>array</c> <td>unsigned integer</td>
</texttable> </tr>
<tr>
<t>The CDDL fragment that represents the text above for the Join_Request follows <td>network identifier</td>
.</t> <td>5</td>
<td>byte string</td>
<figure><artwork><![CDATA[ </tr>
<tr>
<td>unsupported configuration</td>
<td>8</td>
<td>array</td>
</tr>
</tbody>
</table>
<t>The CDDL fragment that represents the text above for the Join_Reque
st follows:</t>
<sourcecode type=""><![CDATA[
Join_Request = { Join_Request = {
? 1 : uint, ; role ? 1 : uint, ; role
5 : bstr, ; network identifier 5 : bstr, ; network identifier
? 8 : Unsupported_Configuration ; unsupported configuration ? 8 : Unsupported_Configuration ; unsupported configuration
} }
]]></artwork></figure> ]]></sourcecode>
<table anchor="table_role_values" align="center">
<texttable title="Role values." anchor="table_role_values"> <name>Role values.</name>
<ttcol align='right'>Name</ttcol> <thead>
<ttcol align='left'>Value</ttcol> <tr>
<ttcol align='right'>Description</ttcol> <th>Name</th>
<ttcol align='left'>Reference</ttcol> <th>Value</th>
<c>6TiSCH Node</c> <th>Description</th>
<c>0</c> <th>Reference</th>
<c>The pledge requests to play the role of a regular 6TiSCH node, i.e. non </tr>
-6LBR node.</c> </thead>
<c>[[this document]]</c> <tbody>
<c>6LBR</c> <tr>
<c>1</c> <td>6TiSCH Node</td>
<c>The pledge requests to play the role of 6LoWPAN Border Router (6LBR).</ <td>0</td>
c> <td>The pledge requests to play the role of a regular 6TiSCH nod
<c>[[this document]]</c> e, i.e., non-6LBR node.</td>
</texttable> <td>RFC 9031</td>
</tr>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> <tr>
<td>6LBR</td>
<td>1</td>
<td>The pledge requests to play the role of 6LoWPAN Border Route
r (6LBR).</td>
<td>RFC 9031</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="configuration_object" title="Configuration Object"> <section anchor="configuration_object" numbered="true" toc="default">
<name>Configuration Object</name>
<t>The Configuration structure is built on a CBOR map object. <t>The Configuration structure is built on a CBOR map object.
The set of parameters that can appear in a Configuration object is summarized be low. The set of parameters that can appear in a Configuration object is summarized be low.
The labels can be found in "CoJP Parameters" registry <xref target="iana_cojp_re The labels can be found in "Constrained Join Protocol (CoJP) Parameters" registr
gistry"/>.</t> y, <xref target="iana_cojp_registry" format="default"/>.</t>
<dl spacing="normal">
<t><list style="symbols"> <dt>link-layer key set:</dt>
<t>link-layer key set: An array encompassing a set of cryptographic keys and t <dd>An array encompassing a set of cryptographic keys
heir identifiers that are currently in use in the network, or that are scheduled and their identifiers that are currently in use in the network
to be used in the future. or that are scheduled to be used in the future.
The encoding of individual keys is described in <xref target="ll_keys"/>. The encoding of individual keys is described in <xref target="ll_keys" format="d
The link-layer key set parameter MAY be included in a Configuration object. efault"/>.
When present, the link-layer key set parameter MUST contain at least one key. The link-layer key set parameter <bcp14>MAY</bcp14> be included in a Configurati
on object.
When present, the link-layer key set parameter <bcp14>MUST</bcp14> contain at le
ast one key.
This parameter is also used to implement rekeying in the network. This parameter is also used to implement rekeying in the network.
How the keys are installed and used differs for the 6LBR and other (regular) nod The installation and use of keys differs for the 6LBR and
es, and this is explained in <xref target="keychanging6lbr"/> and <xref target=" other (regular) nodes, and this is explained in Sections <xref target="keychangi
keychanging6lr"/>.</t> ng6lbr" format="counter"/>
<t>short identifier: a compact identifier assigned to the pledge. and <xref target="keychanging6lr" format="counter"/>.</dd>
The short identifier structure is described in <xref target="short_identifier"/> <dt>short identifier: </dt>
. <dd>A compact identifier assigned to the pledge.
The short identifier parameter MAY be included in a Configuration object.</t> The short identifier structure is described in <xref target="short_identifier" f
<t>JRC address: the IPv6 address of the JRC, encoded as a byte string, with th ormat="default"/>.
e length of 16 bytes. The short identifier parameter <bcp14>MAY</bcp14> be included in a Configuration
If the length of the byte string is different from 16, the parameter MUST be dis object.</dd>
carded. <dt>JRC address:</dt>
If the JRC is not co-located with the 6LBR and has a different IPv6 address than <dd>The IPv6 address of the JRC, encoded as a byte string, with the
the 6LBR, this parameter MUST be included. length of 16 bytes.
In the special case where the JRC is co-located with the 6LBR and has the same I If the length of the byte string is different from 16, the parameter <bcp14>MUST
Pv6 address as the 6LBR, this parameter MAY be included. </bcp14> be discarded.
If the JRC address parameter is not present in the Configuration object, this in If the JRC is not co-located with the 6LBR and has a different IPv6 address than
dicates that the JRC has the same IPv6 address as the 6LBR. the 6LBR,
this parameter <bcp14>MUST</bcp14> be included.
In the special case where the JRC is co-located with the 6LBR and
has the same IPv6 address as the 6LBR, this parameter <bcp14>MAY</bcp14> be incl
uded.
If the JRC address parameter is not present in the Configuration 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 JRC through network co ntrol traffic. The joined node can then discover the IPv6 address of the JRC through network co ntrol traffic.
See <xref target="netreq"/>.</t> See <xref target="netreq" format="default"/>.</dd>
<t>blacklist: An array encompassing a list of pledge identifiers that are blac <dt>blacklist:</dt>
klisted by the JRC, with each pledge identifier encoded as a byte string. <dd>An array encompassing a list of pledge identifiers
The blacklist parameter MAY be included in a Configuration object. that are blacklisted by the JRC, with each pledge identifier encoded as a byte s
When present, the array MUST contain zero or more byte strings encoding pledge i tring.
dentifiers. The blacklist parameter <bcp14>MAY</bcp14> be included in a Configuration object
The joined node MUST silently drop any link-layer frames originating from the pl .
edge identifiers enclosed in the blacklist parameter. When present, the array <bcp14>MUST</bcp14> contain zero or more byte strings en
When this parameter is received, its value MUST overwrite any previously set val coding pledge identifiers.
ues. The joined node <bcp14>MUST</bcp14> silently drop any link-layer frames
This parameter allows the JRC to configure the node acting as a JP to filter out originating from the pledge identifiers enclosed in the blacklist parameter.
traffic from misconfigured or malicious pledges before their traffic is forward When this parameter is received, its value <bcp14>MUST</bcp14> overwrite any pre
ed into the network. viously set values.
If the JRC decides to remove a given pledge identifier from a blacklist, it omit This parameter allows the JRC to configure the node acting as a JP to filter out
s the pledge identifier in the blacklist parameter value it sends next. traffic from misconfigured or malicious pledges before their traffic is forwarde
d 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.
Since the blacklist parameter carries the pledge identifiers, privacy considerat ions apply. Since the blacklist parameter carries the pledge identifiers, privacy considerat ions apply.
See <xref target="privacy_considerations"/>.</t> See <xref target="privacy_considerations" format="default"/>.</dd>
<t>join rate: Average data rate (in units of bytes/second) of join traffic for <dt>join rate:</dt>
warded into the network that should not be exceeded when a joined node operates <dd>The average data rate (in units of bytes/second) of join traffic
as a JP, encoded as an unsigned integer. forwarded into the network that should not be exceeded when a joined node operat
The join rate parameter MAY be included in a Configuration object. es
This parameter allows the JRC to configure different nodes in the network to ope as a JP, encoded as an unsigned integer.
rate as JP, and act in case of an attack by throttling the rate at which JP forw The join rate parameter <bcp14>MAY</bcp14> be included in a Configuration object
ards unauthenticated traffic into the network. .
When this parameter is present in a Configuration object, the value MUST be used This parameter allows the JRC to configure different nodes in the network to
to set the PROBING_RATE of CoAP at the joined node for communication with the J operate as JP and to act in case of an attack by throttling the rate at which JP
RC. forwards unauthenticated traffic into the network.
In case this parameter is set to zero, a joined node MUST silently drop any join When this parameter is present in a Configuration object, the value <bcp14>MUST<
traffic coming from unauthenticated pledges. /bcp14>
In case this parameter is omitted, the value of positive infinity SHOULD be assu be used to set the PROBING_RATE of CoAP at the joined node for communication wit
med. h the JRC.
Node operating as a JP MAY use another mechanism that is out of scope of this sp If this parameter is set to zero, a joined node <bcp14>MUST</bcp14> silently dro
ecification to configure PROBING_RATE of CoAP in the absence of a join rate para p
meter from the Configuration object.</t> any join traffic coming from unauthenticated pledges.
</list></t> If this parameter is omitted, the value of positive infinity <bcp14>SHOULD</bcp1
4> be assumed.
<t><xref target="table_configuration_params"/> summarizes the parameters that ma A node operating as a JP <bcp14>MAY</bcp14> use another mechanism that is out of
y appear in a Configuration object.</t> scope
of this specification to configure the PROBING_RATE of CoAP in the absence of a
<texttable title="Summary of Configuration parameters." anchor="table_configurat join rate parameter from the Configuration object.</dd>
ion_params"> </dl>
<ttcol align='right'>Name</ttcol> <t><xref target="table_configuration_params" format="default"/>
<ttcol align='left'>Label</ttcol> summarizes the parameters that may appear in a Configuration object.</t>
<ttcol align='right'>CBOR Type</ttcol> <table anchor="table_configuration_params" align="center">
<c>link-layer key set</c> <name>Summary of Configuration parameters.</name>
<c>2</c> <thead>
<c>array</c> <tr>
<c>short identifier</c> <th>Name</th>
<c>3</c> <th>Label</th>
<c>array</c> <th>CBOR Type</th>
<c>JRC address</c> </tr>
<c>4</c> </thead>
<c>byte string</c> <tbody>
<c>blacklist</c> <tr>
<c>6</c> <td>link-layer key set</td>
<c>array</c> <td>2</td>
<c>join rate</c> <td>array</td>
<c>7</c> </tr>
<c>unsigned integer</c> <tr>
</texttable> <td>short identifier</td>
<td>3</td>
<t>The CDDL fragment that represents the text above for the Configuration follow <td>array</td>
s. </tr>
Structures Link_Layer_Key and Short_Identifier are specified in <xref target="ll <tr>
_keys"/> and <xref target="short_identifier"/>.</t> <td>JRC address</td>
<td>4</td>
<figure><artwork><![CDATA[ <td>byte string</td>
</tr>
<tr>
<td>blacklist</td>
<td>6</td>
<td>array</td>
</tr>
<tr>
<td>join rate</td>
<td>7</td>
<td>unsigned integer</td>
</tr>
</tbody>
</table>
<t>The CDDL fragment that represents the text above for the Configurat
ion follows.
The structures Link_Layer_Key and Short_Identifier are specified in
Sections <xref target="ll_keys" format="counter"/> and <xref target="short_ident
ifier" format="counter"/>,
respectively.</t>
<sourcecode type=""><![CDATA[
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
? 6 : [ *bstr ], ; blacklist ? 6 : [ *bstr ], ; blacklist
? 7 : uint ; join rate ? 7 : uint ; join rate
} }
]]></artwork></figure> ]]></sourcecode>
<texttable title="CoJP parameters map labels." anchor="table_cojp_parameters_lab
els">
<ttcol align='right'>Name</ttcol>
<ttcol align='left'>Label</ttcol>
<ttcol align='right'>CBOR type</ttcol>
<ttcol align='left'>Description</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>role</c>
<c>1</c>
<c>unsigned integer</c>
<c>Identifies the role parameter</c>
<c>[[this document]]</c>
<c>link-layer key set</c>
<c>2</c>
<c>array</c>
<c>Identifies the array carrying one or more link-level cryptographic keys
</c>
<c>[[this document]]</c>
<c>short identifier</c>
<c>3</c>
<c>array</c>
<c>Identifies the assigned short identifier</c>
<c>[[this document]]</c>
<c>JRC address</c>
<c>4</c>
<c>byte string</c>
<c>Identifies the IPv6 address of the JRC</c>
<c>[[this document]]</c>
<c>network identifier</c>
<c>5</c>
<c>byte string</c>
<c>Identifies the network identifier parameter</c>
<c>[[this document]]</c>
<c>blacklist</c>
<c>6</c>
<c>array</c>
<c>Identifies the blacklist parameter</c>
<c>[[this document]]</c>
<c>join rate</c>
<c>7</c>
<c>unsigned integer</c>
<c>Identifier the join rate parameter</c>
<c>[[this document]]</c>
<c>unsupported configuration</c>
<c>8</c>
<c>array</c>
<c>Identifies the unsupported configuration parameter</c>
<c>[[this document]]</c>
</texttable>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> <table anchor="table_cojp_parameters_labels" align="center">
<name>CoJP parameters map labels.</name>
<thead>
<tr>
<th>Name</th>
<th>Label</th>
<th>CBOR type</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>role</td>
<td>1</td>
<td>unsigned integer</td>
<td>Identifies the role parameter</td>
<td>RFC 9031</td>
</tr>
<tr>
<td>link-layer key set</td>
<td>2</td>
<td>array</td>
<td>Identifies the array carrying one or more link-layer cryptog
raphic keys</td>
<td>RFC 9031</td>
</tr>
<tr>
<td>short identifier</td>
<td>3</td>
<td>array</td>
<td>Identifies the assigned short identifier</td>
<td>RFC 9031</td>
</tr>
<tr>
<td>JRC address</td>
<td>4</td>
<td>byte string</td>
<td>Identifies the IPv6 address of the JRC</td>
<td>RFC 9031</td>
</tr>
<tr>
<td>network identifier</td>
<td>5</td>
<td>byte string</td>
<td>Identifies the network identifier parameter</td>
<td>RFC 9031</td>
</tr>
<tr>
<td>blacklist</td>
<td>6</td>
<td>array</td>
<td>Identifies the blacklist parameter</td>
<td>RFC 9031</td>
</tr>
<tr>
<td>join rate</td>
<td>7</td>
<td>unsigned integer</td>
<td>Identifier the join rate parameter</td>
<td>RFC 9031</td>
</tr>
<tr>
<td>unsupported configuration</td>
<td>8</td>
<td>array</td>
<td>Identifies the unsupported configuration parameter</td>
<td>RFC 9031</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="ll_keys" title="Link-Layer Key"> <section anchor="ll_keys" numbered="true" toc="default">
<name>Link-Layer Key</name>
<t>The Link_Layer_Key structure encompasses the parameters needed to configure t <t>The Link_Layer_Key structure encompasses the parameters needed to c
he link-layer security module: onfigure the link-layer security module:
the key identifier; the key identifier;
the value of the cryptographic key; the value of the cryptographic key;
the link-layer algorithm identifier and the security level and the frame typ the link-layer algorithm identifier and the security level and the frame typ
es that it should be used with, both for outgoing and incoming security operatio es
ns; with which it should be used for both outgoing and incoming security op
erations;
and any additional information that may be needed to configure the key.</t> and any additional information that may be needed to configure the key.</t>
<t>For encoding compactness, the Link_Layer_Key object is not enclosed
<t>For encoding compactness, the Link_Layer_Key object is not enclosed in a top- in a top-level CBOR object.
level CBOR object. Rather, it is transported as a sequence of CBOR elements <xref target="RFC8742"
Rather, it is transported as a sequence of CBOR elements <xref target="I-D.ietf- format="default"/>, some being optional.</t>
cbor-sequence"/>, some being optional.</t> <t>The set of parameters that can appear in a Link_Layer_Key object is
summarized below, in order:</t>
<t>The set of parameters that can appear in a Link_Layer_Key object is summarize <dl spacing="normal">
d below, in order:</t> <dt>key_id:</dt>
<dd>The identifier of the key, encoded as a CBOR unsigned integer.
<t><list style="symbols"> This parameter <bcp14>MUST</bcp14> be included.
<t>key_id: The identifier of the key, encoded as a CBOR unsigned integer. If the decoded CBOR unsigned integer value is larger than the maximum link-layer
This parameter MUST be included. key identifier, the key is considered invalid.
If the decoded CBOR unsigned integer value is larger than the maximum link-layer If the key is considered invalid, the key <bcp14>MUST</bcp14> be discarded,
key identifier, the key is considered invalid. and the implementation <bcp14>MUST</bcp14> signal the error as specified in
In case the key is considered invalid, the key MUST be discarded and the impleme <xref target="cojp_error_handling" format="default"/>.</dd>
ntation MUST signal the error as specified in <xref target="cojp_error_handling" <dt>key_usage:</dt>
/>.</t> <dd>The identifier of the link-layer algorithm, security level, and
<t>key_usage: The identifier of the link-layer algorithm, security level and l link-layer frame types that can be used with the key, encoded as an integer.
ink-layer frame types that can be used with the key, encoded as an integer. This parameter <bcp14>MAY</bcp14> be included.
This parameter MAY be included. Possible values and the corresponding link-layer settings are specified in the
Possible values and the corresponding link-layer settings are specified in IANA IANA "Constrained Join Protocol (CoJP) Key Usage" registry (<xref target="iana_c
"CoJP Key Usage" registry (<xref target="iana_cojp_key_usage_registry"/>). ojp_key_usage_registry" format="default"/>).
In case the parameter is omitted, the default value of 0 (6TiSCH-K1K2-ENC-MIC32) If the parameter is omitted, the default value of 0 (6TiSCH-K1K2-ENC-MIC32)
from <xref target="table_key_usage_values"/> MUST be assumed. from <xref target="table_key_usage_values" format="default"/> <bcp14>MUST</bcp14
This default value has been chosen such that it results in byte savings in the m > be assumed.
ost constrained settings but does not imply a recommendation for its general usa This default value has been chosen because it results in byte savings
ge.</t> in the most constrained settings; its selection does not imply a recommendation
<t>key_value: The value of the cryptographic key, encoded as a byte string. for its general usage.</dd>
This parameter MUST be included. <dt>key_value:</dt>
If the length of the byte string is different than the corresponding key length <dd>The value of the cryptographic key, encoded as a byte string.
for a given algorithm specified by the key_usage parameter, the key MUST be disc This parameter <bcp14>MUST</bcp14> be included.
arded and the implementation MUST signal the error as specified in <xref target= If the length of the byte string is different than the corresponding key length
"cojp_error_handling"/>.</t> for a given algorithm specified by the key_usage parameter, the key
<t>key_addinfo: Additional information needed to configure the link-layer key, <bcp14>MUST</bcp14> be discarded, and the implementation <bcp14>MUST</bcp14>
encoded as a byte string. signal the error as specified in <xref target="cojp_error_handling" format="defa
This parameter MAY be included. ult"/>.</dd>
The processing of this parameter is dependent on the link-layer technology in us <dt>key_addinfo:</dt>
e and a particular keying mode.</t> <dd>Additional information needed to configure the link-layer key,
</list></t> encoded as a byte string.
This parameter <bcp14>MAY</bcp14> be included.
<t>To be able to decode the keys that are present in the link-layer key set, and The processing of this parameter is dependent on the link-layer technology
to identify individual parameters of a single Link_Layer_Key object, the CBOR d in use and a particular keying mode.</dd>
ecoder needs to differentiate between elements based on the CBOR type. </dl>
<t>To be able to decode the keys that are present in the
link-layer key set and to identify individual parameters of a single
Link_Layer_Key object, the CBOR decoder needs to differentiate between elements
based on the CBOR type.
For example, a uint that follows a byte string signals to the decoder that a new Link_Layer_Key object is being processed.</t> For example, a uint that follows a byte string signals to the decoder that a new Link_Layer_Key object is being processed.</t>
<t>The CDDL fragment for the Link_Layer_Key that
<t>The CDDL fragment that represents the text above for the Link_Layer_Key follo represents the text above follows:</t>
ws.</t> <sourcecode type=""><![CDATA[
<figure><artwork><![CDATA[
Link_Layer_Key = ( Link_Layer_Key = (
key_id : uint, key_id : uint,
? key_usage : int, ? key_usage : int,
key_value : bstr, key_value : bstr,
? key_addinfo : bstr, ? key_addinfo : bstr,
) )
]]></artwork></figure> ]]></sourcecode>
<texttable title="Key Usage values." anchor="table_key_usage_values">
<ttcol align='right'>Name</ttcol>
<ttcol align='left'>Value</ttcol>
<ttcol align='right'>Algorithm</ttcol>
<ttcol align='left'>Description</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>6TiSCH-K1K2-ENC-MIC32</c>
<c>0</c>
<c>IEEE802154-AES-CCM-128</c>
<c>Use MIC-32 for EBs, ENC-MIC-32 for DATA and ACKNOWLEDGMENT.</c>
<c>[[this document]]</c>
<c>6TiSCH-K1K2-ENC-MIC64</c>
<c>1</c>
<c>IEEE802154-AES-CCM-128</c>
<c>Use MIC-64 for EBs, ENC-MIC-64 for DATA and ACKNOWLEDGMENT.</c>
<c>[[this document]]</c>
<c>6TiSCH-K1K2-ENC-MIC128</c>
<c>2</c>
<c>IEEE802154-AES-CCM-128</c>
<c>Use MIC-128 for EBs, ENC-MIC-128 for DATA and ACKNOWLEDGMENT.</c>
<c>[[this document]]</c>
<c>6TiSCH-K1K2-MIC32</c>
<c>3</c>
<c>IEEE802154-AES-CCM-128</c>
<c>Use MIC-32 for EBs, DATA and ACKNOWLEDGMENT.</c>
<c>[[this document]]</c>
<c>6TiSCH-K1K2-MIC64</c>
<c>4</c>
<c>IEEE802154-AES-CCM-128</c>
<c>Use MIC-64 for EBs, DATA and ACKNOWLEDGMENT.</c>
<c>[[this document]]</c>
<c>6TiSCH-K1K2-MIC128</c>
<c>5</c>
<c>IEEE802154-AES-CCM-128</c>
<c>Use MIC-128 for EBs, DATA and ACKNOWLEDGMENT.</c>
<c>[[this document]]</c>
<c>6TiSCH-K1-MIC32</c>
<c>6</c>
<c>IEEE802154-AES-CCM-128</c>
<c>Use MIC-32 for EBs.</c>
<c>[[this document]]</c>
<c>6TiSCH-K1-MIC64</c>
<c>7</c>
<c>IEEE802154-AES-CCM-128</c>
<c>Use MIC-64 for EBs.</c>
<c>[[this document]]</c>
<c>6TiSCH-K1-MIC128</c>
<c>8</c>
<c>IEEE802154-AES-CCM-128</c>
<c>Use MIC-128 for EBs.</c>
<c>[[this document]]</c>
<c>6TiSCH-K2-MIC32</c>
<c>9</c>
<c>IEEE802154-AES-CCM-128</c>
<c>Use MIC-32 for DATA and ACKNOWLEDGMENT.</c>
<c>[[this document]]</c>
<c>6TiSCH-K2-MIC64</c>
<c>10</c>
<c>IEEE802154-AES-CCM-128</c>
<c>Use MIC-64 for DATA and ACKNOWLEDGMENT.</c>
<c>[[this document]]</c>
<c>6TiSCH-K2-MIC128</c>
<c>11</c>
<c>IEEE802154-AES-CCM-128</c>
<c>Use MIC-128 for DATA and ACKNOWLEDGMENT.</c>
<c>[[this document]]</c>
<c>6TiSCH-K2-ENC-MIC32</c>
<c>12</c>
<c>IEEE802154-AES-CCM-128</c>
<c>Use ENC-MIC-32 for DATA and ACKNOWLEDGMENT.</c>
<c>[[this document]]</c>
<c>6TiSCH-K2-ENC-MIC64</c>
<c>13</c>
<c>IEEE802154-AES-CCM-128</c>
<c>Use ENC-MIC-64 for DATA and ACKNOWLEDGMENT.</c>
<c>[[this document]]</c>
<c>6TiSCH-K2-ENC-MIC128</c>
<c>14</c>
<c>IEEE802154-AES-CCM-128</c>
<c>Use ENC-MIC-128 for DATA and ACKNOWLEDGMENT.</c>
<c>[[this document]]</c>
</texttable>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<section anchor="keychanging6lbr" title="Rekeying of (6LoWPAN) Border Routers (6
LBR)">
<t>When the 6LoWPAN Border Router (6LBR) receives the Configuration object conta <table anchor="table_key_usage_values" align="center">
ining a link-layer key set, it MUST immediately install and start using the new <name>Key Usage values.</name>
keys for all outgoing traffic, and remove any old keys it has installed from the <thead>
previous key set after a delay of COJP_REKEYING_GUARD_TIME has passed. <tr>
This mechanism is used by the JRC to force the 6LBR to start sending traffic wit <th>Name</th>
h the new key. <th>Value</th>
The decision is taken by the JRC when it has determined that the new key has bee <th>Algorithm</th>
n made available to all (or some overwhelming majority) of nodes. <th>Description</th>
Any node that the JRC has not yet reached at that point is either non-functional </tr>
or in extended sleep such that it will not be reached. </thead>
To get the key update, such node needs to go through the join process anew.</t> <tbody>
<tr>
<td>6TiSCH-K1K2-ENC-MIC32</td>
<td>0</td>
<td>IEEE802154-AES-CCM-128</td>
<td>Use MIC-32 for EBs, ENC-MIC-32 for DATA and ACKNOWLEDGMENT.<
/td>
</tr>
<tr>
<td>6TiSCH-K1K2-ENC-MIC64</td>
<td>1</td>
<td>IEEE802154-AES-CCM-128</td>
<td>Use MIC-64 for EBs, ENC-MIC-64 for DATA and ACKNOWLEDGMENT.<
/td>
</tr>
<tr>
<td>6TiSCH-K1K2-ENC-MIC128</td>
<td>2</td>
<td>IEEE802154-AES-CCM-128</td>
<td>Use MIC-128 for EBs, ENC-MIC-128 for DATA and ACKNOWLEDGMENT
.</td>
</tr>
<tr>
<td>6TiSCH-K1K2-MIC32</td>
<td>3</td>
<td>IEEE802154-AES-CCM-128</td>
<td>Use MIC-32 for EBs, DATA and ACKNOWLEDGMENT.</td>
</tr>
<tr>
<td>6TiSCH-K1K2-MIC64</td>
<td>4</td>
<td>IEEE802154-AES-CCM-128</td>
<td>Use MIC-64 for EBs, DATA and ACKNOWLEDGMENT.</td>
</tr>
<tr>
<td>6TiSCH-K1K2-MIC128</td>
<td>5</td>
<td>IEEE802154-AES-CCM-128</td>
<td>Use MIC-128 for EBs, DATA and ACKNOWLEDGMENT.</td>
</tr>
<tr>
<td>6TiSCH-K1-MIC32</td>
<td>6</td>
<td>IEEE802154-AES-CCM-128</td>
<td>Use MIC-32 for EBs.</td>
</tr>
<tr>
<td>6TiSCH-K1-MIC64</td>
<td>7</td>
<td>IEEE802154-AES-CCM-128</td>
<td>Use MIC-64 for EBs.</td>
</tr>
<tr>
<td>6TiSCH-K1-MIC128</td>
<td>8</td>
<td>IEEE802154-AES-CCM-128</td>
<td>Use MIC-128 for EBs.</td>
</tr>
<tr>
<td>6TiSCH-K2-MIC32</td>
<td>9</td>
<td>IEEE802154-AES-CCM-128</td>
<td>Use MIC-32 for DATA and ACKNOWLEDGMENT.</td>
</tr>
<tr>
<td>6TiSCH-K2-MIC64</td>
<td>10</td>
<td>IEEE802154-AES-CCM-128</td>
<td>Use MIC-64 for DATA and ACKNOWLEDGMENT.</td>
</tr>
<tr>
<td>6TiSCH-K2-MIC128</td>
<td>11</td>
<td>IEEE802154-AES-CCM-128</td>
<td>Use MIC-128 for DATA and ACKNOWLEDGMENT.</td>
</tr>
<tr>
<td>6TiSCH-K2-ENC-MIC32</td>
<td>12</td>
<td>IEEE802154-AES-CCM-128</td>
<td>Use ENC-MIC-32 for DATA and ACKNOWLEDGMENT.</td>
</tr>
<tr>
<td>6TiSCH-K2-ENC-MIC64</td>
<td>13</td>
<td>IEEE802154-AES-CCM-128</td>
<td>Use ENC-MIC-64 for DATA and ACKNOWLEDGMENT.</td>
</tr>
<tr>
<td>6TiSCH-K2-ENC-MIC128</td>
<td>14</td>
<td>IEEE802154-AES-CCM-128</td>
<td>Use ENC-MIC-128 for DATA and ACKNOWLEDGMENT.</td>
</tr>
</tbody>
</table>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> <section anchor="keychanging6lbr" numbered="true" toc="default">
<name>Rekeying of 6LBRs</name>
<t>When the 6LBR receives the Configuration object containing
a link-layer key set, it <bcp14>MUST</bcp14> immediately install and start
using the new keys for all outgoing traffic and
remove any old keys it has installed from the previous key set
after a delay of COJP_REKEYING_GUARD_TIME has passed.
This mechanism is used by the JRC to force the 6LBR to start sending
traffic with the new key.
The decision is made by the JRC when it has determined that the new key
has been made available to all (or some overwhelming majority) of nodes.
Any node that the JRC has not yet reached at that point is either
nonfunctional or in extended sleep such that it will not be reached.
To get the key update, such a node will need to go through the join process anew
.</t>
</section> </section>
<section anchor="keychanging6lr" title="Rekeying of regular (6LoWPAN) Nodes (6LN <section anchor="keychanging6lr" numbered="true" toc="default">
)"> <name>Rekeying of 6LNs</name>
<t>When a regular 6LN receives the Configuration object
<t>When a regular 6LN node receives the Configuration object with a link-layer k with a link-layer key set, it <bcp14>MUST</bcp14> install the new keys.
ey set, it MUST install the new keys.
The 6LN will use both the old and the new keys to decrypt and authenticate any i ncoming traffic that arrives based upon the key identifier in the packet. The 6LN will use both the old and the new keys to decrypt and authenticate any i ncoming traffic that arrives based upon the key identifier in the packet.
It MUST continue to use the old keys for all outgoing traffic until it has detec It <bcp14>MUST</bcp14> continue to use the old keys for all outgoing
ted that the network has switched to the new key set.</t> traffic until it has detected that the network has switched to the new key set.<
/t>
<t>The detection of network switch is based upon the receipt of traffic secured <t>The detection of the network switch is based
with the new keys. upon the receipt of traffic secured with the new keys.
Upon reception and successful security processing of a link-layer frame secured Upon the reception and the successful security processing of a link-layer
with a key from the new key set, a 6LN node MUST then switch to sending outgoing frame secured with a key from the new key set, a 6LN <bcp14>MUST</bcp14>
traffic using the keys from the new set for all outgoing traffic. then switch to sending all outgoing traffic using the keys from the
The 6LN node MUST remove any old keys it has installed from the previous key set new set.
after a delay of COJP_REKEYING_GUARD_TIME has passed after it starts using the The 6LN <bcp14>MUST</bcp14> remove any keys it had installed
new key set.</t> from the previous key set after waiting COJP_REKEYING_GUARD_TIME since
it started using the new key set.
<t>Sending of traffic with the new keys signals to other downstream nodes to swi </t>
tch to their new key, and the effect is that there is a ripple of key updates ar <t>Sending traffic with the new keys signals to other
ound each 6LBR.</t> downstream nodes to switch to their new key, causing
a ripple of key updates around each 6LBR.</t>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
</section> </section>
<section anchor="use-in-ieee-std-802154" title="Use in IEEE Std 802.15.4"> <section anchor="use-in-ieee-std-802154" numbered="true" toc="default"
>
<t>When Link_Layer_Key is used in the context of <xref target="IEEE802.15.4"/>, <name>Use in IEEE Std 802.15.4</name>
the following considerations apply.</t> <t>When Link_Layer_Key is used in the context of <xref target="IEEE8
02.15.4" format="default"/>, the following considerations apply.</t>
<t>Signaling of different keying modes of <xref target="IEEE802.15.4"/> is done <t>Signaling of different keying modes of <xref target="IEEE802.15.4
based on the parameter values present in a Link_Layer_Key object. " format="default"/> is done based on the parameter values present in a Link_Lay
For instance, the value of the key_id parameter in combination with key_addinfo er_Key object.
denotes which of the four Key ID modes of <xref target="IEEE802.15.4"/> is used For instance, the value of the key_id parameter in combination with key_addinfo
and how.</t> denotes which of the four Key ID modes of <xref target="IEEE802.15.4" format="de
fault"/> is used and how.</t>
<t><list style="symbols"> <dl spacing="normal">
<t>Key ID Mode 0x00 (Implicit, pairwise): <dt>Key ID Mode 0x00 (Implicit, pairwise):</dt>
key_id parameter MUST be set to 0. <dd>The key_id parameter <bcp14>MUST</bcp14> be set to 0.
key_addinfo parameter MUST be present. The key_addinfo parameter <bcp14>MUST</bcp14> be present.
key_addinfo parameter MUST be set to the link-layer address(es) of a single peer The key_addinfo parameter <bcp14>MUST</bcp14> be set to the link-layer
with whom the key should be used. address(es) of a single peer with whom the key should be used.
Depending on the configuration of the network, key_addinfo may carry the peer's Depending on the configuration of the network, key_addinfo may carry
long link-layer address (i.e. pledge identifier), short link-layer address, or t the peer's long link-layer address (i.e., pledge identifier),
heir concatenation with the long address being encoded first. short link-layer address, or their concatenation with the long address being enc
Which address type(s) is carried is determined from the length of the byte strin oded first.
g.</t> Which address type(s) is carried is determined from the length of the byte strin
<t>Key ID Mode 0x01 (Key Index): g.</dd>
key_id parameter MUST be set to a value different than 0. <dt>Key ID Mode 0x01 (Key Index):</dt>
key_addinfo parameter MUST NOT be present.</t> <dd>The key_id parameter <bcp14>MUST</bcp14> be set to a value different from 0.
<t>Key ID Mode 0x02 (4-byte Explicit Key Source): The key_addinfo parameter <bcp14>MUST NOT</bcp14> be present.</dd>
key_id parameter MUST be set to a value different than 0. <dt>Key ID Mode 0x02 (4-byte Explicit Key Source):</dt>
key_addinfo parameter MUST be present. <dd>The key_id parameter <bcp14>MUST</bcp14> be set to a value different from 0.
key_addinfo parameter MUST be set to a byte string, exactly 4 bytes long. The key_addinfo parameter <bcp14>MUST</bcp14> be present.
key_addinfo parameter carries the Key Source parameter used to configure <xref t The key_addinfo parameter <bcp14>MUST</bcp14> be set to a byte string, exactly 4
arget="IEEE802.15.4"/>.</t> bytes long.
<t>Key ID Mode 0x03 (8-byte Explicit Key Source): The key_addinfo parameter carries the Key Source parameter used to configure
key_id parameter MUST be set to a value different than 0. <xref target="IEEE802.15.4" format="default"/>.</dd>
key_addinfo parameter MUST be present. <dt>Key ID Mode 0x03 (8-byte Explicit Key Source):</dt>
key_addinfo parameter MUST be set to a byte string, exactly 8 bytes long. <dd>The key_id parameter <bcp14>MUST</bcp14> be set to a value different from 0.
key_addinfo parameter carries the Key Source parameter used to configure <xref t The key_addinfo parameter <bcp14>MUST</bcp14> be present.
arget="IEEE802.15.4"/>.</t> The key_addinfo parameter <bcp14>MUST</bcp14> be set to a byte string, exactly 8
</list></t> bytes long.
The key_addinfo parameter carries the Key Source parameter used to configure
<t>In all cases, key_usage parameter determines how a particular key should be u <xref target="IEEE802.15.4" format="default"/>.</dd>
sed in respect to incoming and outgoing security policies.</t> </dl>
<t>In all cases, the key_usage parameter determines how a
<t>For Key ID Modes 0x01 - 0x03, parameter key_id sets the "secKeyIndex" paramet particular key should be used with respect to incoming and outgoing security pol
er of <xref target="IEEE802.15.4"/> that is signaled in all outgoing frames secu icies.</t>
red with a given key. <t>For Key ID Modes 0x01 through 0x03, the key_id parameter
The maximum value key_id can have is 254. sets the "secKeyIndex" parameter of <xref target="IEEE802.15.4" format="default"
The value of 255 is reserved in <xref target="IEEE802.15.4"/> and is therefore c />
onsidered invalid.</t> that is signaled in all outgoing frames secured with a given key.
The maximum value that key_id can have is 254.
<t>Key ID Mode 0x00 (Implicit, pairwise) enables the JRC to act as a trusted thi The value of 255 is reserved in <xref target="IEEE802.15.4" format="default"/> a
rd party and assign pairwise keys between nodes in the network. nd is therefore considered invalid.</t>
How JRC learns about the network topology is out of scope of this specification, <t>Key ID Mode 0x00 (Implicit, pairwise) enables the JRC to act as a
but could be done through 6LBR - JRC signaling for example. trusted third party and assign pairwise keys between nodes in the network.
Pairwise keys could also be derived through a key agreement protocol executed be How the JRC learns about the network topology is out of scope of
tween the peers directly, where the authentication is based on the symmetric cry this specification, but it could be done through 6LBR-JRC signaling, for example
ptographic material provided to both peers by the JRC. .
Pairwise keys could also be derived through a key agreement protocol
executed between the peers directly, where the authentication is based on
the symmetric cryptographic material provided to both peers by the JRC.
Such a protocol is out of scope of this specification.</t> Such a protocol is out of scope of this specification.</t>
<t>Implementations <bcp14>MUST</bcp14> use different
<t>Implementations MUST use different link-layer keys when using different authe link-layer keys when using different authentication tag (MIC) lengths,
ntication tag (MIC) lengths, as using the same key with different authentication as using the same key with different authentication tag lengths might be unsafe.
tag lengths might be unsafe.
For example, this prohibits the usage of the same key for both MIC-32 and MIC-64 levels. For example, this prohibits the usage of the same key for both MIC-32 and MIC-64 levels.
See Annex B.4.3 of <xref target="IEEE802.15.4"/> for more information.</t> See Annex B.4.3 of <xref target="IEEE802.15.4" format="default"/> for more infor
mation.</t>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
</section> </section>
</section> </section>
<section anchor="short_identifier" title="Short Identifier"> <section anchor="short_identifier" numbered="true" toc="default">
<name>Short Identifier</name>
<t>The Short_Identifier object represents an identifier assigned to the pledge. <t>The Short_Identifier object represents an identifier assigned to th
It is encoded as a CBOR array object, containing, in order:</t> e pledge.
It is encoded as a CBOR array object and contains, in order:</t>
<t><list style="symbols"> <dl spacing="normal">
<t>identifier: The short identifier assigned to the pledge, encoded as a byte <dt>identifier:</dt>
string. <dd>The short identifier assigned to the pledge, encoded as a byte s
This parameter MUST be included. tring.
The identifier MUST be unique in the set of all identifiers assigned in a networ This parameter <bcp14>MUST</bcp14> be included.
k that is managed by a JRC. The identifier <bcp14>MUST</bcp14> be unique in the set of all identifiers assig
In case the identifier is invalid, the decoder MUST silently ignore the Short_Id ned
entifier object.</t> in a network that is managed by a JRC.
<t>lease_time: The validity of the identifier in hours after the reception of If the identifier is invalid, the decoder <bcp14>MUST</bcp14> silently
the CBOR object, encoded as a CBOR unsigned integer. ignore the Short_Identifier object.</dd>
This parameter MAY be included. <dt>lease_time:</dt>
The node MUST stop using the assigned short identifier after the expiry of the l <dd>The validity of the identifier in hours after the reception
ease_time interval. of the CBOR object, encoded as a CBOR unsigned integer.
This parameter <bcp14>MAY</bcp14> be included.
The node <bcp14>MUST</bcp14> stop using the assigned short identifier after
the expiry of the lease_time interval.
It is up to the JRC to renew the lease before the expiry of the previous interva l. It is up to the JRC to renew the lease before the expiry of the previous interva l.
The JRC updates the lease by executing the Parameter Update exchange with the no The JRC updates the lease by executing the parameter update exchange with the no
de and including the Short_Identifier in the Configuration object, as described de
in <xref target="update"/>. and including the Short_Identifier in the Configuration object, as described in
In case the lease expires, the node SHOULD initiate a new join exchange, as desc <xref target="update" format="default"/>.
ribed in <xref target="join"/>. If the lease expires, then the node <bcp14>SHOULD</bcp14> initiate a new join ex
In case this parameter is omitted, the value of positive infinity MUST be assume change,
d, meaning that the identifier is valid for as long as the node participates in as described in <xref target="join" format="default"/>.
the network.</t> If this parameter is omitted, then the value of positive infinity <bcp14>MUST</b
</list></t> cp14>
be assumed, meaning that the identifier is valid for as long as the node partici
<t>The CDDL fragment that represents the text above for the Short_Identifier fol pates
lows.</t> in the network.</dd>
</dl>
<figure><artwork><![CDATA[ <t>The CDDL fragment for the Short_Identifier that
represents the text above follows:</t>
<sourcecode type=""><![CDATA[
Short_Identifier = [ Short_Identifier = [
identifier : bstr, identifier : bstr,
? lease_time : uint ? lease_time : uint
] ]
]]></artwork></figure> ]]></sourcecode>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<section anchor="use-in-ieee-std-802154-1" title="Use in IEEE Std 802.15.4">
<t>When Short_Identifier is used in the context of <xref target="IEEE802.15.4"/>
, the following considerations apply.</t>
<t>The identifier MUST be used to set the short address of IEEE Std 802.15.4 mod
ule.
When operating in TSCH mode, the identifier MUST be unique in the set of all ide
ntifiers assigned in multiple networks that share link-layer key(s).
If the length of the byte string corresponding to the identifier parameter is di
fferent than 2, the identifier is considered invalid.
The values 0xfffe and 0xffff are reserved by <xref target="IEEE802.15.4"/> and t
heir use is considered invalid.</t>
<t>The security properties offered by the <xref target="IEEE802.15.4"/> link-lay <section anchor="use-in-ieee-std-802154-1" numbered="true" toc="default">
er in TSCH mode are conditioned on the uniqueness requirement of the short ident <name>Use in IEEE Std 802.15.4</name>
ifier (i.e. short address). <t>When the Short_Identifier is used in the context of <xref target=
"IEEE802.15.4" format="default"/>, the following considerations apply.</t>
<t>The identifier <bcp14>MUST</bcp14> be used to set the
short address of the IEEE Std 802.15.4 module.
When operating in TSCH mode, the identifier <bcp14>MUST</bcp14> be unique in the
set of all identifiers assigned in multiple networks that share link-layer key(
s).
If the length of the byte string corresponding to the identifier
parameter is different from 2, the identifier is considered invalid.
The values 0xfffe and 0xffff are reserved by <xref target="IEEE802.15.4" format=
"default"/>,
and their use is considered invalid.</t>
<t>The security properties offered by the
<xref target="IEEE802.15.4" format="default"/> link-layer in TSCH mode are
conditioned on the uniqueness requirement of the short identifier (i.e., short a
ddress).
The short address is one of the inputs in the construction of the nonce, which i s used to protect link-layer frames. The short address is one of the inputs in the construction of the nonce, which i s used to protect link-layer frames.
If a misconfiguration occurs, and the same short address is assigned twice under the same link-layer key, the loss of security properties is imminent. If a misconfiguration occurs, and the same short address is assigned twice under the same link-layer key, the loss of security properties is imminent.
For this reason, practices where the pledge generates the short identifier local ly are not safe and are likely to result in the loss of link-layer security prop erties.</t> For this reason, practices where the pledge generates the short identifier local ly are not safe and are likely to result in the loss of link-layer security prop erties.</t>
<t>The JRC <bcp14>MUST</bcp14> ensure that at any
<t>The JRC MUST ensure that at any given time there are never two same short ide given time there are never two of the same short identifiers being
ntifiers being used under the same link-layer key. used under the same link-layer key.
If the lease_time parameter of a given Short_Identifier object is set to positiv If the lease_time parameter of a given Short_Identifier object is
e infinity, care needs to be taken that the corresponding identifier is not assi set to positive infinity, care needs to be taken that the corresponding
gned to another node until the JRC is certain that it is no longer in use, poten identifier is not assigned to another node until the JRC is certain
tially through out-of-band signaling. that it is no longer in use, potentially through out-of-band signaling.
If the lease_time parameter expires for any reason, the JRC should take into con If the lease_time parameter expires for any reason, the JRC should take
sideration potential ongoing transmissions by the joined node, which may be hang into consideration potential ongoing transmissions by the joined node,
ing in the queues, before assigning the same identifier to another node.</t> which may be hanging in the queues, before assigning the same identifier
to another node.</t>
<t>Care needs to be taken on how the pledge (joined node) configures the expirat <t>Care needs to be taken on how the pledge (joined node) configures
ion of the lease. the expiration of the lease.
Since units of the lease_time parameter are in hours after the reception of the Since units of the lease_time parameter are in hours after the reception of the
CBOR object, the pledge needs to convert the received time to the corresponding CBOR object, the pledge needs to convert the received time to the corresponding
absolute slot number in the network. Absolute Slot Number in the network.
The joined node (pledge) MUST only use the absolute slot number as the appropria The joined node (pledge) <bcp14>MUST</bcp14> only use the
te reference of time to determine whether the assigned short identifier is still Absolute Slot Number as the appropriate reference of time to determine whether t
valid.</t> he assigned short identifier is still valid.</t>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
</section> </section>
</section> </section>
<section anchor="unsupported_configuration_object" title="Unsupported Configurat <section anchor="unsupported_configuration_object" numbered="true" toc="
ion Object"> default">
<name>Unsupported Configuration Object</name>
<t>The Unsupported_Configuration object is encoded as a CBOR array, containing a <t>The Unsupported_Configuration object is encoded as a CBOR array, co
t least one Unsupported_Parameter object. ntaining at least one Unsupported_Parameter object.
Each Unsupported_Parameter object is a sequence of CBOR elements without an encl osing top-level CBOR object for compactness. Each Unsupported_Parameter object is a sequence of CBOR elements without an encl osing top-level CBOR object for compactness.
The set of parameters that appear in an Unsupported_Parameter object is summariz ed below, in order:</t> The set of parameters that appear in an Unsupported_Parameter object is summariz ed below, in order:</t>
<dl spacing="normal">
<t><list style="symbols"> <dt>code:</dt>
<t>code: Indicates the capability of acting on the parameter signaled by param <dd>Indicates the capability of acting on the
eter_label, encoded as an integer. parameter signaled by parameter_label, encoded as an integer.
This parameter MUST be included. This parameter <bcp14>MUST</bcp14> be included.
Possible values of this parameter are specified in the IANA "CoJP Unsupported Co Possible values of this parameter are specified in the
nfiguration Code Registry" (<xref target="iana_cojp_unsupported_code_registry"/> IANA "Constrained Join Protocol (CoJP) Unsupported Configuration Codes" registry
).</t> (<xref target="iana_cojp_unsupported_code_registry" format="default"/>).</dd>
<t>parameter_label: Indicates the parameter. <dt>parameter_label:</dt>
This parameter MUST be included. <dd>Indicates the parameter. This parameter
Possible values of this parameter are specified in the label column of the IANA <bcp14>MUST</bcp14> be included. Possible values of this
"CoJP Parameters" registry (<xref target="iana_cojp_registry"/>).</t> parameter are specified in the label column of the
<t>parameter_addinfo: Additional information about the parameter that cannot b IANA "Constrained Join Protocol (CoJP) Parameters" registry" (<xref target="iana
e acted upon. _cojp_registry" format="default"/>).</dd>
This parameter MUST be included. <dt>parameter_addinfo:</dt>
In case the code is set to "Unsupported", parameter_addinfo gives additional inf <dd>Additional information about the parameter
ormation to the JRC. that cannot be acted upon.
If the parameter indicated by parameter_label cannot be acted upon regardless of This parameter <bcp14>MUST</bcp14> be included.
its value, parameter_addinfo MUST be set to null, signaling to the JRC that it If the code is set to "Unsupported", parameter_addinfo gives
SHOULD NOT attempt to configure the parameter again. additional information to the JRC.
If the pledge can act on the parameter, but cannot configure the setting indicat If the parameter indicated by parameter_label cannot be acted upon
ed by the parameter value, the pledge can hint this to the JRC. regardless of its value, parameter_addinfo <bcp14>MUST</bcp14>
In this case, parameter_addinfo MUST be set to the value of the parameter that c be set to null, signaling to the JRC that it <bcp14>SHOULD NOT</bcp14>
annot be acted upon following the normative parameter structure specified in thi attempt to configure the parameter again.
s document. If the pledge can act on the parameter, but cannot configure the
For example, it is possible to include the link-layer key set object, signaling setting indicated by the parameter value, the pledge can hint this
a subset of keys that cannot be acted upon, or the entire key set that was recei to the JRC.
ved. In this case, parameter_addinfo <bcp14>MUST</bcp14> be set to the
In that case, the value of the parameter_addinfo follows the link-layer key set value of the parameter that cannot be acted upon following the
structure defined in <xref target="configuration_object"/>. normative parameter structure specified in this document.
In case the code is set to "Malformed", parameter_addinfo MUST be set to null, s For example, it is possible to include the link-layer key set
ignaling to the JRC that it SHOULD NOT attempt to configure the parameter again. object, signaling that either a subset or the entire key set that
</t> was received cannot be acted upon.
</list></t> In that case, the value of parameter_addinfo follows the
link-layer key set structure defined in
<t>The CDDL fragment that represents the text above for Unsupported_Configuratio <xref target="configuration_object" format="default"/>.
n and Unsupported_Parameter objects follows.</t> If the code is set to "Malformed", parameter_addinfo <bcp14>MUST</bcp14>
be set to null, signaling to the JRC that it <bcp14>SHOULD NOT</bcp14>
<figure><artwork><![CDATA[ attempt to configure the parameter again.</dd>
</dl>
<t>The CDDL fragment
for the Unsupported_Configuration and Unsupported_Parameter objects
that represents the text above
follows:</t>
<sourcecode type=""><![CDATA[
Unsupported_Configuration = [ Unsupported_Configuration = [
+ parameter : Unsupported_Parameter + parameter : Unsupported_Parameter
] ]
Unsupported_Parameter = ( Unsupported_Parameter = (
code : int, code : int,
parameter_label : int, parameter_label : int,
parameter_addinfo : nil / any parameter_addinfo : nil / any
) )
]]></artwork></figure> ]]></sourcecode>
<texttable title="Unsupported Configuration code values." anchor="table_unsuppor
ted_code_values">
<ttcol align='right'>Name</ttcol>
<ttcol align='left'>Value</ttcol>
<ttcol align='right'>Description</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>Unsupported</c>
<c>0</c>
<c>The indicated setting is not supported by the networking stack implemen
tation.</c>
<c>[[this document]]</c>
<c>Malformed</c>
<c>1</c>
<c>The indicated parameter value is malformed.</c>
<c>[[this document]]</c>
</texttable>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> <table anchor="table_unsupported_code_values" align="center">
<name>Unsupported Configuration code values.</name>
<thead>
<tr>
<th>Name</th>
<th>Value</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>Unsupported</td>
<td>0</td>
<td>The indicated setting is not supported by the networking sta
ck implementation.</td>
<td>RFC 9031</td>
</tr>
<tr>
<td>Malformed</td>
<td>1</td>
<td>The indicated parameter value is malformed.</td>
<td>RFC 9031</td>
</tr>
</tbody>
</table>
</section> </section>
</section> </section>
<section anchor="recommended-settings" title="Recommended Settings"> <section anchor="recommended-settings" numbered="true" toc="default">
<name>Recommended Settings</name>
<t>This section gives RECOMMENDED values of CoJP settings.</t> <t>This section gives <bcp14>RECOMMENDED</bcp14> values of CoJP settings
.</t>
<texttable title="Recommended CoJP settings."> <table align="center">
<ttcol align='right'>Name</ttcol> <name>Recommended CoJP settings.</name>
<ttcol align='left'>Default Value</ttcol> <thead>
<c>COJP_MAX_JOIN_ATTEMPTS</c> <tr>
<c>4</c> <th>Name</th>
<c>COJP_REKEYING_GUARD_TIME</c> <th>Default Value</th>
<c>12 seconds</c> </tr>
</texttable> </thead>
<tbody>
<t>The COJP_REKEYING_GUARD_TIME value SHOULD take into account possible retransm <tr>
issions at the link layer due to imperfect wireless links.</t> <td>COJP_MAX_JOIN_ATTEMPTS</td>
<td>4</td>
<!-- ====================================================================== --> </tr>
<tr>
<td>COJP_REKEYING_GUARD_TIME</td>
<td>12 seconds</td>
</tr>
</tbody>
</table>
<t>The COJP_REKEYING_GUARD_TIME value <bcp14>SHOULD</bcp14> take into ac
count possible retransmissions at the link layer due to imperfect wireless links
.</t>
</section> </section>
</section> </section>
<section anchor="sec_considerations" title="Security Considerations"> <section anchor="sec_considerations" numbered="true" toc="default">
<name>Security Considerations</name>
<t>Since this document uses the pledge identifier to set the ID Context paramete <t>Since this document uses the pledge identifier to set
r of OSCORE, an important security requirement is that the pledge identifier is the ID Context parameter of OSCORE, an important security requirement is
unique in the set of all pledge identifiers managed by a JRC. that the pledge identifier is unique in the set of all pledge identifiers manage
The uniqueness of the pledge identifier ensures unique (key, nonce) pairs for AE d by a JRC.
AD algorithm used by OSCORE. The uniqueness of the pledge identifier ensures unique (key, nonce) pairs
It also allows the JRC to retrieve the correct security context, upon the recept for the AEAD algorithm used by OSCORE.
ion of a Join Request message. It also allows the JRC to retrieve the correct security context
The management of pledge identifiers is simplified if the globally unique EUI-64 upon the reception of a Join Request message.
is used, but this comes with privacy risks, as discussed in <xref target="priva The management of pledge identifiers is simplified if the globally
cy_considerations"/>.</t> unique EUI-64 is used, but this comes with privacy risks, as discussed
in <xref target="privacy_considerations" format="default"/>.</t>
<t>This document further mandates that the (6LBR) pledge and the JRC are provisi <t>This document further mandates that the (6LBR) pledge and the JRC are p
oned with unique PSKs. rovisioned with unique PSKs.
While the process of provisioning PSKs to all pledges can result in a substantia l operational overhead, it is vital to do so for the security properties of the network. While the process of provisioning PSKs to all pledges can result in a substantia l operational overhead, it is vital to do so for the security properties of the network.
The PSK is used to set the OSCORE Master Secret during security context derivati on. The PSK is used to set the OSCORE Master Secret during security context derivati on.
This derivation process results in OSCORE keys that are important for mutual aut hentication of the (6LBR) pledge and the JRC. This derivation process results in OSCORE keys that are important for mutual aut hentication of the (6LBR) pledge and the JRC.
The resulting security context shared between the pledge (joined node) and the J The resulting security context shared between the pledge (joined node)
RC is used for the purpose of joining and is long-lived in that it can be used t and the JRC is used for the purpose of joining and is long-lived in
hroughout the lifetime of a joined node for parameter update exchanges. that it can be used throughout the lifetime of a joined node
for parameter update exchanges.
Should an attacker come to know the PSK, then a man-in-the-middle attack is poss ible.</t> Should an attacker come to know the PSK, then a man-in-the-middle attack is poss ible.</t>
<t>Note that while OSCORE provides replay protection, it does not
<t>Note that while OSCORE provides replay protection, it does not provide an ind provide an indication of freshness in the presence of an attacker
ication of freshness in the presence of an attacker that can drop/reorder traffi that can drop and/or reorder traffic.
c. Since the Join Request contains no randomness, and the
Since the join request contains no randomness, and the sequence number is predic sequence number is predictable, the JRC could in principle anticipate
table, the JRC could in principle anticipate a join request from a particular pl a Join Request from a particular pledge and pre-calculate the response.
edge and pre-calculate the response. In such a scenario, the JRC does not have to be alive at the time
In such a scenario, the JRC does not have to be alive at the time when the reque the request is received.
st is received. This could be relevant in the case when the JRC was temporarily compromised
This could be relevant in case the JRC was temporarily compromised and control s and control was subsequently regained by the legitimate owner.</t>
ubsequently regained by the legitimate owner.</t> <t>It is of utmost importance to avoid unsafe practices when generating an
d provisioning PSKs.
<t>It is of utmost importance to avoid unsafe practices when generating and prov
isioning PSKs.
The use of a single PSK shared among a group of devices is a common pitfall that results in poor security. The use of a single PSK shared among a group of devices is a common pitfall that results in poor security.
In this case, the compromise of a single device is likely to lead to a compromis In this case, the compromise of a single device is likely to lead to a compromis
e of the entire batch, with the attacker having the ability to impersonate a leg e of the entire batch, with the attacker having the ability to impersonate a leg
itimate device and join the network, generate bogus data and disturb the network itimate device and join the network,
operation. generate bogus data, and disturb the network operation.
Additionally, some vendors use methods such as scrambling or hashing of device s Additionally, some vendors use methods such as scrambling or hashing
erial numbers or their EUI-64 to generate "unique" PSKs. device serial numbers or their EUI-64 identifiers to generate "unique" PSKs.
Without any secret information involved, the effort that the attacker needs to i nvest into breaking these unsafe derivation methods is quite low, resulting in t he possible impersonation of any device from the batch, without even needing to compromise a single device. Without any secret information involved, the effort that the attacker needs to i nvest into breaking these unsafe derivation methods is quite low, resulting in t he possible impersonation of any device from the batch, without even needing to compromise a single device.
The use of cryptographically secure random number generators to generate the PSK The use of cryptographically secure random number generators to generate the PSK
is RECOMMENDED, see <xref target="NIST800-90A"/> for different mechanisms using is <bcp14>RECOMMENDED</bcp14>, see <xref target="NIST800-90A" format="default"/
deterministic methods.</t> > for different mechanisms using deterministic methods.</t>
<t>The JP forwards the unauthenticated join traffic into the network.
<t>The JP forwards the unauthenticated join traffic into the network.
A data cap on the JP prevents it from forwarding more traffic than the network c an handle and enables throttling in case of an attack. A data cap on the JP prevents it from forwarding more traffic than the network c an handle and enables throttling in case of an attack.
Note that this traffic can only be directed at the JRC so that the JRC needs to be prepared to handle such unsanitized inputs. Note that this traffic can only be directed at the JRC so that the JRC needs to be prepared to handle such unsanitized inputs.
The data cap can be configured by the JRC by including a join rate parameter in The data cap can be configured by the JRC by including a join rate parameter
the Join Response and it is implemented through the CoAP's PROBING_RATE setting. in the Join Response, and it is implemented through the CoAP's PROBING_RATE sett
ing.
The use of a data cap at a JP forces attackers to use more than one JP if they w ish to overwhelm the network. The use of a data cap at a JP forces attackers to use more than one JP if they w ish to overwhelm the network.
Marking the join traffic packets with a non-zero DSCP allows the network to carr Marking the join traffic packets with a nonzero DSCP allows the
y the traffic if it has capacity, but encourages the network to drop the extra t network to carry the traffic if it has capacity, but it encourages
raffic rather than add bandwidth due to that traffic.</t> the network to drop the extra traffic rather than add bandwidth due to that traf
fic.</t>
<t>The shared nature of the "minimal" cell used for the join traffic makes the n <t>The shared nature of the "minimal" cell used for the join traffic makes
etwork prone to a DoS attack by congesting the JP with bogus traffic. the network prone to a DoS attack by congesting the JP with bogus traffic.
Such an attacker is limited by its maximum transmit power. Such an attacker is limited by its maximum transmit power.
The redundancy in the number of deployed JPs alleviates the issue and also gives The redundancy in the number of deployed JPs alleviates the issue
the pledge a possibility to use the best available link for joining. and also gives the pledge the possibility to use the best available link for joi
ning.
How a network node decides to become a JP is out of scope of this specification. </t> How a network node decides to become a JP is out of scope of this specification. </t>
<t>At the beginning of the join process, the pledge has no
<t>At the beginning of the join process, the pledge has no means of verifying th means of verifying the content in the EB and has to accept it at "face value".
e content in the EB, and has to accept it at "face value". If the pledge tries to join an attacker's network,
In case the pledge tries to join an attacker's network, the Join Response messag the Join Response message will either fail the security check or time out.
e will either fail the security check or time out. The pledge may implement a temporary blacklist in order to filter out
The pledge may implement a temporary blacklist in order to filter out undesired undesired EBs and try to join using the next seemingly valid EB.
EBs and try to join using the next seemingly valid EB. This blacklist alleviates the issue but is effectively limited by
This blacklist alleviates the issue, but is effectively limited by the node's av the node's available memory.
ailable memory. Note that this temporary blacklist is different from the one
Note that this temporary blacklist is different from the one communicated as par communicated as part of the CoJP Configuration object as it helps
t of the CoJP Configuration object as it helps pledge fight a DoS attack. the pledge fight a DoS attack.
The bogus beacons prolong the join time of the pledge, and so the time spent in The bogus beacons prolong the join time of the pledge and so does the
"minimal" <xref target="RFC8180"/> duty cycle mode. time spent in "minimal" duty cycle mode <xref target="RFC8180" format="default"/
The blacklist communicated as part of the CoJP Configuration object helps JP fig >.
ht a DoS attack by a malicious pledge.</t> The blacklist communicated as part of the CoJP Configuration object
helps the JP fight a DoS attack by a malicious pledge.</t>
<t>During the network lifetime, the JRC may at any time initiate a Parameter Upd <t>During the network lifetime, the JRC may at any time initiate a paramet
ate exchange with a joined node. er update exchange with a joined node.
The Parameter Update message uses the same OSCORE security context as is used fo The Parameter Update message uses the same OSCORE security context
r the join exchange, except that the server/client roles are interchanged. as is used for the join exchange, except that the server and client
roles are interchanged.
As a consequence, each Parameter Update message carries the well-known OSCORE Se nder ID of the JRC. As a consequence, each Parameter Update message carries the well-known OSCORE Se nder ID of the JRC.
A passive attacker may use the OSCORE Sender ID to identify the Parameter Update A passive attacker may use the OSCORE Sender ID to identify the
traffic in case the link-layer protection does not provide confidentiality. Parameter Update traffic if the link-layer protection does not provide confident
A countermeasure against such traffic analysis attack is to use encryption at th iality.
e link-layer. A countermeasure against such a traffic-analysis attack is to
Note that the join traffic does not undergo link-layer protection at the first h use encryption at the link layer.
op, as the pledge is not yet in possession of cryptographic keys. Note that the join traffic does not undergo link-layer protection
Similarly, enhanced beacon traffic in the network is not encrypted. at the first hop, as the pledge is not yet in possession of cryptographic keys.
Similarly, EB traffic in the network is not encrypted.
This makes it easy for a passive attacker to identify these types of traffic.</t > This makes it easy for a passive attacker to identify these types of traffic.</t >
<!-- ====================================================================== -->
</section> </section>
<section anchor="privacy_considerations" title="Privacy Considerations"> <section anchor="privacy_considerations" numbered="true" toc="default">
<name>Privacy Considerations</name>
<t>The join solution specified in this document relies on the uniqueness of the <t>The join solution specified in this document relies on the uniqueness o
pledge identifier in the set of all pledge identifiers managed by a JRC. f the pledge identifier in the set of all pledge identifiers managed by a JRC.
This identifier is transferred in clear as an OSCORE kid context. This identifier is transferred in the clear as an OSCORE 'kid context'.
The use of the globally unique EUI-64 as pledge identifier simplifies the manage ment but comes with certain privacy risks. The use of the globally unique EUI-64 as pledge identifier simplifies the manage ment but comes with certain privacy risks.
The implications are thoroughly discussed in <xref target="RFC7721"/> and compri The implications are thoroughly discussed in <xref target="RFC7721" format="defa
se correlation of activities over time, location tracking, address scanning and ult"/>
device-specific vulnerability exploitation. and comprise correlation of activities over time, location tracking, address sca
nning,
and device-specific vulnerability exploitation.
Since the join process occurs rarely compared to the network lifetime, long-term threats that arise from using EUI-64 as the pledge identifier are minimal. Since the join process occurs rarely compared to the network lifetime, long-term threats that arise from using EUI-64 as the pledge identifier are minimal.
However, the use of EUI-64 after the join process completes, in the form of a la However, after the join process completes, the use of EUI-64
yer-2 or layer-3 address, extends the aforementioned privacy threats to long ter in the form of a Layer 2 or Layer 3 address extends the
m.</t> aforementioned privacy threats to the long term.</t>
<t>As an optional mitigation technique, the Join Response message
<t>As an optional mitigation technique, the Join Response message may contain a may contain a short address that is assigned by the JRC to the (6LBR) pledge.
short address which is assigned by the JRC to the (6LBR) pledge. The assigned short address <bcp14>SHOULD</bcp14> be uncorrelated with the long-t
The assigned short address SHOULD be uncorrelated with the long-term pledge iden erm pledge identifier.
tifier.
The short address is encrypted in the response. The short address is encrypted in the response.
Once the join process completes, the new node may use the short addresses for al Once the join process completes, the new node may use the short addresses for al
l further layer-2 (and layer-3) operations. l further Layer 2 (and Layer 3) operations.
This reduces the privacy threats as the short layer-2 address (visible even when This reduces the privacy threats as the short Layer 2 address (visible even when
the network is encrypted) does not disclose the manufacturer, as is the case of the network is encrypted) does not disclose the manufacturer, as is the case of
EUI-64. EUI-64.
However, an eavesdropper with access to the radio medium during the join process may be able to correlate the assigned short address with the extended address b ased on timing information with a non-negligible probability. However, an eavesdropper with access to the radio medium during the join process may be able to correlate the assigned short address with the extended address b ased on timing information with a non-negligible probability.
This probability decreases with an increasing number of pledges joining concurre ntly.</t> This probability decreases with an increasing number of pledges joining concurre ntly.</t>
<!-- ====================================================================== -->
</section> </section>
<section anchor="iana-considerations" title="IANA Considerations"> <section anchor="iana-considerations" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>Note to RFC Editor: Please replace all occurrences of "[[this document]]" wit
h the RFC number of this specification.</t>
<t>This document allocates a well-known name under the .arpa name space accordin <t>This document allocates a well-known name under
g to the rules given in <xref target="RFC3172"/>. the .arpa name space according to the rules given in <xref target="RFC3172" form
at="default"/> and <xref target="RFC6761" format="default"/>.
The name "6tisch.arpa" is requested. The name "6tisch.arpa" is requested.
No subdomains are expected, and addition of any such subdomains requires the pub No subdomains are expected, and addition of any such subdomains
lication of an IETF standards-track RFC. requires the publication of an IETF Standards Track RFC.
No A, AAAA or PTR record is requested.</t> No A, AAAA, or PTR record is requested.</t>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<section anchor="iana_cojp_registry" title="CoJP Parameters Registry">
<t>This section defines a sub-registry within the "IPv6 over the TSCH mode of IE
EE 802.15.4e (6TiSCH) parameters" registry with the name "Constrained Join Proto
col Parameters Registry".</t>
<t>The columns of the registry are:</t>
<t>Name: This is a descriptive name that enables an easier reference to the item
.
It is not used in the encoding.</t>
<t>Label: The value to be used to identify this parameter.
The label is an integer.</t>
<t>CBOR type: This field contains the CBOR type for the field.</t>
<t>Description: This field contains a brief description for the field.</t> <section anchor="iana_cojp_registry" numbered="true" toc="default">
<name>Constrained Join Protocol (CoJP) Parameters</name>
<t>Reference: This field contains a pointer to the public specification for the <t>This section defines a subregistry within the
field, if one exists.</t> "IPv6 Over the TSCH Mode of IEEE 802.15.4 (6TiSCH)" registry with the
name "Constrained Join Protocol (CoJP) Parameters".</t>
<t>The columns of the registry are:</t>
<dl>
<dt>Name:</dt>
<dd>This is a descriptive name that enables an easier reference to the i
tem.
It is not used in the encoding. The name <bcp14>MUST</bcp14> be unique.</dd>
<dt>Label:</dt>
<dd>The value to be used to identify this parameter.
The label is an integer. The label <bcp14>MUST</bcp14> be unique.</dd>
<dt>CBOR Type:</dt>
<dd>This field contains the CBOR type for the field.</dd>
<dt>Description:</dt>
<dd>This field contains a brief description for the field. The descripti
on <bcp14>MUST</bcp14> be unique.</dd>
<dt>Reference:</dt>
<dd>This field contains a pointer to the public specification for the fi
eld, if one exists.</dd>
</dl>
<t>This registry is to be populated with the values in <xref target="table_cojp_ <t>This registry is populated with the values
parameters_labels"/>.</t> in <xref target="table_cojp_parameters_labels" format="default"/>.</t>
<t>The amending formula for this sub-registry is: Different ranges of values use <t>The amending formula for this subregistry is:
different registration policies <xref target="RFC8126"/>. Different ranges of values use different registration policies <xref target="RFC
8126" format="default"/>.
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 Speci fication Required. Integer values from -65536 to -257 and from 256 to 65535 are designated as Speci fication Required.
Integer values greater than 65535 are designated as Expert Review. Integer values greater than 65535 are designated as Expert Review.
Integer values less than -65536 are marked as Private Use.</t> Integer values less than -65536 are marked as Private Use.</t>
</section>
</section> <section anchor="iana_cojp_key_usage_registry" numbered="true" toc="defaul
<section anchor="iana_cojp_key_usage_registry" title="CoJP Key Usage Registry"> t">
<name>Constrained Join Protocol (CoJP) Key Usage</name>
<t>This section defines a sub-registry within the "IPv6 over the TSCH mode of IE <t>This section defines a subregistry within the
EE 802.15.4e (6TiSCH) parameters" registry with the name "Constrained Join Proto "IPv6 Over the TSCH Mode of IEEE 802.15.4 (6TiSCH)" registry with the
col Key Usage Registry".</t> name "Constrained Join Protocol (CoJP) Key Usage".</t>
<t>The columns of this registry are:</t>
<t>The columns of this registry are:</t> <dl>
<dt>Name:</dt>
<t>Name: This is a descriptive name that enables easier reference to the item. <dd>This is a descriptive name that enables easier reference to the item
The name MUST be unique. .
It is not used in the encoding.</t> It is not used in the encoding. The name <bcp14>MUST</bcp14> be unique.</dd>
<dt>Value:</dt>
<t>Value: This is the value used to identify the key usage setting. <dd>This is the value used to identify the key usage setting.
These values MUST be unique. These values <bcp14>MUST</bcp14> be unique. The value is an integer.</dd>
The value is an integer.</t> <dt>Algorithm:</dt>
<dd>This is a descriptive name of the link-layer algorithm in use and un
<t>Algorithm: This is a descriptive name of the link-layer algorithm in use and iquely determines the key length.
uniquely determines the key length. The name is not used in the encoding. The algorithm <bcp14>MUST</bcp14> be uniqu
The name is not used in the encoding.</t> e.</dd>
<dt>Description:</dt>
<t>Description: This field contains a description of the key usage setting. <dd>This field contains a description of the key usage setting.
The field should describe in enough detail how the key is to be used with differ The field should describe in enough detail how the key is to be used with differ
ent frame types, specific for the link-layer technology in question.</t> ent frame types, specific for the link-layer technology in question. The descrip
tion <bcp14>MUST</bcp14> be unique.</dd>
<t>Reference: This contains a pointer to the public specification for the field <dt>Reference:</dt>
, if one exists.</t> <dd>This contains a pointer to the public specification for the field, i
f one exists.</dd>
<t>This registry is to be populated with the values in <xref target="table_key_u </dl>
sage_values"/>.</t> <t>This registry is populated with the values in <xref target="table_key
_usage_values" format="default"/>.</t>
<t>The amending formula for this sub-registry is: Different ranges of values use <t>The amending formula for this subregistry is:
different registration policies <xref target="RFC8126"/>. Different ranges of values use different registration policies <xref target="RFC
8126" format="default"/>.
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 Speci fication Required. Integer values from -65536 to -257 and from 256 to 65535 are designated as Speci fication Required.
Integer values greater than 65535 are designated as Expert Review. Integer values greater than 65535 are designated as Expert Review.
Integer values less than -65536 are marked as Private Use.</t> Integer values less than -65536 are marked as Private Use.</t>
</section>
<section anchor="iana_cojp_unsupported_code_registry" numbered="true" toc=
"default">
<name>Constrained Join Protocol (CoJP) Unsupported Configuration Codes</
name>
</section> <t>This section defines a subregistry within the
<section anchor="iana_cojp_unsupported_code_registry" title="CoJP Unsupported Co "IPv6 Over the TSCH Mode of IEEE 802.15.4 (6TiSCH)" registry with the
nfiguration Code Registry"> name "Constrained Join Protocol (CoJP) Unsupported Configuration Codes".</t>
<t>The columns of this registry are:</t>
<t>This section defines a sub-registry within the "IPv6 over the TSCH mode of IE <dl>
EE 802.15.4e (6TiSCH) parameters" registry with the name "Constrained Join Proto <dt>Name:</dt>
col Unsupported Configuration Code Registry".</t> <dd>This is a descriptive name that enables easier reference to the item
.
<t>The columns of this registry are:</t> It is not used in the encoding.
The name <bcp14>MUST</bcp14> be unique.</dd>
<t>Name: This is a descriptive name that enables easier reference to the item. <dt>Value:</dt>
The name MUST be unique. <dd>This is the value used to identify the diagnostic code.
It is not used in the encoding.</t> These values <bcp14>MUST</bcp14> be unique.
The value is an integer.</dd>
<t>Value: This is the value used to identify the diagnostic code. <dt>Description:</dt>
These values MUST be unique. <dd>This is a descriptive human-readable name.
The value is an integer.</t> The description <bcp14>MUST</bcp14> be unique.
It is not used in the encoding.</dd>
<t>Description: This is a descriptive human-readable name. <dt>Reference:</dt>
The description MUST be unique. <dd>This contains a pointer to the public specification for the field, i
It is not used in the encoding.</t> f one exists.</dd>
</dl>
<t>Reference: This contains a pointer to the public specification for the field <t>This registry is to be populated with the values in <xref target="tab
, if one exists.</t> le_unsupported_code_values" format="default"/>.</t>
<t>This registry is to be populated with the values in <xref target="table_unsup
ported_code_values"/>.</t>
<t>The amending formula for this sub-registry is: Different ranges of values use <t>The amending formula for this subregistry is:
different registration policies <xref target="RFC8126"/>. Different ranges of values use different registration policies <xref target="RFC
8126" format="default"/>.
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 Speci fication Required. Integer values from -65536 to -257 and from 256 to 65535 are designated as Speci fication Required.
Integer values greater than 65535 are designated as Expert Review. Integer values greater than 65535 are designated as Expert Review.
Integer values less than -65536 are marked as Private Use.</t> Integer values less than -65536 are marked as Private Use.
</t>
<!-- ====================================================================== --> </section>
</section>
</middle>
</section> <back>
</section>
<section anchor="acknowledgments" title="Acknowledgments">
<t>The work on this document has been partially supported by the European Union' <references>
s H2020 Programme for research, technological development and demonstration unde <name>References</name>
r grant agreements: No 644852, project ARMOUR; No 687884, project F-Interop and <references>
open-call project SPOTS; No 732638, project Fed4FIRE+ and open-call project SODA <name>Normative References</name>
.</t> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7554.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8180.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8613.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7252.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8949.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8152.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2597.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3172.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8126.xml"/>
<t>The following individuals provided input to this document (in alphabetic orde <reference anchor="IEEE802.15.4" target="https://ieeexplore.ieee.org/docume
r): nt/7460875">
Christian Amsuss, <front>
Tengfei Chang, <title>IEEE Standard for Low-Rate Wireless Networks</title>
Klaus Hartke, <author>
Tero Kivinen, <organization>IEEE</organization>
Jim Schaad, </author>
Goeran Selander, <date month="April" year="2016"/>
Yasuyuki Tanaka, </front>
Pascal Thubert, <seriesInfo name="IEEE Standard" value="802.15.4-2015"/>
William Vignat, <seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7460875"/>
Xavier Vilajosana, </reference>
Thomas Watteyne.</t>
</section> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.8974.xml"/>
</middle> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.8505.xml"/>
<back> <reference anchor="RFC9030" target="https://www.rfc-editor.org/info/rfc9030">
<front>
<title>An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IE
EE 802.15.4 (6TiSCH)</title>
<references title='Normative References'> <author initials="P" surname="Thubert" fullname="Pascal Thubert" role="editor">
<organization/>
</author>
&RFC7554; <date month="May" year="2021"/>
&RFC8180;
&RFC8613; </front>
&RFC7252; <seriesInfo name="RFC" value="9030"/>
&RFC7049; <seriesInfo name="DOI" value="10.17487/RFC9030"/>
&RFC8152;
&RFC2119;
&RFC8174;
&RFC2597;
&RFC3172;
&RFC8126;
<reference anchor="IEEE802.15.4" >
<front>
<title>IEEE Std 802.15.4 Standard for Low-Rate Wireless Networks</title>
<author initials="." surname="IEEE standard for Information Technology">
<organization></organization>
</author>
<date year="n.d."/>
</front>
</reference> </reference>
&I-D.ietf-core-stateless;
&RFC8505;
&I-D.ietf-6tisch-architecture;
&RFC7320;
&RFC8085;
&RFC5869;
</references> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8820.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8085.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5869.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6761.xml"/>
</references>
<references>
<references title='Informative References'> <name>Informative References</name>
&I-D.ietf-6tisch-msf; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
&I-D.ietf-cbor-cddl; ence.RFC.8610.xml"/>
&I-D.ietf-cbor-sequence; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
&RFC8480; ence.RFC.8742.xml"/>
&RFC5785; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
&RFC7721; ence.RFC.8480.xml"/>
&RFC4944; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
&RFC6550; ence.RFC.8615.xml"/>
&RFC4231; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
&RFC8415; ence.RFC.7721.xml"/>
&I-D.ietf-anima-grasp; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
&RFC6762; ence.RFC.4944.xml"/>
<reference anchor="NIST800-90A" > <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<front> ence.RFC.6550.xml"/>
<title>Recommendation for Random Number Generation Using Deterministic Rando <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
m Bit Generators</title> ence.RFC.4231.xml"/>
<author initials="." surname="NIST Special Publication 800-90A, Revision 1"> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<organization></organization> ence.RFC.8415.xml"/>
</author> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<author initials="E." surname="Barker"> ence.RFC.8990.xml"/>
<organization></organization> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
</author> ence.RFC.6762.xml"/>
<author initials="J." surname="Kelsey">
<organization></organization>
</author>
<date year="2015"/>
</front>
</reference>
<reference anchor="NIST800-90A">
<front>
<title>Recommendation for Random Number Generation Using Determinist
ic Random Bit Generators</title>
<author>
<organization>National Institute of Standards and Technology</orga
nization>
</author>
<date month="June" year="2015"/>
</front>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-90Ar1"/>
<refcontent>Special Publication 800-90A, Revision 1</refcontent>
</reference>
</references>
</references> </references>
<!-- ====================================================================== --> <section anchor="example" numbered="true" toc="default">
<name>Example</name>
<section anchor="example" title="Example"> <t><xref target="fig_example" format="default"/> illustrates a successful
join protocol exchange.
<t><xref target="fig_example"/> illustrates a successful join protocol exchange.
The pledge instantiates the OSCORE context and derives the OSCORE keys and nonce s from the PSK. The pledge instantiates the OSCORE context and derives the OSCORE keys and nonce s from the PSK.
It uses the instantiated context to protect the Join Request addressed with It uses the instantiated context to protect the Join Request addressed with
a Proxy-Scheme option, a Proxy-Scheme option,
the well-known host name of the JRC in the Uri-Host option, and the well-known host name of the JRC in the Uri-Host option, and
its EUI-64 as pledge identifier and OSCORE kid context. it uses its EUI-64 as pledge identifier and OSCORE 'kid context'.
Triggered by the presence of a Proxy-Scheme option, the JP forwards the request to the JRC and sets the CoAP token to the internally needed state. Triggered by the presence of a 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 IPv6 address of the JRC when it acted as a pledge and joi The JP learned the IPv6 address of the JRC when it acted as a pledge and joined
ned the network. the network.
Once the JRC receives the request, it looks up the correct context based on the Once the JRC receives the request, it looks up the correct context based on the
kid context parameter. 'kid context' parameter.
The OSCORE data authenticity verification ensures that the request has not been modified in transit. The OSCORE data authenticity verification ensures that the request has not been modified in transit.
In addition, replay protection is ensured through persistent handling of mutable context parameters.</t> In addition, replay protection is ensured through persistent handling of mutable context parameters.</t>
<t>Once the JP receives the Join Response, it authenticates the state with
<t>Once the JP receives the Join Response, it authenticates the state within the in the CoAP token before deciding where to forward.
CoAP token before deciding where to forward. The JP sets its internal state to that found in the token and
The JP sets its internal state to that found in the token, and forwards the Join forwards the Join Response to the correct pledge.
Response to the correct pledge.
Note that the JP does not possess the key to decrypt the CoJP object (configurat ion) present in the payload. Note that the JP does not possess the key to decrypt the CoJP object (configurat ion) present in the payload.
The Join Response is matched to the Join Request and verified for replay protect At the pledge, the Join Response is matched to the Join Request
ion at the pledge using OSCORE processing rules. and verified for replay protection using OSCORE processing rules.
In this example, the Join Response does not contain the IPv6 address of the JRC, In this example, the Join Response does not contain the IPv6 address
the pledge hence understands the JRC is co-located with the 6LBR.</t> of the JRC, hence the pledge understands that the JRC is co-located with the 6LB
R.</t>
<figure title="Example of a successful join protocol exchange. { ... } denotes a <figure anchor="fig_example">
uthenticated encryption, &lt;Tag&gt; denotes the authentication tag." anchor="fi <name>Example of a successful join protocol exchange. { ... } denotes au
g_example"><artwork align="center"><![CDATA[ thenticated encryption, &lt;Tag&gt; denotes the authentication tag.</name>
<---E2E OSCORE--> <artwork align="center" name="" type="" alt=""><![CDATA[
<-----E2E OSCORE------>
Client Proxy Server Client Proxy Server
Pledge JP JRC Pledge JP JRC
| | | | | |
| Join | | Code: 0.02 (POST) | Join | | Code: 0.02 (POST)
| Request | | Token: - | Request | | Token: -
+--------->| | Proxy-Scheme: coap +--------->| | Proxy-Scheme: coap
| | | Uri-Host: 6tisch.arpa | | | Uri-Host: 6tisch.arpa
| | | OSCORE: kid: -, | | | OSCORE: kid: -,
| | | kid_context: EUI-64, | | | kid_context: EUI-64,
| | | Partial IV: 1 | | | Partial IV: 1
skipping to change at line 1755 skipping to change at line 2053
| | | Payload: { Code: 2.04 (Changed), | | | Payload: { Code: 2.04 (Changed),
| | | configuration, <Tag> } | | | configuration, <Tag> }
| | | | | |
| | | | | |
| Join | | Code: 2.04 (Changed) | Join | | Code: 2.04 (Changed)
| Response | | Token: - | Response | | Token: -
|<---------+ | OSCORE: - |<---------+ | OSCORE: -
| | | Payload: { Code: 2.04 (Changed), | | | Payload: { Code: 2.04 (Changed),
| | | configuration, <Tag> } | | | configuration, <Tag> }
| | | | | |
]]></artwork></figure> ]]></artwork>
</figure>
<t>Where the join_request object is:</t> <t>Where the join_request object is:</t>
<sourcecode type=""><![CDATA[
<figure><artwork><![CDATA[
join_request: join_request:
{ {
5 : h'cafe' / PAN ID of the network pledge is attempting to join / 5 : h'cafe' / PAN ID of the network pledge is attempting to join /
} }
]]></artwork></figure> ]]></sourcecode>
<t>Since the role parameter is not present, the default role of "6TiSCH No
<t>Since the role parameter is not present, the default role of "6TiSCH Node" is de" is implied.</t>
implied.</t> <t>The join_request object is converted to h'a10542cafe' with a size of 5
bytes.</t>
<t>The join_request object encodes to h'a10542cafe' with a size of 5 bytes.</t> <t>And the configuration object is the following:</t>
<sourcecode type=""><![CDATA[
<t>And the configuration object is:</t>
<figure><artwork><![CDATA[
configuration: configuration:
{ {
2 : [ / link-layer key set / 2 : [ / link-layer key set /
1, / key_id / 1, / key_id /
h'e6bf4287c2d7618d6a9687445ffd33e6' / key_value / h'e6bf4287c2d7618d6a9687445ffd33e6' / key_value /
], ],
3 : [ / short identifier / 3 : [ / short identifier /
h'af93' / assigned short address / h'af93' / assigned short address /
] ]
} }
]]></artwork></figure> ]]></sourcecode>
<t>Since the key_usage parameter is not present in the link-layer key set
<t>Since the key_usage parameter is not present in the link-layer key set object object, the default value of "6TiSCH-K1K2-ENC-MIC32" is implied.
, the default value of "6TiSCH-K1K2-ENC-MIC32" is implied. Since the key_addinfo parameter is not present and key_id is
Since key_addinfo parameter is not present and key_id is different than 0, Key I different from 0, Key ID Mode 0x01 (Key Index) is implied.
D Mode 0x01 (Key Index) is implied.
Similarly, since the lease_time parameter is not present in the short identifier object, the default value of positive infinity is implied.</t> Similarly, since the lease_time parameter is not present in the short identifier object, the default value of positive infinity is implied.</t>
<t>The configuration object is converted to the following:</t>
<t>The configuration object encodes to</t> <t>h'a202820150e6bf4287c2d7618d6a9687445ffd33e6038142af93' with a size of
26 bytes.</t>
<t>h'a202820150e6bf4287c2d7618d6a9687445ffd33e6038142af93' with a size of 26 byt
es.</t>
<!-- ====================================================================== -->
</section> </section>
<section anchor="lightweight" title="Lightweight Implementation Option"> <section anchor="lightweight" numbered="true" toc="default">
<name>Lightweight Implementation Option</name>
<t>In environments where optimizing the implementation footprint is important, i <t>In environments where optimizing the implementation footprint is import
t is possible to implement this specification without having the implementations ant, it is possible to implement this specification without having the implement
of HKDF <xref target="RFC5869"/> and SHA <xref target="RFC4231"/> on constraine ations of HKDF <xref target="RFC5869" format="default"/> and SHA <xref target="R
d devices. FC4231" format="default"/> on constrained devices.
HKDF and SHA are used during the OSCORE security context derivation phase. HKDF and SHA are used during the OSCORE security context derivation phase.
This derivation can also be done by the JRC or a provisioning device, on behalf This derivation can also be done by the JRC or a provisioning device on behalf
of the (6LBR) pledge during the provisioning phase. of the (6LBR) pledge during the provisioning phase.
In that case, the derived OSCORE security context parameters are written directl In that case, the derived OSCORE security context parameters are
y into the (6LBR) pledge, without requiring the PSK be provisioned to the (6LBR) written directly into the (6LBR) pledge, without requiring the PSK to
pledge.</t> be provisioned to the (6LBR) pledge.</t>
<t>The use of HKDF to derive OSCORE security context parameters
<t>The use of HKDF to derive OSCORE security context parameters ensures that the ensures that the resulting OSCORE keys have good security properties
resulting OSCORE keys have good security properties, and are unique as long as and are unique as long as the input varies for different pledges.
the input for different pledges varies.
This specification ensures the uniqueness by mandating This specification ensures the uniqueness by mandating
unique pledge identifiers unique pledge identifiers
and a unique PSK for each (6LBR) pledge. and a unique PSK for each (6LBR) pledge.
From the AEAD nonce reuse viewpoint, having a unique pledge identifier is a suff icient condition. From the AEAD nonce reuse viewpoint, having a unique pledge identifier is a suff icient condition.
However, as discussed in <xref target="sec_considerations"/>, the use of a singl e PSK shared among many devices is a common security pitfall. However, as discussed in <xref target="sec_considerations" format="default"/>, t he use of a single PSK shared among many devices is a common security pitfall.
The compromise of this shared PSK on a single device would lead to the compromis e of the entire batch. The compromise of this shared PSK on a single device would lead to the compromis e of the entire batch.
When using the implementation/deployment scheme outlined above, the PSK does not When using the implementation/deployment scheme outlined above,
need to be written to individual pledges. the PSK does not need to be written to individual pledges.
As a consequence, even if a shared PSK is used, the scheme offers a comparable l As a consequence, even if a shared PSK is used, the scheme offers a
evel of security as in the scenario where each pledge is provisioned with a uniq level of security comparable to the scenario in which each pledge
ue PSK. is provisioned with a unique PSK.
In this case, there is still a latent risk of the shared PSK being compromised f In this case, there is still a latent risk of the shared PSK being
rom the provisioning device, which would compromise all devices in the batch.</t compromised on the provisioning device, which would compromise all devices in th
> e batch.</t>
</section>
</section>
</back>
<!-- ##markdown-source:
H4sIAMtm710AA+29+1IbWZo4+L+eIpeK2IJuSQUYbBfdPTsYcBflGwu4a2an
OxwpKYWyLWVqMlNg2uWNfYd9w32S/a7nfCcvQq4qZn4dMVREGaTMc/3u18Fg
0KvSap4cRSd5VlZFnGbJJPoxT7PoosirfJzPo+2T/MeLnWiaF9HT6/Tq5Ife
N1E8GhXJ7VH0tErL8WywSLN0Ec8HZTJeFWl135vk4yxewLCTIp5WgzSppoOO
Zwd7hz0YsazibPIhnucZvFUVq6TXS5fFUYQ/8GdZ7e/ufr+734uLJKZPz7Mq
KbKk6t3d8FOyuuinvPiYZjfRn4t8tex9vJNv9fnBKS6pN44r/qKsJr3eOJ/A
K0fRqhzE5ThNe8v0qEdT52N5n37uk5I+LvOiKpJpeVT7+H5hPnUfwyCTZFnN
9PP9Xi9eVbO84DkGPR0+zdy7b4bRX1ZjOKux+5ZPlL+N52kZN57ICz0L2G6R
xu6LIp/rq8kkrfLCfZMs4nTOXy1o0OEtD/qvKY4wnPpHAT6ShE9tP7pcJdFV
uoDris6nU/fMGG5UJrqIi7T0X+QTXcGzw929ffPFKqsKeullEWfjpPtMfhzy
lG0n8mOexdUszmpPmBM5zgC6bqLT5DYdJ2XbAfxdxhiWOMa/xvTCcJwv2o7g
yf733+9Gx/PbuIgn+eBtOk/K6DKPJ/3oapVWSfT93m7bsbzP0jyLTuCDfnRy
3HY+3x8cPn/Wdj7vr467D+fVMLpIS4DxttN5BVdR/9ocDazpNilKWFOUT6MT
gAPA9iyNoxdJ8TGZJ/dtp7Wk4f41ScblcCTPDZPJqu2wDvf2gcIU99EP8Xze
dio6UfeZPNvf/eozASS6TMezuJiU7VDzBr9N5m1PmeO5AtKUzBcIXPm0ugMS
RESmFYYW4+L3SO7+tdSXhuO47UgOnu1Gp/EdTBkd3ybZKmk7lndVFd/F/ejd
27ZDebX3fx3+pRVSTgB2J3Gvl+XFIq7gcpnSXL48eXZ4eHAUfRO9L5FGnp+d
nUXPd/eHe4fDgyS6ThfJ4GqeVxVwgRPAhAzO5od8ucRnt6+Buu7A8UbVLHHk
FAHmegbfl9H2eX69c4SMYzRPFtFVFVfJIskqnfr53vNdnPoNc4Do/OL2aZQD
4NGAOHr0BjaHI9bWtc2kfQe51DS9WRWwJ7kqHPfp3hMc993o78m4iq6EsRDH
smzt8uzqerqaR2fZbVrkGS4NFv3u6uTd5dmOO5/9w30c7BqWZF8+Xi7n6Zjm
DVjj8YV/dffge3wVXhunZRK9SLMYQF6WdZksi6SEOXmM7ZMX7y53/NHwrPih
20d6k+G5AxzBksfF/VJefHfll7u/t0dzvkruo7scIJh2vYLZ4Z7g+xKYD9zV
BJeewBr+c5UWdCnR6+Q2mZd+Ac8ILI4XIzhfIQTvl8ukGMcw2G0Zvc7v5A8e
OcKpad6fcF63oMPvn9FAZbkq4Nxe5gUgDHLX6OKHF8KU5dkne89o128AWm94
VX9epYA1cOJl9L9H72B6Oi0AFrN03iPCzPFkAmda0hFd5quKZgF6vEgAOKNj
EBWi0xxwE05tKy6W8ZY58P2nOLWZDwf9CQCHzzw6P357TBAAD/AqSgQtugM5
WxoMQVUh9cjhokhVWwTIV9XEATOiRTaBE6H54FAHl3gzP8He5riVt0l1h7Rl
yw1lRYWAxvHgpR3vPJsyxsMir5PxLMuBg93zWOeD0yEJYuO8SAYlYifO6CjD
88PdQzySy+QmRbCnQc4+VQkcAW6exncoiyu/QJDwS78AFkJ3RQcvGwHcfZ3/
dHH8dgc+SW9mIxjlFARBHOQ+XJcIiHExngH/HFcAP0ePSjtenFzsfQ/DIu4+
2d+NkCxenoOEUALqRe/uMtjQLHXg+nz3OR3Q+9MLIJ8AsQZ69JnD508JH394
c3wyGAG2TPAIi3hcDeCaBmeflgiriDWnSZHe8iG/XGUMV9s/vDp9uQOSr16j
Eu76GS3KKc4iEq8eytV4Bvx3jgCsQ9ZuHk5/MJ5M5kctn5eAYQnIX19JwgAp
+D1PSw74rmR1DotBLhrN43u4s+2nVb7cMXT0qaeih8/glB1Jfba/h0M5mo6n
d4EHN76vI6eDT6UKf04ynfkN4EKcpeXCLfLg+wMieNcgc5aLtEQYJ+jBES7i
8ccE6AwBWABPDj91nKeHh7TZy4vXR/yyI0S6O0V0Rhfcweu8LO8bQx3sP6HN
nk/giNNpCtBHT18nZRX9BS4gL3iXBFxXPxwP9vcP+uavw6fmryfP4Tt83X1y
KFI3XdEegfLpPQhD6Rh4PEwRIEi4fNrY9ukPJ/DvTgg7McLe4KaIyyXRfT52
GPN4VeVZjqMjJ4vnwZls//ny+Mpf+tNnT5kTrOYVsCpYzOnbK/ry7fnV9fPd
3cH3u8dN6nqZgHAOLGHCS8aVXsKW80X0drUAmdSCAAs8p8gZUAUtYR59+EVa
6ZNwxOso76CFCuMKo6tlMk4BBS8AxFVMkGX3AW9uU4Kvva0HxjobRi9ikISL
hx4EVegVsO/k3j8IhwBnsr+L+vRgMAAdvSTC0+uBfFZGoJKviMVOknJcpCPg
eEg6RR2Ppsg1iWAXzGmZocRRltzBK6gz9aMxSO/wxdYS/n+TbPVRuCA9Ppnf
g/YEbDFWrN9uodCLVgq9A1MQIgx7KHQ1FoLrjCsaheclqMY/f7w8ibZp2kJ4
VvHdOM9R2sCbBPCPxrDjAraHGFXd7/Sjcobie4yqOkgJCKcfQW3p/ZDfwZBw
TPBXBP8si5zvDLYLfwJK48KBbS1pB5U9UVw3iDU3MxwWgGyOkuPxBUqH6+XH
HdoiYPcAdrmEh5Mo+YSECvbIxzqJRkB9SUIFSfUXyLewY3NwMh2QlYmSvDSD
O8RH5BKCwx0LRYA7ABS5S6tZBGj8ccBUHI4KUQr4FOA7nDG+mcOrRbRUGazk
O8WxFjFQ7woeugf0XSTRaokAy6tzj8OfcpIZj/QVBzRkOC8RE6d61JNkSsJd
VRPnQxMXrjyFYyHxe3sT5reD6BajPrciQaVkWutxa4YAlfsTpBUUSMkJfBLF
EyRgq0yXC1LZ+KOIt7AXgm0AxTGyMxgtH8OeI0Iz3j6cKuhoxbAHPC8VSVkN
a9HCMT06/BGA/WQCe4d5gP06MG5QgCHTj0UKgkLS6/3xf4M//vSb/ESDwb+g
sQ+UxyKfrFjo+fxNav780iRXfINxtCV7xlPZisp8vnJU/xeTqYD0IGuozVIk
UwLL3OPHmG4DeQMSFb64vvCK9B98jwgLDqqjCdKmdLSSJ0vZ0wRv8vPndfLv
ly+8sgets2bEgDZFAAETtEy1rwZ2lUwcqRcqAZsdIWNFMomnAN9nQLmHvTer
aoV4Hmw9mgC0ARmonw+i1AJpHlCO2uEgAYY9ggI6cQiPKIFqK0ClA+4xWyDo
yBwiEcY36K/dcjwvcyUDBDjjQLCBGSbpFK4VnyVKVtZwcqmHy+hI7AcmXo2F
kJwmGdI7eOkqKRDkQDTKr3aAvNHzoPhOY/hQDgbfsIg8rEM40hX4rWxAJYMK
UxTcNrH6z5/FivPlCx6y/wxVJISXF/f4Eohcfbq2MmqB92CUWXxL5CkFchtP
UmAHqwIvPZ9OgWV7ioVkuy9ErYSNAzEG2nMD3PNYTllVCGY6yCrwTunGLIYS
uOGR6PHoqmaw4Xm6SNH8NILN3aUTYDnB7hAbDIZ6MtCJAchHEpgxAYaVLPkG
MxYPYWMooQzgo0EM21fmQggfM2VcLejCUFIaFzkoz0isgL6gcM5SySyJCzok
PWM6dTpVAGUgrYAyC7TN4TNovgPKvMgLOLfzCoULv0BCUnoS5i+SFfE7FFXh
nBQoYdrbOJ3HIxAzYsLrOkshqIVL4dXFRvAgaO83ngWMAY19cg9TzhFj0D6N
AgwDyf7hPgAJXtldMooq1JemOAqx+0ylE76kp3tP5FlkpyCYD6p8AP84pvTr
LpCOBA8sh5MBkLGHUtKUo1U6J2PTaJ6PPyKuIX3EU46jG1FMHHoTYo/jDFkj
wWlcDlLGF7izBV2jiquBDQeItrH6fPnSh3fG89VE4XkTOyoJw3ILMCnbCvJs
yAsmaamEE4eF6OpgXSwUbc9Bm1yiNulkZ5pZDT54h3d4aFEyBUkoBZS8p2MF
/lYyEFqhA1EAYHhCN0rwOc3zagnEi8ATqHheVDHS2XO4rtUY5Vw0BPZRKBTJ
IkuQtKG4BJDLN1kju0bIUxEtEtHTLZxWSQIfcUrlDbDcZUxuE4UJkStx5XhV
KiJ5YkmcFeFrIN8N8NnbNLljsknzNvgCfsgYkYar5HtSaIpLptcku5JQOBbG
Rbz50ikjJ14ZibZBCN5pqiS8kXAlnZjgJ+5WiFTBgfuFkzR6DlmQc1DUlzPW
epygdHH1KtpeolEQ353gdzu8LvwGFkDgF0izgvVVzprSJGlwbfwOT0t1KzcY
KLAVz/uQYnUkAiqA2AzIWJJZluo0NCKOMzRMwykTp0EdzukJIbbjWLDTMUg9
NEryCRat18/L7f0E0o093TJJPlqViXhDyE8JFaZpAcyyvM/GALdZ+g9mI2nV
x1UBK6nSuHKrh6tMgUGUSH5CcTCgLHwNKpjhwjyPYkKBaId/kXYmQPAHr0IY
GhxiPSyND7Xvx0DImbLBnrk2szJlDy28xu1fQEmF009Ag3jtbnBd+ASpq4AE
AqwCr5c+FyRngqxuJE2gNkoi9fqXSVEhqRMIrKmCAAMkCIaTNVQymfUB3Rbt
BkAEo9SZ5jq03eNplcjJWyanBAqoJ/4LWjrsDsnaHN4r+05GFFGbmFKKHrZ4
LHo3MrdMDOgliwdEKFGnU83Pi0yrUgENLa1eW2AufYCiFG0AMBF2BQSMWJcV
FYBEIe8YPor+d002OKb4n7+p/F9fWNT66LxZW2/eX12DBkf/Rm/f0e+XZ//n
+/PLs1P8/eqH49ev3S/6xNUP796/PvW/+TdP3r15c/b2lF+GT6PaR2+O/32L
ZZutdxfX5+/eHr/eaiHEhahJfEtAUSoSH0IOhP6FAz5zdJbBmYso+wzFbuDQ
mUpRAA38Z0VwC2gZFyqHjONlCgSzJDUIwPAui5C3i1SKmAkQh5j+CRhWxYQa
FjaNF+k8hWEcYWD2z0weONaysoqo6BHrldG+0UBILDQfsOzXr+sk+JQsNbTM
EHKy2ESqT8m+ZOP6CF8oDVCrhYZsMLSHVOTb7GaFjpntk9PT1zt2P8714ZYz
zZEysOCEB/MVSjndPzHFhP1jt2hZEHEFWVrIxnq93wmdgV8MmstfSB0+3YOA
cLGjn7TaM1mEgEeSbIaBMkDwkniMjpizFztmLEJ18zdSnA22LC5A2R1dD/P9
ddsS5170AlYJYIi+D/LvvH5xuWO+fotEDT59u9MzlhZ8asvJF4RJzCJAubkP
4TbaOn13evznqADJdKuxbnTCIOwJbyAxib3lTlJCbYEkrlT43DgfgIoA9H1C
iFWoK4H5yMNmGbMPZ2eKy5YjS9yJ9RFHySIyRx09y4H2AyBkAzwI0Y1Rq6wS
XD3eUs6XaHVkhwVp0aKZ6FN0mGiFYCYsejedhoxfutFjlmRpEcLdrTF4ksOi
ABjIlq922cY8QoHC3U10bLpqwYGtoZewKsCfCBgZc3tkPyw0tci2ZgTml1sM
ZToqCi4LBSa4HtBVlDX2QY8i45JqgAz9cm+GqW8x4Xeb818Me1dJAlBhpU6C
gkfgjhdWsr0gyfbzN8HEDHzB/utOC8KeMUhIGP1gdK8Ra9LrgazvTr2E9+zr
iDl2GrkrIEwEaDgyW6UBf+P7ElHpDtSNGZOOQGYXxXsC4wx7F7P7MkUZ8r5f
dwnIc3dFCms2Dotw+4wWsbHsePN3X7RW9rSClnYNlMRBbl8+LdmLsT3G+NAd
Mmfl86T+3HJVzsi+sKoqZEpluljNQTtO8lUJMIzamzMuCkbzi4GhKdT3yED3
EuMIQTsZxwjgSTUW0b/jyNgKmkS3QLJysenAsa9gpUih5BNc/E3BzjAasnea
AETMyQowU59XMAdR+CzZwOv1E1ITtKyQVjphU1Ys9hpdq6qFfZgF4x1I18Vg
Q976CAAuEWJglYHgchUcDSlXYomzOFUvBBzY7IV1LMVVF/TWEIllEsO1DSEI
9DGjDbhfy+aIXe+QSIvGHdbUBQVFDiKzRv0V1IUxVEosqop1LWPzmBnqHHhD
mbfieP9Q4UOq2CsBfG5VlspX4bkP4yDEoqaO2u3Dtu+XjMC0i5t5PqI/ZHNP
DwYjUJEpnAhZ7Hv+2Ic6gBDz/nzw9GBHWVCTt6l7B1bHNIWj0ao66RPMwIDO
O6FGDi3WbECNHDccCcDgRF7smANKEucnCAGGgDPX0e5xRcZOEVgYrC+AxLQh
IORS1C+RXgLaELhvzXrJPogimjNdiuKZNJyGbl01JXPYewky5VKCaUCPKJGe
bZfC5+jjBgDs9PXA87JM0QZdkZjovUdmkZ4STot8QfPzJfPUyacYFeB+67vq
sYwKjtEY3Vdom8Nj7SPxhcsvEnJflaLwVPHHRAQ+MVLy48AIMJaHHEweKwzw
DxHTL4pkcMXmL4zO2r64erUD6vw6+1kk5jJLw1ogw7HHPJrnOQhwS2cNY7fb
DagPWSDaECV0ej1gkdtnWeViuBjnBTvFCXZaCNVZDIcQrkcpTkNQcOZCWJW3
/Onjcbh3WhGcbQ7zkhmRh6iieYKRO3v7z6MRmisA3tHUmS/vEWcn7MdYpXBq
CDeApVN4nmAILSEriSojUHHXDssiuU6uUm20KJXMk+ymmjXMi4q+ZM7+jiD8
4VCOQNMUf+I4X80njt0KRschsyyrZIlmxxYLNbEmHvc+9G4i6MQ3RZKI908p
wQkoIGgoT6spHDGZ8DPdDomCV69YANuIUIP8S/QR3Z0s/QOEo47DVkyR/Ngt
l2OoY9+dot672OuGvbd5lXj+Kwfdgt2hAa2MXu0RCrzad+5Yo2sah56MGAOC
ZDcDUqpgUwVwQiXKeEoYhdFKUWuWNvHd2hlD680d+Y/wVgEYAPDoUGtrJ6Lw
bqkY2KeTqqsFvPrm53VxoC3YoOUtd+5xUaSCmrD4M1X3X3h1n6M10MSqbJev
b+8p8dn2UFzLbVErPz/dWWd7dkxRlLi2/QPyJbcIOzwevgKKX6TgiC+jkRGR
vGXD5LQjUi8SXC2WYJ5OEwoWSqfkYJ7POY6OCU5dFUV7RkUmMMKlzRHSQ3LL
GtVXDZJ/AUwPrbUjNYVsSE4Cha79JBkXvSpnrJLmkCcr4re5iYsfa2RIJWbk
lrHxgPFWALQ+Zmg/VEEaj/bOeTtatABPRlhRcEEkcs8twrTlY8oG6xYHRL14
cov2e4QvZ20ATJQoAxbwMIqBzjFDmwJMhvShbEg5QrD96tr4nCzPmBGaKJ7d
kzkGcCIGpQ4ErJscJOXZolQrSv1zohw12rao0g/4BFFhsnS45wNRnuSX8Az7
Fi7h17J1TvbJzlMycxwbMaFf3yHTbIeTavAKfEWBDFUXDEgJ+jPJ8oEorJRX
NBCk3fKF0gwRwoPF5O4pnbszROa69q6Td/MRWTTqsrlZkFrfxDvjoyVaDAIR
hzSrX2TvEK2IFJpsLYAmxBm/X5y+vRK747OnaAS3t8aA+7DyfEH7wk/ocvAS
Ou6A39R9Mi2+JxmALHKobXAUtyhfvHnxZT6CeUpdfKRfvBOvevT5m3ZvuwQ7
lZI5EwYfo/hUiuBOGq1TwVsi9BiVvsopWwU2b2cnoDDKEmB7bxhFRh+cY0aj
ZBLE6/hui5sWTTy0U35AfJKlo23eLaw2H5epI+aNBGW+yhtriTCnHKCCHjrY
H4+tAbtoU1fXHX7A3oBSiSdovAQusXfKspPBpU9Z64qdjT1J7GQcJynFMdHU
us2kcTZuvzUxsI6eFxJr6xFa4wdQY+AXgUiF1GbY2w8vKohL7nyNpnJshkQN
NVdeiL2wmZLkt+jeJJmRJH1RSvNFSpE96dRsl6bXmTGQbYQ64QSzfDDAkrUa
Zr/O4ONs544teMqEAEjKsj+FJ+Ep4N27670Ud7DfIfJZcsrY6FdjpCiT+dTB
kiKZbj4YMy1NVIC1+B4MMdHc6Rneu62E3Ohs4q+uxaMTeJlNSJS30ygoxP82
jWVTO40VygsYlgd8oewOOvIRSiH4t9m/gXC+1BXwU9+CeAGjIF7AgvsuelG0
Frz7JWBQDrAC0/5//8//a2cg/666822kxkVf0YGZMHICBBEyzU7jQmwt7jSQ
I/ZR35To8gLdbcGNvMOp2BaUkNydsrmalB2QBPOmpsMOntTzIFpBPFLvFUZ9
pOPVPOY42SZhJmYdWJ1SdVQT+aGQwVjofwqab7xgSQku6oMyig/yzZcvQJf/
b//T+/1Afn4f1X9+/+A3g9/3ftZb+LnxFHwCeBJ1fAOQB7/0fjafNZ964Bt4
/9euv3X85kQtX9Grf4RBGoxsbwc+ffDVXzVrk7JG2/s7g395zFnpxALKtf0k
xq0Ofu78Bhb0118xL/yHkpY76kFIlrafjHZq04ffwC1892u2bTHl81H0TRtK
cbrcn7acrMYx9p5YB6L31hccCHAekXsQz0EF+9MWxiwmBXyFod5IP0X11vjy
wHfo5H6SUIjRjys1IqBU6oR7/C71flqyfbRrKUJlJt57laB5k7gymcRs3E0o
9onoWao0/Nv8J9LwN9EVLmEPPqlj2edvcHWDZCTuWuXatfhAq7ODDMwyKK57
mkuQNXNJMnx3SaWYlyRR9njmGrBX52rX4u1TIo2yAIkFagXiyIdabLNNbPL2
O04egEN9l42DUDoMh2fx5QU5C9o2rOyz5IzlxMT2jEkOFn7u7/PsReC6QTEV
J4rQ+5rCh/BA+QexBs5F2XDq2NkLdVN4xYweJeXMxUr6OA3iyg2PmNn1OXou
FoQVxOvQVLwAPUbVQCPeq0THeaR3qJG32X9oj06OYZ8xOXjj+Spx8jNi6hv2
R8Brc28jfCGvgBxPqEnby1fFeJ04DhM6SbUikyOHB/T9UkvK3aXCJWhuZwXF
2ctg2uguKZwkB/J2JZ7mIP7CgIfI0EuyRrucHpJRMcSGboOGZb+Ei8Jusz72
zqeBf6xplHI0pPk6AWeraarFHlUP7ePg8g8i1LbiAcNhKQfdigq4AFT9UEBK
OciNwhtQpJQIf8oToEwRpmiiOCveWDhrwRk1R0gBEHl5nlfNGHK8FwRelY5D
e8ypN9QUWO0mm3CQRf3JvldNaQIEr1KSOAQNrWFQVFRlDJyzQt7FNKsaYENz
CLAg1d3vs+8FLjRjyyhTT1bgfVwsgNNjEv99+KRF3BH6n01C+o/3tV5tDeKc
25XEmNQRJklYyaDmmX9z/O/4PXnOcBC3uqucArQYXr7znx8Huq4zlISaCs+p
NVAOh08RAEzcIOWBuWXxZ3SHhaCm0zB0bZMVBxwnbu9swde0znbtOtiqc7Fe
EPRWFBfXcbJS5AVDK8rViJPVqlpYfHfSnneCtVy2j8qPLQhbIy+7JhqR5i4c
Q/AgpGW4ghxXrvUp8BH2T6nfE20qYw7nZZPxKvOzsZuohZfNQUT4Tx/B9hh4
8QQ+eTBx9cw58wRfxvnflyHGAGe6ueEYHrkUb8njA3lolqFXUd2r5KIq2U2N
EUWap3DkGa3qCvJVtM3bind8fFwo1OuDY/TKV8yBBI+NuO1uvNNIojONdpAm
AriGqR4IVD6bguMy1Qlq8z00EQdh1hnoiOkSKQHZHovQURC1y7TQIitFspwz
yRWEHPZeMiyhd5KSI5qL2hDS72weSxg/0cTqzdGibteAh4AkMKKI4dHxHcSX
X4QuZIWePngSzd2xriRM8dbL6BKR09Cg2g4OrU0UJDvBLeRcVktYqnsotIBp
5mBo3XoEnFekj+GzAHsEr8k9oPIS43fdyBg7BCqDsAJvqLNWM40rJSgR+2QZ
GMMMDfESkJxFaDRF1KNgz8rXyEA+NY/rSlTfpWUKYBoZvhY8XRsMD0DKYdj1
NtbiNqCkw6UAI0gI4U8+gew0l0R4zuPqdkerXvMH0AgWbn2cWHeXljPO2ZQa
cU7gpvRtBkBgnqRKlLXSFLUkoccBqJEHKCGzIUTxhyFIyYNp6TRj5xwMvdSi
6BnztqlHoLaKJZWDUvlaxYNwKjgKrKcXWq7r7gb8Q5z38BdZb+vmEwchWFgM
42SN28KGk8ITPFJSirfAZG8J3aC8kn7EEX2kr9AnLnuhw4Tu1bvAfJ5MvFu3
pVIE57TZ0ATFAw42vCZia0aUONsW0r1d7kRAzHAJZDjXeoYNGslJed41ispq
eyRCl6+4a1tytl456WMOPzJqlGcfS53AS9FKUiexCwNgYxl7jOnSAHp6DRe5
CNUlRoQ5QepLm5JmVNl4lJM7Y1VWDEb3mtSoCDIfJQCBImS0RMoEiSZO0if/
EwZyAVnxWa+hqG35vt2IiZpsU7xhZuHFeAK8WnYky1b98+Gm2dOOaHLfGg2i
ArVdC4cbEH41XIuBXNoISiOZwEWjPRwQ8Biu+tcercLibp+/YYGG02SyAG3r
TnRUl0TgQTw0qMruaCd4NML6miHcXtmpuAZN4ukAj2YFUcmOdBE68khNgo22
02EyBMFXS6SS0Jzdhw7ysxe6CR8clCxjsT2JgToW1gzCZcXjCxyUw0AjIY8Z
y6GY1Y1LA+hC5Ank6PEsGX80tjZeQF/C3twgIsl2EEKVYq0wA2ytSlEEkQBs
2EepUcFZRcFuTqEQuxya1Cjj15ugatZnWhc9JpK8nCi8HNwsi8B6rnKoHWpz
YMJhf/Uq8+PiglaZzfJ2IrgYp7wQQhZFdmi3mag0eEbC0vvKeBdE2UJ5X0uH
yVQ63KRWCaIlxGyUgOye5i48PXVmYOIhZVI5Wod1pEC5XSyrLQ/trnpyN2aE
4juFTpZaKcan+Krxbk42QsfuWcXT5HEyG6GZUev/yoWvsK6vvEQjNY4EQQDo
PgopCkASwaBJGEFGjh0QLfNsicHQM2OexMR+tJDHZOTBlO/Yp2jGDQcy/jXH
DSg7aCxSzO4cMoWvYUCcsYrgbKXmAoRzktjXdMjb09w4VJzmwl0HEfsPOAOa
pn3O+8Vb8nGM258/B+DwIadadF++7FCakBdr+9FSEugkMY3qkpSa9FWvaOHJ
1hpvFFms0X6boXEkzoimgBiQTu8VxgNqB986GscloTKpiCVQQYl1PooJrx0T
ItAQSmAxT25gWVhywQ3ER56TdrNaRljO+QrWMObqjhumLD2KqHZqq6hhDXSM
pf38DXoLbIG1L2g37CrChfWoMP+D4yuB5CrxwbEkUpchJR5RmSS23UuOI5xx
y6cmnVoZAhcpbDeUZDmV62rUpOsuQrIedtzFBXqXaOxSvKkG+G17A5q8ytwe
qHjoVS2Azpa6PptLIs+xCWxWH1/4Xj9cJsJlBgIuCpGjJApZUSZ1rKaASzPK
GiLwp8Db040ZnlArl4Bo7U2Gy6mHDq1U7ntjzcOyOUk8GbbKISYqluPlzeEI
CEmqQ5s6QE8QyfVvwZ9sQG8pD9oVT65+evIsE+PyNMDVbZF6K6Qr0PUriWCL
Yz39u4UolLJdZUr15fnAx0WcDdKMsm65muV6WyOfrZ/mDmUsIuTm8RHWSLs1
6TC8btKlWgCZQZ2rvKlSW0f1ugXgxb0aJAIQE2uLHpA5GUSw4Cz1+EOlthnm
9p78eF6rc4ZrTJCbx5WxL3I5utw6XL8taxq4sbMI6oh/lWNJm2nmrr7TOBbv
jVkuz9hGsFyQB1VcYkxOK8E3g13tOZGU28WldzCC/qWatDgFMlB4clDxUGbw
qCqG5AnWKGvYGrrEYJ9JF9CXJvZ7MxEmifno/WJBFLfVFDLsvW4xFRvfQujn
FWm3TAIon8bpvN3Ufp90e6FCT9wYiYGEtddmqKgWRotJmxlD6MIykp4fk2vB
rhJj7mbp2gjXKBOFwZ2mpHQgL8Zl6e/OSq9TThjUo/P3AR8uUNjIV6WrY91I
mMp9gYx4iRWqihTR0yUemMoXdlLrB8pqV+Ag1dGpupuDi5loJEW/MTrBntgq
9Oi6/E9hUqnEfLvAhjUvKjcVh0jVsC6qZT+1RbD6AVVspZ8fUXEjTjS/r0Ey
V3zCBM1kPCdNHgAY6G06eRxriqTRdRhUxCzV63BOSx0qEflKND0gaGhJLzi6
8YyRE5v4gNJK3B+DckqVncQSzCnAFP5GoPZtyLg7Hdhv0k+cWycz6ujA0PLs
Rii9mDtoSuOxirk4aVV3cTjJXHZJsSsoozMn6jv5VRkT0vopEpwfL771Bc1Y
zRXZB5irxItMnHsdpjXsztVBa4m6UYNdA0uyidiqy7CssSa0qy3Fhcp7Y2XS
UoKtb2UuPQ4yEcIOpuknmpBL0sBrN80UKu+T1qJvyBrg9oEj3+SqxU+oOoDk
CTs7R55X6O9eBksSEJJr7asp5F4jqXxQDi4rKeYUl8lYE5MI4WMmg6gOHwpP
IQ2oBUoUqQr3lbH8stwAOD9Ll4G41bLO+xD44jrehKfTsXKXzNcmGDcuUeUT
ISUu05RNTJzK5uOsarKTMjJkSopknWlx5yywBxqBWU6QB9C6HOE+zQAYCQWd
tO6opd5vXNZzFNucQRddq0NpDs3/LUCsRR7RXyXIWq7FiFrmTsuQQE3YTKLh
EsIBOwxzDlYAHVGy4qcaydwGNuZJXGTlurszTjzLwzoP0vkgv/wBiclKko1I
UhUQtsk4xrcUS9hbqZGOmNFLpXVx9noCJMcNWENTSx0uFhp1FXZaT686k2QC
76UvEKmpUK6oZCOfnTMUdVV+NTa51IR7Cklquf4+hzE7kckJwQ+24AjPS2wN
pNUaU+gkLRJynHcSBka6lpXBx4oq2Bojroer596TRbZqby0MLrUL5mRAzS1r
B0EnRqGgUC5xU+geWYhxwxwDMRMS/VAqxoGogN75qcQNCyRcXryOTs/flbaO
Hkemli3cqolBLRuxYE+Sy1JOBk3JS4vHrL7JEnRrxlTE8k4TXR7Dnqe1EcbO
BfC+5pi4FvX78zeiiH8IQoClIKDq6AK1SyqF6xzM9UxMlkforut+EJHEXKhZ
4UKnkQIUoxTLQ96byvIpF+j26Vr9wAKLL1MaKYjqK4wdRiFLVptm8qjq6kjI
72bJPDCuqCHZRzCY+vOxdRIpgdDWImHtQmcfhV2WvmWZz3BnRNHFrTsdYzsw
7uZERdf1VXKHvWNroSblcOVKHXB9YfIUe+OEbkSOiMqpVKbu7jZeFndF2LG5
DkHvhwAMkHBSlSpKVoj9nTjTwybwUebsgbjNUy6vPJYLaisOzKmfw8ZK1JeF
eEZBgWOQMBEXVtVNjqMFVqiRecOHhgf9uGBLexo8g/roExSuc7TRwDgaR/xk
uDd84iOJd58fssE5dZX/XK8QR6dhkBsuEh9JPwbDMAIOrbMcDJ+5Obh0rZtj
yRYQE7vYBkuad08GY3gU07XDA6FbKpIbRD0fGXUKlDuVYmLuUK3bUFVBLh5I
ap2/FDHr3dzAuLiW5oRUatFW3X4QJUBbxnzrKldASSyYUPqN+htRGSnTQlWj
SR5Rzd7IdWPSAv51mCXbVgfEGkcuh4IjCuEo7ctlmEacDMlCWPrrhuoUcanl
w++fAQnyfYOkoh7MNJjlS+fDFdVWiGqSYeeDiS8veZpOp9jlBBR9OK0LVH3K
aPv06uSi3Bn2XtgYffyw37Z8Lu5Ox+3ycjjYAO3yWviLEOSxYuiuLbCwhg5M
ukGGxDzhZAXYEZ2ZNEJUoXJJfZoYHaw9wJirjZ56/PLgCTeUYM1xG2uoKkb6
7AG+MKq2ZlZEUzo9Tsq12YQgWqN4kgxSuEg+MffhlliQ+EdSEADrZsS6RnrM
BKkcSuJtTTRh4S93omKVZWKiCxq9+Arj3QjFwgv2+ZnzmclquUqrPyE8MVu8
6OqlqV+kdyQljFz5zqB0sQYoIF8RuokWvESr7akr4uHWoS01kBfl9LEcqnVI
5ejJHy+8xN0BolIvWwiSAqzqp75egYEsgsx9c+4AevgBtR+iEIAJcH+E5FE8
SinGiFrL4+30EWuZ3+FJypqXRZpzhDZwrNWUeoa53of6EDPRKjeBvy6xlWR2
iu+NWBioxGpCDZiE3/mSYDFL88z8RVXAIH8Cogm65JxJBnZxQ+oL1SinRr3b
aP3Doss7hpMONZmOtah4zCo6Fom4swE/4Xl7eZfLh2DsLCFbhhWrMAw+keB2
L38olri7GaGElkyn6ErSAZUPmTXNxJgIHDQec+DXVPBYa45JEsiOW48QAS0y
QvHPekFBgQyQWEqpC9bSulrRijrAbIyc3Ui+H1HYNrZmE7EGT1SKrowpulyE
OLoYV4MraUf2WvazqbcjZ8OWPfUOqBTLrI/id+GAMsfOxWNbC65o1XoeqQT2
sY1lxkblDXO7sWD1pEUecLcwxWdNkQki/lJmjxC10fDKVcAOu9o0m43Y9gfD
lsLc3h1Nc4znKYXiOytL+DU1ViucVc0I5fS1sDdpGTAVUs1xkIFw+yLxWovG
J0m92Niiiq+qS7V/KKhR56Q+T8AYarZVai7HgeeSoBPLeqjPjW2ERQR3gMxl
kUggJ94KbcXlRjjPrQuXD/2KQaOIVG0JmlgBf7wv0gF1MJYZnLWepQPiGDw0
Jm4MOGYBzv5btPWmcbnGsOehXC4EUyHmt+Jap7d17O5yZCxukNUk8ZWWGiZs
pubNfKCmWZrluIKUhXUGbXVCEMgEx0bh17MYiHvg0X+0dEBpNp8FtaAUcY8v
BH7qfR0EFblvH8rvjDwRNa8Pw1UMLQ837DQVz3ZVTcldyo6ci7aQbRle+5RI
lVuXnk+rr/KPSeZT9tsggVfu26MQ3J5eaI4+Fud2cV1XqTq1BHM7kFZ8cyEB
kaQPbjHI3RSlfwpFsrAQz7Q+lk6Wg3w6aOtkqcE8PuhONR6/Lhg+vYkl/hVm
cN7fCx9UXer1ByvkEKAt+nKL9K8F+eUlrcqcPrmUWFzAUFagvysbmX3tF3SH
TjGi2nyFlVcTyfPaLLgc1Xp1uHpt3AYuo76zNBjHXm5J7CjHrKeVOXmCAl9/
RPWQopHY5ZasOfchIDWi8Xy7HS05VmL4tqt+i30L4INJZBcqmnVJOfI6SaL1
181s7X1vxjn2g9OLo0TunAsVEKj6M+bZfJ9nisDyaSQ+kJ4w3MPPgJ5exkCq
2Uy9WtLIbom8Oq7yXK5pm1tfqcUfey9llIxnOQKq3KylDy5e3HiCQXMXt2x4
sIEfy3wtuUTdFCggtNc1IHfxZLAIB7RslXCtAewqjGWcoJTzrzyqcWfohnBZ
g36pJUrsXgKURb/G6hpVrRRtsEiXfkbTNyYmsyQVDxFXKpBvjYus1OsiGzNE
lFA0Iae/Ik5a+XTJRrvygJF1Wpxc2A3fsLdgt6697wU/icg3EcWsbq2BP8kw
Uvmxul+aPPVjlyccnKXbXwdfdgFkWJ6WYA/ABsF0++27tzt9NDvC63PDb9ws
OH0YxF+HQlcHuT64juHCeFEGAc7jKongynFEpK2cB2325zu149kMpVsZkRAt
2jlaAYXMxCSR+XJE5SydGv1QF3tMgg8e2wOwx9kxIelvsRl7OFTKrMmS7YHk
l0b3ItGy5K6RJLZT5gcnk+CBdibEjIAw1vINfZhQn7R/xlCict43S0Kor0GR
ZkEyLxejJ8IWoDMSTiEN2x4Dd8yRudQvU6NTbKJwf3OkvxwLJpATjv9tGUaF
iOcT66ujylr27ZCBJ49WgCsTzsCNGzC2qYNerAA65iFJZeMXgzZGEWHwPRry
TIluifipSEdJtU+rl2geSeK1oHKlsPH5G3OdtcK4N1QH09LaLgjrrlDyc/QW
o/A6qsidSiXpv5BS5EvI/Rwdn7z6cH3+5uzd++vGW3u7zmkTFJ7jty6P356+
e/Ph5fHJ9btL+9bwsLVc3c/Rm+N/+3B5dg0vXr05D6b7OTroKHIH+7q6Pr6s
L07n6nzr9Ozl8fvX1x9en51fvQdF3b512LYteuvi8t2L87d/hr1dn9XGhLmw
D8l3/Kp56/MRVqcv/7RVRPMtrbdnYSC4QqyxJ/nQcsmKcEFBLPmu3i15kizn
+b2PetAK4fI4BYlQRa8xoiFXRh7jSvIJIR8QPBApCq2f4odDZGUBnotQwUsr
6mKFqKZFA0QTDg6J1WzPzdJSSezcu75b8puU2rbnOGGTmCAeTWVg0ryx8/ON
uNRUCHLFkH0JBUr/o2RGtkTadXMXGtMOiTrgdI0vBj5UeeBBuiNJioavKQeZ
QuFhuZP8rh8lw5uhRaz1nOVRaJCap77JS5RRPsjU2HMP4O8FN4KrmvYq20ya
wn+Ek9c5vA21JybKE0oTU631xBWQaURZkBWsqAGgl0pM5TZPKtsyvRp9+K7X
jK/CkxZjrlWyMt5nMeL1fkfLeQOKPj+HrUh0FLJrYZuc8KF4Hj6CoRT3tm2R
vnB+isbMYGHGQtXSyMe91i4Smpdb5iQm09LoSmzpcmRXCSWCNOZQxaN+onSS
kk9VprUQXJ8h1mr6bG4IIa1lN2Yf0e6ng/hw/+BJtL0FT1NH3uOrk/PznU13
CMQ4XZLx6BdtMnYOm+7tqemWt3fsmj60bI0ppmgSrk9un9sCkQiDNpkRBS0z
+aSWRz7IwfTFYTzwYGl5ApzF8dnV4OTkzWDv6eDpwWBv/7kuENtcnboteref
y1X5DdZy6tfxw6vTlxiyP9g/lH4Lh8+ffk/YdlWDIBAqG3ApbssGhPfZnurT
HEU0kgHYIlzLyhOz8UdsU6W3L89P5/ENDc8ipC8bFEe7A7ZFRB/TMAvPWUU4
prWBwVbThXc92aNAPIHFYL16ie5y1AzEBEocyaT9yHsuxj2myEbMj/wLq9JU
JjedOB3Utl/Ezk7Z2DXElSNknv1v7y6/tXU7eEgfgiNJG1xFDyM9xXj5kvxR
UqY3k3wtXFmwwyAvFfXXKdtuQzJ8HuoyDJogjrDdBYM3tPpr4FHoWy9EbtLb
AH3LvnaBXFIgOTxZBDFMtQ1hr5Dc6+ol57YGj5CTjdydlLFGHIq7nY1NBSjP
KynE34/mkFbByTVSZK+IrSEVbiUK/J8blj1lKNmo7ClcJlzjinudUxj2PcdK
jUBW+hgSzZsV8GuAa98k8TgwxZy58hy8uOOyzMcpfXWKMtb28dnx6Y5plTMS
BxaMxjBEh6sm6S5Wr8QfQJ/M7EKsXcHhtgaOfZONuoHrTvrF+ipg3C7kPkIj
dWGy91dLFLhLO3yLw09cGm0pD3XW0iYI8SSILd424Fo6dQt2YprBomely9Ko
ryeY2sFr19FjVRNfDkVELS4Wq7X43BL061pnYWBBXDVPzIASsuK5QBCJgIMF
bJ2+ddWyuZWlCTOsiXkUcNTooexLbOSsSmmlNcSQrq3XKpU/SnjMJRdk/In0
C9o7NnmjerdjLDa79H+hdI9Wpu7rJ0Jq/byNco82adEYCSsjXMhprHm1PRbz
yXB/uF+7jEbPs01oP2eNyTL0LgxIbQvgXCm9fkv0uh+e5Q438ULLEy3THWQl
TjSEE9jajLu2MG/jR4+X1Lv1U/RiuNeAr0jqblI+W+nzp+sMxglcJipUuncy
ctdEhBAQ9GVtj80hlfUNiJC8QSfgwJPqiLqQYNM/lWuE4jxxNpZ0bVoXuw4x
+qzIqc8qZavJ80jd0GOnMcSbdE4lK1+MHaTFveiWDaLpHSaViYxSkhUSD0KT
GVsO4lFwU27mrCiAav2AYT1ktFDFO8HPP8zkc8BOehB3lZZBJMlD6eNlOuea
eBiftkQySZQnyyOawhtGuXYPu1+SUFplZ5sbCLgJeqqQf7m3W8q4qmrvBSue
Ed1TaBO6wrI2CW+LU5UQNcTf6nuyOxuLG4eY6ZQxCqvBrJZkoc2CBOoGwd0m
84o1oTf72ccACrlvJrnTt1NNEhVHpK17jgXYb7Wag5hxZEXyJrnqKrd3oC8u
xVIS0xcxltfGFPF4XjmHEYdsY4X3HfRN2ivEweTujVFFKIbNpH24fMZYol1R
TctvYAkhSJTEUscund235JOsDychtRfAZ+t7PHfJHNbSSL0DHgu53sSYT4DB
DLBaxxW8fo12dd9zkS1BC/uO53MoYxoRU301BsJbNeaGoj509JSuwA2ooqcA
LJxms9CXKwIHF+ValGP1g7n6Yaa5Nn7C2GShybdpUa3Y6jCXnMgUaXgRT1IQ
zmfpEt2crl3geJZTVFdorxPNxyI2YNrzAenTsGVbn4Krj934UtfBNsto7wm/
NiccIzVyuPbwZ3E5s60wy9AacLD/ZE8D6DpGwJoYRinW6DdnXTBWhT7Vy4kx
9MBv1U2ISwFUJIPsHBgIs5EKeDadfegQv1mlE+JxYmjAUoXA0oA0ZZX4z5mf
Pk4o5IMV1H0sJH3swiEfeI07l/nN+1qV3fGQrsr4ptGQFJQpgWtxjcUH2Vnq
EZb2Fz5CNYtvTPoc5VVXQXkbiRQPAzKUTHo1WJu/efHQh6xQGA6LWvSyUUoq
4oxMAkf3HHJHVHLlbHkbJakHW2cjiWg3fd3sgP0yCUA5ziDxVbUKg7RMUyOG
+tuj3olKruYPccFdPvwCyxWVrgq9qeCB6W0pG/Frd6jkTYPebE35B6vH95sK
QT8EnlHK+hvJA8KdDDQgGWltALfmB9u8PQzyP2841kZPRdFffW84rd5dRt+5
XN1SnYboVdxgxJ+DbnPyI0hVc0NS17Hji1827BviBngBrylG1A676da/2/xW
wh8Meaz9bHorLa3OBhzyIP7W4xFe/7ji2FeBMOqDu9Xdz0y6yoakyZncav1l
OTDD1kf05To4vqcRg04UwfSaOFLnUluHiX5QNq9BLl2Qiouq467YQYbxhUns
rDew4GaTKKGz6AljEp1PHw5/DhYdJqOHqzZ1z2tWttR7e3x5h7mrJqT03C6c
E4YFCaRVplbypOe5WPvG9QKC4p3eqtuwAiFBAznlH2wHatZNu+46C5LaNr6d
2rtffT1adsKW+AxaerdzNQqB+Xq2RQDPda4tvNcNnhvA/oV75T2/8hAk/RIe
e71moq84are9D97UKl0B7ud5PFEi46VsKn/I2aQkgJy8eHcpotTuwfcq49Kn
xD3ZD7IqtNgSdUwE9TkuXEU2P5X3ADSbjtRWPh7lhURTPF6QAUHymd44y6L1
2CZdF2/GLdn3SOkwWLeQYRt7u7Z6yWNpowF5eiPQJCL4mu4mjaDPcKfs6XEF
zRAqmfTEgWeLEAjHLtywQKeog8XFu6vroXxLMZ9pyTlTGih68u7tjj7QmpZT
qoN6a5zHyy19tp5cY57jrNBhXCzjraE1MYLMPI4x5F1iX5s9UnxiTKkpNZO2
uiMm9lQK+wUl+/0SLzCQvLnEv7t9hO5Hd9T4YNBLJ9BfUD4xLzfsUOzuk6yS
zPs1CP9awm6aQ1qHsM3wYdqH8bJSbbTFCtbMZtDNKsFItbX2BwVEIjtMFJox
9RaKTRyWTUhptOxpCRh2ifo+0hduOoR49iMmtUAxBPZvy3qYcM0VgWGyd2Eh
ko4wbtNlB9YarJ04Rms0dWAzebh41rkJ7a5ZDhqblkKFAR2snVNJFspVIYcY
vi8xaKZQi1g6a4WlXet6Z/loadxhIozYEmJjjQm2ig3inau8NdxZaTv36Iy1
Vob1O5tFhiZFNtGu2b/0JCXOSBYyCevNnFE6841HWUKkWGkbymJgqvfi5GLv
+11h0U/2sYCNq6WP1h9QoTPWod9fnkv+I7emuAMww0J3ZJVwx1V6N2zCIYIA
fwV5O7H7WZzxAbCVCyMy31++xg/ukpFKnpVWf6100ze5BA5sfTf0aYxb0bbt
BXn4DMun7EgUNsdgq4DCB9pCzuP5HdZdbqPqrLlzQ0pbx8lUeXEpmeeIyBNf
adwcp6uxCFJ+YfoXmApejorikQY9VErOTKOS8lg9v69hLOOk4KL09uJslxe1
Xa58miixCdQOMpAdt75D9vCocoJI+A1BYU3TqmZ+CCpMDwoI/LaREGQ4Kl8C
O94f7h6AFMAS104rowhzrNdyiq6Q3UeRMRtSvJE3RSjv2YLsLgc2nSZsujNC
IvCWFeXh1kqY1C4h9hGso0Q0G6mkIQE69Yoa3lkbVh8MTHRantj3XHFOPlfw
X02Awy4pGng+1phKx0btFRE6LZv6WKqBGVXNktpWLh/hs430dketBKnYevTm
wL2SXiTi0AjyTRALXYe5PgZg5GXd5Fvv/BI4xsO2YhS3gc7HflMdjrUZQL4q
5yxHob2opmE2Ah5ox+9GFAmjdNM1wluuClywq7SQxNSAxtaq9uUIiE5a8dZp
Pq66PCesNEKBkNtoLyqtTuhq8/lao7kKanVNirJkpAWQNb5QvWSf0BUggVQW
6y6b679p1C6wix8XicRQuscwE0fIm+NIritECwuqnwdDSdkEIKdVrEIg6rSG
oJMik17A83sPNEF3vQDo6c4CQ3zdqSAo8Z0jws4kYiMeNFu2eV3a0NGVkJFm
oQMYFATVtJwlk0AncR6Zx2JnDRLsOVrDQNJbb3pp4WstVp7/Ml14Y/32n1TX
FAO3PVtPDdzhOU+Zj7WTbfnI+yBgf6deN5tKx1Ok3HqlNYyVeyQpRD17WDII
lTL0TEWuPYF6w9qqDxs26Cgd92vD18MGCd6q4WDaHjNd2APVPhxDcIyTaiV7
36SpYyv7MNGVD6w8KHirj4URAWRyIQbiSwzhtKbwGsEKVy9ziezxGhNuWnk1
z8Vnhxo9p/SYbDeh06TgzO9dolGXHUDbGUi0RYsJAgjxy5Q6cTm/Q5uGHijk
axVx9RNr7hbfCd3nLKV69S0QwBXRMUICo8RrPgTXqQyPm4oEqjhANf6XtZgm
FVZiChBKWYKpTbaBzwOzGroy251+pxnh2lDV9/9Vveq/s/VWGGb3SAyPVE8i
Pu+43sKF73nx+RvsrdoM6/PviNWdrPIuPSRx5dsoBzwsgiTxlOw5rkn+Wt5L
SoaJwYvwFXRgqupdn7oeWY2oLBU2PLrVkIFl6zToR4I4UKqBqD2c8YuTyt3q
AHYkRM6W2PThjjVc19CrYDmu0ST37/NaDRoNEglhIuOXPchou92v2kWudlAD
O03jmwxEAFCoGlq4hl6q2ojBwOueB3GlbNHLtdF0zZTIR6kPfZBBvEPP7pu9
aVyii6riVmqUEYfTCn3axHLSeWIvMWbwEMiwZyaL2261QNDZtBrgUJ4PTJC+
4LkvdN76pm36/D7zENnJ9G3yVHC1fjf4lW9d0Xb/zE43m4/wbo5lPTJpMsY1
nX3EUcMvL/ZIjBQK9F7hCHU0C1qo+MIN2lVNFtnMTiBQpDKjcvgLTuCNYQPv
frz4gKn1P747f/vh+Pr67M3F9ZUJvG0k/AhTbHby6ag3T/lcXHCMMoPOp18x
KTfXwhKjroWGKKH/hVZenx/TsXAuM+W0kbhRg9DSNydR1DHcW9rJHSkejVrZ
A98oFovcFqkWlOsUeGTGuoCk8B09Ehdso3Re8+ugXix+ryOSqTHDafaURKuJ
OuLMIg34VF2BvQTDTebyIa8+TDFodh726nZE48Gxf4099mC4uxttv4gnSqxa
bbLZZlSrqRqt/Gsf2tWkfiQkjgyUSEqCrpEjrYhW40Be9Gb1zsXycS8/d3aP
Ao+aj2hyLERKt3JYq/nBmWBEGvH7MEGe1o/VtCIDYwX6R40UljHmoWGRiHl0
n8Ro+HEG6JQcMmk+IV2ICt+MQeCOTKNjldlFcEIVABPPQG3mNBuXhSapANo1
WLNpiPxxYzhVU0rN8nEeFfEvGU6kKVOGS3Ulv6PQuC6niLPrPn+2aWdfdhDB
SLi19i3t1bBtdo411I+bZs5trU+Edg6XB9td+5BL6PI4uNrElzMq25dN0g/w
k0k65rOwJb/EcoGhtFN3WI2jsadXeoNvLeGJrkxP3nfHSkvqCE+ZCCavVc3F
RSI5lBR7Vs9fcynJXLnSpe1pwV5vcg7HCZJahj3VZQELZnkpvWuMU4FinG2S
Se1o208WR5wnMVFB7HHrj3iSUGNXWd6YQ6h9WWPZCR4bwztiJJlgEW0Krr/s
ipWMWY6gyCk403Uwypc6z9k4suF9YjNqzHMmXB8b03DkLc5dt8iGFHyC90E7
c4gqgOvMCv58N1mal/zVvjZRE1zYFj7WHKeacYCAYOxDArLkzncN1yrAK1EY
6MuGmYvDuClh3epmsiPdNN5aaXoC6zIlW8pYgDFig9rPeL5DrctNFRjtckI9
wmHm0pAUszR4QgLm3el4x9MtrI/OFys/rjBR5of8LqGsZl6Z3LmX2BuM0JKu
vqjJzjzClX/MYrhL8obwlmPd2XPhn6mWOEctyjAjdRICRCFmGPQ2Xa19+Ac2
3kGCiSVbSW3A3C9X67QmImNrd4zQMEOU9cwLASkXlqRuQh7PZePV16VCGwVt
SSMVqliflDM4cKI45Jac3GfxAsu+Y1ZeflPES8A/X9VCionWlCuKFoG7mjN1
XJPjEOpcjKYuyxXjGdDRQvJ6G0j3W0iqtuyyjVVB6k9ucnS0mq13mfP17Nzt
TnC+oJK7SS+u50sD99SuQXo9Dy5XOrs6BYfbb0k9f1Gqp6zjKX4RdhAoICAK
4QDJdU+6Y0mMNCtkTB1Af5nAORJVDBJPpXe61HEJ81XFFJ45R3VnPL0lUF1H
q+ZxulC4I1NxSaKRg5a3GVaoyPyl3eWSz9YnP4vG4TSLaFoHHkOooyCyZwXw
UlvYwr1RU2o6DNcqN7gDk7R0Z5der53QsXtvrpbeBwEPq7AGdDzWojIu/Lk5
nVuGMTeTR6OlQhWastndouJY6kOru+zSvnefVLtRyPfYUDeYrUEIVb9tBUWb
ys5LayJLGYn+yReozWfFaqnyzFfKEQz3Ui5IC5jYgGftK83KqezWFV6SGuPR
c6pEpGmVhkigc0Y74jhxuyVzXmtY3OT5JFITPqZdEY5mFDvwE1kLHfNxQjdF
UaFtsTS1/RCq0kniQrDqQjmKk7UUYzxGCpCwpci1TQXXrXVBlH6LADFzVWbX
3bpEXTRM2+pje4At1tABA1R8XTlHHpLCb1EaozY5mK1X18lnH8kjQnTynfgc
Pn8TBP6vjcV3qQcuiyFwX1jrvXbLaKYkBIkIw95VvjCROTqU+gCUiBLY1kKw
Wsi9MwQJgIVRGZLXp5etrd+7ElL6DwwnQp5YIyWL8vGzCMTBFCYRqJnGRwi6
EG5/aXCvo1U6l3ZidHUL7NknJdnpVe1+VpOdxlxiAZNMSCXGGf76oW5cRzV2
sYiZy2Ov5jshbTH84Rr0TfNV5jqKbtEtOvNLiaE5N4h12KAkBVHiAznP9ENJ
LsNCREdk/WrmCuB3Dc5qq2KRchu6VzkQKmXxBjBSE3LI7AfqqUju2LPtBjnY
heomEufckk5DVP8DLuYDP+TqAHiAe3P875S0y16OSdi6J3BhSZ/XvkCjKeGK
294FzWSYDP32tyTC+y3sYqvvWQVQ5wWVXvhdS2B314H64MMH6mqG58YAFlSX
JC3QVCmoarBKCtYslYBnx5bMPdXvNXUFz0wtjz77X1xvCWZtrKL4GANfotZI
nRo0h++547ULMMfjBDtHpc5eSL2G5k1r0R65ao9FdSRq1manG/VD0bLoCo3R
Nsxy6rrJOlZv6Oqt44OxMX8Ibcyyh0At2cS4vAFmTBveRSNpiuvI5F+yg1zu
Jea4xQ5nFWlzWrEGAx5Ee61c70Wq0ygcbLttxxze1HBaBlvCRg/xGPvDaVSh
aJJc/H+SjFY3N9w1WqmHUvgPNArmWTj6WrZeqMkF7CTTD1b+fo3UGnPGEX+v
MSDOpV7/zMDY8eKe/Funl/RiCwK5Fw/lX1vC1c3YCeXwwnN5EYQN2HmQJY45
362n6EtvR4Urvn1F53pPBhOLlEZI39JSGaenrxHNbxZO9neRyhIZRPrXKL9N
XKxDMCh7n+uFC4JH/hR9pnC8/wMO9Shapaimt//8ga6kx38cwsOY1t79cPMa
ZJ7n8Go3YuOrnRfR+xJspAZeP0sJeSwpj2RhKQP+Jj8/AzqT/3QcQiUCjuGB
8NyuPH+9Rihw1FZszNyc17TvFD6LiWDORjWEQf/6H3/9j0BL/evf/vo3XgQ+
5ha795WLePo6/+ni+G30ghXTS9AQ4B8mg8P6SXQtwmOCkUYsFtgi9LkTagjg
HylYyoKWk2dbWYMrT2Pe2Fii/QqBtpWPfa1A+8uE2TD/Axd8FGGrcaJprtEV
27FkNx12TzY0W8uyY/NSgJdK2Ebc7TkU7vLCPyxt1n0+iwh8ZA5Z4cnzMZBY
IMYx02qL1kNxV4EYMJ9/wG80o7257W7+331HoVApLpy1I6MkJq5sbztByx08
25BDKN+tzF3Ral9dylXe6QrU5FshP3lZxZSyindEI3HUR+nYA1EJb7neFtKz
ox4Evly2uSSfgEx4zz1Mo+X2n85HhZi2ap8XAmp118OROJxQzrGOG3VVtDSh
qg8RYmPtyunhD/5hvfvGIL/o5mFDZFPlUOUjWmpHW8WaahJWBFfTpbfA7T1V
W5qYmvxX+JeVU5oxPHtP+zUFznUU4PKJiTdhScFKbkg70Ea3bkUOLma0bD9R
sE2K6dLH+3W5s656uGxPUlix5TRqnGHRYYzMe2g5NATy+WAt8kX7SlqEemcY
l/cD1OPKkoG62AYJMpGvvh7kjGy01pYsJD5Tqs09dpk13V072YSn4pX2jJIu
uBoSC18DvxdkHM3j8cc5cIJuco/fEvdqODA9sXbDBAlMAtaBe8ajWxcy8DG4
EX8rgsx7CygvdVcH6keRRGYFpWcqzU03b6lWnhT7cFNtbc8BWCF3TTyD5lQt
xwqzz3PD7lrOwvWHq3MK1Tf7ppssLRDBh4MiKOjT663ImkTaqnOeZnWHsGYd
5/lxB4NYeuuiipliKVEuOGc7pC8Qil0CBR68Kz6qATc+agKECH05LU1vyno7
vQCDNSmBXKSLnJJAwuaBNdNJ7A+X1Ge0cXVlzHTfhpyz6wqcgfJlezq2vcLG
6Y65gN0usWjkuJHwQNkMrvwBP9OWxfA7370IULvRGmgbJbAspRpHzGakQ9SO
a1Dvrq7z6Bn/xWcnkR7ctEiziGqhY4HpGtP7H7JxKqrVujB9DSX4CpA2FSdy
07jZ7Ta37eCo8x26jzmi24UFZRraRHSwyKvKGQH51UoCdWwPxXoXSAf5DWDv
QHvDodoPom/MicqNVaCktLlZrUOWls1oyRHiBKbFAgBIUnTCDDlvQa4vUxL0
kPD2a8DRQUUDUIRJHe3sbJzZPXtgwHaWVVdHOYVTy9A76vtmOWP1Ww+/ltgh
HHKTABaaf1lNNwuDrXcggBiPfEh5K1o4ptIhq6pNL9Ryf6lhr2OSX2HYa1Ga
3Iv78m+Lme3npixvZnyy7kUr9tWXeiD/tloEPUlv7vHpuhn9vTVffCb/thgv
vQGl7fIesieGV/VbGRTDUZ1F8coXh3sNF/qBanZ+wN5NSC+vSB07N4pe02/l
tHTRI9tUuMDcF67EGy73o6PoP6Lf15bxNzRN/qEF2uStJ/BWfZlizfxDA9Tk
nYNuq+cfLJTJ409pYb/DN3g59nEHW/LwMzG/NoeGhx08rbeAeiALMLCyGPib
GUfXWUTbjPfrzPaRu4OyzRP1NYvqtpC2EZ51JKe+KH4CRbp7LUivegUPTck4
LRazdYtqI2rryFljUV3Bnr/mpNoI5jpSWV9Ul/L6q66vza+zzqNTX1TL+5tB
2LpFtXGIdbyhvqg2pWGjn3WLauM+6/hOZAh11SGM/+pFfaV3rXFS3e8/sMhN
/BVkLfcc84Oa3a3rwjgvwvqyFFIolvrH82UgextwZWxkb5+/Uf7JvL3G/byt
1Bl6mgJfxkpcQ+M3hNIFEy5ytNMfEbMSo7PBpD+4z4NYhgYt9M+ZOUzvhTCk
n4xpugCmrvoxGVuIsYncmjodVXUeVFekrTnKMiCj3+TanivNRMvwPXtcfg6v
kbS+jMpTUDJnPA+i720EWtcxkpmfS+qrpUlM4JnLMK1dm3cHUW9gYyKKYfyl
sBgTCzfsXVKXX80YsEn93M5cc3RQQMT3EnYrlCBxnQ9Oh2lSTQcYmDfQJzG8
hhJWuVkPF4uJ518XttW5r7qbq++iYSklEc4MRMCusBL4ti30p82k8JBlWluG
8Vitw6jBpwTcLjiWXszfi/hTulgt6hJFagRJhyOlM+7QyBQfEsZfdT7mR2nY
9R0i1JK4RcF2GcoSAd9I8G8rFMEWJbyBFYardF1CG+b22/C0bhu16CoOTYeo
7debdd9o3cLfCJST86HyP5RfgMAcUDapFNpQTc6P3x6LhxVh9z0ehnGwblsP
qzst42vd+eXhddE2xwAMXu292h+cvT0ZvDk/ebK/o51+mFv5STXgrxl4xymX
wQTon7AN2H0mIGURuNatLErFt3Q6YpVYYCUqG1jtjg/jmFxVnpR6cca1UpzS
OaiUqOR5tJJcXIY2Wh1D23ru0e1b2xzjN/SvOVQP4QdxUUawRY49B/OAJB4S
d1e2vfx/E1ojLwMedhQdtzO1DeSBr7yFOpZSOEotdb5uwJskGFZPGXtZfXpq
d5jP8xsXXcDJPRitnY4piEYrW3KU9DWFFWgtMCb33mnuXFs1319TUxTPeK70
8N6GIdRbGODe5h28nS+fi+zTagpfBtKBHzWX05J8jmFzuVs5FKfY15r2xGxE
kGYE2uHIwjmDkQt81VVIjiZm23Qyb5YItC/GZPgrzEq1Odoj1WoP/SnalvAz
FhMCMV+C18Sa4tHOPOC+jzzdsd+TaccMIPhSf2BnExNMZOPRfM/12gO/zhbz
cExajY9EJjwNO8A9393fOzwYuMZy+8/hi/dYS+P8ZACP42WdvQBRVUbQz06P
r48JIY5PXr1999Prs9M/vzl7ez2M1quALWt6emANQw+uCR5vrEk+++3WxFPu
b7omasRXX5R+2LmqTdck98ZrefJL7m7NwTTgaeM1PT3QVw42XZO9u0dZE07H
rxxuuqbg7jZe1EZrsjdnbUJfcXctx9H5s/Ga9OasSegr7u5R1qQ3Fxlb0Nfc
3VcsapM17dfv7vtN1/QwffxVa7J3t7f7dXf3WGuyd7e395V393WL2mxNhtvR
mvY3WNPm/O1XrYnvD9b05CvW9PX391Vr4vuDNR18xZq+/v42scLW9dqO0HGn
lD92/Dg2txd1AuT6bYmR3wmD5EtNFvr8TT1C1nQ/Wxdf7+sed3n1bUWsuFU7
AQ2edMQUtO4Jqg8Uf03hwFwuvcJ8Vk3v5qR6UoFIjYWHnHlUwjD6ktjE8VWY
hz6fSLx1xeWLXbCxj3KTeDPnXouppkDMhXbIAokV7i7PXp39O4Y//Pn98eXp
h+vzN2c0Ihmp1XThgyzS1prpWjhEYkWpNi1uUQt/aTRJULVAAq9J6UlLKZON
udaZHV1LI8/i0jf1c71B3EjenrKIMULOVXPBdC440W3st0w5xxiUN0vmC+64
8Hdqo7LD+ffUpfw4uzct5Gw4KdpU7pPKVSmMRb9a5tLkN0kpJAXzRLTtMFaJ
IissKF3cI6ecJ8kyNPdQmyNXt4cGH6KyfCNRQrg/zlLu84u0Pqep3uSRrRMS
NIWP4XweKT85REhNm/GI+ZYiuuDvtw10LHxPTZdu8/ptre54J/5JhZG1mCfY
ZrGLgQ3nofNGe4Uri4D4pNYeh41so0C7Fxs2TPATIaHzWyh4iwWDKzXW+uGE
Jmm1bSyxLXtFjYFcnGyacQmslZgsHa53UQdpu26QxNd5sr5W/LaEwyPgdVFu
d3p6rsSGNOQlnJBX+TWyOjTa/CSgMpPxSFbDvQYmDWSHC3iPr+ErrGSHfSaC
mjzGKBU3bdfBFDFtwNE9syM0wDi44lIOVJCKN0NheFKYsHGijjbzydvBkZZ2
XYWHMT/nfwPZlpfQDYd0uGzyGrnwK1OZsYNGl9ZGxTF3k/wObc9JvJCwTTxK
d6gcSSxv+wL2yXQqhquw3h2QgHS55MQ3T+jQE0D5VRTKzrH6j0TF3nNaFIpa
0VU1iUDeGu4dDg+ERNXMXsoAU7VIc1kXqjgi0hq9jY478o26msPtYcW9Kzpd
uQRv8zaW07JtdDLOYtRLYIisxUfXolRbTYlssiRIzMZJLVJTjebpxJqFscH9
YpRmJhLVWuiAyuUV1anHoFstPpWv2Fd+frp+U3S6lG2CaXe93+lLbxChdj9h
PdRzaXKALZvS4i4tk52jXmOZas/XFhXDnl1k8zk5qocek+HqzjeOr9lOyp3A
7LxM4Es6obuZYDhhX+AdH/ZOyczOgUwKV5bx1Uoy2BUuNAyKAQDm+7akbgIt
y4u2KZG1Efy+05eIpeYrfV/xPSyC5fOncC7XiZOM0uqToOJhVD0I66Vp3tL9
MtkuqXqnlotJA9nO0cJO91AbXOxF2/QJCFmfNgCHWIC85mVaDyVYV9tCSnMV
+9H2wYBWevZJOorgE1dUVumxlvXVwFtLhUs+xdT944DzEuhGu0aySRR+Z7ac
Tln3WtWxvO3cnkTbz/9pz+35f9m5nWckdqA7u+y3uTNt43MgoA1vXD0uh+pZ
od+S9uckWkpKVdnGy2U53gzVGkOeYa6wZAwc0FWaTnrKPOD8pA0XDAbvEZZu
mefamIEG9LP8IZE3VuiSJK+aNMheYKddangIw4esByMeuDBkGe0fHvCTjuvt
Hx5Ky2HsVSbe3NripJIciTGUQNUWWNLbiHcFfQNEo6YmLigcVcWqZGneNwcl
bYRCTd0gLKmpl7ItmcYX4JsnMfbE9MW7fbrNUty5m2RRcNWUsYLThMsgsh5K
ZoCBlIJT+WbqXaPD3kWwcB6Fcq5HvnihbwqIkBvfFAknYbsi7NJnfhJ0TEMW
WLqWRraCrtHgxNwQCE/l/WKBdWHrBUZdX0bp98r58ag68lS2CeGVNCLRFW50
kojYQYhByYSHSj47ghbqu9IGiAV7/1Bti1V8E22/OT/ZEV7KPZW8NkDZsXi4
hDtrh5EBokV6MyNLxSor42nd463VCmfpSNP6mEIJE3cTIjDQGYqlF2FaDKwU
tCT9ZI6zLMGafgfDJ600YqpB3yZ04rHqsVGCgg3P/fxNI02CdehGxoWr8uQ8
8RhO9XDq/XmlfVvCIDuOzdUgBm+QrAXw1at8NcLS2+f9VaE9tTg1l/mWpf+5
cvUnJHARqXlQEbl0QX8U/WByHtOg2nBcT3sL00bLMGhPoyrChDeYScuFd9wX
1+lIYIYPWNvfRUWlEwpSnTbmBaaSU1nraZVotV81dmj5QtuP4ZdET7ZF8Zh0
PuwJ5vG7OyHBLzH5tEwLtx2/XVpCcYvBpgyGq2VQny2nUsZ3/i1bgD0c1Bk1
/JDXMoyq+2aUe6HruonuLg3eVqHtT/lc9M3Gva4tJxA3CllIr8ovIaTxMmmH
Uudbu1FKITCuTizxO0GpyrZJ8IFwil+aRVmLO+xTOVHXQaaJJFwebcrBa6zG
lX47LDimS7qeuizxy2ONGnfSHm3UeOxP0X9IuFAzrSaMFjIg7L7HcKTe38JY
of8Wc1ITJH9rg1IXAa6lHjNFMHlBjRVLmoFkQPtUXFjpNZbGWuRa5Pe3oPeN
Co2R5LrHRT0GcBsbgzwYQhoGiwrlas03agab7jf21RE67vQG1ICmMAZRIfp1
SsGMTokY3bcrEWxbWXFz6FYlgjh3a736aWL6YjZGN4dmr4wLQ2lfLC/+8o1h
NoSWjSa0VsGtzkDYlBRA0Y4t86OQhfQrc/Jfmi1XVWmAnXNjrJErJzMkGw8V
ObBKGvdnahb5kCqRptSFkHVqMeEN0CR6NtbmJaC7dCy9s/zj9WBbtncxvrRd
CUoeC9S+M7GrSgHruER9aVlg5Y4xt/AURtmoAd962FIY3pfujAXSGDm4MUUu
ceMucFYW2pZB5NdsGuES7iZZyaHGcaVNj1ijJoLKZntaRkLVce5ye7AWudkU
SNe39lQNKju6HRgGVKXvkqp9lYMGS8SGH4VxlWJLJ/IwO44YUokQ4am6uZGQ
teYAN+4lp5tKQ4i70mVTvbppra/rCrt1LPOKQorn8/uorQC405bXn4oIH64v
mkKYLkesPFS5nCpaBLzCrwJQ0/mvfONdpShBf2Pf12pETTxvTBU0oBsrFIVE
AOQzC3RM2wY5PEiAv5P2O8ozMmEZLLHNoXa8paz0ImdgL6ej06owrvZK56Fy
1bavFOHN6twOYGGAG5V7m40ZhD55C9DFozKfr5BxzQHgpDNiXeC6nnU0weJS
Qxk3XmChv208kexASADML0g+LVy8Mm5Mlufsh0ijqpmcQbcegchXoT9dudWj
qN7d/e1cHckHyw336v0926sYd+vbQS+8oIagHdRrK6pEnqELc90j7AbtTg7U
dpjY1ZKyEFmgaclA1EIxmte4thimSRHMHlzfA6mCeGBH6HxxtdiwltoyHmHl
Y9IDpWhVw1HprLsj0xiVc343zj9rGCHqCWjN3JZGohmuyiSbremoiOh3KQlm
W2EGWgiEk1oiGpxTbYf1IzPVxh5rjzQvBvOtFo6imX23ljHdbq9jWt/SQylN
ne0i2xoWb5JFZpTysTQwE0lgy9zfVr+5RhIpys6EYmfm8F1HjPt7IgWQmhDb
3no5LO7uqsS1LavmcMpWc8ACb0IP6uOzmCFWB9vyt5EzZkDiJqZGzFPLuChf
eFw1cFMs/LylcETtTRscRjiV7LE2z4wTotIyPOSgMfSDxxLYQTaEJ6M4s5pB
l30bkCKXp1/DGhMnW7N315vW5ZFtXt1S5ETlBn+nQPlXIyHRPhGubQuueQly
3yJxY9ILd7EvRSgHSsOUbTEdzRPW9LSOZfujCRrIdtX1X4eZb+I5YloHXv4X
IcAvs191Cw8ou69joWWHmat7RG/vin7fWlXjqH3C3t96vfaV+Iw9+KFbqf0E
SXnwUydu65/xCXpHUQaq0XeomTyQn/ffViXesvdamXhP0hyR6+gf1ejOHiYK
D2XQ7vh/hwr84F7rKho1L9ETIu9tnGuzScR/Q3hZG/jfLSARaD1uNgDcrOS0
J9gAl7Pfa02smMPbVm9eUCJRR7Pm11fQQ9DkxH0BVXi4oze8z8CzoNYZr0np
MFwDtOSH4S7cYfvi/Gar4bpdKbmuGRhghEB6Y0A8Hucr9KMr2wo7yru2rMgH
IuYD0pYXADwpphyEXSQk0eBDrmXZn36TH7lluFixVp2Elu7P38Cp1Uuw9lz1
VwPjqBN3FZc1tnDT0TCwPGl7GNQ9FgjrcVZ5G5q1kpqw1rY6tmW3PbylGnHT
0Xkd2mfzacdEbLxzs22T0ZIsqjsUKsIWI+pI7MskaEIH75a8fRSJ0Szcqm1z
vRFjbM7D9ZYMosOd6SQOG5q5JvC4N96x2ptbjoTCgDB0hoUy3v/NPB+RJU22
e/b+HOMHxGjM0iuLlflCe/JpkV/szly2N7fqrPAbdk6frgqyjzQ7qIcNi2yv
RS5v4DsX05Jk9di32HdaDLr5Bg0Hqb+xpLVoEWeUrL3xlyVKBFYy8WkxJfz9
NilmSeyaQt+mFRaxyGFXUZk7H90m3XHx2mAp1kSv6CRNR9/EJeIRYDHAjfYp
bu/DKnEbUidFP3BHYOqhyNhhxQiPnBQPsqqwEEQthkXW33k3vCOeqXWh5Imq
hRq1mSXtfevh6MEuVwW1uZSKz64CFrtfB/P0VlUOlm1tZR4xF6sKDaiQkNHO
1aZNTLFgE1cY+swxroaNw65uckImI6LvHzMxuMLNktqAwAQAPkizAfw1WKQT
bJAq9ZaN5gPY8TavxG1wRzAsNyVBU6X2lxc/DgWQpaZajTzHdp6JuTXqoklk
T5NmSEIfh8WfjepHpYy/KxJp6+pq8bvi4EEnXbHpkbHetzw1biM1y6lhloLq
tW29N7lzCBulXsFE5MlEBGQHuqserL2guBK6ic00AAnDD8bxHD93LcO4eRkp
VtJ8uhwnWVykuV+BO0qKbGRLeowgpfycwMV1t9S1pFZvvGZyKTF9yOJv48yX
29apUNlEVSsvYAnzezI5wpZSjd3XRgik2WpbYTSDEJSK+DxPblJYEm4yv8vQ
5iWBJnCvq4qKHClijzmR7zZPJxJ3FjrTMnWgKUY1KKbwUCkZruH5SMAEr+MF
BUBEN4BlS8rFkFauZJxFEQwJUlpNOa8sDqo0LfPcO9fq5gxmlnpAwfzSYTQt
jRNP2wnHtZeM4j+Kq/HMtDBxKDCjQlHiBWDTq0ptJTAAAkRz7DI9HhhX/Z6Z
JAN1SUaj/GZVciV7almXltWqGNmHPY8Z9rztD4MvKefyFoTXvCBSCGy/muWT
UqAY/h0DoeKujTmuv5xpKgyvreTQS0a+0icjCK/H9Edd5xYz0i3lpM5qjiYM
4kHWxpdmt/n8VqNqkuk0LyrPwt2JOqcOPE/YggL0qEjij3LQpUZCWsalu4SL
BRmxQl/sXd8wF6VkKoD7G1JhCRYtJ+DSIcyt476wCzUtT+wiBlpq8BXAfhDb
StITx0+7nuxM5uRU8drsGVee6xvNCivOYQDC2/Or6+e7u4Pvd48lNtPHVbgc
Yo0/VU8Tdlof64mpN9pU6q9I9g1Lzwc16psl+48ZWsfYFEz6jV5QEBoZdlKh
vzIDp1mhocincYZtCDhanFqDIwL4cG3Xa6CtHcHQcEQ2eGpN/Thjhx0VGys4
W9M2z849HOLf1jMKm1gSufLdygmTEAQx7uwfJD9gjIXkVus5iCRhuoGYJOvR
vQmcay90b/q2+l6aJLtUHPUglg8Ttk2+0vz44tsyrLEv+muNIruVUuUrBgAk
v4qJpebE8l3N6BDpYlkbwBjmkhIQXYp3CBRv4kJxNoQfTsItNX8A07epT83p
1cmFVYJMVwqfcOWAcKpJnej2GlPsAeof6MFaYSuQxhjUcIEd1zCIG6iIxeuK
gDSBa4JDvksnGJ69EgdyXHmpRiJuCCaAfEiXbhx2C3FrEc+3onHC+c5eDg32
v4g/1lYHdCRjjhud5lemvcYYoxl893Y4fDo05hBe0iLabiQz4m+LVExnKXX6
5qwMsTugLeJO24/AVlagUmVj36+ZaRJxheU8v4dxfrzAHm0gnqTOeSZd6DNJ
JLhxWeQqWwm9dXxRHeYjJOy+ZACZPfCkRETnzAkfj0xCtul7M0pIfCag3TTe
/7iSmW/SLHPV98Lk/cB3wgUIuEE8Pgwwnk7v9SJIR/El885e9H3DLrL3gBqO
8AmQszWNx2Ke26rVxuSZKs5Tch113TV+W3rhoEkLtK8uJddLJQRsqRsqlONZ
ApCEUEiqy6oK+jBjdInvtRc7EfPelOZWt3Ot7RGGGJUpYsHZCyk4Wty7Xdj8
Z1TlkgTTnIAEcwjs2QuRfP00bbDFGI0BApTLDPA1v7eAzX6lSQIH5aFpkQDB
um8yg7atNZrK4YiIir73CzvDUXFw4ShoE2wNZYg50TyZL7XdE5wYZm9YtJbm
X4TBoyRGswcCIIUDe1IhiqYHEwawMveKBYA4Q6AnPJ8/X748eb73fBekgckK
r/9+jEdCYT80rdv7L9sh7w2ZRWNfbD2r97sC1DtlQ4Sld6pLe12KOq+w7Cix
8C6o+4Fw9EAXFzNJ/Q3FFWedpBgpUZgbhoe4bNgRakHl2AJqaaRXCjktvhvP
U7wS7N+gPSlhEfwS6HrHrNhkquH2Odm+c7U2hfEOWMoArQXOIoOlBOCd81PT
YwAlMWprd2skajxapbyNd21Rz6rt6LzQZwLyvb/SWxealgWSfSYc+EZq2nFE
dnCQQpOYgh7JOVhWUp1FZopBlbkv09JYPYR3wKGhME3+v6q2khDhaxzXLY0C
I2/yjh3Iq5RFHc3yZV+juNRA6mvSkA6KZeVLUSCanS/QArIAolTMqWrsDLXq
iaC8PVaLGKmrfY7D+XpAJDEAbYFzu5fiu417rl1lqSWnfa2Jx/EaXIiFt+E0
6LDs9nzPM4qbo17Dnf5/tImQObQRNN1plP/FNn+UqwMnAklLwB84PjwaYyan
xEapXTSdKN0I5Os15vK4bFmzM7YzwBn7PCd9Onu6Rr0GdnXJAqNUV81OIKE9
J80Au42FRndgE8+e7e9JSDxpsqjHkoth7pVi5LkpW6Mp+JhINvUrTRmGxx8p
CU7ju0uMolCTEOvCA5XEotvVHJVaEQexv26eiuO2bit0pngKKQcRvUjE6KW6
WDs3IaMu0hfUiZK4ciZr3Bz3VCPBxN9EOwTh4QlTJWEUQ6+ZV8n16gAuaDVY
Ni50DkS07CssohlEausg0Rnso0jGvz7xlR+4ZpUEjmJkLwIAOy70ut2+ONI5
ws2ieEswqd0KYO1VeiOXhEWjEfzWyZBU00KbNddi9l1igItJDWuRNYz8DIy1
CFYdzTeeW2UKbbZ2kb/Bxq10JDs4Wqln7Y2371qBytwOQ9EdaxiWTwazJL4U
lPqg9Ba3qdQ/3+OOaaMh1AQ1q7EqRbUb1H65XAdExnN1Q9CYitIsGZ2cCdmw
CbftHc/dEMmxZ4aSkBWoHqihFn2RaUh1iS0IG/DGaNcYVDjUk2EjIl1RtSi9
5yKepKgTTVJQJSdergvOV0LWtRqcu2UG63awcPfvyra5AicuYzxdsOXHmxSN
ASFLbubpDR0ZrGMkVEZjGv0nVGEMg9HV/ICGSfoEB/d6rzr61GuEtVi0t/vj
sFGKCQ15qPp48gjodXQ2Sau8OIouOB+S3DtoTMYKDWNe3JjZ/VZr7MmWP2Uc
zu+1VWEOfa9oleGo2diKohmK0T7ZZBgXy5g/LJe0tjHcvk0HK1YoGnN6iTKi
J3vP9rVjOb279bQCQJ7RaFvsLiHPCXepRB/HJF+QCwnpNDASsuhJr1KxhqtN
lyRL84bEEAhKrkZz4/iKMYvw+iXGFmUTNIUOiMPhadHEx/3oGH6QdF9cX1Kb
h2JSW9+jBN/UAoVdMDTIWC1hwrWwHI4fLNlJPXAhxggLQjC3qGOZa77tE9c0
SVFz3BLt0LFjYttN2LJPD6ZrPDEdM4jvXGiVhpa9bIlpjQOlnXTnxoarPgJ8
iDktPBU30USj2G5lUuL3ajAmilYiQ/epF5qXWCULzbMmxcCkhGrDIljRaw4a
x4VxbA9bhdUBb+RtGzrNsMwxfGkYSd9zrQtkG8DZ5hPvFCX127UtVPWTHkJV
2gfttb8eRyNQGaf+XKT/iB3EBel1DUH1NVmh8FhS6+gaDNpHayyaTZJPcFml
Ug93d6mzpufLVY3hS4wYEYN17cgkIARoykIqdyEfgNFkKZQyYeA7LY+iU2fc
KcgVT3Y8ni8s9SFvabIWV91Ra8r+U46wNW2RpELhYP/wKe4M69fEFKpLgbNi
UblSMhIdj5moto7x9PDwCY0Coz0jGkafy9D4bevgwW1cMlWbNKa4QVlDrdtd
Y519wpgTGOQ2xeKltSEo6Izel6WScBwXH/ll0v6ASb1HgcsRK1+luJVWtTQO
+iegWs1NtRItC/mWam1MttbTLMcmw8zvDYjZX7jVkFuHQ782eiZVcGm71oFU
OpStz++JZJ3muQ4ga0n3mg5btt8NT4cqra+8pcvl5HRzRusPJCCnHcTQUlJf
oLHlYORVyQTVmhNUijgj9xysF83zmmIpjc8MQ6nVBDJtw/qO+jrC29kXiEQR
luEMpY8k0OR/FSLf7OL1P+T9n4e8b5isF9D87lS9fwLSv2l24tfwg38ydjBJ
45ssp9iRsXpafgkzaCG6jUOYrTAGEoB7QlYE3J+WrvfU+Ks3/L8wOexIBfkf
qvjPQBUfwRh0PEYDC9qgKCOdgYAj/+r+EdeIgYJbOcCsnjh1tsK4cso6h5P7
tox+2N/d30XydgNUccGKJkb5xgVGvDmBAgPW0I6fzPMl24HIrr9gOkm3wNYf
GAa/1YqRAIZv4RoPDp4f7mMZlpycx8eXb969v/wDffX82fPnB/6rlwO8AAzQ
oUqoyyTDiNy5+/7q4t31Fb357Mn+0yfPzZvJ5ODl+eXZ77vefHd6LEjkE1J9
+8LSF5mkMC4mAPZ8t6kK6nIGWijSPoqF2DnqncwKDKSDMz1elKuy7PeuQfic
Jml0gv7efu/VPF7BQcOlfEzwyyKPXsGkWZL1ez+mi+hqPIvjSb/35zyBw4uu
knmMR9nv/Xtcru5XH9PoGnjnx7jfu4hLvIfr2WoEINvv/ZTO52m8iP5C4Nzv
/Vt8iwziL+k8/ntewksw3SxfAFz8hAma9xkC6QBgdBSPPz4KuJ5xem6v9/kz
sMYPkq2L9cXn8xWBivBz13tALcZaV5Sd5EFwCpdIr3xMiLjcnJueYLFwUUc2
UwG/ozQc00vg4uoVMQkXBGAmcE48W/nI+Es4clv9AUzKuVM2ItGn+wHcZoI6
DLGmvmv0bWylM4yvtooO5Sswk3pfpIMf8Ht5H9dPY2Do1jq3Ie6z1RNZpDc3
tlhVEMPfumZeUy0OVGPWTRowhaFoeWEMN4QvqcKPSCWIxxSMrB1V4ZAruVkY
HskVFcRNONyfRDlTFU2n0T40nI1NlUFMyL6EfBifiPH24OtBVxPZBeU/zPP8
I5dWnPmUKr38oDytOdC6aU+OnEO0NVAWvQsUJaYMSpPDXEyCnqY2t+H+OSCe
OM83+pvTisLE1JLdbyZysP+npKhSDf7EeGYgSMwRuPktHudiRQJGcyMosfgT
uwgPLPAS0rHZcGBxXOG1WqncwILUJaKYPVyIlN/KFbgcNBAgpVXpwEaG1bDL
KfWkkAlobDbzB0Aa+jRtyR+4WvVJhtEhMLUPV+E4DqeUmzY0vC14WMKftoP8
+51659xlfD/PY91dsCoK4gg6wYSUBfbEsCNBR807D5Md2Y/tU360fws5WHxC
hKkTXF+R2786ftdgYxgZmWRauI08JT5jkUTqAXuKjLgr3URsXnoU/REY0tn+
mWwB+cgJR0/RDxEo+u2KQqt6Fzw3/8CF6G+XJz3MAjbZwyYXmP6kXUddD0Wk
wB1Fu0NsJXDx7up6p8eZ7HwxXa9dIyweRQN4+PcD/fmX+sOWzmKqcbzsXq3+
orzgKDJusIdfi+Qkj5BuwcL6m7yiP/DKB6EQR8Jvvur9CxY9o/O/HEV7G7x4
wYhyFH1uHv9XTczHdRFXs6No6+9bX/kucpEPjjn88Tq++Zfoy0PwZL5pAa0u
eDKvtYGWwlO+jDFSiIhg+F47lP3Pnf9X33n3N2ugYX+4exBtn3AgaAtACEn+
KoD4+Y8OIn7vP1WAGPySGwmX+ZUHG7DG3+BkN6PbLSfbdpwdpLv9DFvw65/g
OC17xRojRhHTyhaipklG5IPKGGxkOBxGf/3iOkyFSWE+HFfXp89RpE+jpcFw
CzYASwPCgRL7IJ6DAvunrTFmMRVb3KKw8AFbiqW+KN5RKETYh456n0lhOoyO
otm343iafBt9F2HTUR8g7bJtXDSv1C+SABU6hu96X8IKOj40EeO6wyrGHO1M
MqBWvufSJfQoRuKw+Zl6M25p3laaaJXhtm1yCT6yHs6+jfd2Dw/2eTsS7VSm
/6ChD7kJDrrXJHN63F5esXZqwVN6bPtwbP9hoO+7tppU3/kqRNFe3z8qPV7s
17Nvk6ej6cH+82fj/cmzp3vPJ0/j758+f3ZwcDidTp48SZ5+Ky+ykdi/+zdW
np80FtSohBnOF0+/f/ItPdgRYmam6L7itg4/4T27sn7dpcYsILgqYFu2X7vr
0hzCBK+jvZ9RbRWoMMi5p41q2rv9tc26anO6GPXSHUNrudb2c2hcy9pTaNbQ
b+BEKxR7pOj14K73d/ef7+/uHe4+BGW7T57vHewzbNTwZ/+pQ6BHsIi9xvyY
u4SyZMJeM9E7dl98/mbun/lCraaS7DYt8kyKkBIxROPMIv2HBlqGBa9AU8wr
LH+gKaFclKO1Sp7L8mpG+7kMZ5PNntb648CB/fDq9CW7Bw6fP/1eQsevfjjm
zw72n2A4OZWj8l40yekf9uhlfQGN6eSjMSGkXck4tjrJjMoL14uWUDVF7WRE
HRp9fDJnStjaBLyiPi50lMzi+bS9UIlZWfC6rKFZ7k97KHXtwxSDxe3fFdhi
InNtk3xSdbAOn33OgYuuRcfVK85O9qVt2kOxbU4C3QFZN3Cpm6y0xYKlGfXW
2kr1L27yfNJWyKbv6qZLGkSt9wWb3cPcdY2+vY0Lqph+3YRZv7QgKQTunusD
wRqJ4MukzQwQNt/i0kxBIO6ZhVlZtXN8qVZkquVEpmU4DDxY9B+R97Cv+BN3
TiqFh1eYjEPGDtcWwMZhN0oktVTf+hKkI3TX11j4wgZhZQ1/U1xiYyjEN6yA
gcfOw+HIedaopHFH0S5aQqNqGSIsoiHNLXx+aEhovuN8YyJUpZinV5jyjxvC
spB9B/7OfoVmZvG1KlZR+Qh18Sg0tSbgUSAyHaDfpqtnRfxNVoGgKceHCEJ5
y1QN2nYmiF3NHK0WI2ScQMrLnY2SVBYGW8qZcOdervuNKSRk5sXMH98twq2e
2wDYAjGm13ELIeT8Dr5HW9JiPvdww3uSC+z9/9dELDWhogEA
<section anchor="acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The work on this document has been partially supported by the
European Union's H2020 Programme for research, technological development and
demonstration under grant agreements: No. 644852, project ARMOUR;
No. 687884, project F-Interop and open-call project SPOTS;
No. 732638, project Fed4FIRE+ and open-call project SODA.</t>
<t>The following individuals provided input to this document (in alphabeti
c order):
<contact fullname="Christian Amsüss"/>,
<contact fullname="Tengfei Chang"/>,
<contact fullname="Roman Danyliw"/>,
<contact fullname="Linda Dunbar"/>,
<contact fullname="Vijay Gurbani"/>,
<contact fullname="Klaus Hartke"/>,
<contact fullname="Barry Leiba"/>,
<contact fullname="Benjamin Kaduk"/>,
<contact fullname="Tero Kivinen"/>,
<contact fullname="Mirja Kühlewind"/>,
<contact fullname="John Mattsson"/>,
<contact fullname="Hilarie Orman"/>,
<contact fullname="Alvaro Retana"/>,
<contact fullname="Adam Roach"/>,
<contact fullname="Jim Schaad"/>,
<contact fullname="Göran Selander"/>,
<contact fullname="Yasuyuki Tanaka"/>,
<contact fullname="Pascal Thubert"/>,
<contact fullname="William Vignat"/>,
<contact fullname="Xavier Vilajosana"/>,
<contact fullname="Éric Vyncke"/>, and
<contact fullname="Thomas Watteyne"/>.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 206 change blocks. 
2689 lines changed or deleted 2119 lines changed or added

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