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" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.12 --> nsus="true" docName="draft-ietf-6tisch-minimal-security-15" indexInclude="true"
ipr="trust200902" number="9031" prepTime="2021-05-29T09:15:10" scripts="Common,L
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ atin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="2" tocInclu
<!ENTITY RFC7554 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere de="true" xml:lang="en">
nce.RFC.7554.xml"> <link href="https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-securit
<!ENTITY RFC8180 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere y-15" rel="prev"/>
nce.RFC.8180.xml"> <link href="https://dx.doi.org/10.17487/rfc9031" rel="alternate"/>
<!ENTITY RFC8613 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <link href="urn:issn:2070-1721" rel="alternate"/>
nce.RFC.8613.xml">
<!ENTITY RFC7252 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.7252.xml">
<!ENTITY RFC7049 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.7049.xml">
<!ENTITY RFC8152 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8152.xml">
<!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">
<front> <front>
<title>Constrained Join Protocol (CoJP) for 6TiSCH</title> <title abbrev="CoJP for 6TiSCH">Constrained Join Protocol (CoJP) for 6TiSCH<
/title>
<author initials="M." surname="Vucinic" fullname="Malisa Vucinic" role="edit <seriesInfo name="RFC" value="9031" stream="IETF"/>
or"> <author initials="M." surname="Vučinić" fullname="Mališa Vučinić" role="edit
<organization>Inria</organization> or">
<organization showOnFrontPage="true">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 showOnFrontPage="true">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 showOnFrontPage="true">University of California Berkeley</or ganization>
<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 showOnFrontPage="true">Sandelman Software Works</organizatio n>
<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 month="05" year="2021"/>
<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>
<abstract> <keyword>oscore</keyword>
<abstract pn="section-abstract">
<t>This document describes the minimal framework required for a new device, call <t indent="0" pn="section-abstract-1">This document describes the minimal
ed "pledge", to securely join a 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4 framework required for
e) network. a new device, called a "pledge", to securely join a 6TiSCH (IPv6 over
The framework requires that the pledge and the JRC (join registrar/coordinator, the Time-Slotted Channel Hopping mode of IEEE 802.15.4) network.
a central entity), share a symmetric key. The framework requires that the pledge and the JRC (Join Registrar/Coordinator,
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>
<boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
>
<t indent="0" pn="section-boilerplate.1-1">
This is an Internet Standards Track document.
</t>
<t indent="0" pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
</t>
<t indent="0" pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc9031" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t indent="0" pn="section-boilerplate.2-1">
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t indent="0" pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-introduction">
Introduction</xref></t>
</li>
<li pn="section-toc.1-1.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref der
ivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-terminology">T
erminology</xref></t>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref der
ivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-provisioning-p
hase">Provisioning Phase</xref></t>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-join-process-overview">Join Proces
s Overview</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.4.2">
<li pn="section-toc.1-1.4.2.1">
<t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent=
"4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-step-1-enhanced-beacon
">Step 1 - Enhanced Beacon</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2">
<t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent=
"4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-step-2-neighbor-discov
ery">Step 2 - Neighbor Discovery</xref></t>
</li>
<li pn="section-toc.1-1.4.2.3">
<t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent=
"4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-step-3-constrained-joi
n-pro">Step 3 - Constrained Join Protocol (CoJP) Execution</xref></t>
</li>
<li pn="section-toc.1-1.4.2.4">
<t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent=
"4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-the-special-case-of-th
e-6lb">The Special Case of the 6LBR Pledge Joining</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-link-layer-configuration">Link-Lay
er Configuration</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.5.2">
<li pn="section-toc.1-1.5.2.1">
<t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent=
"5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-distribution-of-time">
Distribution of Time</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-network-layer-configuration">Netwo
rk-Layer Configuration</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent=
"6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-identification-of-unau
thent">Identification of Unauthenticated Traffic</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-application-layer-configura">Appli
cation-Layer Configuration</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.7.2">
<li pn="section-toc.1-1.7.2.1">
<t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent=
"7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-statelessness-of-the-j
p">Statelessness of the JP</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2">
<t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent=
"7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-recommended-settings">
Recommended Settings</xref></t>
</li>
<li pn="section-toc.1-1.7.2.3">
<t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent=
"7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-oscore">OSCORE</xref><
/t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-constrained-join-protocol-c">Const
rained Join Protocol (CoJP)</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.8.2">
<li pn="section-toc.1-1.8.2.1">
<t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent=
"8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-join-exchange">Join Ex
change</xref></t>
</li>
<li pn="section-toc.1-1.8.2.2">
<t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent=
"8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-parameter-update-excha
nge">Parameter Update Exchange</xref></t>
</li>
<li pn="section-toc.1-1.8.2.3">
<t indent="0" pn="section-toc.1-1.8.2.3.1"><xref derivedContent=
"8.3" format="counter" sectionFormat="of" target="section-8.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-error-handling">Error
Handling</xref></t>
</li>
<li pn="section-toc.1-1.8.2.4">
<t indent="0" pn="section-toc.1-1.8.2.4.1"><xref derivedContent=
"8.4" format="counter" sectionFormat="of" target="section-8.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-cojp-objects">CoJP Obj
ects</xref></t>
</li>
<li pn="section-toc.1-1.8.2.5">
<t indent="0" pn="section-toc.1-1.8.2.5.1"><xref derivedContent=
"8.5" format="counter" sectionFormat="of" target="section-8.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-recommended-settings-2
">Recommended Settings</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" form
at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-security-considerations">Security
Considerations</xref></t>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" fo
rmat="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-privacy-considerations">Privacy
Considerations</xref></t>
</li>
<li pn="section-toc.1-1.11">
<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" fo
rmat="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-iana-considerations">IANA Consid
erations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.11.2">
<li pn="section-toc.1-1.11.2.1">
<t indent="0" pn="section-toc.1-1.11.2.1.1"><xref derivedContent
="11.1" format="counter" sectionFormat="of" target="section-11.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-constrained-join-pr
otocol-co">Constrained Join Protocol (CoJP) Parameters</xref></t>
</li>
<li pn="section-toc.1-1.11.2.2">
<t indent="0" pn="section-toc.1-1.11.2.2.1"><xref derivedContent
="11.2" format="counter" sectionFormat="of" target="section-11.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-constrained-join-pr
otocol-coj">Constrained Join Protocol (CoJP) Key Usage</xref></t>
</li>
<li pn="section-toc.1-1.11.2.3">
<t indent="0" pn="section-toc.1-1.11.2.3.1"><xref derivedContent
="11.3" format="counter" sectionFormat="of" target="section-11.3"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-constrained-join-pr
otocol-cojp">Constrained Join Protocol (CoJP) Unsupported Configuration Codes</x
ref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.12">
<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" fo
rmat="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-references">References</xref></t
>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.12.2">
<li pn="section-toc.1-1.12.2.1">
<t indent="0" pn="section-toc.1-1.12.2.1.1"><xref derivedContent
="12.1" format="counter" sectionFormat="of" target="section-12.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-normative-reference
s">Normative References</xref></t>
</li>
<li pn="section-toc.1-1.12.2.2">
<t indent="0" pn="section-toc.1-1.12.2.2.1"><xref derivedContent
="12.2" format="counter" sectionFormat="of" target="section-12.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-informative-referen
ces">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.13">
<t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="Append
ix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-example">Exampl
e</xref></t>
</li>
<li pn="section-toc.1-1.14">
<t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="Append
ix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-lightweight-imp
lementation-">Lightweight Implementation Option</xref></t>
</li>
<li pn="section-toc.1-1.15">
<t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgment
s</xref></t>
</li>
<li pn="section-toc.1-1.16">
<t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
resses</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="include" removeInRFC="fa
<!-- ====================================================================== --> lse" pn="section-1">
<name slugifiedName="name-introduction">Introduction</name>
<section anchor="introduction" title="Introduction"> <t indent="0" pn="section-1-1">This document defines a "secure join" solut
ion for a new device,
<t>This document defines a "secure join" solution for a new device, called "pled called a "pledge", to securely join a 6TiSCH network.
ge", to securely join a 6TiSCH network. The term "secure join" refers to network access authentication, authorization,
The term "secure join" refers to network access authentication, authorization an and parameter distribution as defined in <xref target="RFC9030" format="default"
d parameter distribution, as defined in <xref target="I-D.ietf-6tisch-architectu sectionFormat="of" derivedContent="RFC9030"/>.
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 indent="0" pn="section-1-2">This document presumes a 6TiSCH network as
<t>This document presumes a 6TiSCH network as described by described by
<xref target="RFC7554"/> and <xref target="RFC7554" format="default" sectionFormat="of" derivedContent="R
<xref target="RFC8180"/>. FC7554"/> and
By design, nodes in a 6TiSCH network <xref target="RFC7554"/> have their radio t <xref target="RFC8180" format="default" sectionFormat="of" derivedContent="R
urned off most of the time, to conserve energy. FC8180"/>.
As a consequence, the link used by a new device for joining the network has limi By design, nodes in a 6TiSCH network <xref target="RFC7554" format="default" sec
ted bandwidth <xref target="RFC8180"/>. tionFormat="of" derivedContent="RFC7554"/>
have their radio turned off most of the time in order to conserve energy.
As a consequence, the link used by a new device for joining the network has limi
ted bandwidth <xref target="RFC8180" format="default" sectionFormat="of" derived
Content="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 indent="0" pn="section-1-3">The microcontrollers at the heart of 6TiSCH
<t>The micro-controllers at the heart of 6TiSCH nodes have a small amount of cod nodes have small
e memory. amounts of code 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" sectionFormat="of" derivedContent="
to-end security. RFC7252"/> for web transfer and
on OSCORE <xref target="RFC8613" format="default" sectionFormat="of" derivedCont
ent="RFC8613"/> 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 indent="0" pn="section-1-4">CoJP is a generic protocol that can be used
<t>CoJP is a generic protocol that can be used as-is in all modes of IEEE Std 80 as-is in all modes
2.15.4 <xref target="IEEE802.15.4"/>, including the Time-Slotted Channel Hopping of IEEE Std 802.15.4 <xref target="IEEE802.15.4" format="default" sectionFormat=
(TSCH) mode 6TiSCH is based on. "of" derivedContent="IEEE802.15.4"/>, including
CoJP may as well be used in other (low-power) networking technologies where effi the Time-Slotted Channel Hopping (TSCH) mode on which 6TiSCH is based.
ciency in terms of communication overhead and code footprint is important. CoJP may also be used in other (low-power) networking technologies where
In such a case, it may be necessary to define configuration parameters specific efficiency in terms of communication overhead and code footprint is important.
to the technology in question, through companion documents. In such a case, it may be necessary to define through companion documents
The overall process described in <xref target="join-process-overview"/> and the the configuration parameters specific to the technology in question.
configuration of the stack is specific to 6TiSCH.</t> The overall process is described in <xref target="join-process-overview" format=
"default" sectionFormat="of" derivedContent="Section 4"/>,
<t>CoJP assumes the presence of a Join Registrar/Coordinator (JRC), a central en and the configuration of the stack is specific to 6TiSCH.</t>
tity. <t indent="0" pn="section-1-5">CoJP assumes the presence of a Join Registr
ar/Coordinator (JRC), a central entity.
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 indent="0" pn="section-1-6">When the pledge seeks admission to a 6TiSCH
<t>When the pledge seeks admission to a 6TiSCH network, it first synchronizes to network, it first
it, by initiating the passive scan defined in <xref target="IEEE802.15.4"/>. synchronizes to it by initiating the passive scan defined in
The pledge then exchanges CoJP messages with the JRC; for this end-to-end commun <xref target="IEEE802.15.4" format="default" sectionFormat="of" derivedContent="
ication to happen, messages are forwarded by nodes already part of the 6TiSCH ne IEEE802.15.4"/>.
twork, called Join Proxies. The pledge then exchanges CoJP messages with the JRC; for this end-to-end
The messages exchanged allow the JRC and the pledge to mutually authenticate, ba communication to happen, the messages are forwarded by nodes, called Join Proxie
sed on the properties provided by OSCORE. s,
They also allow the JRC to configure the pledge with link-layer keying material, that are already part of the 6TiSCH network.
short identifier and other parameters. The messages exchanged allow the JRC and the pledge to mutually
After this secure join process successfully completes, the joined node can inter authenticate based on the properties provided by OSCORE.
act with its neighbors to request additional bandwidth using the 6top Protocol < They also allow the JRC to configure the pledge with link-layer
xref target="RFC8480"/> and start sending application traffic.</t> keying material, a short identifier, and other parameters.
After this secure join process successfully completes, the joined node
<!-- ====================================================================== --> can interact with its neighbors to request additional bandwidth using
the 6TiSCH Operation Sublayer (6top) Protocol <xref target="RFC8480" format="def
</section> ault" sectionFormat="of" derivedContent="RFC8480"/>
<section anchor="terminology" title="Terminology"> and can start sending application traffic.</t>
</section>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", <section anchor="terminology" numbered="true" toc="include" removeInRFC="fal
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this d se" pn="section-2">
ocument are to be interpreted as described in BCP14 <xref target="RFC2119"/> <xr <name slugifiedName="name-terminology">Terminology</name>
ef target="RFC8174"/> when, and only when, they appear in all capitals, as shown <t indent="0" pn="section-2-1">
here.</t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
<t>The reader is expected to be familiar with the terms and concepts defined in ",
<xref target="I-D.ietf-6tisch-architecture"/>, "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
<xref target="RFC7252"/>, "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
<xref target="RFC8613"/>, and "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
<xref target="RFC8152"/>.</t> be
interpreted as described in BCP 14 <xref target="RFC2119" format="default" s
<t>The specification also includes a set of informative specifications using the ectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="defa
Concise data definition language (CDDL) <xref target="I-D.ietf-cbor-cddl"/>.</t ult" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they app
> ear in all capitals, as
shown here.
<t>The following terms defined in <xref target="I-D.ietf-6tisch-architecture"/> </t>
are used extensively throughout this document:</t> <t indent="0" pn="section-2-2">The reader is expected to be familiar with
the terms and concepts defined in
<t><list style="symbols"> <xref target="RFC9030" format="default" sectionFormat="of" derivedContent="R
<t>pledge</t> FC9030"/>,
<t>joined node</t> <xref target="RFC7252" format="default" sectionFormat="of" derivedContent="R
<t>join proxy (JP)</t> FC7252"/>,
<t>join registrar/coordinator (JRC)</t> <xref target="RFC8613" format="default" sectionFormat="of" derivedContent="R
<t>enhanced beacon (EB)</t> FC8613"/>, and
<t>join protocol</t> <xref target="RFC8152" format="default" sectionFormat="of" derivedContent="R
<t>join process</t> FC8152"/>.</t>
</list></t> <t indent="0" pn="section-2-3">The specification also includes a set of in
formative specifications using the Concise Data Definition Language (CDDL) <xref
<t>The following terms defined in <xref target="RFC8505"/> are also used through target="RFC8610" format="default" sectionFormat="of" derivedContent="RFC8610"/>
out this document:</t> .</t>
<t indent="0" pn="section-2-4">The following terms defined in <xref target
<t><list style="symbols"> ="RFC9030" format="default" sectionFormat="of" derivedContent="RFC9030"/>
<t>6LoWPAN Border Router (6LBR)</t> are used extensively throughout this document:</t>
<t>6LoWPAN Node (6LN)</t> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2-5
</list></t> ">
<li pn="section-2-5.1">pledge</li>
<t>The term "6LBR" is used interchangeably with the term "DODAG root" defined in <li pn="section-2-5.2">joined node</li>
<xref target="RFC6550"/>, on the assumption that the two entities are co-locate <li pn="section-2-5.3">Join Proxy (JP)</li>
d, as recommended by <xref target="I-D.ietf-6tisch-architecture"/>.</t> <li pn="section-2-5.4">Join Registrar/Coordinator (JRC)</li>
<li pn="section-2-5.5">Enhanced Beacon (EB)</li>
<t>The term "pledge", as used throughout the document, explicitly denotes non-6L <li pn="section-2-5.6">join protocol</li>
BR devices attempting to join the network using their IEEE Std 802.15.4 network <li pn="section-2-5.7">join process</li>
interface. </ul>
<t indent="0" pn="section-2-6">The following terms defined in <xref target
="RFC8505" format="default" sectionFormat="of" derivedContent="RFC8505"/> are al
so used throughout this document:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2-7
">
<li pn="section-2-7.1">6LoWPAN Border Router (6LBR)</li>
<li pn="section-2-7.2">6LoWPAN Node (6LN)</li>
</ul>
<t indent="0" pn="section-2-8">The term "6LBR" is used interchangeably wit
h the term "DODAG root"
defined in <xref target="RFC6550" format="default" sectionFormat="of" derivedCon
tent="RFC6550"/> on the assumption that
the two entities are co-located, as recommended by
<xref target="RFC9030" format="default" sectionFormat="of" derivedContent="RFC90
30"/>.</t>
<t indent="0" pn="section-2-9">The term "pledge", as used throughout the d
ocument, explicitly denotes non-6LBR devices attempting to join the network usin
g their IEEE Std 802.15.4 network 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 indent="0" pn="section-2-10">In addition, we use generic terms "pledge
<t>In addition, we use generic terms "pledge identifier" and "network identifier identifier" and "network identifier".
". See <xref target="provisioning" format="default" sectionFormat="of" derivedConte
See <xref target="provisioning"/>.</t> nt="Section 3"/>.</t>
</section>
<!-- ====================================================================== --> <section anchor="provisioning" numbered="true" toc="include" removeInRFC="fa
lse" pn="section-3">
</section> <name slugifiedName="name-provisioning-phase">Provisioning Phase</name>
<section anchor="provisioning" title="Provisioning Phase"> <t indent="0" pn="section-3-1">The (6LBR) pledge is provisioned with certa
in parameters before attempting to join the network, and the same parameters are
<t>The (6LBR) pledge is provisioned with certain parameters before attempting to provisioned to the JRC.
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 indent="0" pn="section-3-2">Details of how this provisioning is done ar
<t>Details of how this provisioning is done is out of scope of this document. e out of scope of this document.
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 indent="0" pn="section-3-3">Parameters that are provisioned to the (6LB
<t>Parameters that are provisioned to the (6LBR) pledge include:</t> R) pledge include:</t>
<dl spacing="normal" indent="3" newline="false" pn="section-3-4">
<t><list style="symbols"> <dt pn="section-3-4.1">pledge identifier:</dt>
<t>pledge identifier. <dd pn="section-3-4.2">The pledge identifier identifies the (6LBR) pledg
The pledge identifier identifies the (6LBR) pledge. e.
The pledge identifier MUST be unique in the set of all pledge identifiers manage The pledge identifier <bcp14>MUST</bcp14> be unique in the set of all pledge ide
d by a JRC. ntifiers managed by a JRC.
The pledge identifier uniqueness is an important security requirement, as discus The pledge identifier uniqueness is an important security requirement,
sed in <xref target="sec_considerations"/>. as discussed in <xref target="sec_considerations" format="default" sectionFormat
The pledge identifier is typically the globally unique 64-bit Extended Unique Id ="of" derivedContent="Section 9"/>.
entifier (EUI-64) of the IEEE Std 802.15.4 device, in which case it is provision The pledge identifier is typically the globally unique 64-bit Extended
ed by the hardware manufacturer. Unique Identifier (EUI-64) of the IEEE Std 802.15.4 device, in which
The pledge identifier is used to generate the IPv6 addresses of the (6LBR) pledg case it is provisioned by the hardware manufacturer. The pledge
e and to identify it during the execution of the join protocol. identifier is used to generate the IPv6 addresses of the (6LBR)
Depending on the configuration, the pledge identifier may also be used after the pledge and to identify it during the execution of the join protocol.
join process to identify the joined node. Depending on the configuration, the pledge identifier may also be
For privacy reasons (see <xref target="privacy_considerations"/>), it is possibl used after the join process to identify the joined node.
e to use a pledge identifier different from the EUI-64. For privacy reasons (see <xref target="privacy_considerations" format="default"
For example, a pledge identifier may be a random byte string, but care needs to sectionFormat="of" derivedContent="Section 10"/>),
be taken that such a string meets the uniqueness requirement.</t> it is possible to use a pledge identifier different from the EUI-64.
<t>Pre-Shared Key (PSK). For example, a pledge identifier may be a random byte string,
A symmetric cryptographic key shared between the (6LBR) pledge and the JRC. but care needs to be taken that such a string meets the uniqueness requirement.<
To look up the PSK for a given pledge, the JRC additionally needs to store the c /dd>
orresponding pledge identifier. <dt pn="section-3-4.3">Pre-Shared Key (PSK):</dt>
Each (6LBR) pledge MUST be provisioned with a unique PSK. <dd pn="section-3-4.4">A symmetric cryptographic key shared between the
The PSK MUST be a cryptographically strong key, with at least 128 bits of entrop (6LBR) pledge and the JRC.
y, indistinguishable by feasible computation from a random uniform string of the To look up the PSK for a given pledge, the JRC additionally needs to store
same length. the corresponding pledge identifier.
Each (6LBR) pledge <bcp14>MUST</bcp14> be provisioned with a unique PSK.
The PSK <bcp14>MUST</bcp14> be a cryptographically strong key, with at
least 128 bits of entropy, indistinguishable by feasible computation
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" sectionFormat="of" derivedCon
In case of device re-commissioning to a new owner, the PSK MUST be changed. tent="Section 9"/>.
Note that the PSK is different from the link-layer keys K1 and K2 specified in < In the case of recommissioning a device to a new owner, the PSK <bcp14>MUST</bcp
xref target="RFC8180"/>. 14> be changed.
The PSK is a long-term secret used to protect the execution of the secure join p Note that the PSK is different from the link-layer keys K1 and K2
rotocol specified in this document whose one output are link-layer keys.</t> specified in <xref target="RFC8180" format="default" sectionFormat="of" derivedC
<t>Optionally, a network identifier. ontent="RFC8180"/>.
The network identifier identifies the 6TiSCH network. The PSK is a long-term secret used to protect the execution of the secure
The network identifier MUST be carried within Enhanced Beacon (EB) frames. join protocol specified in this document; the link-layer keys are transported as
Typically, the 16-bit Personal Area Network Identifier (PAN ID) defined in <xref part of the secure join protocol.</dd>
target="IEEE802.15.4"/> is used as the network identifier. <dt pn="section-3-4.5">Optionally, a network identifier:</dt>
However, PAN ID is not considered a stable network identifier as it may change d <dd pn="section-3-4.6">The network identifier identifies the 6TiSCH netw
uring network lifetime if a collision with another network is detected. ork.
Companion documents can specify the use of a different network identifier for jo The network identifier <bcp14>MUST</bcp14> be carried within Enhanced Beacon (EB
in purposes, but this is out of scope of this specification. ) frames.
Provisioning the network identifier to a pledge is RECOMMENDED. Typically, the 16-bit Personal Area Network Identifier (PAN ID)
However, due to operational constraints, the network identifier may not be known defined in <xref target="IEEE802.15.4" format="default" sectionFormat="of" deriv
at the time when the provisioning is done. edContent="IEEE802.15.4"/> is used as the network identifier.
In case this parameter is not provisioned to the pledge, the pledge attempts to However, PAN ID is not considered a stable network identifier as it may change d
join one advertised network at a time, which significantly prolongs the join pro uring network
cess. lifetime if a collision with another network is detected.
This parameter MUST be provisioned to the 6LBR pledge.</t> Companion documents can specify the use of a different network identifier for jo
<t>Optionally, any non-default algorithms. in purposes,
The default algorithms are specified in <xref target="mti_algos"/>. but this is out of scope of this specification.
When algorithm identifiers are not provisioned, the use of these default algorit Provisioning the network identifier to a pledge is <bcp14>RECOMMENDED</bcp14>.
hms is implied.</t> However, due to operational constraints, the network identifier may not be
</list></t> known at the time of provisioning.
If this parameter is not provisioned to the pledge, the pledge
<t>Additionally, the 6LBR pledge that is not co-located with the JRC needs to be will attempt to join one advertised network at a time, which significantly prolo
provisioned with:</t> ngs the join process.
This parameter <bcp14>MUST</bcp14> be provisioned to the 6LBR pledge.</dd>
<t><list style="symbols"> <dt pn="section-3-4.7">Optionally, any non-default algorithms:</dt>
<t>Global IPv6 address of the JRC. <dd pn="section-3-4.8">The default algorithms are specified in <xref tar
This address is used by the 6LBR pledge to address the JRC during the join proce get="mti_algos" format="default" sectionFormat="of" derivedContent="Section 7.3.
ss. 3"/>.
The 6LBR pledge may also obtain the IPv6 address of the JRC through other availa When algorithm identifiers are not provisioned, the use of these default algorit
ble mechanisms, such as DHCPv6 <xref target="RFC8415"/>, GRASP <xref target="I-D hms is implied.</dd>
.ietf-anima-grasp"/>, mDNS <xref target="RFC6762"/>, the use of which is out of </dl>
scope of this document. <t indent="0" pn="section-3-5">Additionally, the 6LBR pledge that is not c
Pledges do not need to be provisioned with this address as they discover it dyna o-located
mically through CoJP.</t> with the JRC needs to be provisioned with the following:</t>
</list></t> <dl spacing="normal" indent="3" newline="false" pn="section-3-6">
<dt pn="section-3-6.1">Global IPv6 address of the JRC:</dt>
<!-- ====================================================================== --> <dd pn="section-3-6.2">This address is used by the 6LBR pledge to addres
s the JRC during the join process.
</section> The 6LBR pledge may also obtain the IPv6 address of the JRC through other availa
<section anchor="join-process-overview" title="Join Process Overview"> ble
mechanisms, such as DHCPv6 <xref target="RFC8415" format="default" sectionFormat
<t>This section describes the steps taken by a pledge in a 6TiSCH network. ="of" derivedContent="RFC8415"/>,
Generic Autonomic Signaling Protocol (GRASP) <xref target="RFC8990" format="defa
ult" sectionFormat="of" derivedContent="RFC8990"/>,
or Multicast DNS (mDNS) <xref target="RFC6762" format="default" sectionFormat="o
f" derivedContent="RFC6762"/>;
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 anchor="join-process-overview" numbered="true" toc="include" remove
InRFC="false" pn="section-4">
<name slugifiedName="name-join-process-overview">Join Process Overview</na
me>
<t indent="0" pn="section-4-1">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" indent="adaptive" start="1" pn="section-4-2"
<t><list style="numbers"> >
<t>The pledge listens for an Enhanced Beacon (EB) frame <xref target="IEEE802. <li pn="section-4-2.1" derivedCounter="1.">The pledge listens for an Enh
15.4"/>. anced Beacon (EB) frame <xref target="IEEE802.15.4" format="default" sectionForm
This frame provides network synchronization information, and tells the device wh at="of" derivedContent="IEEE802.15.4"/>.
en it can send a frame to the node sending the beacons, which acts as a Join Pro This frame provides network synchronization information,
xy (JP) for the pledge, and when it can expect to receive a frame. telling the device when it can send a frame to the node
The Enhanced Beacon provides the link-layer address of the JP and it may also pr sending the beacons, which acts as a Join Proxy (JP) for the pledge,
ovide its link-local IPv6 address.</t> and when it can expect to receive a frame.
<t>The pledge configures its link-local IPv6 address and advertises it to the The EB provides the link-layer address of the JP,
JP using Neighbor Discovery. and it may also provide its link-local IPv6 address.</li>
The advertisement step may be omitted if the link-local address has been derived <li pn="section-4-2.2" derivedCounter="2.">The pledge configures its lin
from a known unique interface identifier, such as an EUI-64 address.</t> k-local IPv6 address and advertises it to the JP using Neighbor Discovery.
<t>The pledge sends a Join Request to the JP in order to securely identify its The advertisement step may be omitted if the link-local address has been derived
elf to the network. from a known unique interface identifier, such as an EUI-64 address.</li>
The Join Request is forwarded to the JRC.</t> <li pn="section-4-2.3" derivedCounter="3.">The pledge sends a Join Reque
<t>In case of successful processing of the request, the pledge receives a Join st to the JP in order to securely identify itself to the network.
Response from the JRC (via the JP). The Join Request is forwarded to the JRC.</li>
The Join Response contains configuration parameters necessary for the pledge to <li pn="section-4-2.4" derivedCounter="4.">In the case of successful pro
join the network.</t> cessing of the request, the pledge receives a Join Response from the JRC (via th
</list></t> e JP).
The Join Response contains configuration parameters necessary for the pledge to
<t>From the pledge's perspective, joining is a local phenomenon &#8211; the pled join the network.</li>
ge only interacts with the JP, and it needs not know how far it is from the 6LBR </ol>
, or how to route to the JRC. <t indent="0" pn="section-4-3">From the pledge's perspective, joining is a
local phenomenon --
the pledge only interacts with the JP, and it needs not know how far it
is from the 6LBR 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 indent="0" pn="section-4-4">The join process is shown as a transaction
<t>The join process is shown as a transaction diagram in <xref target="fig_overv diagram in <xref target="fig_overview_diagram" format="default" sectionFormat="o
iew_diagram"/>:</t> f" derivedContent="Figure 1"/>:</t>
<figure anchor="fig_overview_diagram" align="left" suppress-title="false"
<figure title="Overview of a successful join process." anchor="fig_overview_diag pn="figure-1">
ram"><artwork align="center"><![CDATA[ <name slugifiedName="name-overview-of-a-successful-jo">Overview of a suc
cessful join process.</name>
<artwork align="center" name="" type="" alt="" pn="section-4-5.1">
+--------+ +-------+ +--------+ +--------+ +-------+ +--------+
| pledge | | JP | | JRC | | pledge | | JP | | JRC |
| | | | | | | | | | | |
+--------+ +-------+ +--------+ +--------+ +-------+ +--------+
| | | | | |
|<---Enhanced Beacon (1)---| | |&lt;---Enhanced Beacon (1)---| |
| | | | | |
|<-Neighbor Discovery (2)-&gt;| | |<-Neighbor Discovery (2)-&gt;| |
| | | | | |
|-----Join Request (3a)----|----Join Request (3a)---->| \ |-----Join Request (3a)----|----Join Request (3a)----&gt;| \
| | | | CoJP | | | | CoJP
|<----Join Response (3b)---|----Join Response (3b)----| / |&lt;----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 indent="0" pn="section-4-6">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 indent="0" pn="section-4-7">The details of each step are described in t
<t>The details of each step are described in the following sections.</t> he following sections.</t>
<section anchor="step-eb" numbered="true" toc="include" removeInRFC="false
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> " pn="section-4.1">
<name slugifiedName="name-step-1-enhanced-beacon">Step 1 - Enhanced Beac
<section anchor="step-eb" title="Step 1 - Enhanced Beacon"> on</name>
<t indent="0" pn="section-4.1-1">The pledge synchronizes to the network
<t>The pledge synchronizes to the network by listening for, and receiving, an En by listening for,
hanced Beacon (EB) sent by a node already in the network. and receiving, an EB sent by a node already in the network.
This process is entirely defined by <xref target="IEEE802.15.4"/>, and described This process is entirely defined by <xref target="IEEE802.15.4" format="default"
in <xref target="RFC7554"/>.</t> sectionFormat="of" derivedContent="IEEE802.15.4"/>
and described in <xref target="RFC7554" format="default" sectionFormat="of" deri
<t>Once the pledge hears an EB, it synchronizes to the joining schedule using th vedContent="RFC7554"/>.</t>
e cells contained in the EB. <t indent="0" pn="section-4.1-2">Once the pledge hears an EB, it synchro
The pledge can hear multiple EBs; the selection of which EB to use is out of the nizes to the joining schedule using the cells contained in the EB.
scope for this document, and is discussed in <xref target="RFC7554"/>. The pledge can hear multiple EBs; the selection of which EB to use
Implementers should make use of information such as: is out of the scope for this document and is discussed in <xref target="RFC7554"
what network identifier the EB contains, format="default" sectionFormat="of" derivedContent="RFC7554"/>.
Implementers should make use of information such as the following:
which 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 indent="0" pn="section-4.1-3">If the pledge is not provisioned with t
<t>If the pledge is not provisioned with the network identifier, it attempts to he network identifier,
join one network at a time, as described in <xref target="join_request"/>.</t> it attempts to join one network at a time, as described in <xref target="join_re
quest" format="default" sectionFormat="of" derivedContent="Section 8.1.1"/>.</t>
<t>Once the pledge selects the EB, it synchronizes to it and transitions into a <t indent="0" pn="section-4.1-4">Once the pledge selects the EB, it sync
low-power mode. hronizes to it and transitions into a low-power mode.
It follows the schedule information contained in the EB which indicates the slot It follows the schedule information contained in the EB,
s that the pledge may use for the join process. which indicates the slots 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 indent="0" pn="section-4.1-5">At this point, the pledge may either pr
<t>At this point, the pledge may proceed to step 2, or continue to listen for ad oceed to step 2 or
ditional EBs.</t> continue to listen for additional EBs.</t>
</section>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> <section anchor="step-nd" numbered="true" toc="include" removeInRFC="false
" pn="section-4.2">
</section> <name slugifiedName="name-step-2-neighbor-discovery">Step 2 - Neighbor D
<section anchor="step-nd" title="Step 2 - Neighbor Discovery"> iscovery</name>
<t indent="0" pn="section-4.2-1">The pledge forms its link-local IPv6 ad
<t>The pledge forms its link-local IPv6 address based on the interface identifie dress based on
r, as per <xref target="RFC4944"/>. the interface identifier per <xref target="RFC4944" format="default" sectionForm
The pledge MAY perform the Neighbor Solicitation / Neighbor Advertisement exchan at="of" derivedContent="RFC4944"/>.
ge with the JP, as per Section 5.6 of <xref target="RFC8505"/>. The pledge <bcp14>MAY</bcp14> perform the Neighbor Solicitation / Neighbor Adver
As per <xref target="RFC8505"/>, there is no need to perform duplicate address d tisement
etection for the link-local address. exchange with the JP per <xref target="RFC8505" section="5.6" sectionFormat="of"
format="default" derivedLink="https://rfc-editor.org/rfc/rfc8505#section-5.6" d
erivedContent="RFC8505"/>.
Per <xref target="RFC8505" format="default" sectionFormat="of" derivedContent="R
FC8505"/>, there is no need to perform duplicate 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 indent="0" pn="section-4.2-2">Note that Neighbor Discovery exchanges
<t>Note that Neighbor Discovery exchanges at this point are not protected with l at this point are not protected with link-layer security as the pledge is not in
ink-layer security as the pledge is not in possession of the keys. 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"
/>.</t> format="default" sectionFormat="of" derivedContent="Section 5"/>.</t>
</section>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> <section anchor="step-cojp" numbered="true" toc="include" removeInRFC="fal
se" pn="section-4.3">
</section> <name slugifiedName="name-step-3-constrained-join-pro">Step 3 - Constrai
<section anchor="step-cojp" title="Step 3 - Constrained Join Protocol (CoJP) Exe ned Join Protocol (CoJP) Execution</name>
cution"> <t indent="0" pn="section-4.3-1">The pledge triggers the join exchange o
f the Constrained Join Protocol (CoJP).
<t>The pledge triggers the join exchange of the Constrained Join Protocol (CoJP) The join exchange consists of two messages: the Join Request message
. (<xref target="step-join-request" format="default" sectionFormat="of" derivedCon
The join exchange consists of two messages: the Join Request message (Step 3a), tent="Section 4.3.1">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" format="default" se
ctionFormat="of" derivedContent="Section 4.3.2">Step 3b</xref>).</t>
<t>All CoJP messages are exchanged over a secure end-to-end channel that provide <t indent="0" pn="section-4.3-2">All CoJP messages are exchanged over a
s confidentiality, data authenticity and replay protection. secure end-to-end
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" sectionFormat="of" derivedContent="Section 5"/>.
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="exclude" remove
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> InRFC="false" pn="section-4.3.1">
<name slugifiedName="name-step-3a-join-request">Step 3a - Join Request
<section anchor="step-join-request" title="Step 3a - Join Request"> </name>
<t indent="0" pn="section-4.3.1-1">The Join Request is a message sent
<t>The Join Request is a message sent from the pledge to the JP, and which the J from the pledge to the JP,
P forwards to the JRC. and which the JP 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 anchor="step-join-response" numbered="true" toc="exclude" remov
eInRFC="false" pn="section-4.3.2">
</section> <name slugifiedName="name-step-3b-join-response">Step 3b - Join Respon
<section anchor="step-join-response" title="Step 3b - Join Response"> se</name>
<t indent="0" pn="section-4.3.2-1">The Join Response is sent by the JR
<t>The Join Response is sent by the JRC to the pledge, and is forwarded through C to the pledge, and it is forwarded through the JP.
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" sectionFormat="of" derivedContent="Section 7"/>.</t>
<t indent="0" pn="section-4.3.2-2">The Join Response contains various
<t>The Join Response contains different parameters needed by the pledge to becom parameters needed by
e a fully operational network node. the pledge to become 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 anchor="the-special-case-of-the-6lbr-pledge-joining" numbered="tr
</section> ue" toc="include" removeInRFC="false" pn="section-4.4">
</section> <name slugifiedName="name-the-special-case-of-the-6lb">The Special Case
<section anchor="the-special-case-of-the-6lbr-pledge-joining" title="The Special of the 6LBR Pledge Joining</name>
Case of the 6LBR Pledge Joining"> <t indent="0" pn="section-4.4-1">The 6LBR pledge performs <xref target="
step-cojp" format="default" sectionFormat="of" derivedContent="Section 4.3"/>
<t>The 6LBR pledge performs <xref target="step-cojp"/> of the join process descr of the join process just like any other pledge, albeit over a different network
ibed above, just as any other pledge, albeit over a different network interface. interface.
There is no JP intermediating the communication between the 6LBR pledge and the There is no JP intermediating the communication between the 6LBR pledge and the
JRC, as described in <xref target="netreq"/>. JRC, as described in <xref target="netreq" format="default" sectionFormat="of" d
erivedContent="Section 6"/>.
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 anchor="llreq" numbered="true" toc="include" removeInRFC="false" pn
</section> ="section-5">
</section> <name slugifiedName="name-link-layer-configuration">Link-Layer Configurati
<section anchor="llreq" title="Link-layer Configuration"> on</name>
<t indent="0" pn="section-5-1">In an operational 6TiSCH network, all frame
<t>In an operational 6TiSCH network, all frames use link-layer frame security <x s use link-layer frame security <xref target="RFC8180" format="default" sectionF
ref target="RFC8180"/>. ormat="of" derivedContent="RFC8180"/>.
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 indent="0" pn="section-5-2">Any node sending EB frames <bcp14>MUST</bcp
<t>Any node sending EB frames MUST be prepared to act as a JP for potential pled 14> be prepared to act as a JP for potential pledges.</t>
ges.</t> <t indent="0" pn="section-5-3">The pledge does not initially perform an au
thenticity check of the EB frames
<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" sectionFormat="of" derivedContent="RFC8180"/>.</t>
<t indent="0" pn="section-5-4">When sending frames during the join process
<t>When sending frames during the join process, the pledge sends unencrypted and , the pledge sends unencrypted 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" sectio
tton press, etc.</t> nFormat="of" derivedContent="Section 8.4.2"/>)
set by the JRC, physical button press, etc.</t>
<t>When the pledge initially synchronizes to the network, it has no means of ver <t indent="0" pn="section-5-5">When the pledge initially synchronizes with
ifying the authenticity of EB frames. the network,
As an attacker can craft a frame that looks like a legitimate EB frame this open it has no means of verifying the authenticity of EB frames.
s up a DoS vector, as discussed in <xref target="sec_considerations"/>.</t> Because an attacker can craft a frame that looks like a legitimate EB frame,
this opens up a DoS vector, as discussed in <xref target="sec_considerations" fo
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> rmat="default" sectionFormat="of" derivedContent="Section 9"/>.</t>
<section anchor="timedistribution" numbered="true" toc="include" removeInR
<section anchor="timedistribution" title="Distribution of Time"> FC="false" pn="section-5.1">
<name slugifiedName="name-distribution-of-time">Distribution of Time</na
<t>Nodes in a 6TiSCH network keep a global notion of time known as the absolute me>
slot number. <t indent="0" pn="section-5.1-1">Nodes in a 6TiSCH network keep a global
Absolute slot number is used in the construction of the link-layer nonce, as def 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" sec
lement. tionFormat="of" derivedContent="IEEE802.15.4"/>.
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 indent="0" pn="section-5.1-2">This enables an attack on the pledge wh
<t>This enables an attack on the pledge where the attacker replays to the pledge ere the attacker replays to the pledge legitimate EB frames obtained from the ne
legitimate EB frames obtained from the network and acts as a man-in-the-middle twork and acts as a man-in-the-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 indent="0" pn="section-5.1-3">For this reason, all frames originated
<t>For this reason, all frames originated at the JP and destined to the pledge d at the JP and
uring the join process MUST be authenticated at the link-layer using the key tha destined to the pledge during the join process <bcp14>MUST</bcp14>
t is normally in use in the network. be authenticated at the link layer using the key that is normally in use in the
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" sectionFormat="of" deri
When the upper layer processing on the pledge is completed and the link-layer ke vedContent="IEEE802.15.4"/> or another appropriate 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 anchor="netreq" numbered="true" toc="include" removeInRFC="false" p
</section> n="section-6">
<section anchor="netreq" title="Network-layer Configuration"> <name slugifiedName="name-network-layer-configuration">Network-Layer Confi
guration</name>
<t>The pledge and the JP SHOULD keep a separate neighbor cache for untrusted ent <t indent="0" pn="section-6-1">The pledge and the JP <bcp14>SHOULD</bcp14>
ries and use it to store each other's information during the join process. keep a separate neighbor cache for untrusted entries and use it to store each o
Mixing neighbor entries belonging to pledges and nodes that are part of the netw ther's information during the 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 indent="0" pn="section-6-2">Once the pledge obtains link-layer keys and
form its global IPv6 address. becomes a joined node,
The joined node then undergoes an independent process to bootstrap its neighbor it is able to securely communicate with its neighbors,
cache entries, possibly with a node that formerly acted as a JP, following <xref obtain the network IPv6 prefix, and form its global IPv6 address.
target="RFC8505"/>. The joined node then undergoes an independent process to bootstrap its neighbor
cache entries, possibly with a node that formerly acted as a JP, following <xref
target="RFC8505" format="default" sectionFormat="of" derivedContent="RFC8505"/>
.
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 indent="0" pn="section-6-3">The pledge does not communicate with the JR
<t>The pledge does not communicate with the JRC at the network layer. C 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" sectionFormat="of" derivedContent="Section
7"/>.</t>
<t>The JP communicates with the JRC over global IPv6 addresses. <t indent="0" pn="section-6-4">The JP communicates with the JRC over globa
l 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" sectionFormat="of" derivedCo
as a JP.</t> ntent="Section 8.1.2"/>; it uses it once joined in order to operate as a JP.</t>
<t indent="0" pn="section-6-5">As a special case, the 6LBR pledge may have
<t>As a special case, the 6LBR pledge may have an additional network interface t an additional
hat it uses in order to obtain the configuration parameters from the JRC and sta network interface that it uses in order to obtain the configuration
rt advertising the 6TiSCH network. parameters from the JRC and to start advertising the 6TiSCH network.
This additional interface needs to be configured with a global IPv6 address, by This additional interface needs to be configured with a global IPv6 address,
a mechanism that is out of scope of this document. by 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 indent="0" pn="section-6-6">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" section
The pledge learns the address of the JRC once joined and upon the reception of t Format="of" derivedContent="RFC6550"/> to its 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" numbered="true" toc="include" remov
eInRFC="false" pn="section-6.1">
<section anchor="traffic_join_request" title="Identification of Unauthenticated <name slugifiedName="name-identification-of-unauthent">Identification of
Traffic"> Unauthenticated Traffic</name>
<t indent="0" pn="section-6.1-1">The traffic that is proxied by the JP c
<t>The traffic that is proxied by the Join Proxy (JP) comes from unauthenticated omes from unauthenticated pledges, and there may be an arbitrary amount of it.
pledges, 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 indent="0" pn="section-6.1-2">When operating as part of a 6TiSCH mini
<t>When operating as part of a <xref target="RFC8180"/> 6TiSCH minimal network u mal network
sing distributed scheduling algorithms, the traffic from unauthenticated pledges <xref target="RFC8180" format="default" sectionFormat="of" derivedContent="RFC81
may cause intermediate nodes to request additional bandwidth. 80"/> using distributed scheduling algorithms,
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 indent="0" pn="section-6.1-3">The JP is aware of what traffic origina
<t>The Join Proxy is aware of what traffic originates from unauthenticated pledg tes from unauthenticated pledges, and so can avoid allocating additional bandwid
es, and so can avoid allocating additional bandwidth itself. th itself.
The Join Proxy implements a data cap on outgoing join traffic by implementing th The JP implements a data cap on outgoing join traffic by
e recommendation of 1 packet per 3 seconds in Section 3.1.3 of <xref target="RFC implementing the recommendation of 1 packet per 3 seconds in
8085"/>. <xref target="RFC8085" section="3.1.3" sectionFormat="of" format="default" deriv
This can be achieved with the congestion control mechanism specified in Section edLink="https://rfc-editor.org/rfc/rfc8085#section-3.1.3" derivedContent="RFC808
4.7 of <xref target="RFC7252"/>. 5"/>.
This cap will not protect intermediate nodes as they can not tell join traffic f This can be achieved with the congestion control mechanism
rom regular traffic. specified in <xref target="RFC7252" section="4.7" sectionFormat="of" format="def
Despite the data cap implemented separately on each Join Proxy, the aggregate jo ault" derivedLink="https://rfc-editor.org/rfc/rfc7252#section-4.7" derivedConten
in traffic from many Join Proxies may cause intermediate nodes to decide to allo t="RFC7252"/>.
cate additional cells. This cap will not protect intermediate nodes as they cannot tell join traffic fr
It is undesirable to do so in response to the traffic originated at unauthentica om regular traffic.
ted pledges. Despite the data cap implemented separately on each JP,
the aggregate join traffic from many JPs may cause intermediate nodes to decide
to allocate additional cells.
It is undesirable to do so in response to the traffic originated from unauthenti
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" sectionFormat="of" derivedContent="RFC25
into the Diffserv Code Points (DSCPs). 97"/> defines a set of
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="exclude" r
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> emoveInRFC="false" pn="section-6.1.1">
<name slugifiedName="name-traffic-from-jp-to-jrc">Traffic from JP to J
<section anchor="traffic-from-jp-to-jrc" title="Traffic from JP to JRC"> RC</name>
<t indent="0" pn="section-6.1.1-1">The JP <bcp14>SHOULD</bcp14> set th
<t>The Join Proxy SHOULD set the DSCP of packets that it produces as part of the e DSCP of packets that it
forwarding process to AF43 code point (See Section 6 of <xref target="RFC2597"/ produces as part of the forwarding process to AF43 code point
>). (See <xref target="RFC2597" section="6" sectionFormat="of" format="default" deri
A Join Proxy that does not require a specific DSCP value on traffic forwarded sh vedLink="https://rfc-editor.org/rfc/rfc2597#section-6" derivedContent="RFC2597"/
ould set it to zero so that it is compressed out.</t> >).
A JP that does not require a specific DSCP value on forwarded traffic
<t>A Scheduling Function (SF) running on 6TiSCH nodes SHOULD NOT allocate additi should set it to zero so that it is compressed out.</t>
onal cells as a result of traffic with code point AF43. <t indent="0" pn="section-6.1.1-2">A Scheduling Function (SF) running
Companion SF documents SHOULD specify how this recommended behavior is achieved. on 6TiSCH nodes <bcp14>SHOULD NOT</bcp14> allocate additional cells as a result
One example is the 6TiSCH Minimal Scheduling Function <xref target="I-D.ietf-6ti of traffic with code point AF43.
sch-msf"/>.</t> Companion SF documents <bcp14>SHOULD</bcp14> specify how this recommended behavi
or is achieved.</t>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> </section>
<section anchor="traffic-from-jrc-to-jp" numbered="true" toc="exclude" r
</section> emoveInRFC="false" pn="section-6.1.2">
<section anchor="traffic-from-jrc-to-jp" title="Traffic from JRC to JP"> <name slugifiedName="name-traffic-from-jrc-to-jp">Traffic from JRC to
JP</name>
<t>The JRC SHOULD set the DSCP of join response packets addressed to the Join Pr <t indent="0" pn="section-6.1.2-1">The JRC <bcp14>SHOULD</bcp14> set t
oxy to AF42 code point. he DSCP of
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 indent="0" pn="section-6.1.2-2">The 6LBR links are often the most c
<t>The 6LBR links are often the most congested within a DODAG, and from that poi ongested within a DODAG,
nt down there is progressively less (or equal) congestion. and from that point down, there is progressively less (or equal) congestion.
If the 6LBR paces itself when sending join response traffic then it ought to nev If the 6LBR paces itself when sending Join Response traffic,
er exceed the bandwidth allocated to the best effort traffic cells. then it ought to never exceed the bandwidth allocated to the best effort traffic
If the 6LBR has the capacity (if it is not constrained) then it should provide s cells.
ome buffers in order to satisfy the Assured Forwarding behavior.</t> If the 6LBR has the capacity (if it is not constrained), then it
should provide some buffers in order to satisfy the Assured Forwarding behavior.
<t>Companion SF documents SHOULD specify how traffic with code point AF42 is han </t>
dled with respect to cell allocation. <t indent="0" pn="section-6.1.2-3">Companion SF documents <bcp14>SHOUL
In case the recommended behavior described in this section is not followed, the D</bcp14> specify how traffic with code point AF42 is handled with respect to ce
network may become prone to the attack discussed in <xref target="traffic_join_r ll allocation.
equest"/>.</t> If the recommended behavior described in this section is not followed,
the network may become prone to the attack discussed in <xref target="traffic_jo
<!-- ====================================================================== --> in_request" format="default" sectionFormat="of" derivedContent="Section 6.1"/>.<
/t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="join_proxy" title="Application-level Configuration"> <section anchor="join_proxy" numbered="true" toc="include" removeInRFC="fals
e" pn="section-7">
<t>The CoJP join exchange in <xref target="fig_overview_diagram"/> is carried ov <name slugifiedName="name-application-layer-configura">Application-Layer C
er CoAP <xref target="RFC7252"/> and the secure channel provided by OSCORE <xref onfiguration</name>
target="RFC8613"/>. <t indent="0" pn="section-7-1">The CoJP join exchange in <xref target="fig
_overview_diagram" format="default" sectionFormat="of" derivedContent="Figure 1"
/> is carried over CoAP <xref target="RFC7252" format="default" sectionFormat="o
f" derivedContent="RFC7252"/> and the secure channel provided by OSCORE <xref ta
rget="RFC8613" format="default" sectionFormat="of" derivedContent="RFC8613"/>.
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" sectionFormat="of" derivedContent="RFC7252"/>.
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 indent="0" pn="section-7-2">The pledge designates a JP as a proxy by in
<t>The pledge designates a JP as a proxy by including the Proxy-Scheme option in cluding the
CoAP requests it sends to the JP. Proxy-Scheme option in the CoAP requests that it sends to the JP.
The pledge also includes in the requests the Uri-Host option with its value set The pledge also includes in the requests the Uri-Host option with
to the well-known JRC's alias, as specified in <xref target="join_request"/>.</t its value set to the well-known JRC's alias, as specified in <xref target="join_
> request" format="default" sectionFormat="of" derivedContent="Section 8.1.1"/>.</
t>
<t>The JP resolves the alias to the IPv6 address of the JRC that it learned when <t indent="0" pn="section-7-3">The JP resolves the alias to the IPv6 addre
it acted as a pledge, and joined the network. ss 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="include" re
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> moveInRFC="false" pn="section-7.1">
<name slugifiedName="name-statelessness-of-the-jp">Statelessness of the
<section anchor="statelessness-of-the-jp" title="Statelessness of the JP"> JP</name>
<t indent="0" pn="section-7.1-1">The CoAP proxy defined in <xref target=
<t>The CoAP proxy defined in <xref target="RFC7252"/> keeps per-client state inf "RFC7252" format="default" sectionFormat="of" derivedContent="RFC7252"/>
ormation in order to forward the response towards the originator of the request. keeps per-client state information 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 indent="0" pn="section-7.1-2">This DoS vector on the JP can be mitiga
<t>This DoS vector on the JP can be mitigated by making the JP act as a stateles ted by making the JP act as a stateless CoAP proxy, where "state" encompasses th
s CoAP proxy, where "state" encompasses the information related to individual pl e information related to individual 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" sectionFormat="of" derivedContent="RFC7252"/>,
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" sectionFormat="of"
token lengths, as defined in <xref target="I-D.ietf-core-stateless"/>. derivedContent="RFC8974"/>
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" sectionFormat="of" derivedContent="RFC8974"/>.
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 indent="0" pn="section-7.1-3">It is <bcp14>RECOMMENDED</bcp14> that t
<t>It is RECOMMENDED that the JP operates in a stateless manner and signals the he JP operates in a
per-pledge state within the CoAP token, for every request it forwards into the n stateless manner and signals the per-pledge state within the CoAP token
etwork on behalf of unauthenticated pledges. for every request that it forwards into the network on behalf of unauthenticated
When the JP is operating in a stateless manner, the security considerations from pledges.
<xref target="I-D.ietf-core-stateless"/> apply and the type of the CoAP message When the JP is operating in a stateless manner, the security considerations from
that the JP forwards on behalf of the pledge MUST be non-confirmable (NON), reg <xref target="RFC8974" format="default" sectionFormat="of" derivedContent="RFC89
ardless of the message type received from the pledge. 74"/> apply, and the type of the CoAP message that the JP forwards on behalf of
the pledge <bcp14>MUST</bcp14> be non-confirmable (NON), regardless of the messa
ge 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" secti
Recommended values of CoAP settings for use during the join process, both by the onFormat="of" derivedContent="Section 9"/>.
pledge and the JP, are given in <xref target="parameters"/>.</t> Recommended values of CoAP settings for use during the join process, both by the
pledge and the JP, are given in <xref target="parameters" format="default" sect
<t>Note that in some networking stack implementations, a fully (per-pledge) stat ionFormat="of" derivedContent="Section 7.2"/>.</t>
eless operation of the JP may be challenging from the implementation's point of <t indent="0" pn="section-7.1-4">Note that in some networking stack impl
view. ementations, a fully (per-pledge) stateless operation of the JP may be challengi
In those cases, the JP may operate as a statefull proxy that stores the per-pled ng from the implementation's point of view.
ge state until the response is received or timed out, but this comes at a price In those cases, the JP may operate as a stateful proxy that stores
of a DoS vector.</t> the per-pledge state until the response is received or timed out, but this comes
at a price of a DoS vector.</t>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> </section>
<section anchor="parameters" numbered="true" toc="include" removeInRFC="fa
</section> lse" pn="section-7.2">
<section anchor="parameters" title="Recommended Settings"> <name slugifiedName="name-recommended-settings">Recommended Settings</na
me>
<t>This section gives RECOMMENDED values of CoAP settings during the join proces <t indent="0" pn="section-7.2-1">This section gives <bcp14>RECOMMENDED</
s.</t> bcp14> values of CoAP settings during the join process.</t>
<table align="center" pn="table-1">
<texttable title="Recommended CoAP settings."> <name slugifiedName="name-recommended-coap-settings">Recommended CoAP
<ttcol align='right'>Name</ttcol> settings.</name>
<ttcol align='left'>Default Value</ttcol> <thead>
<c>ACK_TIMEOUT</c> <tr>
<c>10 seconds</c> <th align="left" colspan="1" rowspan="1">Name</th>
<c>ACK_RANDOM_FACTOR</c> <th align="left" colspan="1" rowspan="1">Default Value</th>
<c>1.5</c> </tr>
<c>MAX_RETRANSMIT</c> </thead>
<c>4</c> <tbody>
<c>NSTART</c> <tr>
<c>1</c> <td align="left" colspan="1" rowspan="1">ACK_TIMEOUT</td>
<c>DEFAULT_LEISURE</c> <td align="left" colspan="1" rowspan="1">10 seconds</td>
<c>5 seconds</c> </tr>
<c>PROBING_RATE</c> <tr>
<c>1 byte/second</c> <td align="left" colspan="1" rowspan="1">ACK_RANDOM_FACTOR</td>
</texttable> <td align="left" colspan="1" rowspan="1">1.5</td>
</tr>
<t>These values may be configured to values specific to the deployment. <tr>
<td align="left" colspan="1" rowspan="1">MAX_RETRANSMIT</td>
<td align="left" colspan="1" rowspan="1">4</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">NSTART</td>
<td align="left" colspan="1" rowspan="1">1</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">DEFAULT_LEISURE</td>
<td align="left" colspan="1" rowspan="1">5 seconds</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">PROBING_RATE</td>
<td align="left" colspan="1" rowspan="1">1 byte/second</td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-7.2-3">These values may be configured to value
s 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 indent="0" pn="section-7.2-4">The PROBING_RATE value at the JP is con
<t>The PROBING_RATE value at the JP is controlled by the join rate parameter, se trolled by the join rate parameter, see <xref target="configuration_object" form
e <xref target="configuration_object"/>. at="default" sectionFormat="of" derivedContent="Section 8.4.2"/>.
Following <xref target="RFC7252"/>, the average data rate in sending to the JRC Following <xref target="RFC7252" format="default" sectionFormat="of" derivedCont
must not exceed PROBING_RATE. ent="RFC7252"/>, the average data rate in sending to the JRC must not exceed PRO
For security reasons, the average data rate SHOULD be measured over a rather sho BING_RATE.
rt window, e.g. ACK_TIMEOUT, see <xref target="sec_considerations"/>.</t> For security reasons, the average data rate <bcp14>SHOULD</bcp14>
be measured over a rather short window, e.g., ACK_TIMEOUT,
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> see <xref target="sec_considerations" format="default" sectionFormat="of" derive
dContent="Section 9"/>.</t>
</section> </section>
<section anchor="oscore_sec_context" title="OSCORE"> <section anchor="oscore_sec_context" numbered="true" toc="include" removeI
nRFC="false" pn="section-7.3">
<t>Before the (6LBR) pledge and the JRC start exchanging CoAP messages protected <name slugifiedName="name-oscore">OSCORE</name>
with OSCORE, they need to derive the OSCORE security context from the provision <t indent="0" pn="section-7.3-1">Before the (6LBR) pledge and the JRC st
ed parameters, as discussed in <xref target="provisioning"/>.</t> art exchanging CoAP messages protected with OSCORE, they need to derive the OSCO
RE security context from the provisioned parameters, as discussed in <xref targe
<t>The OSCORE security context MUST be derived as per Section 3 of <xref target= t="provisioning" format="default" sectionFormat="of" derivedContent="Section 3"/
"RFC8613"/>.</t> >.</t>
<t indent="0" pn="section-7.3-2">The OSCORE security context <bcp14>MUST
<t><list style="symbols"> </bcp14> be derived per
<t>the Master Secret MUST be the PSK.</t> <xref target="RFC8613" section="3" sectionFormat="of" format="default" derivedLi
<t>the Master Salt MUST be the empty byte string.</t> nk="https://rfc-editor.org/rfc/rfc8613#section-3" derivedContent="RFC8613"/>.</t
<t>the ID Context MUST be set to the pledge identifier.</t> >
<t>the ID of the pledge MUST be set to the empty byte string. <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7
This identifier is used as the OSCORE Sender ID of the pledge in the security co .3-3">
ntext derivation, since the pledge initially acts as a CoAP client.</t> <li pn="section-7.3-3.1">The Master Secret <bcp14>MUST</bcp14> be the
<t>the ID of the JRC MUST be set to the byte string 0x4a5243 ("JRC" in ASCII). PSK.</li>
This identifier is used as the OSCORE Recipient ID of the pledge in the security <li pn="section-7.3-3.2">The Master Salt <bcp14>MUST</bcp14> be the em
context derivation, as the JRC initially acts as a CoAP server.</t> pty byte string.</li>
<t>the Algorithm MUST be set to the value from <xref target="RFC8152"/>, agree <li pn="section-7.3-3.3">The ID Context <bcp14>MUST</bcp14> be set to
d out-of-band by the same mechanism used to provision the PSK. the pledge identifier.</li>
The default is AES-CCM-16-64-128.</t> <li pn="section-7.3-3.4">The ID of the pledge <bcp14>MUST</bcp14> be s
<t>the Key Derivation Function MUST be agreed out-of-band by the same mechanis et to the empty byte string.
m used to provision the PSK. This identifier is used as the OSCORE Sender ID of the pledge in the security co
Default is HKDF SHA-256 <xref target="RFC5869"/>.</t> ntext derivation, since the pledge initially acts as a CoAP client.</li>
</list></t> <li pn="section-7.3-3.5">The ID of the JRC <bcp14>MUST</bcp14> be set
to the byte string 0x4a5243 ("JRC" in ASCII).
<t>Since the pledge's OSCORE Sender ID is the empty byte string, when constructi This identifier is used as the OSCORE Recipient ID of the pledge in the security
ng the OSCORE option, the pledge sets the k bit in the OSCORE flag byte, but ind context derivation, as the JRC initially acts as a CoAP server.</li>
icates a 0-length kid. <li pn="section-7.3-3.6">The Algorithm <bcp14>MUST</bcp14> be set to t
The pledge transports its pledge identifier within the kid context field of the he value
OSCORE option. from <xref target="RFC8152" format="default" sectionFormat="of" derivedContent="
The derivation in <xref target="RFC8613"/> results in OSCORE keys and a common I RFC8152"/>, agreed to out-of-band
V for each side of the conversation. by the same mechanism used to provision the PSK.
Nonces are constructed by XOR'ing the common IV with the current sequence number The default is AES-CCM-16-64-128.</li>
. <li pn="section-7.3-3.7">The key derivation function <bcp14>MUST</bcp1
For details on nonce and OSCORE option construction, refer to <xref target="RFC8 4> be agreed out-of-band by the same mechanism used to provision the PSK.
613"/>.</t> Default is HKDF SHA-256 <xref target="RFC5869" format="default" sectionFormat="o
f" derivedContent="RFC5869"/>.</li>
<t>Implementations MUST ensure that multiple CoAP requests, including to differe </ul>
nt JRCs, are properly incrementing the sequence numbers, so that the same sequen <t indent="0" pn="section-7.3-4">Since the pledge's OSCORE Sender ID is
ce number is never reused in distinct requests protected under the same PSK. the empty byte string,
when constructing the OSCORE option, the pledge sets the 'kid' flag in the
OSCORE flag bits but indicates a 0-length 'kid'.
The pledge transports its pledge identifier within the 'kid context' field of th
e OSCORE option.
The derivation in <xref target="RFC8613" format="default" sectionFormat="of" der
ivedContent="RFC8613"/> results in OSCORE keys and a Common Initialization Vecto
r (IV) for each side of the conversation.
Nonces are constructed by XORing the Common IV with the current sequence number.
For details on nonce and OSCORE option construction, refer to <xref target="RFC8
613" format="default" sectionFormat="of" derivedContent="RFC8613"/>.</t>
<t indent="0" pn="section-7.3-5">Implementations <bcp14>MUST</bcp14> ens
ure that multiple CoAP requests, including to different JRCs, are properly incre
menting the sequence numbers, so that the same sequence number is never reused i
n 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 indent="0" pn="section-7.3-6">This OSCORE security context is used fo
<t>This OSCORE security context is used for r the
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" sectionFormat="of" derivedContent="Section 8.2"/>.
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" de
rivedLink="https://rfc-editor.org/rfc/rfc8613#section-3.1" derivedContent="RFC86
13"/>).
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="exclude" removeInRFC=
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> "false" pn="section-7.3.1">
<name slugifiedName="name-replay-window-and-persisten">Replay Window a
<section anchor="persistency" title="Replay Window and Persistency"> nd Persistency</name>
<t indent="0" pn="section-7.3.1-1">Both the (6LBR) pledge and the JRC
<t>Both (6LBR) pledge and the JRC MUST implement a replay protection mechanism. <bcp14>MUST</bcp14>
The use of the default OSCORE replay protection mechanism specified in Section 3 implement a replay-protection mechanism.
.2.2 of <xref target="RFC8613"/> is RECOMMENDED.</t> The use of the default OSCORE replay-protection mechanism specified in
<xref target="RFC8613" section="3.2.2" sectionFormat="of" format="default" deriv
<t>Implementations MUST ensure that mutable OSCORE context parameters (Sender Se edLink="https://rfc-editor.org/rfc/rfc8613#section-3.2.2" derivedContent="RFC861
quence Number, Replay Window) are stored in persistent memory. 3"/> is <bcp14>RECOMMENDED</bcp14>.</t>
A technique detailed in Appendix B.1.1 of <xref target="RFC8613"/> that prevents <t indent="0" pn="section-7.3.1-2">Implementations <bcp14>MUST</bcp14>
reuse of sequence numbers MUST be implemented. ensure that mutable OSCORE context parameters (Sender Sequence Number, Replay W
Each update of the OSCORE Replay Window MUST be written to persistent memory.</t indow) are stored in persistent memory.
> A technique detailed in <xref target="RFC8613" section="B.1.1" sectionFormat="of
" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8613#appendix-B.1.
<t>This is an important security requirement in order to guarantee nonce uniquen 1" derivedContent="RFC8613"/>
ess and resistance to replay attacks across reboots and rejoins. 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 indent="0" pn="section-7.3.1-3">This is an important security requi
rement in order to guarantee nonce uniqueness and resistance to replay attacks a
cross 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 anchor="oscore_error_handling" numbered="true" toc="exclude" re
moveInRFC="false" pn="section-7.3.2">
</section> <name slugifiedName="name-oscore-error-handling">OSCORE Error Handling
<section anchor="oscore_error_handling" title="OSCORE Error Handling"> </name>
<t indent="0" pn="section-7.3.2-1">Errors raised by OSCORE during the
<t>Errors raised by OSCORE during the join process MUST be silently dropped, wit join process <bcp14>MUST</bcp14> be silently dropped, with no error response bei
h no error response being signaled. ng 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 indent="0" pn="section-7.3.2-2">Such errors may happen for a number
<t>Such errors may happen for a number of reasons, including of reasons, including
failed lookup of an appropriate security context (e.g. the pledge attempting failed lookup of an appropriate security context (e.g., the pledge attemptin
to join a wrong network), g 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 anchor="mti_algos" numbered="true" toc="exclude" removeInRFC="f
alse" pn="section-7.3.3">
</section> <name slugifiedName="name-mandatory-to-implement-algo">Mandatory-to-Im
<section anchor="mti_algos" title="Mandatory to Implement Algorithms"> plement Algorithms</name>
<t indent="0" pn="section-7.3.3-1">The mandatory-to-implement AEAD alg
<t>The mandatory to implement AEAD algorithm for use with OSCORE is AES-CCM-16-6 orithm for use with OSCORE is AES-CCM-16-64-128 from <xref target="RFC8152" form
4-128 from <xref target="RFC8152"/>. at="default" sectionFormat="of" derivedContent="RFC8152"/>.
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 indent="0" pn="section-7.3.3-2">The mandatory-to-implement hash alg
<t>The mandatory to implement hash algorithm is SHA-256 <xref target="RFC4231"/> orithm is SHA-256 <xref target="RFC4231" format="default" sectionFormat="of" der
. ivedContent="RFC4231"/>.
The mandatory to implement key derivation function is HKDF <xref target="RFC5869 The mandatory-to-implement key derivation function is HKDF <xref target="RFC5869
"/>, instantiated with a SHA-256 hash. " format="default" sectionFormat="of" derivedContent="RFC5869"/>, instantiated w
See <xref target="lightweight"/> for implementation guidance when code footprint ith a SHA-256 hash.
is important.</t> See <xref target="lightweight" format="default" sectionFormat="of" derivedConten
t="Appendix B"/> for implementation guidance when code footprint is important.</
<!-- ====================================================================== --> t>
</section>
</section> </section>
</section> </section>
</section> <section anchor="join_protocol" numbered="true" toc="include" removeInRFC="f
<section anchor="join_protocol" title="Constrained Join Protocol (CoJP)"> alse" pn="section-8">
<name slugifiedName="name-constrained-join-protocol-c">Constrained Join Pr
<t>The Constrained Join Protocol (CoJP) is a lightweight protocol over CoAP <xre otocol (CoJP)</name>
f target="RFC7252"/> and a secure channel provided by OSCORE <xref target="RFC86 <t indent="0" pn="section-8-1">The Constrained Join Protocol (CoJP) is a l
13"/>. ightweight protocol over CoAP <xref target="RFC7252" format="default" sectionFor
mat="of" derivedContent="RFC7252"/> and a secure channel provided by OSCORE <xre
f target="RFC8613" format="default" sectionFormat="of" derivedContent="RFC8613"/
>.
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 indent="0" pn="section-8-2">CoJP relies on the security properties prov
<t>CoJP relies on the security properties provided by OSCORE. ided 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" align="left" suppress-title="false" pn="figure-
<figure title="Abstract layering of CoJP." anchor="fig-stack"><artwork align="ce 2">
nter"><![CDATA[ <name slugifiedName="name-abstract-layering-of-cojp">Abstract layering o
f CoJP.</name>
<artwork align="center" name="" type="" alt="" pn="section-8-3.1">
+-----------------------------------+ +-----------------------------------+
| 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 indent="0" pn="section-8-4">When a (6LBR) pledge requests admission to
CoJP join exchange that consists of:</t> a given network, it undergoes the CoJP join exchange that consists of:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8-5
<t><list style="symbols"> ">
<t>the Join Request message, sent by the (6LBR) pledge to the JRC, potentially <li pn="section-8-5.1">The Join Request message, sent by the (6LBR) pled
proxied by the JP. ge to the JRC, potentially 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"/>.</t> oin_request" format="default" sectionFormat="of" derivedContent="Section 8.1.1"/
<t>the Join Response message, sent by the JRC to the (6LBR) pledge, if the JRC >.</li>
successfully processes the Join Request using OSCORE and it determines through <li pn="section-8-5.2">The Join Response message, sent by the JRC to the
a mechanism that is out of scope of this specification that the (6LBR) pledge is (6LBR) pledge, if the JRC successfully processes the Join Request using OSCORE
authorized to join the network. and it determines through a mechanism that is out of scope of this specification
that the (6LBR) pledge is 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" sectionFormat="of" derivedContent="Section 8.1.2
</list></t> "/>.</li>
</ul>
<t>When the JRC needs to update the parameters of a joined node that formerly ac <t indent="0" pn="section-8-6">When the JRC needs to update the parameters
ted as a (6LBR) pledge, it executes the CoJP parameter update exchange that cons of a joined node
ists of:</t> that formerly acted as a (6LBR) pledge, it executes the CoJP parameter update ex
change
<t><list style="symbols"> that consists of the following:</t>
<t>the Parameter Update message, sent by the JRC to the joined node that forme <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8-7
rly acted as a (6LBR) pledge. ">
The Parameter Update message and its mapping to CoAP is specified in <xref targe <li pn="section-8-7.1">The Parameter Update message, sent by the JRC to
t="parameter_update"/>.</t> the joined node that formerly acted as a (6LBR) pledge.
</list></t> The Parameter Update message and its mapping to CoAP is specified in <xref targe
t="parameter_update" format="default" sectionFormat="of" derivedContent="Section
<t>The payload of CoJP messages is encoded with CBOR <xref target="RFC7049"/>. 8.2.1"/>.</li>
The CBOR data structures that may appear as the payload of different CoJP messag </ul>
es are specified in <xref target="cbor_objects"/>.</t> <t indent="0" pn="section-8-8">The payload of CoJP messages is encoded wit
h CBOR <xref target="RFC8949" format="default" sectionFormat="of" derivedContent
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> ="RFC8949"/>.
The CBOR data structures that may appear as the payload of different CoJP messag
<section anchor="join" title="Join Exchange"> es are specified in <xref target="cbor_objects" format="default" sectionFormat="
of" derivedContent="Section 8.4"/>.</t>
<t>This section specifies the messages exchanged when the (6LBR) pledge requests <section anchor="join" numbered="true" toc="include" removeInRFC="false" p
admission and configuration parameters from the JRC.</t> n="section-8.1">
<name slugifiedName="name-join-exchange">Join Exchange</name>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> <t indent="0" pn="section-8.1-1">This section specifies the messages exc
hanged when the (6LBR) pledge requests admission and configuration parameters fr
<section anchor="join_request" title="Join Request Message"> om the JRC.</t>
<section anchor="join_request" numbered="true" toc="exclude" removeInRFC
<t>The Join Request message that the (6LBR) pledge sends SHALL be mapped to a Co ="false" pn="section-8.1.1">
AP request:</t> <name slugifiedName="name-join-request-message">Join Request Message</
name>
<t><list style="symbols"> <t indent="0" pn="section-8.1.1-1">The Join Request message that the (
<t>The request method is POST.</t> 6LBR) pledge sends <bcp14>SHALL</bcp14> be mapped to a CoAP request:</t>
<t>The type is Confirmable (CON).</t> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<t>The Proxy-Scheme option is set to "coap".</t> -8.1.1-2">
<t>The Uri-Host option is set to "6tisch.arpa". <li pn="section-8.1.1-2.1">The request method is POST.</li>
This is an anycast type of identifier of the JRC that is resolved to its IPv6 ad <li pn="section-8.1.1-2.2">The type is Confirmable (CON).</li>
dress by the JP or the 6LBR pledge.</t> <li pn="section-8.1.1-2.3">The Proxy-Scheme option is set to "coap".
<t>The Uri-Path option is set to "j".</t> </li>
<t>The OSCORE option SHALL be set according to <xref target="RFC8613"/>. <li pn="section-8.1.1-2.4">The Uri-Host option is set to "6tisch.arp
The OSCORE security context used is the one derived in <xref target="oscore_se a".
c_context"/>. This is an anycast type of identifier of the JRC that is resolved to its IPv6 ad
The OSCORE kid context allows the JRC to retrieve the security context for a g dress by the JP or the 6LBR pledge.</li>
iven pledge.</t> <li pn="section-8.1.1-2.5">The Uri-Path option is set to "j".</li>
<t>The payload is a Join_Request CBOR object, as defined in <xref target="join <li pn="section-8.1.1-2.6">The OSCORE option <bcp14>SHALL</bcp14> be
_request_object"/>.</t> set according to <xref target="RFC8613" format="default" sectionFormat="of" der
</list></t> ivedContent="RFC8613"/>.
The OSCORE security context used is the one derived in <xref target="oscore_se
<t>Since the Join Request is a confirmable message, the transmission at (6LBR) p c_context" format="default" sectionFormat="of" derivedContent="Section 7.3"/>.
ledge will be controlled by CoAP's retransmission mechanism. The OSCORE 'kid context' allows the JRC to retrieve the security context for a
The JP, when operating in a stateless manner, forwards this Join Request as a no given pledge.</li>
n-confirmable (NON) CoAP message, as specified in <xref target="join_proxy"/>. <li pn="section-8.1.1-2.7">The payload is a Join_Request CBOR object
If the CoAP implementation at (6LBR) pledge declares the message transmission as , as defined in <xref target="join_request_object" format="default" sectionForma
failure, the (6LBR) pledge SHOULD attempt to join a 6TiSCH network advertised w t="of" derivedContent="Section 8.4.1"/>.</li>
ith a different network identifier. </ul>
See <xref target="parameters"/> for recommended values of CoAP settings to use d <t indent="0" pn="section-8.1.1-3">Since the Join Request is a confirm
uring the join exchange.</t> able message, the transmission at (6LBR) pledge will be controlled by CoAP's ret
ransmission mechanism.
<t>If all join attempts to advertised networks have failed, the (6LBR) pledge SH The JP, when operating in a stateless manner, forwards this Join Request as a no
OULD signal the presence of an error condition, through some out-of-band mechani n-confirmable (NON) CoAP message, as specified in <xref target="join_proxy" form
sm.</t> at="default" sectionFormat="of" derivedContent="Section 7"/>.
If the CoAP implementation at the (6LBR) pledge declares the
<t>BCP190 <xref target="RFC7320"/> provides guidelines on URI design and ownersh message transmission a failure, the (6LBR) pledge <bcp14>SHOULD</bcp14>
ip. attempt to join a 6TiSCH network advertised with a different network identifier.
It recommends that whenever a third party wants to mandate a URL to web authorit See <xref target="parameters" format="default" sectionFormat="of" derivedContent
y that it SHOULD go under "/.well-known" (as per <xref target="RFC5785"/>). ="Section 7.2"/> for recommended values of CoAP settings to use during the join
In the case of CoJP, the Uri-Host option is always set to "6tisch.arpa", and bas exchange.</t>
ed upon the recommendations in the Introduction of <xref target="RFC7320"/>, it <t indent="0" pn="section-8.1.1-4">If all join attempts to advertised
is asserted that this document is the owner of the CoJP service. networks have failed, the (6LBR) pledge <bcp14>SHOULD</bcp14> signal the presenc
As such, the concerns of <xref target="RFC7320"/> do not apply, and thus the Uri e of an error condition, through some out-of-band mechanism.</t>
-Path is only "/j".</t> <t indent="0" pn="section-8.1.1-5">BCP 190 <xref target="RFC8820" form
at="default" sectionFormat="of" derivedContent="RFC8820"/>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> provides guidelines on URI design and ownership. It recommends that
whenever a third party wants to mandate a URI to web authority that
</section> it <bcp14>SHOULD</bcp14> go under "/.well-known" (per <xref target="RFC8615" for
<section anchor="join_response" title="Join Response Message"> mat="default" sectionFormat="of" derivedContent="RFC8615"/>).
In the case of CoJP, the Uri-Host option is always set to "6tisch.arpa",
<t>The Join Response message that the JRC sends SHALL be mapped to a CoAP respon and based upon the recommendations in <xref target="RFC8820" section="1" section
se:</t> Format="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8820#sec
tion-1" derivedContent="RFC8820"/>,
<t><list style="symbols"> it is asserted that this document is the owner of the CoJP service.
<t>The response Code is 2.04 (Changed).</t> As such, the concerns of <xref target="RFC8820" format="default" sectionFormat="
<t>The payload is a Configuration CBOR object, as defined in <xref target="con of" derivedContent="RFC8820"/> do not apply,
figuration_object"/>.</t> and thus the Uri-Path is only "j".</t>
</list></t> </section>
<section anchor="join_response" numbered="true" toc="exclude" removeInRF
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> C="false" pn="section-8.1.2">
<name slugifiedName="name-join-response-message">Join Response Message
</section> </name>
</section> <t indent="0" pn="section-8.1.2-1">The Join Response message that the
<section anchor="update" title="Parameter Update Exchange"> JRC sends <bcp14>SHALL</bcp14> be mapped to a CoAP response:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<t>During the network lifetime, parameters returned as part of the Join Response -8.1.2-2">
may need to be updated. <li pn="section-8.1.2-2.1">The Response Code is 2.04 (Changed).</li>
<li pn="section-8.1.2-2.2">The payload is a Configuration CBOR objec
t, as defined in <xref target="configuration_object" format="default" sectionFor
mat="of" derivedContent="Section 8.4.2"/>.</li>
</ul>
</section>
</section>
<section anchor="update" numbered="true" toc="include" removeInRFC="false"
pn="section-8.2">
<name slugifiedName="name-parameter-update-exchange">Parameter Update Ex
change</name>
<t indent="0" pn="section-8.2-1">During the network lifetime, parameters
returned as part of the Join 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 indent="0" pn="section-8.2-2">At the time of the join, the (6LBR) ple
<t>At the time of the join, the (6LBR) pledge acts as a CoAP client and requests dge acts as a
the network parameters through a representation of the "/j" resource, exposed b CoAP client and requests the network parameters through a representation
y the JRC. of the "/j" resource exposed by 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 indent="0" pn="section-8.2-3">Instead, once the (6LBR) pledge receive
<t>Instead, once the (6LBR) pledge receives and successfully validates the Join s and successfully validates the Join Response and so becomes a joined node, it
Response and so becomes a joined node, it becomes a CoAP server. 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="exclude" removeI
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> nRFC="false" pn="section-8.2.1">
<name slugifiedName="name-parameter-update-message">Parameter Update M
<section anchor="parameter_update" title="Parameter Update Message"> essage</name>
<t indent="0" pn="section-8.2.1-1">The Parameter Update message that t
<t>The Parameter Update message that the JRC sends to the joined node SHALL be m he JRC sends to the joined node <bcp14>SHALL</bcp14> be mapped to a CoAP request
apped to a CoAP request:</t> :</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<t><list style="symbols"> -8.2.1-2">
<t>The request method is POST.</t> <li pn="section-8.2.1-2.1">The request method is POST.</li>
<t>The type is Confirmable (CON).</t> <li pn="section-8.2.1-2.2">The type is Confirmable (CON).</li>
<t>The Uri-Host option is set to "6tisch.arpa".</t> <li pn="section-8.2.1-2.3">The Uri-Host option is set to "6tisch.arp
<t>The Uri-Path option is set to "j".</t> a".</li>
<t>The OSCORE option SHALL be set according to <xref target="RFC8613"/>. <li pn="section-8.2.1-2.4">The Uri-Path option is set to "j".</li>
The OSCORE security context used is the one derived in <xref target="oscore_se <li pn="section-8.2.1-2.5">The OSCORE option <bcp14>SHALL</bcp14> be
c_context"/>. set according to <xref target="RFC8613" format="default" sectionFormat="of" der
When a joined node receives a request with the Sender ID set to 0x4a5243 (ID o ivedContent="RFC8613"/>.
f the JRC), it is able to correctly retrieve the security context with the JRC.< The OSCORE security context used is the one derived in <xref target="oscore_se
/t> c_context" format="default" sectionFormat="of" derivedContent="Section 7.3"/>.
<t>The payload is a Configuration CBOR object, as defined in <xref target="con When a joined node receives a request with the Sender ID set to 0x4a5243 (ID o
figuration_object"/>.</t> f the JRC), it is able to correctly retrieve the security context with the JRC.<
</list></t> /li>
<li pn="section-8.2.1-2.6">The payload is a Configuration CBOR objec
<t>The JRC has implicit knowledge on the global IPv6 address of the joined node, t, as defined in <xref target="configuration_object" format="default" sectionFor
as it knows the pledge identifier that the joined node used when it acted as a mat="of" derivedContent="Section 8.4.2"/>.</li>
pledge, and the IPv6 network prefix. </ul>
<t indent="0" pn="section-8.2.1-3">The JRC has implicit knowledge of t
he 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 indent="0" pn="section-8.2.1-4">If the JRC does not receive a respo
<t>In case the JRC does not receive a response to a Parameter Update message, it nse to a
attempts multiple retransmissions, as configured by the underlying CoAP retrans Parameter Update message, it attempts multiple retransmissions as
mission mechanism triggered for confirmable messages. configured by the underlying CoAP retransmission mechanism triggered for confirm
Finally, if the CoAP implementation declares the transmission as failure, the JR able messages.
C may consider this as a hint that the joined node is no longer in the network. Finally, if the CoAP implementation declares the transmission a failure,
How the JRC decides when to stop attempting to contact a previously joined node the JRC may consider this as a hint that the joined node is no longer in the net
is out of scope of this specification but security considerations on the reuse o work.
f assigned resources apply, as discussed in <xref target="sec_considerations"/>. How the JRC decides when to stop attempting to contact a previously
</t> 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" sectionFormat="of" derived
Content="Section 9"/>.</t>
</section> </section>
</section> </section>
<section anchor="error-handling" title="Error Handling"> <section anchor="error-handling" numbered="true" toc="include" removeInRFC
="false" pn="section-8.3">
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> <name slugifiedName="name-error-handling">Error Handling</name>
<section anchor="cojp_error_handling" numbered="true" toc="exclude" remo
<section anchor="cojp_error_handling" title="CoJP CBOR Object Processing"> veInRFC="false" pn="section-8.3.1">
<name slugifiedName="name-cojp-cbor-object-processing">CoJP CBOR Objec
<t>CoJP CBOR objects are transported within both CoAP requests and responses. t Processing</name>
This section describes handling in case certain CoJP CBOR object parameters are <t indent="0" pn="section-8.3.1-1">CoJP CBOR objects are transported w
not supported by the implementation or their processing fails. ithin both CoAP requests and responses.
See <xref target="oscore_error_handling"/> for the handling of errors that may b This section describes handling the cases in which certain CoJP CBOR object
e raised by the underlying OSCORE implementation.</t> parameters are not supported by the implementation or their processing fails.
See <xref target="oscore_error_handling" format="default" sectionFormat="of" der
<t>When such a parameter is detected in a CoAP request (Join Request message, Pa ivedContent="Section 7.3.2"/> for the handling of errors that may be raised by t
rameter Update message), a Diagnostic Response message MUST be returned. he underlying OSCORE implementation.</t>
A Diagnostic Response message maps to a CoAP response and is specified in <xref <t indent="0" pn="section-8.3.1-2">When such a parameter is detected i
target="error_response_message"/>.</t> n a CoAP request (Join Request message, Parameter Update message), a Diagnostic
Response message <bcp14>MUST</bcp14> be returned.
<t>When a parameter that cannot be acted upon is encountered while processing a A Diagnostic Response message maps to a CoAP response and is specified in <xref
CoJP object in a CoAP response (Join Response message), a (6LBR) pledge SHOULD r target="error_response_message" format="default" sectionFormat="of" derivedConte
eattempt to join. nt="Section 8.3.2"/>.</t>
In this case, the (6LBR) pledge SHOULD include the Unsupported Configuration CBO <t indent="0" pn="section-8.3.1-3">When a parameter that cannot be act
R object within the Join Request object in the following Join Request message. ed upon is encountered while processing a CoJP object in a CoAP response (Join R
esponse message), a (6LBR) pledge <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 indent="0" pn="section-8.3.1-4">Note that COJP_MAX_JOIN_ATTEMPTS re
the CoAP response and is different from CoAP's MAX_RETRANSMIT setting that driv lates to the
es the retransmission mechanism of the underlying CoAP message.</t> application-layer handling of the CoAP response and is different from
CoAP's MAX_RETRANSMIT setting, which drives the retransmission mechanism
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> of the underlying CoAP message.</t>
</section>
</section> <section anchor="error_response_message" numbered="true" toc="exclude" r
<section anchor="error_response_message" title="Diagnostic Response Message"> emoveInRFC="false" pn="section-8.3.2">
<name slugifiedName="name-diagnostic-response-message">Diagnostic Resp
<t>The Diagnostic Response message is returned for any CoJP request when the pro onse Message</name>
cessing of the payload failed. <t indent="0" pn="section-8.3.2-1">The Diagnostic Response message is
The Diagnostic Response message is protected by OSCORE as any other CoJP protoco returned for any CoJP request when the processing of the payload failed.
l message.</t> The Diagnostic Response message is protected by OSCORE as any other CoJP messag
e.</t>
<t>The Diagnostic Response message SHALL be mapped to a CoAP response:</t> <t indent="0" pn="section-8.3.2-2">The Diagnostic Response message <bc
p14>SHALL</bcp14> be mapped to a CoAP response:</t>
<t><list style="symbols"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<t>The response Code is 4.00 (Bad Request).</t> -8.3.2-3">
<t>The payload is an Unsupported Configuration CBOR object, as defined in <xre <li pn="section-8.3.2-3.1">The Response Code is 4.00 (Bad Request).<
f target="unsupported_configuration_object"/>, containing more information about /li>
the parameter that triggered the sending of this message.</t> <li pn="section-8.3.2-3.2">The payload is an Unsupported Configurati
</list></t> on CBOR object,
as defined in <xref target="unsupported_configuration_object" format="default" s
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> ectionFormat="of" derivedContent="Section 8.4.5"/>,
containing more information about the parameter that triggered the sending of th
</section> is message.</li>
<section anchor="failure_handling" title="Failure Handling"> </ul>
</section>
<t>The Parameter Update exchange may be triggered at any time during the network <section anchor="failure_handling" numbered="true" toc="exclude" removeI
lifetime, which may span several years. nRFC="false" pn="section-8.3.3">
During this period, it may occur that a joined node or the JRC experience unexpe <name slugifiedName="name-failure-handling">Failure Handling</name>
cted events such as reboots or complete failures.</t> <t indent="0" pn="section-8.3.3-1">The parameter update exchange may b
e triggered at any time
<t>This document mandates that the mutable parameters in the security context ar during the network lifetime, which may span several years.
e written to persistent memory (see <xref target="persistency"/>) by both the JR During this period, a joined node or the JRC may experience unexpected
C and pledges (joined nodes). events such as reboots or complete failures.</t>
As the joined node (pledge) is typically a constrained device that handles the w <t indent="0" pn="section-8.3.3-2">This document mandates that the mut
rite operations to persistent memory in a predictable manner, the retrieval of m able parameters in the
utable security context parameters is feasible across reboots such that there is security context are written to persistent memory (see
no risk of AEAD nonce reuse due to reinitialized Sender Sequence numbers, or of <xref target="persistency" format="default" sectionFormat="of" derivedContent="S
a replay attack due to the reinitialized replay window. ection 7.3.1"/>) by both the JRC and pledges
JRC may be hosted on a generic machine where the write operation to persistent m (joined nodes).
emory may lead to unpredictable delays due to caching. As the pledge (joined node) is typically a constrained device that handles
In case of a reboot event at JRC occurring before the cached data is written to the write operations to persistent memory in a predictable manner, the
persistent memory, the loss of mutable security context parameters is likely whi retrieval of mutable security-context parameters is feasible across reboots
ch consequently poses the risk of AEAD nonce reuse.</t> such that there is no risk of AEAD nonce reuse due to reinitialized
Sender Sequence Numbers or of a replay attack due to the reinitialized Replay Wi
<t>In the event of a complete device failure, where the mutable security context ndow.
parameters cannot be retrieved, it is expected that a failed joined node is rep The JRC may be hosted on a generic machine where the write operation to
laced with a new physical device, using a new pledge identifier and a PSK. persistent memory may lead to unpredictable delays due to caching.
When such a failure event occurs at the JRC, it is possible that the static info If a reboot event occurs at the JRC before the cached data is written
rmation on provisioned pledges, like PSKs and pledge identifiers, can be retriev to persistent memory, the loss of mutable security-context parameters
ed through available backups. is likely, which consequently poses the risk of AEAD nonce reuse.</t>
However, it is likely that the information about joined nodes, their assigned sh <t indent="0" pn="section-8.3.3-3">In the event of a complete device f
ort identifiers and mutable security context parameters is lost. ailure, where the mutable
If this is the case, during the process of JRC reinitialization, the network adm security-context parameters cannot be retrieved, it is expected that a
inistrator MUST force through out-of-band means all the networks managed by the failed joined node will be replaced with a new physical device, using
failed JRC to rejoin, through e.g. the reinitialization of the 6LBR nodes and fr a new pledge identifier and a PSK.
eshly generated dynamic cryptographic keys and other parameters that have influe When such a failure event occurs at the JRC, it is possible that the
nce on the security properties of the network.</t> static information on provisioned pledges, like PSKs and pledge identifiers,
can be retrieved through available backups.
<t>In order to recover from such a failure event, the reinitialized JRC can trig However, it is likely that the information about joined nodes, their
ger the renegotiation of the OSCORE security context through the procedure descr assigned short identifiers and mutable security-context parameters,
ibed in Appendix B.2 of <xref target="RFC8613"/>. is lost.
Aware of the failure event, the reinitialized JRC responds to the first join req If this is the case, the network administrator <bcp14>MUST</bcp14> force
uest of each pledge it is managing with a 4.01 Unauthorized error and a random n all the networks managed by the failed JRC to rejoin through out-of-band
once. means during the process of JRC reinitialization, e.g.,
reinitialize the 6LBR nodes and freshly generate dynamic
cryptographic keys and other parameters that influence the
security properties of the network.</t>
<t indent="0" pn="section-8.3.3-4">In order to recover from such a fai
lure event, the reinitialized JRC can trigger the renegotiation of the OSCORE se
curity context through the procedure described in
<xref target="RFC8613" section="B.2" sectionFormat="of" format="default" derived
Link="https://rfc-editor.org/rfc/rfc8613#appendix-B.2" derivedContent="RFC8613"/
>.
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 indent="0" pn="section-8.3.3-5">The use of the procedure specified
<t>The described procedure is specified in Appendix B.2 of <xref target="RFC8613 in
"/> and is RECOMMENDED in order to handle the failure events or any other event <xref target="RFC8613" section="B.2" sectionFormat="of" format="default" derived
that may lead to the loss of mutable security context parameters. Link="https://rfc-editor.org/rfc/rfc8613#appendix-B.2" derivedContent="RFC8613"/
The length of nonces exchanged using this procedure MUST be at least 8 bytes.</t >
> is <bcp14>RECOMMENDED</bcp14> in order to handle the failure events or
any other event that may lead to the loss of mutable security-context parameters
<t>The procedure does require both the pledge and the JRC to have good sources o .
f randomness. The length of nonces exchanged using this procedure <bcp14>MUST</bcp14> be at le
While this is typically not an issue at the JRC side, the constrained device hos ast 8 bytes.</t>
ting the pledge may pose limitations in this regard. <t indent="0" pn="section-8.3.3-6">The procedure requires both the ple
If the procedure outlined in Appendix B.2 of <xref target="RFC8613"/> is not sup dge and the JRC
ported by the pledge, the network administrator MUST take action in reprovisioni to have good sources of randomness.
ng the concerned devices with freshly generated parameters, through out-of-band While this is typically not an issue at the JRC side, the constrained
means.</t> device hosting the pledge may pose limitations in this regard.
If the procedure outlined in
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> <xref target="RFC8613" section="B.2" sectionFormat="of" format="default" derived
Link="https://rfc-editor.org/rfc/rfc8613#appendix-B.2" derivedContent="RFC8613"/
</section> >
</section> is not supported by the pledge, the network administrator <bcp14>MUST</bcp14>
<section anchor="cbor_objects" title="CoJP Objects"> reprovision the concerned devices with freshly generated parameters
through out-of-band means.</t>
<t>This section specifies the structure of CoJP CBOR objects that may be carried </section>
as the payload of CoJP messages. </section>
Some of these objects may be received both as part of the CoJP join exchange whe <section anchor="cbor_objects" numbered="true" toc="include" removeInRFC="
n the device operates as a (CoJP) pledge, or the parameter update exchange, when false" pn="section-8.4">
the device operates as a joined (6LBR) node.</t> <name slugifiedName="name-cojp-objects">CoJP Objects</name>
<t indent="0" pn="section-8.4-1">This section specifies the structure of
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> CoJP CBOR objects
that may be carried as the payload of CoJP messages.
<section anchor="join_request_object" title="Join Request Object"> Some of these objects may be received both as part of the
CoJP join exchange when the device operates as a (CoJP) pledge or
<t>The Join_Request structure is built on a CBOR map object.</t> as part of the parameter update exchange when the device operates
as a joined (6LBR) node.</t>
<t>The set of parameters that can appear in a Join_Request object is summarized <section anchor="join_request_object" numbered="true" toc="exclude" remo
below. veInRFC="false" pn="section-8.4.1">
The labels can be found in the "CoJP Parameters" registry <xref target="iana_coj <name slugifiedName="name-join-request-object">Join Request Object</na
p_registry"/>.</t> me>
<t indent="0" pn="section-8.4.1-1">The Join_Request structure is built
<t><list style="symbols"> on a CBOR map object.</t>
<t>role: The identifier of the role that the pledge requests to play in the ne <t indent="0" pn="section-8.4.1-2">The set of parameters that can appe
twork once it joins, encoded as an unsigned integer. ar in a Join_Request object is summarized below.
Possible values are specified in <xref target="table_role_values"/>. The labels can be found in the "Constrained Join Protocol (CoJP) Parameters" reg
This parameter MAY be included. istry,
In case the parameter is omitted, the default value of 0, i.e. the role "6TiSCH <xref target="iana_cojp_registry" format="default" sectionFormat="of" derivedCon
Node", MUST be assumed.</t> tent="Section 11.1"/>.</t>
<t>network identifier: The identifier of the network, as discussed in <xref ta <dl spacing="normal" indent="3" newline="false" pn="section-8.4.1-3">
rget="provisioning"/>, encoded as a CBOR byte string. <dt pn="section-8.4.1-3.1">role:</dt>
When present in the Join_Request, it hints to the JRC the network that the pledg <dd pn="section-8.4.1-3.2">The identifier of the role that the pledg
e is requesting to join, enabling the JRC to manage multiple networks. e 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" sectionFormat="of" derivedContent="Table 3"/>.
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 pn="section-8.4.1-3.3">network identifier:</dt>
<dd pn="section-8.4.1-3.4">The identifier of the network, as discuss
ed in
<xref target="provisioning" format="default" sectionFormat="of" derivedContent="
Section 3"/>, 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 pn="section-8.4.1-3.5">unsupported configuration:</dt>
pported by the implementation, encoded as an Unsupported_Configuration object de <dd pn="section-8.4.1-3.6">The identifier of the parameters that are
scribed in <xref target="unsupported_configuration_object"/>. not supported by
This parameter MAY be included. the implementation, encoded as an Unsupported_Configuration object described in
If a (6LBR) pledge previously attempted to join and received a valid Join Respon <xref target="unsupported_configuration_object" format="default" sectionFormat="
se message over OSCORE, but failed to act on its payload (Configuration object), of" derivedContent="Section 8.4.5"/>.
it SHOULD include this parameter to facilitate the recovery and debugging.</t> This parameter <bcp14>MAY</bcp14> be included.
</list></t> If a (6LBR) pledge previously attempted to join and received a valid
Join Response message over OSCORE but failed to act on its payload
<t><xref target="table_join_req_params"/> summarizes the parameters that may app (Configuration object), it <bcp14>SHOULD</bcp14> include this parameter
ear in a Join_Request object.</t> to facilitate the recovery and debugging.</dd>
</dl>
<texttable title="Summary of Join_Request parameters." anchor="table_join_req_pa <t indent="0" pn="section-8.4.1-4"><xref target="table_join_req_params
rams"> " format="default" sectionFormat="of" derivedContent="Table 2"/>
<ttcol align='right'>Name</ttcol> summarizes the parameters that may appear in a Join_Request object.</t>
<ttcol align='left'>Label</ttcol> <table anchor="table_join_req_params" align="center" pn="table-2">
<ttcol align='right'>CBOR Type</ttcol> <name slugifiedName="name-summary-of-join_request-par">Summary of Jo
<c>role</c> in_Request parameters.</name>
<c>1</c> <thead>
<c>unsigned integer</c> <tr>
<c>network identifier</c> <th align="left" colspan="1" rowspan="1">Name</th>
<c>5</c> <th align="left" colspan="1" rowspan="1">Label</th>
<c>byte string</c> <th align="left" colspan="1" rowspan="1">CBOR Type</th>
<c>unsupported configuration</c> </tr>
<c>8</c> </thead>
<c>array</c> <tbody>
</texttable> <tr>
<td align="left" colspan="1" rowspan="1">role</td>
<t>The CDDL fragment that represents the text above for the Join_Request follows <td align="left" colspan="1" rowspan="1">1</td>
.</t> <td align="left" colspan="1" rowspan="1">unsigned integer</td>
</tr>
<figure><artwork><![CDATA[ <tr>
<td align="left" colspan="1" rowspan="1">network identifier</td>
<td align="left" colspan="1" rowspan="1">5</td>
<td align="left" colspan="1" rowspan="1">byte string</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">unsupported configurati
on</td>
<td align="left" colspan="1" rowspan="1">8</td>
<td align="left" colspan="1" rowspan="1">array</td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-8.4.1-6">The CDDL fragment that represents t
he text above for the Join_Request follows:</t>
<sourcecode type="" markers="false" pn="section-8.4.1-7">
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" pn="table-3">
<texttable title="Role values." anchor="table_role_values"> <name slugifiedName="name-role-values">Role values.</name>
<ttcol align='right'>Name</ttcol> <thead>
<ttcol align='left'>Value</ttcol> <tr>
<ttcol align='right'>Description</ttcol> <th align="left" colspan="1" rowspan="1">Name</th>
<ttcol align='left'>Reference</ttcol> <th align="left" colspan="1" rowspan="1">Value</th>
<c>6TiSCH Node</c> <th align="left" colspan="1" rowspan="1">Description</th>
<c>0</c> <th align="left" colspan="1" rowspan="1">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 align="left" colspan="1" rowspan="1">6TiSCH Node</td>
<c>The pledge requests to play the role of 6LoWPAN Border Router (6LBR).</ <td align="left" colspan="1" rowspan="1">0</td>
c> <td align="left" colspan="1" rowspan="1">The pledge requests to
<c>[[this document]]</c> play the role of a regular 6TiSCH node, i.e., non-6LBR node.</td>
</texttable> <td align="left" colspan="1" rowspan="1">RFC 9031</td>
</tr>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> <tr>
<td align="left" colspan="1" rowspan="1">6LBR</td>
</section> <td align="left" colspan="1" rowspan="1">1</td>
<section anchor="configuration_object" title="Configuration Object"> <td align="left" colspan="1" rowspan="1">The pledge requests to
play the role of 6LoWPAN Border Router (6LBR).</td>
<t>The Configuration structure is built on a CBOR map object. <td align="left" colspan="1" rowspan="1">RFC 9031</td>
</tr>
</tbody>
</table>
</section>
<section anchor="configuration_object" numbered="true" toc="exclude" rem
oveInRFC="false" pn="section-8.4.2">
<name slugifiedName="name-configuration-object">Configuration Object</
name>
<t indent="0" pn="section-8.4.2-1">The Configuration structure is buil
t 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" sectionFormat="of" derived
Content="Section 11.1"/>.</t>
<t><list style="symbols"> <dl spacing="normal" indent="3" newline="false" pn="section-8.4.2-2">
<t>link-layer key set: An array encompassing a set of cryptographic keys and t <dt pn="section-8.4.2-2.1">link-layer key set:</dt>
heir identifiers that are currently in use in the network, or that are scheduled <dd pn="section-8.4.2-2.2">An array encompassing a set of cryptograp
to be used in the future. hic keys
The encoding of individual keys is described in <xref target="ll_keys"/>. and their identifiers that are currently in use in the network
The link-layer key set parameter MAY be included in a Configuration object. or that are scheduled to be used in the future.
When present, the link-layer key set parameter MUST contain at least one key. The encoding of individual keys is described in <xref target="ll_keys" format="d
efault" sectionFormat="of" derivedContent="Section 8.4.3"/>.
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" sectionFormat="of" derivedContent="8.4.3.1"/>
<t>short identifier: a compact identifier assigned to the pledge. and <xref target="keychanging6lr" format="counter" sectionFormat="of" derivedCon
The short identifier structure is described in <xref target="short_identifier"/> tent="8.4.3.2"/>.</dd>
. <dt pn="section-8.4.2-2.3">short identifier: </dt>
The short identifier parameter MAY be included in a Configuration object.</t> <dd pn="section-8.4.2-2.4">A compact identifier assigned to the pled
<t>JRC address: the IPv6 address of the JRC, encoded as a byte string, with th ge.
e length of 16 bytes. The short identifier structure is described in <xref target="short_identifier" f
If the length of the byte string is different from 16, the parameter MUST be dis ormat="default" sectionFormat="of" derivedContent="Section 8.4.4"/>.
carded. The short identifier parameter <bcp14>MAY</bcp14> be included in a Configuration
If the JRC is not co-located with the 6LBR and has a different IPv6 address than object.</dd>
the 6LBR, this parameter MUST be included. <dt pn="section-8.4.2-2.5">JRC address:</dt>
In the special case where the JRC is co-located with the 6LBR and has the same I <dd pn="section-8.4.2-2.6">The IPv6 address of the JRC, encoded as a
Pv6 address as the 6LBR, this parameter MAY be included. byte string, with the length of 16 bytes.
If the JRC address parameter is not present in the Configuration object, this in If the length of the byte string is different from 16, the parameter <bcp14>MUST
dicates that the JRC has the same IPv6 address as the 6LBR. </bcp14> be discarded.
If the JRC is not co-located with the 6LBR and has a different IPv6 address than
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" sectionFormat="of" derivedContent="Se
<t>blacklist: An array encompassing a list of pledge identifiers that are blac ction 6"/>.</dd>
klisted by the JRC, with each pledge identifier encoded as a byte string. <dt pn="section-8.4.2-2.7">blacklist:</dt>
The blacklist parameter MAY be included in a Configuration object. <dd pn="section-8.4.2-2.8">An array encompassing a list of pledge id
When present, the array MUST contain zero or more byte strings encoding pledge i entifiers
dentifiers. that are blacklisted by the JRC, with each pledge identifier encoded as a byte s
The joined node MUST silently drop any link-layer frames originating from the pl tring.
edge identifiers enclosed in the blacklist parameter. The blacklist parameter <bcp14>MAY</bcp14> be included in a Configuration object
When this parameter is received, its value MUST overwrite any previously set val .
ues. When present, the array <bcp14>MUST</bcp14> contain zero or more byte strings en
This parameter allows the JRC to configure the node acting as a JP to filter out coding pledge identifiers.
traffic from misconfigured or malicious pledges before their traffic is forward The joined node <bcp14>MUST</bcp14> silently drop any link-layer frames
ed into the network. originating from the pledge identifiers enclosed in the blacklist parameter.
If the JRC decides to remove a given pledge identifier from a blacklist, it omit When this parameter is received, its value <bcp14>MUST</bcp14> overwrite any pre
s the pledge identifier in the blacklist parameter value it sends next. viously set values.
This parameter allows the JRC to configure the node acting as a JP to filter out
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" sectionFormat="of" de
<t>join rate: Average data rate (in units of bytes/second) of join traffic for rivedContent="Section 10"/>.</dd>
warded into the network that should not be exceeded when a joined node operates <dt pn="section-8.4.2-2.9">join rate:</dt>
as a JP, encoded as an unsigned integer. <dd pn="section-8.4.2-2.10">The average data rate (in units of bytes
The join rate parameter MAY be included in a Configuration object. /second) of join traffic
This parameter allows the JRC to configure different nodes in the network to ope forwarded into the network that should not be exceeded when a joined node operat
rate as JP, and act in case of an attack by throttling the rate at which JP forw es
ards unauthenticated traffic into the network. as a JP, encoded as an unsigned integer.
When this parameter is present in a Configuration object, the value MUST be used The join rate parameter <bcp14>MAY</bcp14> be included in a Configuration object
to set the PROBING_RATE of CoAP at the joined node for communication with the J .
RC. This parameter allows the JRC to configure different nodes in the network to
In case this parameter is set to zero, a joined node MUST silently drop any join operate as JP and to act in case of an attack by throttling the rate at which JP
traffic coming from unauthenticated pledges. forwards unauthenticated traffic into the network.
In case this parameter is omitted, the value of positive infinity SHOULD be assu When this parameter is present in a Configuration object, the value <bcp14>MUST<
med. /bcp14>
Node operating as a JP MAY use another mechanism that is out of scope of this sp be used to set the PROBING_RATE of CoAP at the joined node for communication wit
ecification to configure PROBING_RATE of CoAP in the absence of a join rate para h the JRC.
meter from the Configuration object.</t> If this parameter is set to zero, a joined node <bcp14>MUST</bcp14> silently dro
</list></t> p
any join traffic coming from unauthenticated pledges.
<t><xref target="table_configuration_params"/> summarizes the parameters that ma If this parameter is omitted, the value of positive infinity <bcp14>SHOULD</bcp1
y appear in a Configuration object.</t> 4> be assumed.
A node operating as a JP <bcp14>MAY</bcp14> use another mechanism that is out of
<texttable title="Summary of Configuration parameters." anchor="table_configurat scope
ion_params"> of this specification to configure the PROBING_RATE of CoAP in the absence of a
<ttcol align='right'>Name</ttcol> join rate parameter from the Configuration object.</dd>
<ttcol align='left'>Label</ttcol> </dl>
<ttcol align='right'>CBOR Type</ttcol> <t indent="0" pn="section-8.4.2-3"><xref target="table_configuration_p
<c>link-layer key set</c> arams" format="default" sectionFormat="of" derivedContent="Table 4"/>
<c>2</c> summarizes the parameters that may appear in a Configuration object.</t>
<c>array</c> <table anchor="table_configuration_params" align="center" pn="table-4"
<c>short identifier</c> >
<c>3</c> <name slugifiedName="name-summary-of-configuration-pa">Summary of Co
<c>array</c> nfiguration parameters.</name>
<c>JRC address</c> <thead>
<c>4</c> <tr>
<c>byte string</c> <th align="left" colspan="1" rowspan="1">Name</th>
<c>blacklist</c> <th align="left" colspan="1" rowspan="1">Label</th>
<c>6</c> <th align="left" colspan="1" rowspan="1">CBOR Type</th>
<c>array</c> </tr>
<c>join rate</c> </thead>
<c>7</c> <tbody>
<c>unsigned integer</c> <tr>
</texttable> <td align="left" colspan="1" rowspan="1">link-layer key set</td>
<td align="left" colspan="1" rowspan="1">2</td>
<t>The CDDL fragment that represents the text above for the Configuration follow <td align="left" colspan="1" rowspan="1">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 align="left" colspan="1" rowspan="1">short identifier</td>
<td align="left" colspan="1" rowspan="1">3</td>
<figure><artwork><![CDATA[ <td align="left" colspan="1" rowspan="1">array</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">JRC address</td>
<td align="left" colspan="1" rowspan="1">4</td>
<td align="left" colspan="1" rowspan="1">byte string</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">blacklist</td>
<td align="left" colspan="1" rowspan="1">6</td>
<td align="left" colspan="1" rowspan="1">array</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">join rate</td>
<td align="left" colspan="1" rowspan="1">7</td>
<td align="left" colspan="1" rowspan="1">unsigned integer</td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-8.4.2-5">The CDDL fragment that represents t
he text above for the Configuration follows.
The structures Link_Layer_Key and Short_Identifier are specified in
Sections <xref target="ll_keys" format="counter" sectionFormat="of" derivedConte
nt="8.4.3"/> and <xref target="short_identifier" format="counter" sectionFormat=
"of" derivedContent="8.4.4"/>,
respectively.</t>
<sourcecode type="" markers="false" pn="section-8.4.2-6">
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>
<table anchor="table_cojp_parameters_labels" align="center" pn="table-
<texttable title="CoJP parameters map labels." anchor="table_cojp_parameters_lab 5">
els"> <name slugifiedName="name-cojp-parameters-map-labels">CoJP parameter
<ttcol align='right'>Name</ttcol> s map labels.</name>
<ttcol align='left'>Label</ttcol> <thead>
<ttcol align='right'>CBOR type</ttcol> <tr>
<ttcol align='left'>Description</ttcol> <th align="left" colspan="1" rowspan="1">Name</th>
<ttcol align='left'>Reference</ttcol> <th align="left" colspan="1" rowspan="1">Label</th>
<c>role</c> <th align="left" colspan="1" rowspan="1">CBOR type</th>
<c>1</c> <th align="left" colspan="1" rowspan="1">Description</th>
<c>unsigned integer</c> <th align="left" colspan="1" rowspan="1">Reference</th>
<c>Identifies the role parameter</c> </tr>
<c>[[this document]]</c> </thead>
<c>link-layer key set</c> <tbody>
<c>2</c> <tr>
<c>array</c> <td align="left" colspan="1" rowspan="1">role</td>
<c>Identifies the array carrying one or more link-level cryptographic keys <td align="left" colspan="1" rowspan="1">1</td>
</c> <td align="left" colspan="1" rowspan="1">unsigned integer</td>
<c>[[this document]]</c> <td align="left" colspan="1" rowspan="1">Identifies the role par
<c>short identifier</c> ameter</td>
<c>3</c> <td align="left" colspan="1" rowspan="1">RFC 9031</td>
<c>array</c> </tr>
<c>Identifies the assigned short identifier</c> <tr>
<c>[[this document]]</c> <td align="left" colspan="1" rowspan="1">link-layer key set</td>
<c>JRC address</c> <td align="left" colspan="1" rowspan="1">2</td>
<c>4</c> <td align="left" colspan="1" rowspan="1">array</td>
<c>byte string</c> <td align="left" colspan="1" rowspan="1">Identifies the array ca
<c>Identifies the IPv6 address of the JRC</c> rrying one or more link-layer cryptographic keys</td>
<c>[[this document]]</c> <td align="left" colspan="1" rowspan="1">RFC 9031</td>
<c>network identifier</c> </tr>
<c>5</c> <tr>
<c>byte string</c> <td align="left" colspan="1" rowspan="1">short identifier</td>
<c>Identifies the network identifier parameter</c> <td align="left" colspan="1" rowspan="1">3</td>
<c>[[this document]]</c> <td align="left" colspan="1" rowspan="1">array</td>
<c>blacklist</c> <td align="left" colspan="1" rowspan="1">Identifies the assigned
<c>6</c> short identifier</td>
<c>array</c> <td align="left" colspan="1" rowspan="1">RFC 9031</td>
<c>Identifies the blacklist parameter</c> </tr>
<c>[[this document]]</c> <tr>
<c>join rate</c> <td align="left" colspan="1" rowspan="1">JRC address</td>
<c>7</c> <td align="left" colspan="1" rowspan="1">4</td>
<c>unsigned integer</c> <td align="left" colspan="1" rowspan="1">byte string</td>
<c>Identifier the join rate parameter</c> <td align="left" colspan="1" rowspan="1">Identifies the IPv6 add
<c>[[this document]]</c> ress of the JRC</td>
<c>unsupported configuration</c> <td align="left" colspan="1" rowspan="1">RFC 9031</td>
<c>8</c> </tr>
<c>array</c> <tr>
<c>Identifies the unsupported configuration parameter</c> <td align="left" colspan="1" rowspan="1">network identifier</td>
<c>[[this document]]</c> <td align="left" colspan="1" rowspan="1">5</td>
</texttable> <td align="left" colspan="1" rowspan="1">byte string</td>
<td align="left" colspan="1" rowspan="1">Identifies the network
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> identifier parameter</td>
<td align="left" colspan="1" rowspan="1">RFC 9031</td>
</section> </tr>
<section anchor="ll_keys" title="Link-Layer Key"> <tr>
<td align="left" colspan="1" rowspan="1">blacklist</td>
<t>The Link_Layer_Key structure encompasses the parameters needed to configure t <td align="left" colspan="1" rowspan="1">6</td>
he link-layer security module: <td align="left" colspan="1" rowspan="1">array</td>
<td align="left" colspan="1" rowspan="1">Identifies the blacklis
t parameter</td>
<td align="left" colspan="1" rowspan="1">RFC 9031</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">join rate</td>
<td align="left" colspan="1" rowspan="1">7</td>
<td align="left" colspan="1" rowspan="1">unsigned integer</td>
<td align="left" colspan="1" rowspan="1">Identifier the join rat
e parameter</td>
<td align="left" colspan="1" rowspan="1">RFC 9031</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">unsupported configurati
on</td>
<td align="left" colspan="1" rowspan="1">8</td>
<td align="left" colspan="1" rowspan="1">array</td>
<td align="left" colspan="1" rowspan="1">Identifies the unsuppor
ted configuration parameter</td>
<td align="left" colspan="1" rowspan="1">RFC 9031</td>
</tr>
</tbody>
</table>
</section>
<section anchor="ll_keys" numbered="true" toc="exclude" removeInRFC="fal
se" pn="section-8.4.3">
<name slugifiedName="name-link-layer-key">Link-Layer Key</name>
<t indent="0" pn="section-8.4.3-1">The Link_Layer_Key structure encomp
asses the parameters needed to configure 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 indent="0" pn="section-8.4.3-2">For encoding compactness, the Link_
<t>For encoding compactness, the Link_Layer_Key object is not enclosed in a top- Layer_Key object is not enclosed 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" sectionFormat="of" derivedContent="RFC8742"/>, some being optio
cbor-sequence"/>, some being optional.</t> nal.</t>
<t indent="0" pn="section-8.4.3-3">The set of parameters that can appe
<t>The set of parameters that can appear in a Link_Layer_Key object is summarize ar in a Link_Layer_Key object is summarized below, in order:</t>
d below, in order:</t> <dl spacing="normal" indent="3" newline="false" pn="section-8.4.3-4">
<dt pn="section-8.4.3-4.1">key_id:</dt>
<t><list style="symbols"> <dd pn="section-8.4.3-4.2">The identifier of the key, encoded as a C
<t>key_id: The identifier of the key, encoded as a CBOR unsigned integer. BOR unsigned integer.
This parameter MUST be included. This parameter <bcp14>MUST</bcp14> be included.
If the decoded CBOR unsigned integer value is larger than the maximum link-layer If the decoded CBOR unsigned integer value is larger than the maximum link-layer
key identifier, the key is considered invalid. key identifier, the key is considered invalid.
In case the key is considered invalid, the key MUST be discarded and the impleme If the key is considered invalid, the key <bcp14>MUST</bcp14> be discarded,
ntation MUST signal the error as specified in <xref target="cojp_error_handling" and the implementation <bcp14>MUST</bcp14> signal the error as specified in
/>.</t> <xref target="cojp_error_handling" format="default" sectionFormat="of" derivedCo
<t>key_usage: The identifier of the link-layer algorithm, security level and l ntent="Section 8.3.1"/>.</dd>
ink-layer frame types that can be used with the key, encoded as an integer. <dt pn="section-8.4.3-4.3">key_usage:</dt>
This parameter MAY be included. <dd pn="section-8.4.3-4.4">The identifier of the link-layer algorith
Possible values and the corresponding link-layer settings are specified in IANA m, security level, and
"CoJP Key Usage" registry (<xref target="iana_cojp_key_usage_registry"/>). link-layer frame types that can be used with the key, encoded as an integer.
In case the parameter is omitted, the default value of 0 (6TiSCH-K1K2-ENC-MIC32) This parameter <bcp14>MAY</bcp14> be included.
from <xref target="table_key_usage_values"/> MUST be assumed. Possible values and the corresponding link-layer settings are specified in the
This default value has been chosen such that it results in byte savings in the m IANA "Constrained Join Protocol (CoJP) Key Usage" registry (<xref target="iana_c
ost constrained settings but does not imply a recommendation for its general usa ojp_key_usage_registry" format="default" sectionFormat="of" derivedContent="Sect
ge.</t> ion 11.2"/>).
<t>key_value: The value of the cryptographic key, encoded as a byte string. If the parameter is omitted, the default value of 0 (6TiSCH-K1K2-ENC-MIC32)
This parameter MUST be included. from <xref target="table_key_usage_values" format="default" sectionFormat="of" d
If the length of the byte string is different than the corresponding key length erivedContent="Table 6"/> <bcp14>MUST</bcp14> be assumed.
for a given algorithm specified by the key_usage parameter, the key MUST be disc This default value has been chosen because it results in byte savings
arded and the implementation MUST signal the error as specified in <xref target= in the most constrained settings; its selection does not imply a recommendation
"cojp_error_handling"/>.</t> for its general usage.</dd>
<t>key_addinfo: Additional information needed to configure the link-layer key, <dt pn="section-8.4.3-4.5">key_value:</dt>
encoded as a byte string. <dd pn="section-8.4.3-4.6">The value of the cryptographic key, encod
This parameter MAY be included. ed as a byte string.
The processing of this parameter is dependent on the link-layer technology in us This parameter <bcp14>MUST</bcp14> be included.
e and a particular keying mode.</t> If the length of the byte string is different than the corresponding key length
</list></t> for a given algorithm specified by the key_usage parameter, the key
<bcp14>MUST</bcp14> be discarded, and the implementation <bcp14>MUST</bcp14>
<t>To be able to decode the keys that are present in the link-layer key set, and signal the error as specified in <xref target="cojp_error_handling" format="defa
to identify individual parameters of a single Link_Layer_Key object, the CBOR d ult" sectionFormat="of" derivedContent="Section 8.3.1"/>.</dd>
ecoder needs to differentiate between elements based on the CBOR type. <dt pn="section-8.4.3-4.7">key_addinfo:</dt>
<dd pn="section-8.4.3-4.8">Additional information needed to configur
e the link-layer key,
encoded as a byte string.
This parameter <bcp14>MAY</bcp14> be included.
The processing of this parameter is dependent on the link-layer technology
in use and a particular keying mode.</dd>
</dl>
<t indent="0" pn="section-8.4.3-5">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 indent="0" pn="section-8.4.3-6">The CDDL fragment for the Link_Laye
<t>The CDDL fragment that represents the text above for the Link_Layer_Key follo r_Key that
ws.</t> represents the text above follows:</t>
<sourcecode type="" markers="false" pn="section-8.4.3-7">
<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>
<table anchor="table_key_usage_values" align="center" pn="table-6">
<texttable title="Key Usage values." anchor="table_key_usage_values"> <name slugifiedName="name-key-usage-values">Key Usage values.</name>
<ttcol align='right'>Name</ttcol> <thead>
<ttcol align='left'>Value</ttcol> <tr>
<ttcol align='right'>Algorithm</ttcol> <th align="left" colspan="1" rowspan="1">Name</th>
<ttcol align='left'>Description</ttcol> <th align="left" colspan="1" rowspan="1">Value</th>
<ttcol align='left'>Reference</ttcol> <th align="left" colspan="1" rowspan="1">Algorithm</th>
<c>6TiSCH-K1K2-ENC-MIC32</c> <th align="left" colspan="1" rowspan="1">Description</th>
<c>0</c> </tr>
<c>IEEE802154-AES-CCM-128</c> </thead>
<c>Use MIC-32 for EBs, ENC-MIC-32 for DATA and ACKNOWLEDGMENT.</c> <tbody>
<c>[[this document]]</c> <tr>
<c>6TiSCH-K1K2-ENC-MIC64</c> <td align="left" colspan="1" rowspan="1">6TiSCH-K1K2-ENC-MIC32</
<c>1</c> td>
<c>IEEE802154-AES-CCM-128</c> <td align="left" colspan="1" rowspan="1">0</td>
<c>Use MIC-64 for EBs, ENC-MIC-64 for DATA and ACKNOWLEDGMENT.</c> <td align="left" colspan="1" rowspan="1">IEEE802154-AES-CCM-128<
<c>[[this document]]</c> /td>
<c>6TiSCH-K1K2-ENC-MIC128</c> <td align="left" colspan="1" rowspan="1">Use MIC-32 for EBs, ENC
<c>2</c> -MIC-32 for DATA and ACKNOWLEDGMENT.</td>
<c>IEEE802154-AES-CCM-128</c> </tr>
<c>Use MIC-128 for EBs, ENC-MIC-128 for DATA and ACKNOWLEDGMENT.</c> <tr>
<c>[[this document]]</c> <td align="left" colspan="1" rowspan="1">6TiSCH-K1K2-ENC-MIC64</
<c>6TiSCH-K1K2-MIC32</c> td>
<c>3</c> <td align="left" colspan="1" rowspan="1">1</td>
<c>IEEE802154-AES-CCM-128</c> <td align="left" colspan="1" rowspan="1">IEEE802154-AES-CCM-128<
<c>Use MIC-32 for EBs, DATA and ACKNOWLEDGMENT.</c> /td>
<c>[[this document]]</c> <td align="left" colspan="1" rowspan="1">Use MIC-64 for EBs, ENC
<c>6TiSCH-K1K2-MIC64</c> -MIC-64 for DATA and ACKNOWLEDGMENT.</td>
<c>4</c> </tr>
<c>IEEE802154-AES-CCM-128</c> <tr>
<c>Use MIC-64 for EBs, DATA and ACKNOWLEDGMENT.</c> <td align="left" colspan="1" rowspan="1">6TiSCH-K1K2-ENC-MIC128<
<c>[[this document]]</c> /td>
<c>6TiSCH-K1K2-MIC128</c> <td align="left" colspan="1" rowspan="1">2</td>
<c>5</c> <td align="left" colspan="1" rowspan="1">IEEE802154-AES-CCM-128<
<c>IEEE802154-AES-CCM-128</c> /td>
<c>Use MIC-128 for EBs, DATA and ACKNOWLEDGMENT.</c> <td align="left" colspan="1" rowspan="1">Use MIC-128 for EBs, EN
<c>[[this document]]</c> C-MIC-128 for DATA and ACKNOWLEDGMENT.</td>
<c>6TiSCH-K1-MIC32</c> </tr>
<c>6</c> <tr>
<c>IEEE802154-AES-CCM-128</c> <td align="left" colspan="1" rowspan="1">6TiSCH-K1K2-MIC32</td>
<c>Use MIC-32 for EBs.</c> <td align="left" colspan="1" rowspan="1">3</td>
<c>[[this document]]</c> <td align="left" colspan="1" rowspan="1">IEEE802154-AES-CCM-128<
<c>6TiSCH-K1-MIC64</c> /td>
<c>7</c> <td align="left" colspan="1" rowspan="1">Use MIC-32 for EBs, DAT
<c>IEEE802154-AES-CCM-128</c> A and ACKNOWLEDGMENT.</td>
<c>Use MIC-64 for EBs.</c> </tr>
<c>[[this document]]</c> <tr>
<c>6TiSCH-K1-MIC128</c> <td align="left" colspan="1" rowspan="1">6TiSCH-K1K2-MIC64</td>
<c>8</c> <td align="left" colspan="1" rowspan="1">4</td>
<c>IEEE802154-AES-CCM-128</c> <td align="left" colspan="1" rowspan="1">IEEE802154-AES-CCM-128<
<c>Use MIC-128 for EBs.</c> /td>
<c>[[this document]]</c> <td align="left" colspan="1" rowspan="1">Use MIC-64 for EBs, DAT
<c>6TiSCH-K2-MIC32</c> A and ACKNOWLEDGMENT.</td>
<c>9</c> </tr>
<c>IEEE802154-AES-CCM-128</c> <tr>
<c>Use MIC-32 for DATA and ACKNOWLEDGMENT.</c> <td align="left" colspan="1" rowspan="1">6TiSCH-K1K2-MIC128</td>
<c>[[this document]]</c> <td align="left" colspan="1" rowspan="1">5</td>
<c>6TiSCH-K2-MIC64</c> <td align="left" colspan="1" rowspan="1">IEEE802154-AES-CCM-128<
<c>10</c> /td>
<c>IEEE802154-AES-CCM-128</c> <td align="left" colspan="1" rowspan="1">Use MIC-128 for EBs, DA
<c>Use MIC-64 for DATA and ACKNOWLEDGMENT.</c> TA and ACKNOWLEDGMENT.</td>
<c>[[this document]]</c> </tr>
<c>6TiSCH-K2-MIC128</c> <tr>
<c>11</c> <td align="left" colspan="1" rowspan="1">6TiSCH-K1-MIC32</td>
<c>IEEE802154-AES-CCM-128</c> <td align="left" colspan="1" rowspan="1">6</td>
<c>Use MIC-128 for DATA and ACKNOWLEDGMENT.</c> <td align="left" colspan="1" rowspan="1">IEEE802154-AES-CCM-128<
<c>[[this document]]</c> /td>
<c>6TiSCH-K2-ENC-MIC32</c> <td align="left" colspan="1" rowspan="1">Use MIC-32 for EBs.</td
<c>12</c> >
<c>IEEE802154-AES-CCM-128</c> </tr>
<c>Use ENC-MIC-32 for DATA and ACKNOWLEDGMENT.</c> <tr>
<c>[[this document]]</c> <td align="left" colspan="1" rowspan="1">6TiSCH-K1-MIC64</td>
<c>6TiSCH-K2-ENC-MIC64</c> <td align="left" colspan="1" rowspan="1">7</td>
<c>13</c> <td align="left" colspan="1" rowspan="1">IEEE802154-AES-CCM-128<
<c>IEEE802154-AES-CCM-128</c> /td>
<c>Use ENC-MIC-64 for DATA and ACKNOWLEDGMENT.</c> <td align="left" colspan="1" rowspan="1">Use MIC-64 for EBs.</td
<c>[[this document]]</c> >
<c>6TiSCH-K2-ENC-MIC128</c> </tr>
<c>14</c> <tr>
<c>IEEE802154-AES-CCM-128</c> <td align="left" colspan="1" rowspan="1">6TiSCH-K1-MIC128</td>
<c>Use ENC-MIC-128 for DATA and ACKNOWLEDGMENT.</c> <td align="left" colspan="1" rowspan="1">8</td>
<c>[[this document]]</c> <td align="left" colspan="1" rowspan="1">IEEE802154-AES-CCM-128<
</texttable> /td>
<td align="left" colspan="1" rowspan="1">Use MIC-128 for EBs.</t
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> d>
</tr>
<section anchor="keychanging6lbr" title="Rekeying of (6LoWPAN) Border Routers (6 <tr>
LBR)"> <td align="left" colspan="1" rowspan="1">6TiSCH-K2-MIC32</td>
<td align="left" colspan="1" rowspan="1">9</td>
<t>When the 6LoWPAN Border Router (6LBR) receives the Configuration object conta <td align="left" colspan="1" rowspan="1">IEEE802154-AES-CCM-128<
ining a link-layer key set, it MUST immediately install and start using the new /td>
keys for all outgoing traffic, and remove any old keys it has installed from the <td align="left" colspan="1" rowspan="1">Use MIC-32 for DATA and
previous key set after a delay of COJP_REKEYING_GUARD_TIME has passed. ACKNOWLEDGMENT.</td>
This mechanism is used by the JRC to force the 6LBR to start sending traffic wit </tr>
h the new key. <tr>
The decision is taken by the JRC when it has determined that the new key has bee <td align="left" colspan="1" rowspan="1">6TiSCH-K2-MIC64</td>
n made available to all (or some overwhelming majority) of nodes. <td align="left" colspan="1" rowspan="1">10</td>
Any node that the JRC has not yet reached at that point is either non-functional <td align="left" colspan="1" rowspan="1">IEEE802154-AES-CCM-128<
or in extended sleep such that it will not be reached. /td>
To get the key update, such node needs to go through the join process anew.</t> <td align="left" colspan="1" rowspan="1">Use MIC-64 for DATA and
ACKNOWLEDGMENT.</td>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> </tr>
<tr>
</section> <td align="left" colspan="1" rowspan="1">6TiSCH-K2-MIC128</td>
<section anchor="keychanging6lr" title="Rekeying of regular (6LoWPAN) Nodes (6LN <td align="left" colspan="1" rowspan="1">11</td>
)"> <td align="left" colspan="1" rowspan="1">IEEE802154-AES-CCM-128<
/td>
<t>When a regular 6LN node receives the Configuration object with a link-layer k <td align="left" colspan="1" rowspan="1">Use MIC-128 for DATA an
ey set, it MUST install the new keys. d ACKNOWLEDGMENT.</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">6TiSCH-K2-ENC-MIC32</td
>
<td align="left" colspan="1" rowspan="1">12</td>
<td align="left" colspan="1" rowspan="1">IEEE802154-AES-CCM-128<
/td>
<td align="left" colspan="1" rowspan="1">Use ENC-MIC-32 for DATA
and ACKNOWLEDGMENT.</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">6TiSCH-K2-ENC-MIC64</td
>
<td align="left" colspan="1" rowspan="1">13</td>
<td align="left" colspan="1" rowspan="1">IEEE802154-AES-CCM-128<
/td>
<td align="left" colspan="1" rowspan="1">Use ENC-MIC-64 for DATA
and ACKNOWLEDGMENT.</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">6TiSCH-K2-ENC-MIC128</t
d>
<td align="left" colspan="1" rowspan="1">14</td>
<td align="left" colspan="1" rowspan="1">IEEE802154-AES-CCM-128<
/td>
<td align="left" colspan="1" rowspan="1">Use ENC-MIC-128 for DAT
A and ACKNOWLEDGMENT.</td>
</tr>
</tbody>
</table>
<section anchor="keychanging6lbr" numbered="true" toc="exclude" remove
InRFC="false" pn="section-8.4.3.1">
<name slugifiedName="name-rekeying-of-6lbrs">Rekeying of 6LBRs</name
>
<t indent="0" pn="section-8.4.3.1-1">When the 6LBR receives the Conf
iguration 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 anchor="keychanging6lr" numbered="true" toc="exclude" removeI
nRFC="false" pn="section-8.4.3.2">
<name slugifiedName="name-rekeying-of-6lns">Rekeying of 6LNs</name>
<t indent="0" pn="section-8.4.3.2-1">When a regular 6LN receives the
Configuration object
with a link-layer key set, it <bcp14>MUST</bcp14> 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 indent="0" pn="section-8.4.3.2-2">The detection of the network sw
with the new keys. itch is based
Upon reception and successful security processing of a link-layer frame secured upon the receipt of traffic secured with the new keys.
with a key from the new key set, a 6LN node MUST then switch to sending outgoing Upon the reception and the successful security processing of a link-layer
traffic using the keys from the new set for all outgoing traffic. frame secured with a key from the new key set, a 6LN <bcp14>MUST</bcp14>
The 6LN node MUST remove any old keys it has installed from the previous key set then switch to sending all outgoing traffic using the keys from the
after a delay of COJP_REKEYING_GUARD_TIME has passed after it starts using the new set.
new key set.</t> The 6LN <bcp14>MUST</bcp14> remove any keys it had installed
from the previous key set after waiting COJP_REKEYING_GUARD_TIME since
<t>Sending of traffic with the new keys signals to other downstream nodes to swi it started using the new key set.
tch to their new key, and the effect is that there is a ripple of key updates ar </t>
ound each 6LBR.</t> <t indent="0" pn="section-8.4.3.2-3">Sending traffic with the new ke
ys signals to other
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> 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="exclude"
removeInRFC="false" pn="section-8.4.3.3">
<t>When Link_Layer_Key is used in the context of <xref target="IEEE802.15.4"/>, <name slugifiedName="name-use-in-ieee-std-802154">Use in IEEE Std 80
the following considerations apply.</t> 2.15.4</name>
<t indent="0" pn="section-8.4.3.3-1">When Link_Layer_Key is used in
<t>Signaling of different keying modes of <xref target="IEEE802.15.4"/> is done the context of <xref target="IEEE802.15.4" format="default" sectionFormat="of" d
based on the parameter values present in a Link_Layer_Key object. erivedContent="IEEE802.15.4"/>, the following considerations apply.</t>
For instance, the value of the key_id parameter in combination with key_addinfo <t indent="0" pn="section-8.4.3.3-2">Signaling of different keying m
denotes which of the four Key ID modes of <xref target="IEEE802.15.4"/> is used odes of <xref target="IEEE802.15.4" format="default" sectionFormat="of" derivedC
and how.</t> ontent="IEEE802.15.4"/> is done based on the parameter values present in a Link_
Layer_Key object.
<t><list style="symbols"> For instance, the value of the key_id parameter in combination with key_addinfo
<t>Key ID Mode 0x00 (Implicit, pairwise): denotes which of the four Key ID modes of <xref target="IEEE802.15.4" format="de
key_id parameter MUST be set to 0. fault" sectionFormat="of" derivedContent="IEEE802.15.4"/> is used and how.</t>
key_addinfo parameter MUST be present. <dl spacing="normal" indent="3" newline="false" pn="section-8.4.3.3-
key_addinfo parameter MUST be set to the link-layer address(es) of a single peer 3">
with whom the key should be used. <dt pn="section-8.4.3.3-3.1">Key ID Mode 0x00 (Implicit, pairwise)
Depending on the configuration of the network, key_addinfo may carry the peer's :</dt>
long link-layer address (i.e. pledge identifier), short link-layer address, or t <dd pn="section-8.4.3.3-3.2">The key_id parameter <bcp14>MUST</bcp
heir concatenation with the long address being encoded first. 14> be set to 0.
Which address type(s) is carried is determined from the length of the byte strin The key_addinfo parameter <bcp14>MUST</bcp14> be present.
g.</t> The key_addinfo parameter <bcp14>MUST</bcp14> be set to the link-layer
<t>Key ID Mode 0x01 (Key Index): address(es) of a single peer with whom the key should be used.
key_id parameter MUST be set to a value different than 0. Depending on the configuration of the network, key_addinfo may carry
key_addinfo parameter MUST NOT be present.</t> the peer's long link-layer address (i.e., pledge identifier),
<t>Key ID Mode 0x02 (4-byte Explicit Key Source): short link-layer address, or their concatenation with the long address being enc
key_id parameter MUST be set to a value different than 0. oded first.
key_addinfo parameter MUST be present. Which address type(s) is carried is determined from the length of the byte strin
key_addinfo parameter MUST be set to a byte string, exactly 4 bytes long. g.</dd>
key_addinfo parameter carries the Key Source parameter used to configure <xref t <dt pn="section-8.4.3.3-3.3">Key ID Mode 0x01 (Key Index):</dt>
arget="IEEE802.15.4"/>.</t> <dd pn="section-8.4.3.3-3.4">The key_id parameter <bcp14>MUST</bcp
<t>Key ID Mode 0x03 (8-byte Explicit Key Source): 14> be set to a value different from 0.
key_id parameter MUST be set to a value different than 0. The key_addinfo parameter <bcp14>MUST NOT</bcp14> be present.</dd>
key_addinfo parameter MUST be present. <dt pn="section-8.4.3.3-3.5">Key ID Mode 0x02 (4-byte Explicit Key
key_addinfo parameter MUST be set to a byte string, exactly 8 bytes long. Source):</dt>
key_addinfo parameter carries the Key Source parameter used to configure <xref t <dd pn="section-8.4.3.3-3.6">The key_id parameter <bcp14>MUST</bcp
arget="IEEE802.15.4"/>.</t> 14> be set to a value different from 0.
</list></t> The key_addinfo parameter <bcp14>MUST</bcp14> be present.
The key_addinfo parameter <bcp14>MUST</bcp14> be set to a byte string, exactly 4
<t>In all cases, key_usage parameter determines how a particular key should be u bytes long.
sed in respect to incoming and outgoing security policies.</t> The key_addinfo parameter carries the Key Source parameter used to configure
<xref target="IEEE802.15.4" format="default" sectionFormat="of" derivedContent="
<t>For Key ID Modes 0x01 - 0x03, parameter key_id sets the "secKeyIndex" paramet IEEE802.15.4"/>.</dd>
er of <xref target="IEEE802.15.4"/> that is signaled in all outgoing frames secu <dt pn="section-8.4.3.3-3.7">Key ID Mode 0x03 (8-byte Explicit Key
red with a given key. Source):</dt>
The maximum value key_id can have is 254. <dd pn="section-8.4.3.3-3.8">The key_id parameter <bcp14>MUST</bcp
The value of 255 is reserved in <xref target="IEEE802.15.4"/> and is therefore c 14> be set to a value different from 0.
onsidered invalid.</t> The key_addinfo parameter <bcp14>MUST</bcp14> be present.
The key_addinfo parameter <bcp14>MUST</bcp14> be set to a byte string, exactly 8
<t>Key ID Mode 0x00 (Implicit, pairwise) enables the JRC to act as a trusted thi bytes long.
rd party and assign pairwise keys between nodes in the network. The key_addinfo parameter carries the Key Source parameter used to configure
How JRC learns about the network topology is out of scope of this specification, <xref target="IEEE802.15.4" format="default" sectionFormat="of" derivedContent="
but could be done through 6LBR - JRC signaling for example. IEEE802.15.4"/>.</dd>
Pairwise keys could also be derived through a key agreement protocol executed be </dl>
tween the peers directly, where the authentication is based on the symmetric cry <t indent="0" pn="section-8.4.3.3-4">In all cases, the key_usage par
ptographic material provided to both peers by the JRC. ameter determines how a
particular key should be used with respect to incoming and outgoing security pol
icies.</t>
<t indent="0" pn="section-8.4.3.3-5">For Key ID Modes 0x01 through 0
x03, the key_id parameter
sets the "secKeyIndex" parameter of <xref target="IEEE802.15.4" format="default"
sectionFormat="of" derivedContent="IEEE802.15.4"/>
that is signaled in all outgoing frames secured with a given key.
The maximum value that key_id can have is 254.
The value of 255 is reserved in <xref target="IEEE802.15.4" format="default" sec
tionFormat="of" derivedContent="IEEE802.15.4"/> and is therefore considered inva
lid.</t>
<t indent="0" pn="section-8.4.3.3-6">Key ID Mode 0x00 (Implicit, pai
rwise) enables the JRC to act as a trusted third party and assign pairwise keys
between nodes in the network.
How the JRC learns about the network topology is out of scope of
this specification, but it could be done through 6LBR-JRC signaling, for example
.
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 indent="0" pn="section-8.4.3.3-7">Implementations <bcp14>MUST</bc
<t>Implementations MUST use different link-layer keys when using different authe p14> use different
ntication tag (MIC) lengths, as using the same key with different authentication link-layer keys when using different authentication tag (MIC) lengths,
tag lengths might be unsafe. as using the same key with different authentication 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" sectionFormat="o
f" derivedContent="IEEE802.15.4"/> for more information.</t>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> </section>
</section>
</section> <section anchor="short_identifier" numbered="true" toc="exclude" removeI
</section> nRFC="false" pn="section-8.4.4">
<section anchor="short_identifier" title="Short Identifier"> <name slugifiedName="name-short-identifier">Short Identifier</name>
<t indent="0" pn="section-8.4.4-1">The Short_Identifier object represe
<t>The Short_Identifier object represents an identifier assigned to the pledge. nts an identifier assigned to the pledge.
It is encoded as a CBOR array object, containing, in order:</t> It is encoded as a CBOR array object and contains, in order:</t>
<dl spacing="normal" indent="3" newline="false" pn="section-8.4.4-2">
<t><list style="symbols"> <dt pn="section-8.4.4-2.1">identifier:</dt>
<t>identifier: The short identifier assigned to the pledge, encoded as a byte <dd pn="section-8.4.4-2.2">The short identifier assigned to the pled
string. ge, encoded as a byte string.
This parameter MUST be included. This parameter <bcp14>MUST</bcp14> be included.
The identifier MUST be unique in the set of all identifiers assigned in a networ The identifier <bcp14>MUST</bcp14> be unique in the set of all identifiers assig
k that is managed by a JRC. ned
In case the identifier is invalid, the decoder MUST silently ignore the Short_Id in a network that is managed by a JRC.
entifier object.</t> If the identifier is invalid, the decoder <bcp14>MUST</bcp14> silently
<t>lease_time: The validity of the identifier in hours after the reception of ignore the Short_Identifier object.</dd>
the CBOR object, encoded as a CBOR unsigned integer. <dt pn="section-8.4.4-2.3">lease_time:</dt>
This parameter MAY be included. <dd pn="section-8.4.4-2.4">The validity of the identifier in hours a
The node MUST stop using the assigned short identifier after the expiry of the l fter 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" sectionFormat="of" derivedContent="Sectio
ribed in <xref target="join"/>. n 8.2"/>.
In case this parameter is omitted, the value of positive infinity MUST be assume If the lease expires, then the node <bcp14>SHOULD</bcp14> initiate a new join ex
d, meaning that the identifier is valid for as long as the node participates in change,
the network.</t> as described in <xref target="join" format="default" sectionFormat="of" derivedC
</list></t> ontent="Section 8.1"/>.
If this parameter is omitted, then the value of positive infinity <bcp14>MUST</b
<t>The CDDL fragment that represents the text above for the Short_Identifier fol cp14>
lows.</t> be assumed, meaning that the identifier is valid for as long as the node partici
pates
<figure><artwork><![CDATA[ in the network.</dd>
</dl>
<t indent="0" pn="section-8.4.4-3">The CDDL fragment for the Short_Ide
ntifier that
represents the text above follows:</t>
<sourcecode type="" markers="false" pn="section-8.4.4-4">
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" numbered="true" toc="exclud
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> e" removeInRFC="false" pn="section-8.4.4.1">
<name slugifiedName="name-use-in-ieee-std-802154-2">Use in IEEE Std
<section anchor="use-in-ieee-std-802154-1" title="Use in IEEE Std 802.15.4"> 802.15.4</name>
<t indent="0" pn="section-8.4.4.1-1">When the Short_Identifier is us
<t>When Short_Identifier is used in the context of <xref target="IEEE802.15.4"/> ed in the context of <xref target="IEEE802.15.4" format="default" sectionFormat=
, the following considerations apply.</t> "of" derivedContent="IEEE802.15.4"/>, the following considerations apply.</t>
<t indent="0" pn="section-8.4.4.1-2">The identifier <bcp14>MUST</bcp
<t>The identifier MUST be used to set the short address of IEEE Std 802.15.4 mod 14> be used to set the
ule. short address of the IEEE Std 802.15.4 module.
When operating in TSCH mode, the identifier MUST be unique in the set of all ide When operating in TSCH mode, the identifier <bcp14>MUST</bcp14> be unique in the
ntifiers assigned in multiple networks that share link-layer key(s). set of all identifiers assigned in multiple networks that share link-layer key(
If the length of the byte string corresponding to the identifier parameter is di s).
fferent than 2, the identifier is considered invalid. If the length of the byte string corresponding to the identifier
The values 0xfffe and 0xffff are reserved by <xref target="IEEE802.15.4"/> and t parameter is different from 2, the identifier is considered invalid.
heir use is considered invalid.</t> The values 0xfffe and 0xffff are reserved by <xref target="IEEE802.15.4" format=
"default" sectionFormat="of" derivedContent="IEEE802.15.4"/>,
<t>The security properties offered by the <xref target="IEEE802.15.4"/> link-lay and their use is considered invalid.</t>
er in TSCH mode are conditioned on the uniqueness requirement of the short ident <t indent="0" pn="section-8.4.4.1-3">The security properties offered
ifier (i.e. short address). by the
<xref target="IEEE802.15.4" format="default" sectionFormat="of" derivedContent="
IEEE802.15.4"/> 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 indent="0" pn="section-8.4.4.1-4">The JRC <bcp14>MUST</bcp14> ens
<t>The JRC MUST ensure that at any given time there are never two same short ide ure that at any
ntifiers being used under the same link-layer key. given time there are never two of the same short identifiers being
If the lease_time parameter of a given Short_Identifier object is set to positiv used under the same link-layer key.
e infinity, care needs to be taken that the corresponding identifier is not assi If the lease_time parameter of a given Short_Identifier object is
gned to another node until the JRC is certain that it is no longer in use, poten set to positive infinity, care needs to be taken that the corresponding
tially through out-of-band signaling. identifier is not assigned to another node until the JRC is certain
If the lease_time parameter expires for any reason, the JRC should take into con that it is no longer in use, potentially through out-of-band signaling.
sideration potential ongoing transmissions by the joined node, which may be hang If the lease_time parameter expires for any reason, the JRC should take
ing in the queues, before assigning the same identifier to another node.</t> into consideration potential ongoing transmissions by the joined node,
which may be hanging in the queues, before assigning the same identifier
<t>Care needs to be taken on how the pledge (joined node) configures the expirat to another node.</t>
ion of the lease. <t indent="0" pn="section-8.4.4.1-5">Care needs to be taken on how t
Since units of the lease_time parameter are in hours after the reception of the he pledge (joined node) configures the expiration of the lease.
CBOR object, the pledge needs to convert the received time to the corresponding Since units of the lease_time parameter are in hours after the reception of the
absolute slot number in the network. CBOR object, the pledge needs to convert the received time to the corresponding
The joined node (pledge) MUST only use the absolute slot number as the appropria Absolute Slot Number in the network.
te reference of time to determine whether the assigned short identifier is still The joined node (pledge) <bcp14>MUST</bcp14> only use the
valid.</t> Absolute Slot Number as the appropriate reference of time to determine whether t
he assigned short identifier is still valid.</t>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> </section>
</section>
</section> <section anchor="unsupported_configuration_object" numbered="true" toc="
</section> exclude" removeInRFC="false" pn="section-8.4.5">
<section anchor="unsupported_configuration_object" title="Unsupported Configurat <name slugifiedName="name-unsupported-configuration-o">Unsupported Con
ion Object"> figuration Object</name>
<t indent="0" pn="section-8.4.5-1">The Unsupported_Configuration objec
<t>The Unsupported_Configuration object is encoded as a CBOR array, containing a t is encoded as a CBOR array, containing at least one Unsupported_Parameter obje
t least one Unsupported_Parameter object. ct.
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" indent="3" newline="false" pn="section-8.4.5-2">
<t><list style="symbols"> <dt pn="section-8.4.5-2.1">code:</dt>
<t>code: Indicates the capability of acting on the parameter signaled by param <dd pn="section-8.4.5-2.2">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" sectionForm
<t>parameter_label: Indicates the parameter. at="of" derivedContent="Section 11.3"/>).</dd>
This parameter MUST be included. <dt pn="section-8.4.5-2.3">parameter_label:</dt>
Possible values of this parameter are specified in the label column of the IANA <dd pn="section-8.4.5-2.4">Indicates the parameter. This parameter
"CoJP Parameters" registry (<xref target="iana_cojp_registry"/>).</t> <bcp14>MUST</bcp14> be included. Possible values of this
<t>parameter_addinfo: Additional information about the parameter that cannot b parameter are specified in the label column of the
e acted upon. IANA "Constrained Join Protocol (CoJP) Parameters" registry" (<xref target="iana
This parameter MUST be included. _cojp_registry" format="default" sectionFormat="of" derivedContent="Section 11.1
In case the code is set to "Unsupported", parameter_addinfo gives additional inf "/>).</dd>
ormation to the JRC. <dt pn="section-8.4.5-2.5">parameter_addinfo:</dt>
If the parameter indicated by parameter_label cannot be acted upon regardless of <dd pn="section-8.4.5-2.6">Additional information about the paramete
its value, parameter_addinfo MUST be set to null, signaling to the JRC that it r
SHOULD NOT attempt to configure the parameter again. that cannot be acted upon.
If the pledge can act on the parameter, but cannot configure the setting indicat This parameter <bcp14>MUST</bcp14> be included.
ed by the parameter value, the pledge can hint this to the JRC. If the code is set to "Unsupported", parameter_addinfo gives
In this case, parameter_addinfo MUST be set to the value of the parameter that c additional information to the JRC.
annot be acted upon following the normative parameter structure specified in thi If the parameter indicated by parameter_label cannot be acted upon
s document. regardless of its value, parameter_addinfo <bcp14>MUST</bcp14>
For example, it is possible to include the link-layer key set object, signaling be set to null, signaling to the JRC that it <bcp14>SHOULD NOT</bcp14>
a subset of keys that cannot be acted upon, or the entire key set that was recei attempt to configure the parameter again.
ved. If the pledge can act on the parameter, but cannot configure the
In that case, the value of the parameter_addinfo follows the link-layer key set setting indicated by the parameter value, the pledge can hint this
structure defined in <xref target="configuration_object"/>. to the JRC.
In case the code is set to "Malformed", parameter_addinfo MUST be set to null, s In this case, parameter_addinfo <bcp14>MUST</bcp14> be set to the
ignaling to the JRC that it SHOULD NOT attempt to configure the parameter again. value of the parameter that cannot be acted upon following the
</t> normative parameter structure specified in this document.
</list></t> For example, it is possible to include the link-layer key set
object, signaling that either a subset or the entire key set that
<t>The CDDL fragment that represents the text above for Unsupported_Configuratio was received cannot be acted upon.
n and Unsupported_Parameter objects follows.</t> In that case, the value of parameter_addinfo follows the
link-layer key set structure defined in
<figure><artwork><![CDATA[ <xref target="configuration_object" format="default" sectionFormat="of" derivedC
ontent="Section 8.4.2"/>.
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>
attempt to configure the parameter again.</dd>
</dl>
<t indent="0" pn="section-8.4.5-3">The CDDL fragment
for the Unsupported_Configuration and Unsupported_Parameter objects
that represents the text above
follows:</t>
<sourcecode type="" markers="false" pn="section-8.4.5-4">
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>
<table anchor="table_unsupported_code_values" align="center" pn="table
<texttable title="Unsupported Configuration code values." anchor="table_unsuppor -7">
ted_code_values"> <name slugifiedName="name-unsupported-configuration-c">Unsupported C
<ttcol align='right'>Name</ttcol> onfiguration code values.</name>
<ttcol align='left'>Value</ttcol> <thead>
<ttcol align='right'>Description</ttcol> <tr>
<ttcol align='left'>Reference</ttcol> <th align="left" colspan="1" rowspan="1">Name</th>
<c>Unsupported</c> <th align="left" colspan="1" rowspan="1">Value</th>
<c>0</c> <th align="left" colspan="1" rowspan="1">Description</th>
<c>The indicated setting is not supported by the networking stack implemen <th align="left" colspan="1" rowspan="1">Reference</th>
tation.</c> </tr>
<c>[[this document]]</c> </thead>
<c>Malformed</c> <tbody>
<c>1</c> <tr>
<c>The indicated parameter value is malformed.</c> <td align="left" colspan="1" rowspan="1">Unsupported</td>
<c>[[this document]]</c> <td align="left" colspan="1" rowspan="1">0</td>
</texttable> <td align="left" colspan="1" rowspan="1">The indicated setting i
s not supported by the networking stack implementation.</td>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> <td align="left" colspan="1" rowspan="1">RFC 9031</td>
</tr>
</section> <tr>
</section> <td align="left" colspan="1" rowspan="1">Malformed</td>
<section anchor="recommended-settings" title="Recommended Settings"> <td align="left" colspan="1" rowspan="1">1</td>
<td align="left" colspan="1" rowspan="1">The indicated parameter
<t>This section gives RECOMMENDED values of CoJP settings.</t> value is malformed.</td>
<td align="left" colspan="1" rowspan="1">RFC 9031</td>
<texttable title="Recommended CoJP settings."> </tr>
<ttcol align='right'>Name</ttcol> </tbody>
<ttcol align='left'>Default Value</ttcol> </table>
<c>COJP_MAX_JOIN_ATTEMPTS</c> </section>
<c>4</c> </section>
<c>COJP_REKEYING_GUARD_TIME</c> <section anchor="recommended-settings" numbered="true" toc="include" remov
<c>12 seconds</c> eInRFC="false" pn="section-8.5">
</texttable> <name slugifiedName="name-recommended-settings-2">Recommended Settings</
name>
<t>The COJP_REKEYING_GUARD_TIME value SHOULD take into account possible retransm <t indent="0" pn="section-8.5-1">This section gives <bcp14>RECOMMENDED</
issions at the link layer due to imperfect wireless links.</t> bcp14> values of CoJP settings.</t>
<table align="center" pn="table-8">
<!-- ====================================================================== --> <name slugifiedName="name-recommended-cojp-settings">Recommended CoJP
settings.</name>
</section> <thead>
</section> <tr>
<section anchor="sec_considerations" title="Security Considerations"> <th align="left" colspan="1" rowspan="1">Name</th>
<th align="left" colspan="1" rowspan="1">Default Value</th>
<t>Since this document uses the pledge identifier to set the ID Context paramete </tr>
r of OSCORE, an important security requirement is that the pledge identifier is </thead>
unique in the set of all pledge identifiers managed by a JRC. <tbody>
The uniqueness of the pledge identifier ensures unique (key, nonce) pairs for AE <tr>
AD algorithm used by OSCORE. <td align="left" colspan="1" rowspan="1">COJP_MAX_JOIN_ATTEMPTS</t
It also allows the JRC to retrieve the correct security context, upon the recept d>
ion of a Join Request message. <td align="left" colspan="1" rowspan="1">4</td>
The management of pledge identifiers is simplified if the globally unique EUI-64 </tr>
is used, but this comes with privacy risks, as discussed in <xref target="priva <tr>
cy_considerations"/>.</t> <td align="left" colspan="1" rowspan="1">COJP_REKEYING_GUARD_TIME<
/td>
<t>This document further mandates that the (6LBR) pledge and the JRC are provisi <td align="left" colspan="1" rowspan="1">12 seconds</td>
oned with unique PSKs. </tr>
</tbody>
</table>
<t indent="0" pn="section-8.5-3">The COJP_REKEYING_GUARD_TIME value <bcp
14>SHOULD</bcp14> take into account possible retransmissions at the link layer d
ue to imperfect wireless links.</t>
</section>
</section>
<section anchor="sec_considerations" numbered="true" toc="include" removeInR
FC="false" pn="section-9">
<name slugifiedName="name-security-considerations">Security Considerations
</name>
<t indent="0" pn="section-9-1">Since this document uses the pledge identif
ier to set
the ID Context parameter of OSCORE, an important security requirement is
that the pledge identifier is unique in the set of all pledge identifiers manage
d by a JRC.
The uniqueness of the pledge identifier ensures unique (key, nonce) pairs
for the AEAD algorithm used by OSCORE.
It also allows the JRC to retrieve the correct security context
upon the reception of a Join Request message.
The management of pledge identifiers is simplified if the globally
unique EUI-64 is used, but this comes with privacy risks, as discussed
in <xref target="privacy_considerations" format="default" sectionFormat="of" der
ivedContent="Section 10"/>.</t>
<t indent="0" pn="section-9-2">This document further mandates that the (6L
BR) pledge and the JRC are provisioned 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 indent="0" pn="section-9-3">Note that while OSCORE provides replay prot
<t>Note that while OSCORE provides replay protection, it does not provide an ind ection, it does not
ication of freshness in the presence of an attacker that can drop/reorder traffi provide an indication of freshness in the presence of an attacker
c. that can drop and/or reorder traffic.
Since the join request contains no randomness, and the sequence number is predic Since the Join Request contains no randomness, and the
table, the JRC could in principle anticipate a join request from a particular pl sequence number is predictable, the JRC could in principle anticipate
edge and pre-calculate the response. a Join Request from a particular pledge and pre-calculate the response.
In such a scenario, the JRC does not have to be alive at the time when the reque In such a scenario, the JRC does not have to be alive at the time
st is received. the request is received.
This could be relevant in case the JRC was temporarily compromised and control s This could be relevant in the case when the JRC was temporarily compromised
ubsequently regained by the legitimate owner.</t> and control was subsequently regained by the legitimate owner.</t>
<t indent="0" pn="section-9-4">It is of utmost importance to avoid unsafe
<t>It is of utmost importance to avoid unsafe practices when generating and prov practices when generating and provisioning PSKs.
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> sectionFormat="of" derivedContent="NIST800-90A"/> for different mechanisms using
deterministic methods.</t>
<t>The JP forwards the unauthenticated join traffic into the network. <t indent="0" pn="section-9-5">The JP forwards the unauthenticated join tr
affic 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 indent="0" pn="section-9-6">The shared nature of the "minimal" cell use
etwork prone to a DoS attack by congesting the JP with bogus traffic. d for the join traffic makes 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 indent="0" pn="section-9-7">At the beginning of the join process, the p
<t>At the beginning of the join process, the pledge has no means of verifying th ledge has no
e content in the EB, and has to accept it at "face value". means of verifying the content in the EB and has to accept it at "face value".
In case the pledge tries to join an attacker's network, the Join Response messag If the pledge tries to join an attacker's network,
e will either fail the security check or time out. the Join Response message will either fail the security check or time out.
The pledge may implement a temporary blacklist in order to filter out undesired The pledge may implement a temporary blacklist in order to filter out
EBs and try to join using the next seemingly valid EB. undesired EBs and try to join using the next seemingly valid EB.
This blacklist alleviates the issue, but is effectively limited by the node's av This blacklist alleviates the issue but is effectively limited by
ailable memory. the node's available memory.
Note that this temporary blacklist is different from the one communicated as par Note that this temporary blacklist is different from the one
t of the CoJP Configuration object as it helps pledge fight a DoS attack. communicated as part of the CoJP Configuration object as it helps
The bogus beacons prolong the join time of the pledge, and so the time spent in the pledge fight a DoS attack.
"minimal" <xref target="RFC8180"/> duty cycle mode. The bogus beacons prolong the join time of the pledge and so does the
The blacklist communicated as part of the CoJP Configuration object helps JP fig time spent in "minimal" duty cycle mode <xref target="RFC8180" format="default"
ht a DoS attack by a malicious pledge.</t> sectionFormat="of" derivedContent="RFC8180"/>.
The blacklist communicated as part of the CoJP Configuration object
<t>During the network lifetime, the JRC may at any time initiate a Parameter Upd helps the JP fight a DoS attack by a malicious pledge.</t>
ate exchange with a joined node. <t indent="0" pn="section-9-8">During the network lifetime, the JRC may at
The Parameter Update message uses the same OSCORE security context as is used fo any time initiate a parameter update exchange with a joined node.
r the join exchange, except that the server/client roles are interchanged. The Parameter Update message uses the same OSCORE security context
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 anchor="privacy_considerations" numbered="true" toc="include" remov
eInRFC="false" pn="section-10">
</section> <name slugifiedName="name-privacy-considerations">Privacy Considerations</
<section anchor="privacy_considerations" title="Privacy Considerations"> name>
<t indent="0" pn="section-10-1">The join solution specified in this docume
<t>The join solution specified in this document relies on the uniqueness of the nt relies on the uniqueness of the pledge identifier in the set of all pledge id
pledge identifier in the set of all pledge identifiers managed by a JRC. entifiers 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" sectionFormat="of" derivedContent="RFC7721"/>
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 indent="0" pn="section-10-2">As an optional mitigation technique, the J
<t>As an optional mitigation technique, the Join Response message may contain a oin Response message
short address which is assigned by the JRC to the (6LBR) pledge. may contain a short address that is assigned by the JRC to the (6LBR) pledge.
The assigned short address SHOULD be uncorrelated with the long-term pledge iden The assigned short address <bcp14>SHOULD</bcp14> be uncorrelated with the long-t
tifier. erm pledge identifier.
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 anchor="iana-considerations" numbered="true" toc="include" removeIn
RFC="false" pn="section-11">
</section> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<section anchor="iana-considerations" title="IANA Considerations"> <t indent="0" pn="section-11-1">This document allocates a well-known name
under
<t>Note to RFC Editor: Please replace all occurrences of "[[this document]]" wit the .arpa name space according to the rules given in <xref target="RFC3172" form
h the RFC number of this specification.</t> at="default" sectionFormat="of" derivedContent="RFC3172"/> and <xref target="RFC
6761" format="default" sectionFormat="of" derivedContent="RFC6761"/>.
<t>This document allocates a well-known name under the .arpa name space accordin
g to the rules given in <xref target="RFC3172"/>.
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" numbered="true" toc="include" removeI
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> nRFC="false" pn="section-11.1">
<name slugifiedName="name-constrained-join-protocol-co">Constrained Join
<section anchor="iana_cojp_registry" title="CoJP Parameters Registry"> Protocol (CoJP) Parameters</name>
<t indent="0" pn="section-11.1-1">This section defines a subregistry wit
<t>This section defines a sub-registry within the "IPv6 over the TSCH mode of IE hin 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 Parameters Registry".</t> name "Constrained Join Protocol (CoJP) Parameters".</t>
<t indent="0" pn="section-11.1-2">The columns of the registry are:</t>
<t>The columns of the registry are:</t> <dl indent="3" newline="false" spacing="normal" pn="section-11.1-3">
<dt pn="section-11.1-3.1">Name:</dt>
<t>Name: This is a descriptive name that enables an easier reference to the item <dd pn="section-11.1-3.2">This is a descriptive name that enables an e
. asier reference to the item.
It is not used in the encoding.</t> It is not used in the encoding. The name <bcp14>MUST</bcp14> be unique.</dd>
<dt pn="section-11.1-3.3">Label:</dt>
<t>Label: The value to be used to identify this parameter. <dd pn="section-11.1-3.4">The value to be used to identify this parame
The label is an integer.</t> ter.
The label is an integer. The label <bcp14>MUST</bcp14> be unique.</dd>
<t>CBOR type: This field contains the CBOR type for the field.</t> <dt pn="section-11.1-3.5">CBOR Type:</dt>
<dd pn="section-11.1-3.6">This field contains the CBOR type for the fi
<t>Description: This field contains a brief description for the field.</t> eld.</dd>
<dt pn="section-11.1-3.7">Description:</dt>
<t>Reference: This field contains a pointer to the public specification for the <dd pn="section-11.1-3.8">This field contains a brief description for
field, if one exists.</t> the field. The description <bcp14>MUST</bcp14> be unique.</dd>
<dt pn="section-11.1-3.9">Reference:</dt>
<t>This registry is to be populated with the values in <xref target="table_cojp_ <dd pn="section-11.1-3.10">This field contains a pointer to the public
parameters_labels"/>.</t> specification for the field, if one exists.</dd>
</dl>
<t>The amending formula for this sub-registry is: Different ranges of values use <t indent="0" pn="section-11.1-4">This registry is populated with the va
different registration policies <xref target="RFC8126"/>. lues
in <xref target="table_cojp_parameters_labels" format="default" sectionFormat="o
f" derivedContent="Table 5"/>.</t>
<t indent="0" pn="section-11.1-5">The amending formula for this subregis
try is:
Different ranges of values use different registration policies <xref target="RFC
8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>.
Integer values from -256 to 255 are designated as Standards Action. Integer values from -256 to 255 are designated as Standards Action.
Integer values from -65536 to -257 and from 256 to 65535 are designated as 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="includ
<section anchor="iana_cojp_key_usage_registry" title="CoJP Key Usage Registry"> e" removeInRFC="false" pn="section-11.2">
<name slugifiedName="name-constrained-join-protocol-coj">Constrained Joi
<t>This section defines a sub-registry within the "IPv6 over the TSCH mode of IE n Protocol (CoJP) Key Usage</name>
EE 802.15.4e (6TiSCH) parameters" registry with the name "Constrained Join Proto <t indent="0" pn="section-11.2-1">This section defines a subregistry wit
col Key Usage Registry".</t> hin the
"IPv6 Over the TSCH Mode of IEEE 802.15.4 (6TiSCH)" registry with the
<t>The columns of this registry are:</t> name "Constrained Join Protocol (CoJP) Key Usage".</t>
<t indent="0" pn="section-11.2-2">The columns of this registry are:</t>
<t>Name: This is a descriptive name that enables easier reference to the item. <dl indent="3" newline="false" spacing="normal" pn="section-11.2-3">
The name MUST be unique. <dt pn="section-11.2-3.1">Name:</dt>
It is not used in the encoding.</t> <dd pn="section-11.2-3.2">This is a descriptive name that enables easi
er reference to the item.
<t>Value: This is the value used to identify the key usage setting. It is not used in the encoding. The name <bcp14>MUST</bcp14> be unique.</dd>
These values MUST be unique. <dt pn="section-11.2-3.3">Value:</dt>
The value is an integer.</t> <dd pn="section-11.2-3.4">This is the value used to identify the key u
sage setting.
<t>Algorithm: This is a descriptive name of the link-layer algorithm in use and These values <bcp14>MUST</bcp14> be unique. The value is an integer.</dd>
uniquely determines the key length. <dt pn="section-11.2-3.5">Algorithm:</dt>
The name is not used in the encoding.</t> <dd pn="section-11.2-3.6">This is a descriptive name of the link-layer
algorithm in use and uniquely determines the key length.
<t>Description: This field contains a description of the key usage setting. The name is not used in the encoding. The algorithm <bcp14>MUST</bcp14> be uniqu
The field should describe in enough detail how the key is to be used with differ e.</dd>
ent frame types, specific for the link-layer technology in question.</t> <dt pn="section-11.2-3.7">Description:</dt>
<dd pn="section-11.2-3.8">This field contains a description of the key
<t>Reference: This contains a pointer to the public specification for the field usage setting.
, if one exists.</t> 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. The descrip
<t>This registry is to be populated with the values in <xref target="table_key_u tion <bcp14>MUST</bcp14> be unique.</dd>
sage_values"/>.</t> <dt pn="section-11.2-3.9">Reference:</dt>
<dd pn="section-11.2-3.10">This contains a pointer to the public speci
<t>The amending formula for this sub-registry is: Different ranges of values use fication for the field, if one exists.</dd>
different registration policies <xref target="RFC8126"/>. </dl>
<t indent="0" pn="section-11.2-4">This registry is populated with the va
lues in <xref target="table_key_usage_values" format="default" sectionFormat="of
" derivedContent="Table 6"/>.</t>
<t indent="0" pn="section-11.2-5">The amending formula for this subregis
try is:
Different ranges of values use different registration policies <xref target="RFC
8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>.
Integer values from -256 to 255 are designated as Standards Action. Integer values from -256 to 255 are designated as Standards Action.
Integer values from -65536 to -257 and from 256 to 65535 are designated as 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_unsupported_code_registry" numbered="true" toc=
<section anchor="iana_cojp_unsupported_code_registry" title="CoJP Unsupported Co "include" removeInRFC="false" pn="section-11.3">
nfiguration Code Registry"> <name slugifiedName="name-constrained-join-protocol-cojp">Constrained Jo
in Protocol (CoJP) Unsupported Configuration Codes</name>
<t>This section defines a sub-registry within the "IPv6 over the TSCH mode of IE <t indent="0" pn="section-11.3-1">This section defines a subregistry wit
EE 802.15.4e (6TiSCH) parameters" registry with the name "Constrained Join Proto hin the
col Unsupported Configuration Code Registry".</t> "IPv6 Over the TSCH Mode of IEEE 802.15.4 (6TiSCH)" registry with the
name "Constrained Join Protocol (CoJP) Unsupported Configuration Codes".</t>
<t>The columns of this registry are:</t> <t indent="0" pn="section-11.3-2">The columns of this registry are:</t>
<dl indent="3" newline="false" spacing="normal" pn="section-11.3-3">
<t>Name: This is a descriptive name that enables easier reference to the item. <dt pn="section-11.3-3.1">Name:</dt>
The name MUST be unique. <dd pn="section-11.3-3.2">This is a descriptive name that enables easi
It is not used in the encoding.</t> er reference to the item.
It is not used in the encoding.
<t>Value: This is the value used to identify the diagnostic code. The name <bcp14>MUST</bcp14> be unique.</dd>
These values MUST be unique. <dt pn="section-11.3-3.3">Value:</dt>
The value is an integer.</t> <dd pn="section-11.3-3.4">This is the value used to identify the diagn
ostic code.
<t>Description: This is a descriptive human-readable name. These values <bcp14>MUST</bcp14> be unique.
The description MUST be unique. The value is an integer.</dd>
It is not used in the encoding.</t> <dt pn="section-11.3-3.5">Description:</dt>
<dd pn="section-11.3-3.6">This is a descriptive human-readable name.
<t>Reference: This contains a pointer to the public specification for the field The description <bcp14>MUST</bcp14> be unique.
, if one exists.</t> It is not used in the encoding.</dd>
<dt pn="section-11.3-3.7">Reference:</dt>
<t>This registry is to be populated with the values in <xref target="table_unsup <dd pn="section-11.3-3.8">This contains a pointer to the public specif
ported_code_values"/>.</t> ication for the field, if one exists.</dd>
</dl>
<t>The amending formula for this sub-registry is: Different ranges of values use <t indent="0" pn="section-11.3-4">This registry is to be populated with
different registration policies <xref target="RFC8126"/>. the values in <xref target="table_unsupported_code_values" format="default" sect
ionFormat="of" derivedContent="Table 7"/>.</t>
<t indent="0" pn="section-11.3-5">The amending formula for this subregis
try is:
Different ranges of values use different registration policies <xref target="RFC
8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>.
Integer values from -256 to 255 are designated as Standards Action. Integer values from -256 to 255 are designated as Standards Action.
Integer values from -65536 to -257 and from 256 to 65535 are designated as 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>
</section>
<section anchor="acknowledgments" title="Acknowledgments">
<t>The work on this document has been partially supported by the European Union'
s H2020 Programme for research, technological development and demonstration unde
r 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 alphabetic orde
r):
Christian Amsuss,
Tengfei Chang,
Klaus Hartke,
Tero Kivinen,
Jim Schaad,
Goeran Selander,
Yasuyuki Tanaka,
Pascal Thubert,
William Vignat,
Xavier Vilajosana,
Thomas Watteyne.</t>
</section>
</middle> </middle>
<back> <back>
<references pn="section-12">
<references title='Normative References'> <name slugifiedName="name-references">References</name>
<references pn="section-12.1">
&RFC7554; <name slugifiedName="name-normative-references">Normative References</na
&RFC8180; me>
&RFC8613; <reference anchor="IEEE802.15.4" target="https://ieeexplore.ieee.org/doc
&RFC7252; ument/7460875" quoteTitle="true" derivedAnchor="IEEE802.15.4">
&RFC7049; <front>
&RFC8152; <title>IEEE Standard for Low-Rate Wireless Networks</title>
&RFC2119; <author>
&RFC8174; <organization showOnFrontPage="true">IEEE</organization>
&RFC2597; </author>
&RFC3172; <date month="April" year="2016"/>
&RFC8126; </front>
<reference anchor="IEEE802.15.4" > <seriesInfo name="IEEE Standard" value="802.15.4-2015"/>
<front> <seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7460875"/>
<title>IEEE Std 802.15.4 Standard for Low-Rate Wireless Networks</title> </reference>
<author initials="." surname="IEEE standard for Information Technology"> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
<organization></organization> 119" quoteTitle="true" derivedAnchor="RFC2119">
</author> <front>
<date year="n.d."/> <title>Key words for use in RFCs to Indicate Requirement Levels</tit
</front> le>
</reference> <author initials="S." surname="Bradner" fullname="S. Bradner">
&I-D.ietf-core-stateless; <organization showOnFrontPage="true"/>
&RFC8505; </author>
&I-D.ietf-6tisch-architecture; <date year="1997" month="March"/>
&RFC7320; <abstract>
&RFC8085; <t indent="0">In many standards track documents several words are
&RFC5869; used to signify the requirements in the specification. These words are often ca
pitalized. This document defines these words as they should be interpreted in IE
</references> TF documents. This document specifies an Internet Best Current Practices for th
e Internet Community, and requests discussion and suggestions for improvements.<
<references title='Informative References'> /t>
</abstract>
&I-D.ietf-6tisch-msf; </front>
&I-D.ietf-cbor-cddl; <seriesInfo name="BCP" value="14"/>
&I-D.ietf-cbor-sequence; <seriesInfo name="RFC" value="2119"/>
&RFC8480; <seriesInfo name="DOI" value="10.17487/RFC2119"/>
&RFC5785; </reference>
&RFC7721; <reference anchor="RFC2597" target="https://www.rfc-editor.org/info/rfc2
&RFC4944; 597" quoteTitle="true" derivedAnchor="RFC2597">
&RFC6550; <front>
&RFC4231; <title>Assured Forwarding PHB Group</title>
&RFC8415; <author initials="J." surname="Heinanen" fullname="J. Heinanen">
&I-D.ietf-anima-grasp; <organization showOnFrontPage="true"/>
&RFC6762; </author>
<reference anchor="NIST800-90A" > <author initials="F." surname="Baker" fullname="F. Baker">
<front> <organization showOnFrontPage="true"/>
<title>Recommendation for Random Number Generation Using Deterministic Rando </author>
m Bit Generators</title> <author initials="W." surname="Weiss" fullname="W. Weiss">
<author initials="." surname="NIST Special Publication 800-90A, Revision 1"> <organization showOnFrontPage="true"/>
<organization></organization> </author>
</author> <author initials="J." surname="Wroclawski" fullname="J. Wroclawski">
<author initials="E." surname="Barker"> <organization showOnFrontPage="true"/>
<organization></organization> </author>
</author> <date year="1999" month="June"/>
<author initials="J." surname="Kelsey"> <abstract>
<organization></organization> <t indent="0">This document defines a general use Differentiated S
</author> ervices (DS) Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF). [STAND
<date year="2015"/> ARDS-TRACK]</t>
</front> </abstract>
</reference> </front>
<seriesInfo name="RFC" value="2597"/>
<seriesInfo name="DOI" value="10.17487/RFC2597"/>
</reference>
<reference anchor="RFC3172" target="https://www.rfc-editor.org/info/rfc3
172" quoteTitle="true" derivedAnchor="RFC3172">
<front>
<title>Management Guidelines &amp; Operational Requirements for the
Address and Routing Parameter Area Domain ("arpa")</title>
<author initials="G." surname="Huston" fullname="G. Huston" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<date year="2001" month="September"/>
<abstract>
<t indent="0">This memo describes the management and operational r
equirements for the address and routing parameter area ("arpa") domain. This do
cument specifies an Internet Best Current Practices for the Internet Community,
and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="52"/>
<seriesInfo name="RFC" value="3172"/>
<seriesInfo name="DOI" value="10.17487/RFC3172"/>
</reference>
<reference anchor="RFC5869" target="https://www.rfc-editor.org/info/rfc5
869" quoteTitle="true" derivedAnchor="RFC5869">
<front>
<title>HMAC-based Extract-and-Expand Key Derivation Function (HKDF)<
/title>
<author initials="H." surname="Krawczyk" fullname="H. Krawczyk">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Eronen" fullname="P. Eronen">
<organization showOnFrontPage="true"/>
</author>
<date year="2010" month="May"/>
<abstract>
<t indent="0">This document specifies a simple Hashed Message Auth
entication Code (HMAC)-based key derivation function (HKDF), which can be used a
s a building block in various protocols and applications. The key derivation fu
nction (KDF) is intended to support a wide range of applications and requirement
s, and is conservative in its use of cryptographic hash functions. This documen
t is not an Internet Standards Track specification; it is published for informa
tional purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5869"/>
<seriesInfo name="DOI" value="10.17487/RFC5869"/>
</reference>
<reference anchor="RFC6761" target="https://www.rfc-editor.org/info/rfc6
761" quoteTitle="true" derivedAnchor="RFC6761">
<front>
<title>Special-Use Domain Names</title>
<author initials="S." surname="Cheshire" fullname="S. Cheshire">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Krochmal" fullname="M. Krochmal">
<organization showOnFrontPage="true"/>
</author>
<date year="2013" month="February"/>
<abstract>
<t indent="0">This document describes what it means to say that a
Domain Name (DNS name) is reserved for special use, when reserving such a name i
s appropriate, and the procedure for doing so. It establishes an IANA registry
for such domain names, and seeds it with entries for some of the already establi
shed special domain names.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6761"/>
<seriesInfo name="DOI" value="10.17487/RFC6761"/>
</reference>
<reference anchor="RFC7252" target="https://www.rfc-editor.org/info/rfc7
252" quoteTitle="true" derivedAnchor="RFC7252">
<front>
<title>The Constrained Application Protocol (CoAP)</title>
<author initials="Z." surname="Shelby" fullname="Z. Shelby">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Hartke" fullname="K. Hartke">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Bormann" fullname="C. Bormann">
<organization showOnFrontPage="true"/>
</author>
<date year="2014" month="June"/>
<abstract>
<t indent="0">The Constrained Application Protocol (CoAP) is a spe
cialized web transfer protocol for use with constrained nodes and constrained (e
.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers wi
th small amounts of ROM and RAM, while constrained networks such as IPv6 over Lo
w-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error
rates and a typical throughput of 10s of kbit/s. The protocol is designed for m
achine- to-machine (M2M) applications such as smart energy and building automati
on.</t>
<t indent="0">CoAP provides a request/response interaction model b
etween application endpoints, supports built-in discovery of services and resour
ces, and includes key concepts of the Web such as URIs and Internet media types.
CoAP is designed to easily interface with HTTP for integration with the Web wh
ile meeting specialized requirements such as multicast support, very low overhea
d, and simplicity for constrained environments.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7252"/>
<seriesInfo name="DOI" value="10.17487/RFC7252"/>
</reference>
<reference anchor="RFC7554" target="https://www.rfc-editor.org/info/rfc7
554" quoteTitle="true" derivedAnchor="RFC7554">
<front>
<title>Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in t
he Internet of Things (IoT): Problem Statement</title>
<author initials="T." surname="Watteyne" fullname="T. Watteyne" role
="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Palattella" fullname="M. Palattella">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Grieco" fullname="L. Grieco">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="May"/>
<abstract>
<t indent="0">This document describes the environment, problem sta
tement, and goals for using the Time-Slotted Channel Hopping (TSCH) Medium Acces
s Control (MAC) protocol of IEEE 802.14.4e in the context of Low-Power and Lossy
Networks (LLNs). The set of goals enumerated in this document form an initial
set only.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7554"/>
<seriesInfo name="DOI" value="10.17487/RFC7554"/>
</reference>
<reference anchor="RFC8085" target="https://www.rfc-editor.org/info/rfc8
085" quoteTitle="true" derivedAnchor="RFC8085">
<front>
<title>UDP Usage Guidelines</title>
<author initials="L." surname="Eggert" fullname="L. Eggert">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Fairhurst" fullname="G. Fairhurst">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Shepherd" fullname="G. Shepherd">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="March"/>
<abstract>
<t indent="0">The User Datagram Protocol (UDP) provides a minimal
message-passing transport that has no inherent congestion control mechanisms. T
his document provides guidelines on the use of UDP for the designers of applicat
ions, tunnels, and other protocols that use UDP. Congestion control guidelines
are a primary focus, but the document also provides guidance on other topics, in
cluding message sizes, reliability, checksums, middlebox traversal, the use of E
xplicit Congestion Notification (ECN), Differentiated Services Code Points (DSCP
s), and ports.</t>
<t indent="0">Because congestion control is critical to the stable
operation of the Internet, applications and other protocols that choose to use
UDP as an Internet transport must employ mechanisms to prevent congestion collap
se and to establish some degree of fairness with concurrent traffic. They may a
lso need to implement additional mechanisms, depending on how they use UDP.</t>
<t indent="0">Some guidance is also applicable to the design of ot
her protocols (e.g., protocols layered directly on IP or via IP-based tunnels),
especially when these protocols do not themselves provide congestion control.</t
>
<t indent="0">This document obsoletes RFC 5405 and adds guidelines
for multicast UDP usage.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="145"/>
<seriesInfo name="RFC" value="8085"/>
<seriesInfo name="DOI" value="10.17487/RFC8085"/>
</reference>
<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8
126" quoteTitle="true" derivedAnchor="RFC8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<author initials="M." surname="Cotton" fullname="M. Cotton">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Narten" fullname="T. Narten">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="June"/>
<abstract>
<t indent="0">Many protocols make use of points of extensibility t
hat use constants to identify various protocol parameters. To ensure that the v
alues in these fields do not have conflicting uses and to promote interoperabili
ty, their allocations are often coordinated by a central record keeper. For IET
F protocols, that role is filled by the Internet Assigned Numbers Authority (IAN
A).</t>
<t indent="0">To make assignments in a given registry prudently, g
uidance describing the conditions under which new values should be assigned, as
well as when and how modifications to existing values can be made, is needed. T
his document defines a framework for the documentation of these guidelines by sp
ecification authors, in order to assure that the provided guidance for the IANA
Considerations is clear and addresses the various issues that are likely in the
operation of a registry.</t>
<t indent="0">This is the third edition of this document; it obsol
etes RFC 5226.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
<reference anchor="RFC8152" target="https://www.rfc-editor.org/info/rfc8
152" quoteTitle="true" derivedAnchor="RFC8152">
<front>
<title>CBOR Object Signing and Encryption (COSE)</title>
<author initials="J." surname="Schaad" fullname="J. Schaad">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="July"/>
<abstract>
<t indent="0">Concise Binary Object Representation (CBOR) is a dat
a format designed for small code size and small message size. There is a need f
or the ability to have basic security services defined for this data format. Thi
s document defines the CBOR Object Signing and Encryption (COSE) protocol. This
specification describes how to create and process signatures, message authentic
ation codes, and encryption using CBOR for serialization. This specification ad
ditionally describes how to represent cryptographic keys using CBOR.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8152"/>
<seriesInfo name="DOI" value="10.17487/RFC8152"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="May"/>
<abstract>
<t indent="0">RFC 2119 specifies common key words that may be used
in protocol specifications. This document aims to reduce the ambiguity by cla
rifying that only UPPERCASE usage of the key words have the defined special mea
nings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8180" target="https://www.rfc-editor.org/info/rfc8
180" quoteTitle="true" derivedAnchor="RFC8180">
<front>
<title>Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Co
nfiguration</title>
<author initials="X." surname="Vilajosana" fullname="X. Vilajosana"
role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Pister" fullname="K. Pister">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Watteyne" fullname="T. Watteyne">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="May"/>
<abstract>
<t indent="0">This document describes a minimal mode of operation
for an IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) network. This minimal
mode of operation specifies the baseline set of protocols that need to be suppo
rted and the recommended configurations and modes of operation sufficient to ena
ble a 6TiSCH functional network. 6TiSCH provides IPv6 connectivity over a Time-
Slotted Channel Hopping (TSCH) mesh composed of IEEE Std 802.15.4 TSCH links. T
his minimal mode uses a collection of protocols with the respective configuratio
ns, including the IPv6 Low-Power Wireless Personal Area Network (6LoWPAN) framew
ork, enabling interoperable IPv6 connectivity over IEEE Std 802.15.4 TSCH. This
minimal configuration provides the necessary bandwidth for network and security
bootstrapping and defines the proper link between the IETF protocols that inter
face to IEEE Std 802.15.4 TSCH. This minimal mode of operation should be implem
ented by all 6TiSCH-compliant devices.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="210"/>
<seriesInfo name="RFC" value="8180"/>
<seriesInfo name="DOI" value="10.17487/RFC8180"/>
</reference>
<reference anchor="RFC8505" target="https://www.rfc-editor.org/info/rfc8
505" quoteTitle="true" derivedAnchor="RFC8505">
<front>
<title>Registration Extensions for IPv6 over Low-Power Wireless Pers
onal Area Network (6LoWPAN) Neighbor Discovery</title>
<author initials="P." surname="Thubert" fullname="P. Thubert" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Nordmark" fullname="E. Nordmark">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Chakrabarti" fullname="S. Chakrabarti
">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="November"/>
<abstract>
<t indent="0">This specification updates RFC 6775 -- the Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor Discovery specification -- to
clarify the role of the protocol as a registration technique and simplify the r
egistration operation in 6LoWPAN routers, as well as to provide enhancements to
the registration capabilities and mobility detection for different network topol
ogies, including the Routing Registrars performing routing for host routes and/o
r proxy Neighbor Discovery in a low-power network.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8505"/>
<seriesInfo name="DOI" value="10.17487/RFC8505"/>
</reference>
<reference anchor="RFC8613" target="https://www.rfc-editor.org/info/rfc8
613" quoteTitle="true" derivedAnchor="RFC8613">
<front>
<title>Object Security for Constrained RESTful Environments (OSCORE)
</title>
<author initials="G." surname="Selander" fullname="G. Selander">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Mattsson" fullname="J. Mattsson">
<organization showOnFrontPage="true"/>
</author>
<author initials="F." surname="Palombini" fullname="F. Palombini">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Seitz" fullname="L. Seitz">
<organization showOnFrontPage="true"/>
</author>
<date year="2019" month="July"/>
<abstract>
<t indent="0">This document defines Object Security for Constraine
d RESTful Environments (OSCORE), a method for application-layer protection of th
e Constrained Application Protocol (CoAP), using CBOR Object Signing and Encrypt
ion (COSE). OSCORE provides end-to-end protection between endpoints communicati
ng using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes an
d networks supporting a range of proxy operations, including translation between
different transport protocols.</t>
<t indent="0">Although an optional functionality of CoAP, OSCORE a
lters CoAP options processing and IANA registration. Therefore, this document u
pdates RFC 7252.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8613"/>
<seriesInfo name="DOI" value="10.17487/RFC8613"/>
</reference>
<reference anchor="RFC8820" target="https://www.rfc-editor.org/info/rfc8
820" quoteTitle="true" derivedAnchor="RFC8820">
<front>
<title>URI Design and Ownership</title>
<author initials="M." surname="Nottingham" fullname="M. Nottingham">
<organization showOnFrontPage="true"/>
</author>
<date year="2020" month="June"/>
<abstract>
<t indent="0">Section 1.1.1 of RFC 3986 defines URI syntax as "a f
ederated and extensible naming system wherein each scheme's specification may fu
rther restrict the syntax and semantics of identifiers using that scheme." In o
ther words, the structure of a URI is defined by its scheme. While it is common
for schemes to further delegate their substructure to the URI's owner, publishin
g independent standards that mandate particular forms of substructure in URIs is
often problematic.</t>
<t indent="0">This document provides guidance on the specification
of URI substructure in standards.</t>
<t indent="0">This document obsoletes RFC 7320 and updates RFC 398
6.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="190"/>
<seriesInfo name="RFC" value="8820"/>
<seriesInfo name="DOI" value="10.17487/RFC8820"/>
</reference>
<reference anchor="RFC8949" target="https://www.rfc-editor.org/info/rfc8
949" quoteTitle="true" derivedAnchor="RFC8949">
<front>
<title>Concise Binary Object Representation (CBOR)</title>
<author initials="C." surname="Bormann" fullname="C. Bormann">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Hoffman" fullname="P. Hoffman">
<organization showOnFrontPage="true"/>
</author>
<date year="2020" month="December"/>
<abstract>
<t indent="0">The Concise Binary Object Representation (CBOR) is a
data format whose design goals include the possibility of extremely small code
size, fairly small message size, and extensibility without the need for version
negotiation. These design goals make it different from earlier binary serializat
ions such as ASN.1 and MessagePack.</t>
<t indent="0">This document obsoletes RFC 7049, providing editoria
l improvements, new details, and errata fixes while keeping full compatibility w
ith the interchange format of RFC 7049. It does not create a new version of the
format.</t>
</abstract>
</front>
<seriesInfo name="STD" value="94"/>
<seriesInfo name="RFC" value="8949"/>
<seriesInfo name="DOI" value="10.17487/RFC8949"/>
</reference>
<reference anchor="RFC8974" target="https://www.rfc-editor.org/info/rfc8
974" quoteTitle="true" derivedAnchor="RFC8974">
<front>
<title>Extended Tokens and Stateless Clients in the Constrained Appl
ication Protocol (CoAP)</title>
<author initials="K." surname="Hartke" fullname="K. Hartke">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Richardson" fullname="M. Richardson">
<organization showOnFrontPage="true"/>
</author>
<date year="2021" month="January"/>
<abstract>
<t indent="0">This document provides considerations for alleviatin
g Constrained Application Protocol (CoAP) clients and intermediaries of keeping
per-request state. To facilitate this, this document additionally introduces a n
ew, optional CoAP protocol extension for extended token lengths. </t>
<t indent="0">This document updates RFCs 7252 and 8323 with an ext
ended definition of the "TKL" field in the CoAP message header.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8974"/>
<seriesInfo name="DOI" value="10.17487/RFC8974"/>
</reference>
<reference anchor="RFC9030" target="https://www.rfc-editor.org/info/rfc9
030" quoteTitle="true" derivedAnchor="RFC9030">
<front>
<title>An Architecture for IPv6 over the Time-Slotted Channel Hoppin
g Mode of IEEE 802.15.4 (6TiSCH)</title>
<author initials="P" surname="Thubert" fullname="Pascal Thubert" rol
e="editor">
<organization showOnFrontPage="true"/>
</author>
<date month="May" year="2021"/>
</front>
<seriesInfo name="RFC" value="9030"/>
<seriesInfo name="DOI" value="10.17487/RFC9030"/>
</reference>
</references>
<references pn="section-12.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="NIST800-90A" quoteTitle="true" target="https://doi.or
g/10.6028/NIST.SP.800-90Ar1" derivedAnchor="NIST800-90A">
<front>
<title>Recommendation for Random Number Generation Using Determinist
ic Random Bit Generators</title>
<author>
<organization showOnFrontPage="true">National Institute of Standar
ds and Technology</organization>
</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>
<reference anchor="RFC4231" target="https://www.rfc-editor.org/info/rfc4
231" quoteTitle="true" derivedAnchor="RFC4231">
<front>
<title>Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256,
HMAC-SHA-384, and HMAC-SHA-512</title>
<author initials="M." surname="Nystrom" fullname="M. Nystrom">
<organization showOnFrontPage="true"/>
</author>
<date year="2005" month="December"/>
<abstract>
<t indent="0">This document provides test vectors for the HMAC-SHA
-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 message authentication scheme
s. It also provides ASN.1 object identifiers and Uniform Resource Identifiers (
URIs) to identify use of these schemes in protocols. The test vectors provided
in this document may be used for conformance testing. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4231"/>
<seriesInfo name="DOI" value="10.17487/RFC4231"/>
</reference>
<reference anchor="RFC4944" target="https://www.rfc-editor.org/info/rfc4
944" quoteTitle="true" derivedAnchor="RFC4944">
<front>
<title>Transmission of IPv6 Packets over IEEE 802.15.4 Networks</tit
le>
<author initials="G." surname="Montenegro" fullname="G. Montenegro">
<organization showOnFrontPage="true"/>
</author>
<author initials="N." surname="Kushalnagar" fullname="N. Kushalnagar
">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Hui" fullname="J. Hui">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Culler" fullname="D. Culler">
<organization showOnFrontPage="true"/>
</author>
<date year="2007" month="September"/>
<abstract>
<t indent="0">This document describes the frame format for transmi
ssion of IPv6 packets and the method of forming IPv6 link-local addresses and st
atelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifi
cations include a simple header compression scheme using shared context and prov
isions for packet delivery in IEEE 802.15.4 meshes. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4944"/>
<seriesInfo name="DOI" value="10.17487/RFC4944"/>
</reference>
<reference anchor="RFC6550" target="https://www.rfc-editor.org/info/rfc6
550" quoteTitle="true" derivedAnchor="RFC6550">
<front>
<title>RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks</
title>
<author initials="T." surname="Winter" fullname="T. Winter" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Thubert" fullname="P. Thubert" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Brandt" fullname="A. Brandt">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Hui" fullname="J. Hui">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Kelsey" fullname="R. Kelsey">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Levis" fullname="P. Levis">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Pister" fullname="K. Pister">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Struik" fullname="R. Struik">
<organization showOnFrontPage="true"/>
</author>
<author initials="JP." surname="Vasseur" fullname="JP. Vasseur">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Alexander" fullname="R. Alexander">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="March"/>
<abstract>
<t indent="0">Low-Power and Lossy Networks (LLNs) are a class of n
etwork in which both the routers and their interconnect are constrained. LLN ro
uters typically operate with constraints on processing power, memory, and energy
(battery power). Their interconnects are characterized by high loss rates, low
data rates, and instability. LLNs are comprised of anything from a few dozen t
o thousands of routers. Supported traffic flows include point-to-point (between
devices inside the LLN), point-to-multipoint (from a central control point to a
subset of devices inside the LLN), and multipoint-to-point (from devices inside
the LLN towards a central control point). This document specifies the IPv6 Rou
ting Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism
whereby multipoint-to-point traffic from devices inside the LLN towards a centr
al control point as well as point-to-multipoint traffic from the central control
point to the devices inside the LLN are supported. Support for point-to-point
traffic is also available. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6550"/>
<seriesInfo name="DOI" value="10.17487/RFC6550"/>
</reference>
<reference anchor="RFC6762" target="https://www.rfc-editor.org/info/rfc6
762" quoteTitle="true" derivedAnchor="RFC6762">
<front>
<title>Multicast DNS</title>
<author initials="S." surname="Cheshire" fullname="S. Cheshire">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Krochmal" fullname="M. Krochmal">
<organization showOnFrontPage="true"/>
</author>
<date year="2013" month="February"/>
<abstract>
<t indent="0">As networked devices become smaller, more portable,
and more ubiquitous, the ability to operate with less configured infrastructure
is increasingly important. In particular, the ability to look up DNS resource r
ecord data types (including, but not limited to, host names) in the absence of a
conventional managed DNS server is useful.</t>
<t indent="0">Multicast DNS (mDNS) provides the ability to perform
DNS-like operations on the local link in the absence of any conventional Unicas
t DNS server. In addition, Multicast DNS designates a portion of the DNS namesp
ace to be free for local use, without the need to pay any annual fee, and withou
t the need to set up delegations or otherwise configure a conventional DNS serve
r to answer for those names.</t>
<t indent="0">The primary benefits of Multicast DNS names are that
(i) they require little or no administration or configuration to set them up, (
ii) they work when no infrastructure is present, and (iii) they work during infr
astructure failures.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6762"/>
<seriesInfo name="DOI" value="10.17487/RFC6762"/>
</reference>
<reference anchor="RFC7721" target="https://www.rfc-editor.org/info/rfc7
721" quoteTitle="true" derivedAnchor="RFC7721">
<front>
<title>Security and Privacy Considerations for IPv6 Address Generati
on Mechanisms</title>
<author initials="A." surname="Cooper" fullname="A. Cooper">
<organization showOnFrontPage="true"/>
</author>
<author initials="F." surname="Gont" fullname="F. Gont">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Thaler" fullname="D. Thaler">
<organization showOnFrontPage="true"/>
</author>
<date year="2016" month="March"/>
<abstract>
<t indent="0">This document discusses privacy and security conside
rations for several IPv6 address generation mechanisms, both standardized and no
n-standardized. It evaluates how different mechanisms mitigate different threat
s and the trade-offs that implementors, developers, and users face in choosing d
ifferent addresses or address generation mechanisms.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7721"/>
<seriesInfo name="DOI" value="10.17487/RFC7721"/>
</reference>
<reference anchor="RFC8415" target="https://www.rfc-editor.org/info/rfc8
415" quoteTitle="true" derivedAnchor="RFC8415">
<front>
<title>Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</title>
<author initials="T." surname="Mrugalski" fullname="T. Mrugalski">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Siodelski" fullname="M. Siodelski">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Volz" fullname="B. Volz">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Yourtchenko" fullname="A. Yourtchenko
">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Richardson" fullname="M. Richardson">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Jiang" fullname="S. Jiang">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Lemon" fullname="T. Lemon">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Winters" fullname="T. Winters">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="November"/>
<abstract>
<t indent="0">This document describes the Dynamic Host Configurati
on Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes wit
h network configuration parameters, IP addresses, and prefixes. Parameters can b
e provided statelessly, or in combination with stateful assignment of one or mor
e IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or
in addition to stateless address autoconfiguration (SLAAC).</t>
<t indent="0">This document updates the text from RFC 3315 (the or
iginal DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stat
eless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a clie
nt should wait before refreshing information (RFC 4242), a mechanism for throttl
ing DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay ag
ent handling of unknown messages (RFC 7283). In addition, this document clarifi
es the interactions between models of operation (RFC 7550). As such, this docum
ent obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, and RF
C 7550.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8415"/>
<seriesInfo name="DOI" value="10.17487/RFC8415"/>
</reference>
<reference anchor="RFC8480" target="https://www.rfc-editor.org/info/rfc8
480" quoteTitle="true" derivedAnchor="RFC8480">
<front>
<title>6TiSCH Operation Sublayer (6top) Protocol (6P)</title>
<author initials="Q." surname="Wang" fullname="Q. Wang" role="editor
">
<organization showOnFrontPage="true"/>
</author>
<author initials="X." surname="Vilajosana" fullname="X. Vilajosana">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Watteyne" fullname="T. Watteyne">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="November"/>
<abstract>
<t indent="0">This document defines the "IPv6 over the TSCH mode o
f IEEE 802.15.4e" (6TiSCH) Operation Sublayer (6top) Protocol (6P), which enable
s distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes to add/de
lete Time-Slotted Channel Hopping (TSCH) cells to/on one another. 6P is part of
the 6TiSCH Operation Sublayer (6top), the layer just above the IEEE Std 802.15.
4 TSCH Medium Access Control layer. 6top is composed of one or more Scheduling
Functions (SFs) and the 6top Protocol defined in this document. A 6top SF decid
es when to add/delete cells, and it triggers 6P Transactions. The definition of
SFs is out of scope for this document; however, this document provides the requ
irements for an SF.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8480"/>
<seriesInfo name="DOI" value="10.17487/RFC8480"/>
</reference>
<reference anchor="RFC8610" target="https://www.rfc-editor.org/info/rfc8
610" quoteTitle="true" derivedAnchor="RFC8610">
<front>
<title>Concise Data Definition Language (CDDL): A Notational Convent
ion to Express Concise Binary Object Representation (CBOR) and JSON Data Structu
res</title>
<author initials="H." surname="Birkholz" fullname="H. Birkholz">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Vigano" fullname="C. Vigano">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Bormann" fullname="C. Bormann">
<organization showOnFrontPage="true"/>
</author>
<date year="2019" month="June"/>
<abstract>
<t indent="0">This document proposes a notational convention to ex
press Concise Binary Object Representation (CBOR) data structures (RFC 7049). I
ts main goal is to provide an easy and unambiguous way to express structures for
protocol messages and data formats that use CBOR or JSON.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8610"/>
<seriesInfo name="DOI" value="10.17487/RFC8610"/>
</reference>
<reference anchor="RFC8615" target="https://www.rfc-editor.org/info/rfc8
615" quoteTitle="true" derivedAnchor="RFC8615">
<front>
<title>Well-Known Uniform Resource Identifiers (URIs)</title>
<author initials="M." surname="Nottingham" fullname="M. Nottingham">
<organization showOnFrontPage="true"/>
</author>
<date year="2019" month="May"/>
<abstract>
<t indent="0">This memo defines a path prefix for "well-known loca
tions", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes.<
/t>
<t indent="0">In doing so, it obsoletes RFC 5785 and updates the U
RI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595
to track URI schemes that support well-known URIs in their registry.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8615"/>
<seriesInfo name="DOI" value="10.17487/RFC8615"/>
</reference>
<reference anchor="RFC8742" target="https://www.rfc-editor.org/info/rfc8
742" quoteTitle="true" derivedAnchor="RFC8742">
<front>
<title>Concise Binary Object Representation (CBOR) Sequences</title>
<author initials="C." surname="Bormann" fullname="C. Bormann">
<organization showOnFrontPage="true"/>
</author>
<date year="2020" month="February"/>
<abstract>
<t indent="0">This document describes the Concise Binary Object Re
presentation (CBOR) Sequence format and associated media type "application/cbor-
seq". A CBOR Sequence consists of any number of encoded CBOR data items, simply
concatenated in sequence.</t>
<t indent="0">Structured syntax suffixes for media types allow oth
er media types to build on them and make it explicit that they are built on an e
xisting media type as their foundation. This specification defines and register
s "+cbor-seq" as a structured syntax suffix for CBOR Sequences.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8742"/>
<seriesInfo name="DOI" value="10.17487/RFC8742"/>
</reference>
<reference anchor="RFC8990" target="https://www.rfc-editor.org/info/rfc8
990" quoteTitle="true" derivedAnchor="RFC8990">
<front>
<title>GeneRic Autonomic Signaling Protocol (GRASP)</title>
<author initials="C." surname="Bormann" fullname="C. Bormann">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Carpenter" fullname="B. Carpenter" ro
le="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Liu" fullname="B. Liu" role="editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2021" month="May"/>
<abstract>
<t indent="0">This document specifies the GeneRic Autonomic Signal
ing Protocol (GRASP), which enables autonomic nodes and Autonomic Service Agents
to dynamically discover peers, to synchronize state with each other, and to neg
otiate parameter settings with each other. GRASP depends on an external security
environment that is described elsewhere. The technical objectives and parameter
s for specific application scenarios are to be described in separate documents.
Appendices briefly discuss requirements for the protocol and existing protocols
with comparable features.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8990"/>
<seriesInfo name="DOI" value="10.17487/RFC8990"/>
</reference>
</references>
</references> </references>
<section anchor="example" numbered="true" toc="include" removeInRFC="false"
<!-- ====================================================================== --> pn="section-appendix.a">
<name slugifiedName="name-example">Example</name>
<section anchor="example" title="Example"> <t indent="0" pn="section-appendix.a-1"><xref target="fig_example" format=
"default" sectionFormat="of" derivedContent="Figure 3"/> illustrates a successfu
<t><xref target="fig_example"/> illustrates a successful join protocol exchange. l 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 indent="0" pn="section-appendix.a-2">Once the JP receives the Join Resp
<t>Once the JP receives the Join Response, it authenticates the state within the onse, it authenticates the state within the CoAP token before deciding where to
CoAP token before deciding where to forward. forward.
The JP sets its internal state to that found in the token, and forwards the Join The JP sets its internal state to that found in the token and
Response to the correct pledge. forwards the Join 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" align="left" suppress-title="false" pn="figur
uthenticated encryption, &lt;Tag&gt; denotes the authentication tag." anchor="fi e-3">
g_example"><artwork align="center"><![CDATA[ <name slugifiedName="name-example-of-a-successful-joi">Example of a succ
<---E2E OSCORE--> essful join protocol exchange. { ... } denotes authenticated encryption, &lt;Tag
&gt; denotes the authentication tag.</name>
<artwork align="center" name="" type="" alt="" pn="section-appendix.a-3.
1">
&lt;-----E2E OSCORE------&gt;
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 +---------&gt;| | 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
| | | Payload: { Code: 0.02 (POST), | | | Payload: { Code: 0.02 (POST),
| | | Uri-Path: "j", | | | Uri-Path: "j",
| | | join_request, <Tag&gt; } | | | join_request, <Tag&gt; }
| | | | | |
| | Join | Code: 0.02 (POST) | | Join | Code: 0.02 (POST)
| | Request | Token: opaque state | | Request | Token: opaque state
| +--------->| OSCORE: kid: -, | +---------&gt;| OSCORE: kid: -,
| | | kid_context: EUI-64, | | | kid_context: EUI-64,
| | | Partial IV: 1 | | | Partial IV: 1
| | | Payload: { Code: 0.02 (POST), | | | Payload: { Code: 0.02 (POST),
| | | Uri-Path: "j", | | | Uri-Path: "j",
| | | join_request, <Tag&gt; } | | | join_request, <Tag&gt; }
| | | | | |
| | | | | |
| | Join | Code: 2.04 (Changed) | | Join | Code: 2.04 (Changed)
| | Response | Token: opaque state | | Response | Token: opaque state
| |<---------+ OSCORE: - | |&lt;---------+ OSCORE: -
| | | Payload: { Code: 2.04 (Changed), | | | Payload: { Code: 2.04 (Changed),
| | | configuration, <Tag&gt; } | | | configuration, <Tag&gt; }
| | | | | |
| | | | | |
| Join | | Code: 2.04 (Changed) | Join | | Code: 2.04 (Changed)
| Response | | Token: - | Response | | Token: -
|<---------+ | OSCORE: - |&lt;---------+ | OSCORE: -
| | | Payload: { Code: 2.04 (Changed), | | | Payload: { Code: 2.04 (Changed),
| | | configuration, <Tag&gt; } | | | configuration, <Tag&gt; }
| | | | | |
]]></artwork></figure> </artwork>
</figure>
<t>Where the join_request object is:</t> <t indent="0" pn="section-appendix.a-4">Where the join_request object is:<
/t>
<figure><artwork><![CDATA[ <sourcecode type="" markers="false" pn="section-appendix.a-5">
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 indent="0" pn="section-appendix.a-6">Since the role parameter is not pr
<t>Since the role parameter is not present, the default role of "6TiSCH Node" is esent, the default role of "6TiSCH Node" is implied.</t>
implied.</t> <t indent="0" pn="section-appendix.a-7">The join_request object is convert
ed 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 indent="0" pn="section-appendix.a-8">And the configuration object is th
e following:</t>
<t>And the configuration object is:</t> <sourcecode type="" markers="false" pn="section-appendix.a-9">
<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 indent="0" pn="section-appendix.a-10">Since the key_usage parameter is
<t>Since the key_usage parameter is not present in the link-layer key set object not present in the link-layer key set object, the default value of "6TiSCH-K1K2-
, the default value of "6TiSCH-K1K2-ENC-MIC32" is implied. ENC-MIC32" is implied.
Since key_addinfo parameter is not present and key_id is different than 0, Key I Since the key_addinfo parameter is not present and key_id is
D Mode 0x01 (Key Index) is implied. different from 0, Key ID 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 indent="0" pn="section-appendix.a-11">The configuration object is conve
<t>The configuration object encodes to</t> rted to the following:</t>
<t indent="0" pn="section-appendix.a-12">h'a202820150e6bf4287c2d7618d6a968
<t>h'a202820150e6bf4287c2d7618d6a9687445ffd33e6038142af93' with a size of 26 byt 7445ffd33e6038142af93' with a size of 26 bytes.</t>
es.</t> </section>
<section anchor="lightweight" numbered="true" toc="include" removeInRFC="fal
<!-- ====================================================================== --> se" pn="section-appendix.b">
<name slugifiedName="name-lightweight-implementation-">Lightweight Impleme
</section> ntation Option</name>
<section anchor="lightweight" title="Lightweight Implementation Option"> <t indent="0" pn="section-appendix.b-1">In environments where optimizing t
he implementation footprint is important, it is possible to implement this speci
<t>In environments where optimizing the implementation footprint is important, i fication without having the implementations of HKDF <xref target="RFC5869" forma
t is possible to implement this specification without having the implementations t="default" sectionFormat="of" derivedContent="RFC5869"/> and SHA <xref target="
of HKDF <xref target="RFC5869"/> and SHA <xref target="RFC4231"/> on constraine RFC4231" format="default" sectionFormat="of" derivedContent="RFC4231"/> on const
d devices. rained 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 indent="0" pn="section-appendix.b-2">The use of HKDF to derive OSCORE s
<t>The use of HKDF to derive OSCORE security context parameters ensures that the ecurity context parameters
resulting OSCORE keys have good security properties, and are unique as long as ensures that the resulting OSCORE keys have good security properties
the input for different pledges varies. and are unique as long as the input varies for different pledges.
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" sect ionFormat="of" derivedContent="Section 9"/>, the use of a single PSK shared amon g 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> <section anchor="acknowledgments" numbered="false" toc="include" removeInRFC
="false" pn="section-appendix.c">
<name slugifiedName="name-acknowledgments">Acknowledgments</name>
<t indent="0" pn="section-appendix.c-1">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 indent="0" pn="section-appendix.c-2">The following individuals provided
input to this document (in alphabetic 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>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.d">
<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
<author initials="M." surname="Vučinić" fullname="Mališa Vučinić" role="ed
itor">
<organization showOnFrontPage="true">Inria</organization>
<address>
<postal>
<street>2 Rue Simone Iff</street>
<city>Paris</city>
<code>75012</code>
<country>France</country>
</postal>
<email>malisa.vucinic@inria.fr</email>
</address>
</author>
<author initials="J." surname="Simon" fullname="Jonathan Simon">
<organization showOnFrontPage="true">Analog Devices</organization>
<address>
<postal>
<street>32990 Alvarado-Niles Road, Suite 910</street>
<city>Union City</city>
<region>CA</region>
<code>94587</code>
<country>United States of America</country>
</postal>
<email>jonathan.simon@analog.com</email>
</address>
</author>
<author initials="K." surname="Pister" fullname="Kris Pister">
<organization showOnFrontPage="true">University of California Berkeley</
organization>
<address>
<postal>
<street>512 Cory Hall</street>
<city>Berkeley</city>
<region>CA</region>
<code>94720</code>
<country>United States of America</country>
</postal>
<email>pister@eecs.berkeley.edu</email>
</address>
</author>
<author initials="M." surname="Richardson" fullname="Michael Richardson">
<organization showOnFrontPage="true">Sandelman Software Works</organizat
ion>
<address>
<postal>
<street>470 Dawson Avenue</street>
<city>Ottawa</city>
<region>ON</region>
<code>K1Z5V7</code>
<country>Canada</country>
</postal>
<email>mcr+ietf@sandelman.ca</email>
</address>
</author>
</section>
</back> </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
</rfc> </rfc>
 End of changes. 149 change blocks. 
2815 lines changed or deleted 3697 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/