File: rfc9031.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (3932 lines) | stat: -rw-r--r-- 228,066 bytes
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 9031: Constrained Join Protocol (CoJP) for 6TiSCH</title>
<meta content="Mališa Vučinić" name="author">
<meta content="Jonathan Simon" name="author">
<meta content="Kris Pister" name="author">
<meta content="Michael Richardson" name="author">
<meta content='
       This document describes the minimal framework required for 
a new device, called a "pledge", to securely join a 6TiSCH (IPv6 over 
the Time-Slotted Channel Hopping mode of IEEE 802.15.4) network.
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.
Through a single CoAP (Constrained Application Protocol) request-response 
exchange secured by OSCORE (Object Security for Constrained RESTful Environments), 
the pledge requests admission into the network, and the JRC configures it with link-layer keying material and other parameters.
The JRC may at any time update the parameters through another request-response exchange secured by OSCORE.
This specification defines the Constrained Join Protocol and its CBOR 
(Concise Binary Object Representation) data structures, and it describes 
how to configure the rest of the 6TiSCH communication stack for this join process to occur in a secure manner.
Additional security mechanisms may be added on top of this minimal framework. 
    ' name="description">
<meta content="xml2rfc 3.8.0" name="generator">
<meta content="bootstrapping" name="keyword">
<meta content="onboarding" name="keyword">
<meta content="oscore" name="keyword">
<meta content="9031" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.8.0
    Python 3.6.10
    appdirs 1.4.4
    ConfigArgParse 1.2.3
    google-i18n-address 2.3.5
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.2
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.19.0
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.3.1
    requests 2.22.0
    setuptools 40.6.2
    six 1.14.0
    WeasyPrint 51
-->
<link href="rfc9031.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

  NOTE: Changes at the bottom of this file overrides some earlier settings.

  Once the style has stabilized and has been adopted as an official RFC style,
  this can be consolidated so that style settings occur only in one place, but
  for now the contents of this file consists first of the initial CSS work as
  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
  commented changes found necssary during the development of the v3
  formatters.

*/

/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-ms-viewport {
  width: extend-to-zoom;
  zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
  max-width: 90%;
  margin: 1.5em auto;
  color: #222;
  background-color: #fff;
  font-size: 14px;
  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  margin: 1em 0 0.5em;
  font-weight: bold;
  line-height: 1.3;
}
#title {
  clear: both;
  border-bottom: 1px solid #ddd;
  margin: 0 0 0.5em 0;
  padding: 1em 0 0.5em;
}
.author {
  padding-bottom: 4px;
}
h1 {
  font-size: 26px;
  margin: 1em 0;
}
h2 {
  font-size: 22px;
  margin-top: -20px;  /* provide offset for in-page anchors */
  padding-top: 33px;
}
h3 {
  font-size: 18px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h4 {
  font-size: 16px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h5, h6 {
  font-size: 14px;
}
#n-copyright-notice {
  border-bottom: 1px solid #ddd;
  padding-bottom: 1em;
  margin-bottom: 1em;
}
/* general structure */
p {
  padding: 0;
  margin: 0 0 1em 0;
  text-align: left;
}
div, span {
  position: relative;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignRight.art-text pre {
  padding: 0;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
  padding: 0;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

/* definition lists */
dl {
}
dl > dt {
  float: left;
  margin-right: 1em;
}
/* 
dl.nohang > dt {
  float: none;
}
*/
dl > dd {
  margin-bottom: .8em;
  min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
  margin-bottom: 0em;
}
dl > dd > dl {
  margin-top: 0.5em;
  margin-bottom: 0em;
}

/* links */
a {
  text-decoration: none;
}
a[href] {
  color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
  background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
  color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
  background-color: transparent;
  cursor: default;
} */

/* Figures */
tt, code, pre, code {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
pre {
  border: 1px solid #eee;
  margin: 0;
  padding: 1em;
}
img {
  max-width: 100%;
}
figure {
  margin: 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption {
  font-style: italic;
  margin: 0 0 1em 0;
}
@media screen {
  pre {
    overflow-x: auto;
    max-width: 100%;
    max-width: calc(100% - 22px);
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 1.2em 2em;
}
blockquote {
  background-color: #f9f9f9;
  color: #111; /* Arlen: WCAG 2019 */
  border: 1px solid #ddd;
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
  border: 1px solid #eee;
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 0.5em 0.75em;
}
th {
  text-align: left;
  background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
  background-color: #f5f5f5;
}
table caption {
  font-style: italic;
  margin: 0;
  padding: 0;
  text-align: left;
}
table p {
  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
     be allowed within tables more generally, it would be far better to select on a class. */
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  color: #666; /* Arlen: AHDJ 2019 */
  text-decoration: none;
  visibility: hidden;
  user-select: none;
  -ms-user-select: none;
  -o-user-select:none;
  -moz-user-select: none;
  -khtml-user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
}
@media screen {
  aside:hover > a.pilcrow,
  p:hover > a.pilcrow,
  blockquote:hover > a.pilcrow,
  div:hover > a.pilcrow,
  li:hover > a.pilcrow,
  pre:hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid #eee;
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

/* The prepared/rendered info at the very bottom of the page */
.docInfo {
  color: #666; /* Arlen: WCAG 2019 */
  font-size: 0.9em;
  font-style: italic;
  margin-top: 2em;
}
.docInfo .prepared {
  float: left;
}
.docInfo .prepared {
  float: right;
}

/* table of contents */
#toc  {
  padding: 0.75em 0 2em 0;
  margin-bottom: 1em;
}
nav.toc ul {
  margin: 0 0.5em 0 0;
  padding: 0;
  list-style: none;
}
nav.toc li {
  line-height: 1.3em;
  margin: 0.75em 0;
  padding-left: 1.2em;
  text-indent: -1.2em;
}
/* references */
.references dt {
  text-align: right;
  font-weight: bold;
  min-width: 7em;
}
.references dd {
  margin-left: 8em;
  overflow: auto;
}

.refInstance {
  margin-bottom: 1.25em;
}

.references .ascii {
  margin-bottom: 0.25em;
}

/* index */
.index ul {
  margin: 0 0 0 1em;
  padding: 0;
  list-style: none;
}
.index ul ul {
  margin: 0;
}
.index li {
  margin: 0;
  text-indent: -2em;
  padding-left: 2em;
  padding-bottom: 5px;
}
.indexIndex {
  margin: 0.5em 0 1em;
}
.index a {
  font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
  .index ul {
    -moz-column-count: 2;
    -moz-column-gap: 20px;
  }
  .index ul ul {
    -moz-column-count: 1;
    -moz-column-gap: 0;
  }
}

/* authors */
address.vcard {
  font-style: normal;
  margin: 1em 0;
}

address.vcard .nameRole {
  font-weight: 700;
  margin-left: 0;
}
address.vcard .label {
  font-family: "Noto Sans",Arial,Helvetica,sans-serif;
  margin: 0.5em 0;
}
address.vcard .type {
  display: none;
}
.alternative-contact {
  margin: 1.5em 0 1em;
}
hr.addr {
  border-top: 1px dashed;
  margin: 0;
  color: #ddd;
  max-width: calc(100% - 16px);
}

/* temporary notes */
.rfcEditorRemove::before {
  position: absolute;
  top: 0.2em;
  right: 0.2em;
  padding: 0.2em;
  content: "The RFC Editor will remove this note";
  color: #9e2a00; /* Arlen: WCAG 2019 */
  background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
  position: relative;
  padding-top: 1.8em;
  background-color: #ffd; /* Arlen: WCAG 2019 */
  border-radius: 3px;
}
.cref {
  background-color: #ffd; /* Arlen: WCAG 2019 */
  padding: 2px 4px;
}
.crefSource {
  font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
  body {
    padding-top: 2em;
  }
  #title {
    padding: 1em 0;
  }
  h1 {
    font-size: 24px;
  }
  h2 {
    font-size: 20px;
    margin-top: -18px;  /* provide offset for in-page anchors */
    padding-top: 38px;
  }
  #identifiers dd {
    max-width: 60%;
  }
  #toc {
    position: fixed;
    z-index: 2;
    top: 0;
    right: 0;
    padding: 0;
    margin: 0;
    background-color: inherit;
    border-bottom: 1px solid #ccc;
  }
  #toc h2 {
    margin: -1px 0 0 0;
    padding: 4px 0 4px 6px;
    padding-right: 1em;
    min-width: 190px;
    font-size: 1.1em;
    text-align: right;
    background-color: #444;
    color: white;
    cursor: pointer;
  }
  #toc h2::before { /* css hamburger */
    float: right;
    position: relative;
    width: 1em;
    height: 1px;
    left: -164px;
    margin: 6px 0 0 0;
    background: white none repeat scroll 0 0;
    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
    content: "";
  }
  #toc nav {
    display: none;
    padding: 0.5em 1em 1em;
    overflow: auto;
    height: calc(100vh - 48px);
    border-left: 1px solid #ddd;
  }
}

/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
  body {
    max-width: 724px;
    margin: 42px auto;
    padding-left: 1.5em;
    padding-right: 29em;
  }
  #toc {
    position: fixed;
    top: 42px;
    right: 42px;
    width: 25%;
    margin: 0;
    padding: 0 1em;
    z-index: 1;
  }
  #toc h2 {
    border-top: none;
    border-bottom: 1px solid #ddd;
    font-size: 1em;
    font-weight: normal;
    margin: 0;
    padding: 0.25em 1em 1em 0;
  }
  #toc nav {
    display: block;
    height: calc(90vh - 84px);
    bottom: 0;
    padding: 0.5em 0 0;
    overflow: auto;
  }
  img { /* future proofing */
    max-width: 100%;
    height: auto;
  }
}

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

/* This is commented out here, as the string-set: doesn't
   pass W3C validation currently */
/*
.ears thead .left {
  string-set: ears-top-left content();
}

.ears thead .center {
  string-set: ears-top-center content();
}

.ears thead .right {
  string-set: ears-top-right content();
}

.ears tfoot .left {
  string-set: ears-bottom-left content();
}

.ears tfoot .center {
  string-set: ears-bottom-center content();
}

.ears tfoot .right {
  string-set: ears-bottom-right content();
}
*/

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
  /* The follwing is commented out here, but set appropriately by in code, as
     the content depends on the document */
  /*
  @top-left {
    content: 'Internet-Draft';
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-left {
    content: string(ears-top-left);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-center {
    content: string(ears-top-center);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-right {
    content: string(ears-top-right);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @bottom-left {
    content: string(ears-bottom-left);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-center {
    content: string(ears-bottom-center);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-right {
      content: '[Page ' counter(page) ']';
      vertical-align: top;
      border-top: solid 1px #ccc;
  }
  */

}

/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
  z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}


/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
  width: 8em;
}

/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
  margin-left: 1em;
}

/* Give floating toc a background color (needed when it's a div inside section */
#toc {
  background-color: white;
}

/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
}

/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
  #toc {
    padding: 0 0 1em 1em;
  }
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* prevent monospace from becoming overly large */
tt, code, pre, code {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
  line-height: 1.12;
}


/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin-right: 0.5em;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
  text-align: left;
}
table td.text-center,
table th.text-center {
  text-align: center;
}
table td.text-right,
table th.text-right {
  text-align: right;
}

/* Make the alternative author contact informatio look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 30em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Provide table alignment support.  We can't use the alignX classes above
   since they do unwanted things with caption and other styling. */
table.right {
 margin-left: auto;
 margin-right: 0;
}
table.center {
 margin-left: auto;
 margin-right: auto;
}
table.left {
 margin-left: 0;
 margin-right: auto;
}

/* Give the table caption label the same styling as the figcaption */
caption a[href] {
  color: #222;
}

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  .vcard {
    page-break-inside: avoid;
  }

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9031" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security-15" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 9031</td>
<td class="center">CoJP for 6TiSCH</td>
<td class="right">May 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Vučinić, et al.</td>
<td class="center">Standards Track</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc9031" class="eref">9031</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Standards Track</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2021-05" class="published">May 2021</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">M. Vučinić, <span class="editor">Ed.</span>
</div>
<div class="org">Inria</div>
</div>
<div class="author">
      <div class="author-name">J. Simon</div>
<div class="org">Analog Devices</div>
</div>
<div class="author">
      <div class="author-name">K. Pister</div>
<div class="org">University of California Berkeley</div>
</div>
<div class="author">
      <div class="author-name">M. Richardson</div>
<div class="org">Sandelman Software Works</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9031</h1>
<h1 id="title">Constrained Join Protocol (CoJP) for 6TiSCH</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document describes the minimal framework required for 
a new device, called a "pledge", to securely join a 6TiSCH (IPv6 over 
the Time-Slotted Channel Hopping mode of IEEE 802.15.4) network.
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.
Through a single CoAP (Constrained Application Protocol) request-response 
exchange secured by OSCORE (Object Security for Constrained RESTful Environments), 
the pledge requests admission into the network, and the JRC configures it with link-layer keying material and other parameters.
The JRC may at any time update the parameters through another request-response exchange secured by OSCORE.
This specification defines the Constrained Join Protocol and its CBOR 
(Concise Binary Object Representation) data structures, and it describes 
how to configure the rest of the 6TiSCH communication stack for this join process to occur in a secure manner.
Additional security mechanisms may be added on top of this minimal framework.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This is an Internet Standards Track document.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="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
            <span><a href="https://www.rfc-editor.org/info/rfc9031">https://www.rfc-editor.org/info/rfc9031</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2021 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) 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.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-terminology" class="xref">Terminology</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1" class="keepWithNext"><a href="#section-3" class="xref">3</a>.  <a href="#name-provisioning-phase" class="xref">Provisioning Phase</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-join-process-overview" class="xref">Join Process Overview</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-step-1-enhanced-beacon" class="xref">Step 1 - Enhanced Beacon</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-step-2-neighbor-discovery" class="xref">Step 2 - Neighbor Discovery</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-step-3-constrained-join-pro" class="xref">Step 3 - Constrained Join Protocol (CoJP) Execution</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.4.2.4">
                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-the-special-case-of-the-6lb" class="xref">The Special Case of the 6LBR Pledge Joining</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-link-layer-configuration" class="xref">Link-Layer Configuration</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-distribution-of-time" class="xref">Distribution of Time</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-network-layer-configuration" class="xref">Network-Layer Configuration</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.6.2.1">
                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-identification-of-unauthent" class="xref">Identification of Unauthenticated Traffic</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-application-layer-configura" class="xref">Application-Layer Configuration</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.7.2.1">
                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-statelessness-of-the-jp" class="xref">Statelessness of the JP</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.7.2.2">
                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-recommended-settings" class="xref">Recommended Settings</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.7.2.3">
                <p id="section-toc.1-1.7.2.3.1"><a href="#section-7.3" class="xref">7.3</a>.  <a href="#name-oscore" class="xref">OSCORE</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-constrained-join-protocol-c" class="xref">Constrained Join Protocol (CoJP)</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.8.2.1">
                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-join-exchange" class="xref">Join Exchange</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.8.2.2">
                <p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="xref">8.2</a>.  <a href="#name-parameter-update-exchange" class="xref">Parameter Update Exchange</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.8.2.3">
                <p id="section-toc.1-1.8.2.3.1"><a href="#section-8.3" class="xref">8.3</a>.  <a href="#name-error-handling" class="xref">Error Handling</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.8.2.4">
                <p id="section-toc.1-1.8.2.4.1"><a href="#section-8.4" class="xref">8.4</a>.  <a href="#name-cojp-objects" class="xref">CoJP Objects</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.8.2.5">
                <p id="section-toc.1-1.8.2.5.1"><a href="#section-8.5" class="xref">8.5</a>.  <a href="#name-recommended-settings-2" class="xref">Recommended Settings</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-privacy-considerations" class="xref">Privacy Considerations</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-11" class="xref">11</a>. <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.11.2.1">
                <p id="section-toc.1-1.11.2.1.1"><a href="#section-11.1" class="xref">11.1</a>.  <a href="#name-constrained-join-protocol-co" class="xref">Constrained Join Protocol (CoJP) Parameters</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.11.2.2">
                <p id="section-toc.1-1.11.2.2.1"><a href="#section-11.2" class="xref">11.2</a>.  <a href="#name-constrained-join-protocol-coj" class="xref">Constrained Join Protocol (CoJP) Key Usage</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.11.2.3">
                <p id="section-toc.1-1.11.2.3.1"><a href="#section-11.3" class="xref">11.3</a>.  <a href="#name-constrained-join-protocol-cojp" class="xref">Constrained Join Protocol (CoJP) Unsupported Configuration Codes</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-12" class="xref">12</a>. <a href="#name-references" class="xref">References</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.12.2.1">
                <p id="section-toc.1-1.12.2.1.1"><a href="#section-12.1" class="xref">12.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.12.2.2">
                <p id="section-toc.1-1.12.2.2.1"><a href="#section-12.2" class="xref">12.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#section-appendix.a" class="xref">Appendix A</a>.  <a href="#name-example" class="xref">Example</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#section-appendix.b" class="xref">Appendix B</a>.  <a href="#name-lightweight-implementation-" class="xref">Lightweight Implementation Option</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.15">
            <p id="section-toc.1-1.15.1"><a href="#section-appendix.c" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.16">
            <p id="section-toc.1-1.16.1"><a href="#section-appendix.d" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="introduction">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">This document defines a "secure join" solution for a new device, 
called a "pledge", to securely join a 6TiSCH network.
The term "secure join" refers to network access authentication, authorization,
and parameter distribution as defined in <span>[<a href="#RFC9030" class="xref">RFC9030</a>]</span>.
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 
achieved through the use of a secure channel as configured according to this document.
This document also specifies a configuration of different layers of the 6TiSCH protocol stack that reduces the Denial of Service (DoS) attack surface during the join process.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">This document presumes a 6TiSCH network as described by
    <span>[<a href="#RFC7554" class="xref">RFC7554</a>]</span> and
    <span>[<a href="#RFC8180" class="xref">RFC8180</a>]</span>.
By design, nodes in a 6TiSCH network <span>[<a href="#RFC7554" class="xref">RFC7554</a>]</span> 
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 limited bandwidth <span>[<a href="#RFC8180" class="xref">RFC8180</a>]</span>.
The secure join solution defined in this document therefore keeps the number of over-the-air exchanges to a minimum.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">The microcontrollers at the heart of 6TiSCH nodes have small 
amounts of code memory.
It is therefore paramount to reuse existing protocols available as part of the 6TiSCH stack.
At the application layer, the 6TiSCH stack already relies on 
CoAP <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span> for web transfer and 
on OSCORE <span>[<a href="#RFC8613" class="xref">RFC8613</a>]</span> for its end-to-end security.
The secure join solution defined in this document therefore reuses those two protocols as its building blocks.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">CoJP is a generic protocol that can be used as-is in all modes 
of IEEE Std 802.15.4 <span>[<a href="#IEEE802.15.4" class="xref">IEEE802.15.4</a>]</span>, including 
the Time-Slotted Channel Hopping (TSCH) mode on which 6TiSCH is based.
CoJP may also be used in other (low-power) networking technologies where 
efficiency in terms of communication overhead and code footprint is important.
In such a case, it may be necessary to define through companion documents 
the configuration parameters specific to the technology in question.
The overall process is described in <a href="#join-process-overview" class="xref">Section 4</a>, 
and the configuration of the stack is specific to 6TiSCH.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">CoJP assumes the presence of a Join Registrar/Coordinator (JRC), a central entity.
The configuration defined in this document assumes that the pledge and the JRC share a unique symmetric cryptographic key, called PSK (pre-shared key).
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 during the provisioning phase or by a key exchange protocol that may precede the execution of CoJP.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">When the pledge seeks admission to a 6TiSCH network, it first 
synchronizes to it by initiating the passive scan defined in 
<span>[<a href="#IEEE802.15.4" class="xref">IEEE802.15.4</a>]</span>.
The pledge then exchanges CoJP messages with the JRC; for this end-to-end 
communication to happen, the messages are forwarded by nodes, called Join Proxies,
that are already part of the 6TiSCH network.
The messages exchanged allow the JRC and the pledge to mutually 
authenticate based on the properties provided by OSCORE.
They also allow the JRC to configure the pledge with link-layer 
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 <span>[<a href="#RFC8480" class="xref">RFC8480</a>]</span> 
and can start sending application traffic.<a href="#section-1-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="terminology">
<section id="section-2">
      <h2 id="name-terminology">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
      </h2>
<p id="section-2-1">
    The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>",
    "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>",
    "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>",
    "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are to be
    interpreted as described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> when, and only when, they appear in all capitals, as
    shown here.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">The reader is expected to be familiar with the terms and concepts defined in
    <span>[<a href="#RFC9030" class="xref">RFC9030</a>]</span>,
    <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span>,
    <span>[<a href="#RFC8613" class="xref">RFC8613</a>]</span>, and
    <span>[<a href="#RFC8152" class="xref">RFC8152</a>]</span>.<a href="#section-2-2" class="pilcrow">¶</a></p>
<p id="section-2-3">The specification also includes a set of informative specifications using the Concise Data Definition Language (CDDL) <span>[<a href="#RFC8610" class="xref">RFC8610</a>]</span>.<a href="#section-2-3" class="pilcrow">¶</a></p>
<p id="section-2-4">The following terms defined in <span>[<a href="#RFC9030" class="xref">RFC9030</a>]</span> 
are used extensively throughout this document:<a href="#section-2-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2-5.1">pledge<a href="#section-2-5.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-5.2">joined node<a href="#section-2-5.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-5.3">Join Proxy (JP)<a href="#section-2-5.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-5.4">Join Registrar/Coordinator (JRC)<a href="#section-2-5.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-5.5">Enhanced Beacon (EB)<a href="#section-2-5.5" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-5.6">join protocol<a href="#section-2-5.6" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-5.7">join process<a href="#section-2-5.7" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-2-6">The following terms defined in <span>[<a href="#RFC8505" class="xref">RFC8505</a>]</span> are also used throughout this document:<a href="#section-2-6" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2-7.1">6LoWPAN Border Router (6LBR)<a href="#section-2-7.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-7.2">6LoWPAN Node (6LN)<a href="#section-2-7.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-2-8">The term "6LBR" is used interchangeably with the term "DODAG root" 
defined in <span>[<a href="#RFC6550" class="xref">RFC6550</a>]</span> on the assumption that 
the two entities are co-located, as recommended by 
<span>[<a href="#RFC9030" class="xref">RFC9030</a>]</span>.<a href="#section-2-8" class="pilcrow">¶</a></p>
<p id="section-2-9">The term "pledge", as used throughout the document, explicitly denotes non-6LBR devices attempting to join the network using their IEEE Std 802.15.4 network interface.
The device that attempts to join as the 6LBR of the network and does so over another network interface is explicitly denoted as the "6LBR pledge".
When the text applies equally to the pledge and the 6LBR pledge, 
the "(6LBR) pledge" form is used.<a href="#section-2-9" class="pilcrow">¶</a></p>
<p id="section-2-10">In addition, we use generic terms "pledge identifier" and "network identifier".
See <a href="#provisioning" class="xref">Section 3</a>.<a href="#section-2-10" class="pilcrow">¶</a></p>
</section>
</div>
<div id="provisioning">
<section id="section-3">
      <h2 id="name-provisioning-phase">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-provisioning-phase" class="section-name selfRef">Provisioning Phase</a>
      </h2>
<p id="section-3-1">The (6LBR) pledge is provisioned with certain parameters before attempting to join the network, and the same parameters are provisioned to the JRC.
There are many ways by which this provisioning can be done.
Physically, the parameters can be written into the (6LBR) pledge with a number of mechanisms, such as
    using a JTAG (Joint Test Action Group) interface,
    using a serial (craft) console interface,
    pushing buttons simultaneously on different devices,
    configuring over-the-air in a Faraday cage, etc.
The provisioning can be done by the vendor, the manufacturer, the integrator, etc.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">Details of how this provisioning is done are 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.<a href="#section-3-2" class="pilcrow">¶</a></p>
<p id="section-3-3">Parameters that are provisioned to the (6LBR) pledge include:<a href="#section-3-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3-4">
        <dt id="section-3-4.1">pledge identifier:</dt>
        <dd style="margin-left: 1.5em" id="section-3-4.2">The pledge identifier identifies the (6LBR) pledge.
The pledge identifier <span class="bcp14">MUST</span> be unique in the set of all pledge identifiers managed by a JRC.
The pledge identifier uniqueness is an important security requirement, 
as discussed in <a href="#sec_considerations" class="xref">Section 9</a>.
The pledge identifier is typically the globally unique 64-bit Extended 
Unique Identifier (EUI-64) of the IEEE Std 802.15.4 device, in which 
case it is provisioned by the hardware manufacturer.  The pledge 
identifier is used to generate the IPv6 addresses of the (6LBR) 
pledge and to identify it during the execution of the join protocol.
Depending on the configuration, the pledge identifier may also be 
used after the join process to identify the joined node.
For privacy reasons (see <a href="#privacy_considerations" class="xref">Section 10</a>), 
it is possible to use a pledge identifier different from the EUI-64.
For example, a pledge identifier may be a random byte string, 
but care needs to be taken that such a string meets the uniqueness requirement.<a href="#section-3-4.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-4.3">Pre-Shared Key (PSK):</dt>
        <dd style="margin-left: 1.5em" id="section-3-4.4">A symmetric cryptographic key shared between the (6LBR) pledge and the JRC.
To look up the PSK for a given pledge, the JRC additionally needs to store 
the corresponding pledge identifier.
Each (6LBR) pledge <span class="bcp14">MUST</span> be provisioned with a unique PSK.
The PSK <span class="bcp14">MUST</span> 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 specification.
This could be done during a provisioning step, or companion documents 
can specify the use of a key-agreement protocol.
Common pitfalls when generating PSKs are discussed in 
<a href="#sec_considerations" class="xref">Section 9</a>.
In the case of recommissioning a device to a new owner, the PSK <span class="bcp14">MUST</span> be changed.
Note that the PSK is different from the link-layer keys K1 and K2 
specified in <span>[<a href="#RFC8180" class="xref">RFC8180</a>]</span>.
The PSK is a long-term secret used to protect the execution of the secure 
join protocol specified in this document; the link-layer keys are transported as part of the secure join protocol.<a href="#section-3-4.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-4.5">Optionally, a network identifier:</dt>
        <dd style="margin-left: 1.5em" id="section-3-4.6">The network identifier identifies the 6TiSCH network.
The network identifier <span class="bcp14">MUST</span> be carried within Enhanced Beacon (EB) frames.
Typically, the 16-bit Personal Area Network Identifier (PAN ID) 
defined in <span>[<a href="#IEEE802.15.4" class="xref">IEEE802.15.4</a>]</span> is used as the network identifier.
However, PAN ID is not considered a stable network identifier as it may change during network 
lifetime if a collision with another network is detected.
Companion documents can specify the use of a different network identifier for join purposes, 
but this is out of scope of this specification.
Provisioning the network identifier to a pledge is <span class="bcp14">RECOMMENDED</span>.
However, due to operational constraints, the network identifier may not be 
known at the time of provisioning.
If this parameter is not provisioned to the pledge, the pledge 
will attempt to join one advertised network at a time, which significantly prolongs the join process.
This parameter <span class="bcp14">MUST</span> be provisioned to the 6LBR pledge.<a href="#section-3-4.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-4.7">Optionally, any non-default algorithms:</dt>
        <dd style="margin-left: 1.5em" id="section-3-4.8">The default algorithms are specified in <a href="#mti_algos" class="xref">Section 7.3.3</a>.
When algorithm identifiers are not provisioned, the use of these default algorithms is implied.<a href="#section-3-4.8" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-3-5">Additionally, the 6LBR pledge that is not co-located 
with the JRC needs to be provisioned with the following:<a href="#section-3-5" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3-6">
        <dt id="section-3-6.1">Global IPv6 address of the JRC:</dt>
        <dd style="margin-left: 1.5em" id="section-3-6.2">This address is used by the 6LBR pledge to address the JRC during the join process.
The 6LBR pledge may also obtain the IPv6 address of the JRC through other available 
mechanisms, such as DHCPv6 <span>[<a href="#RFC8415" class="xref">RFC8415</a>]</span>, 
Generic Autonomic Signaling Protocol (GRASP) <span>[<a href="#RFC8990" class="xref">RFC8990</a>]</span>, 
or Multicast DNS (mDNS) <span>[<a href="#RFC6762" class="xref">RFC6762</a>]</span>; 
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.<a href="#section-3-6.2" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
</section>
</div>
<div id="join-process-overview">
<section id="section-4">
      <h2 id="name-join-process-overview">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-join-process-overview" class="section-name selfRef">Join Process Overview</a>
      </h2>
<p id="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:<a href="#section-4-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-4-2">
        <li id="section-4-2.1">The pledge listens for an Enhanced Beacon (EB) frame <span>[<a href="#IEEE802.15.4" class="xref">IEEE802.15.4</a>]</span>.
This frame provides network synchronization information, 
telling the device when it can send a frame to the node 
sending the beacons, which acts as a Join Proxy (JP) for the pledge, 
and when it can expect to receive a frame.
The EB provides the link-layer address of the JP, 
and it may also provide its link-local IPv6 address.<a href="#section-4-2.1" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.2">The pledge configures its link-local IPv6 address and advertises it to the JP using Neighbor Discovery.
The advertisement step may be omitted if the link-local address has been derived from a known unique interface identifier, such as an EUI-64 address.<a href="#section-4-2.2" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.3">The pledge sends a Join Request to the JP in order to securely identify itself to the network.
The Join Request is forwarded to the JRC.<a href="#section-4-2.3" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.4">In the case of successful processing of the request, the pledge receives a Join Response from the JRC (via the JP).
The Join Response contains configuration parameters necessary for the pledge to join the network.<a href="#section-4-2.4" class="pilcrow">¶</a>
</li>
      </ol>
<p id="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 the particulars of a 6TiSCH network.<a href="#section-4-3" class="pilcrow">¶</a></p>
<p id="section-4-4">The join process is shown as a transaction diagram in <a href="#fig_overview_diagram" class="xref">Figure 1</a>:<a href="#section-4-4" class="pilcrow">¶</a></p>
<span id="name-overview-of-a-successful-jo"></span><div id="fig_overview_diagram">
<figure id="figure-1">
        <div class="artwork art-text alignCenter" id="section-4-5.1">
<pre>
+--------+                 +-------+                 +--------+
| pledge |                 |  JP   |                 |  JRC   |
|        |                 |       |                 |        |
+--------+                 +-------+                 +--------+
   |                          |                          |
   |&lt;---Enhanced Beacon (1)---|                          |
   |                          |                          |
   |&lt;-Neighbor Discovery (2)-&gt;|                          |
   |                          |                          |
   |-----Join Request (3a)----|----Join Request (3a)----&gt;| \
   |                          |                          | | CoJP
   |&lt;----Join Response (3b)---|----Join Response (3b)----| /
   |                          |                          |
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-overview-of-a-successful-jo" class="selfRef">Overview of a successful join process.</a>
        </figcaption></figure>
</div>
<p id="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.<a href="#section-4-6" class="pilcrow">¶</a></p>
<p id="section-4-7">The details of each step are described in the following sections.<a href="#section-4-7" class="pilcrow">¶</a></p>
<div id="step-eb">
<section id="section-4.1">
        <h3 id="name-step-1-enhanced-beacon">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-step-1-enhanced-beacon" class="section-name selfRef">Step 1 - Enhanced Beacon</a>
        </h3>
<p id="section-4.1-1">The pledge synchronizes to the network by listening for, 
and receiving, an EB sent by a node already in the network.
This process is entirely defined by <span>[<a href="#IEEE802.15.4" class="xref">IEEE802.15.4</a>]</span> 
and described in <span>[<a href="#RFC7554" class="xref">RFC7554</a>]</span>.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">Once the pledge hears an EB, it synchronizes to the joining schedule using the cells contained in the EB.
The pledge can hear multiple EBs; the selection of which EB to use 
is out of the scope for this document and is discussed in <span>[<a href="#RFC7554" class="xref">RFC7554</a>]</span>.
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,
    whether the source link-layer address of the EB has been tried before,
    at which signal strength the different EBs were received, etc.
In addition, the pledge may be preconfigured to search for EBs with a specific network identifier.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<p id="section-4.1-3">If the pledge is not provisioned with the network identifier, 
it attempts to join one network at a time, as described in <a href="#join_request" class="xref">Section 8.1.1</a>.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
<p id="section-4.1-4">Once the pledge selects the EB, it synchronizes to it and transitions into a low-power mode.
It follows the schedule information contained in the EB, 
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 pledge acts as the JP.<a href="#section-4.1-4" class="pilcrow">¶</a></p>
<p id="section-4.1-5">At this point, the pledge may either proceed to step 2 or 
continue to listen for additional EBs.<a href="#section-4.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="step-nd">
<section id="section-4.2">
        <h3 id="name-step-2-neighbor-discovery">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-step-2-neighbor-discovery" class="section-name selfRef">Step 2 - Neighbor Discovery</a>
        </h3>
<p id="section-4.2-1">The pledge forms its link-local IPv6 address based on 
the interface identifier per <span>[<a href="#RFC4944" class="xref">RFC4944</a>]</span>.
The pledge <span class="bcp14">MAY</span> perform the Neighbor Solicitation / Neighbor Advertisement 
exchange with the JP per <span><a href="https://www.rfc-editor.org/rfc/rfc8505#section-5.6" class="relref">Section 5.6</a> of [<a href="#RFC8505" class="xref">RFC8505</a>]</span>.
Per <span>[<a href="#RFC8505" class="xref">RFC8505</a>]</span>, 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 communication during the join process.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2-2">Note that Neighbor Discovery exchanges at this point are not protected with link-layer security as the pledge is not in possession of the keys.
How the JP accepts these unprotected frames is discussed in <a href="#llreq" class="xref">Section 5</a>.<a href="#section-4.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="step-cojp">
<section id="section-4.3">
        <h3 id="name-step-3-constrained-join-pro">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-step-3-constrained-join-pro" class="section-name selfRef">Step 3 - Constrained Join Protocol (CoJP) Execution</a>
        </h3>
<p id="section-4.3-1">The pledge triggers the join exchange of the Constrained Join Protocol (CoJP).
The join exchange consists of two messages: the Join Request message 
(<span><a href="#step-join-request" class="xref">Step 3a</a> (<a href="#step-join-request" class="xref">Section 4.3.1</a>)</span>) 
and the Join Response message, conditioned on the successful security 
processing of the request (<span><a href="#step-join-response" class="xref">Step 3b</a> (<a href="#step-join-response" class="xref">Section 4.3.2</a>)</span>).<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3-2">All CoJP messages are exchanged over a 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 exchanged between the pledge and the JP as the pledge is not in possession of the link-layer keys in use.
How the JP and pledge accept these unprotected frames is discussed in <a href="#llreq" class="xref">Section 5</a>.
When frames carrying CoJP messages are exchanged between nodes that have already joined the network, the link-layer security is applied according to the security configuration used in the network.<a href="#section-4.3-2" class="pilcrow">¶</a></p>
<div id="step-join-request">
<section id="section-4.3.1">
          <h4 id="name-step-3a-join-request">
<a href="#section-4.3.1" class="section-number selfRef">4.3.1. </a><a href="#name-step-3a-join-request" class="section-name selfRef">Step 3a - Join Request</a>
          </h4>
<p id="section-4.3.1-1">The Join Request is a message sent from the pledge to the JP, 
and which the JP forwards to the JRC.
The pledge indicates in the Join Request the role it requests to play in the network, 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.
How exactly this happens is out of scope of this document; some networks 
may wish to dedicate specific link-layer resources for this join traffic.<a href="#section-4.3.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="step-join-response">
<section id="section-4.3.2">
          <h4 id="name-step-3b-join-response">
<a href="#section-4.3.2" class="section-number selfRef">4.3.2. </a><a href="#name-step-3b-join-response" class="section-name selfRef">Step 3b - Join Response</a>
          </h4>
<p id="section-4.3.2-1">The Join Response is sent by the JRC to the pledge, and it is forwarded through the JP.
The packet containing the Join Response travels from the JRC to the JP using the operating routes in the network.
The JP delivers it to the pledge.
The JP operates as an application-layer proxy, see <a href="#join_proxy" class="xref">Section 7</a>.<a href="#section-4.3.2-1" class="pilcrow">¶</a></p>
<p id="section-4.3.2-2">The Join Response contains various parameters needed by 
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.<a href="#section-4.3.2-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="the-special-case-of-the-6lbr-pledge-joining">
<section id="section-4.4">
        <h3 id="name-the-special-case-of-the-6lb">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-the-special-case-of-the-6lb" class="section-name selfRef">The Special Case of the 6LBR Pledge Joining</a>
        </h3>
<p id="section-4.4-1">The 6LBR pledge performs <a href="#step-cojp" class="xref">Section 4.3</a> 
of the join process just like any other pledge, albeit over a different network interface.
There is no JP intermediating the communication between the 6LBR pledge and the JRC, as described in <a href="#netreq" class="xref">Section 6</a>.
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 CoJP is out of scope of this document.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="llreq">
<section id="section-5">
      <h2 id="name-link-layer-configuration">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-link-layer-configuration" class="section-name selfRef">Link-Layer Configuration</a>
      </h2>
<p id="section-5-1">In an operational 6TiSCH network, all frames use link-layer frame security <span>[<a href="#RFC8180" class="xref">RFC8180</a>]</span>.
The IEEE Std 802.15.4 security attributes include frame authenticity 
and optionally frame confidentiality (i.e., encryption).<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">Any node sending EB frames <span class="bcp14">MUST</span> be prepared to act as a JP for potential pledges.<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3">The pledge does not initially perform an authenticity check of the EB frames
because 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 
synchronize to the network, as EBs are not encrypted <span>[<a href="#RFC8180" class="xref">RFC8180</a>]</span>.<a href="#section-5-3" class="pilcrow">¶</a></p>
<p id="section-5-4">When sending frames during the join process, the pledge sends unencrypted and 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.
This behavior may be implemented by setting the "secExempt" attribute in the IEEE Std 802.15.4 security configuration tables.
It is expected that the lower layer provides an interface to indicate to 
the upper layer that unsecured frames are being received from a device.
The upper layer can use that information to determine that a join process 
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.
The JP can additionally use information such as the value of the 
join rate parameter (<a href="#configuration_object" class="xref">Section 8.4.2</a>) 
set by the JRC, physical button press, etc.<a href="#section-5-4" class="pilcrow">¶</a></p>
<p id="section-5-5">When the pledge initially synchronizes with the network, 
it has no means of verifying the authenticity of EB frames.
Because an attacker can craft a frame that looks like a legitimate EB frame, 
this opens up a DoS vector, as discussed in <a href="#sec_considerations" class="xref">Section 9</a>.<a href="#section-5-5" class="pilcrow">¶</a></p>
<div id="timedistribution">
<section id="section-5.1">
        <h3 id="name-distribution-of-time">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-distribution-of-time" class="section-name selfRef">Distribution of Time</a>
        </h3>
<p id="section-5.1-1">Nodes in a 6TiSCH network keep a global notion of time 
known as the Absolute Slot Number.
The Absolute Slot Number is used in the construction of the 
link-layer nonce, as defined in <span>[<a href="#IEEE802.15.4" class="xref">IEEE802.15.4</a>]</span>.
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 nor its freshness verified.
During the join process, the pledge sends frames that are unprotected at the link-layer and protected end-to-end instead.
The pledge does not obtain the time information as the output of the join process as this information is local to the network and may not be known at the JRC.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<p id="section-5.1-2">This enables an attack on the pledge where the attacker replays to the pledge legitimate EB frames obtained from the network and acts as a man-in-the-middle between the pledge and the JP.
The EB frames will make the pledge believe that the replayed Absolute Slot Number value is the current notion of time in the network.
By forwarding the join traffic to the legitimate JP, the attacker enables the pledge to join the network.
Under different conditions relating to the reuse of the pledge's short address by the JRC or its attempt to rejoin the network, this may cause the pledge to reuse the link-layer nonce in the first frame it sends protected after the join process is completed.<a href="#section-5.1-2" class="pilcrow">¶</a></p>
<p id="section-5.1-3">For this reason, all frames originated at the JP and 
destined to the pledge during the join process <span class="bcp14">MUST</span> 
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 pledge 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 frames should be passed to the upper layer for processing using the promiscuous mode of <span>[<a href="#IEEE802.15.4" class="xref">IEEE802.15.4</a>]</span> or another appropriate mechanism.
When the upper-layer processing on the pledge is completed, 
and the link-layer keys are configured, the upper layer <span class="bcp14">MUST</span> 
trigger the security processing of the corresponding frame.
Once the security processing of the frame carrying the Join Response 
message is successful, the current Absolute Slot Number kept locally 
at the pledge <span class="bcp14">SHALL</span> be declared as valid.<a href="#section-5.1-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="netreq">
<section id="section-6">
      <h2 id="name-network-layer-configuration">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-network-layer-configuration" class="section-name selfRef">Network-Layer Configuration</a>
      </h2>
<p id="section-6-1">The pledge and the JP <span class="bcp14">SHOULD</span> keep a separate neighbor cache for untrusted entries and use it to store each other's information during the join process.
Mixing neighbor entries belonging to pledges and nodes that are 
part of the network opens up the JP to a DoS attack, as the attacker 
may fill the JP's neighbor table and prevent the discovery of legitimate neighbors.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">Once the pledge obtains link-layer keys and becomes a joined node, 
it is able to securely communicate with its neighbors, 
obtain the network IPv6 prefix, and form its global IPv6 address.
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 <span>[<a href="#RFC8505" class="xref">RFC8505</a>]</span>.
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 pledge.<a href="#section-6-2" class="pilcrow">¶</a></p>
<p id="section-6-3">The pledge does not communicate with the JRC at the network layer.
This allows the pledge to join without knowing the IPv6 address of the JRC.
Instead, the pledge communicates with the JP at the network layer using link-local addressing, and with the JRC at the application layer, as specified in <a href="#join_proxy" class="xref">Section 7</a>.<a href="#section-6-3" class="pilcrow">¶</a></p>
<p id="section-6-4">The JP communicates with the JRC over global IPv6 addresses.
The JP discovers the network IPv6 prefix and configures its global IPv6 address upon successful completion of the join process and the obtention of link-layer keys.
The pledge learns the IPv6 address of the JRC from the Join Response, as specified in <a href="#join_response" class="xref">Section 8.1.2</a>; it uses it once joined in order to operate as a JP.<a href="#section-6-4" class="pilcrow">¶</a></p>
<p id="section-6-5">As a special case, the 6LBR pledge may have an additional 
network interface that it uses in order to obtain the configuration 
parameters from the JRC and to start advertising the 6TiSCH network.
This additional interface needs to be configured with a global IPv6 address, 
by a mechanism that is out of scope of this document.
The 6LBR pledge uses this interface to directly communicate with the JRC using global IPv6 addressing.<a href="#section-6-5" class="pilcrow">¶</a></p>
<p id="section-6-6">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 Response message for space optimization.
The 6LBR then <span class="bcp14">MUST</span> set the DODAGID field in the RPL 
DODAG Information Objects (DIOs) <span>[<a href="#RFC6550" class="xref">RFC6550</a>]</span> to its IPv6 address.
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.<a href="#section-6-6" class="pilcrow">¶</a></p>
<div id="traffic_join_request">
<section id="section-6.1">
        <h3 id="name-identification-of-unauthent">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-identification-of-unauthent" class="section-name selfRef">Identification of Unauthenticated Traffic</a>
        </h3>
<p id="section-6.1-1">The traffic that is proxied by the JP comes from unauthenticated pledges, and there may be an arbitrary amount of it.
In particular, an attacker may send fraudulent traffic in an attempt to overwhelm the network.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
<p id="section-6.1-2">When operating as part of a 6TiSCH minimal network 
<span>[<a href="#RFC8180" class="xref">RFC8180</a>]</span> 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.<a href="#section-6.1-2" class="pilcrow">¶</a></p>
<p id="section-6.1-3">The JP is aware of what traffic originates from unauthenticated pledges, and so can avoid allocating additional bandwidth itself.
The JP implements a data cap on outgoing join traffic by 
implementing the recommendation of 1 packet per 3 seconds in 
<span><a href="https://www.rfc-editor.org/rfc/rfc8085#section-3.1.3" class="relref">Section 3.1.3</a> of [<a href="#RFC8085" class="xref">RFC8085</a>]</span>.
This can be achieved with the congestion control mechanism 
specified in <span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-4.7" class="relref">Section 4.7</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span>.
This cap will not protect intermediate nodes as they cannot tell join traffic from regular traffic.
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 unauthenticated pledges.
In order to permit the intermediate nodes to avoid this, the traffic needs to be tagged.
<span>[<a href="#RFC2597" class="xref">RFC2597</a>]</span> 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 packet.<a href="#section-6.1-3" class="pilcrow">¶</a></p>
<div id="traffic-from-jp-to-jrc">
<section id="section-6.1.1">
          <h4 id="name-traffic-from-jp-to-jrc">
<a href="#section-6.1.1" class="section-number selfRef">6.1.1. </a><a href="#name-traffic-from-jp-to-jrc" class="section-name selfRef">Traffic from JP to JRC</a>
          </h4>
<p id="section-6.1.1-1">The JP <span class="bcp14">SHOULD</span> set the DSCP of packets that it 
produces as part of the forwarding process to AF43 code point 
(See <span><a href="https://www.rfc-editor.org/rfc/rfc2597#section-6" class="relref">Section 6</a> of [<a href="#RFC2597" class="xref">RFC2597</a>]</span>).
A JP that does not require a specific DSCP value on forwarded traffic 
should set it to zero so that it is compressed out.<a href="#section-6.1.1-1" class="pilcrow">¶</a></p>
<p id="section-6.1.1-2">A Scheduling Function (SF) running on 6TiSCH nodes <span class="bcp14">SHOULD NOT</span> allocate additional cells as a result of traffic with code point AF43.
Companion SF documents <span class="bcp14">SHOULD</span> specify how this recommended behavior is achieved.<a href="#section-6.1.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="traffic-from-jrc-to-jp">
<section id="section-6.1.2">
          <h4 id="name-traffic-from-jrc-to-jp">
<a href="#section-6.1.2" class="section-number selfRef">6.1.2. </a><a href="#name-traffic-from-jrc-to-jp" class="section-name selfRef">Traffic from JRC to JP</a>
          </h4>
<p id="section-6.1.2-1">The JRC <span class="bcp14">SHOULD</span> set the 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 buffers over the traffic going towards the JRC.<a href="#section-6.1.2-1" class="pilcrow">¶</a></p>
<p id="section-6.1.2-2">The 6LBR links are often the most congested within a DODAG, 
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 never exceed the bandwidth allocated to the best effort traffic cells.
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.<a href="#section-6.1.2-2" class="pilcrow">¶</a></p>
<p id="section-6.1.2-3">Companion SF documents <span class="bcp14">SHOULD</span> specify how traffic with code point AF42 is handled with respect to cell allocation.
If the recommended behavior described in this section is not followed, 
the network may become prone to the attack discussed in <a href="#traffic_join_request" class="xref">Section 6.1</a>.<a href="#section-6.1.2-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="join_proxy">
<section id="section-7">
      <h2 id="name-application-layer-configura">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-application-layer-configura" class="section-name selfRef">Application-Layer Configuration</a>
      </h2>
<p id="section-7-1">The CoJP join exchange in <a href="#fig_overview_diagram" class="xref">Figure 1</a> is carried over CoAP <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span> and the secure channel provided by OSCORE <span>[<a href="#RFC8613" class="xref">RFC8613</a>]</span>.
The (6LBR) pledge acts as a CoAP client; the JRC acts as a CoAP server.
The JP implements CoAP forward proxy functionality <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span>.
Because the JP can also be a constrained device, it cannot implement a cache.<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">The pledge designates a JP as a proxy by including the 
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 to the well-known JRC's alias, as specified in <a href="#join_request" class="xref">Section 8.1.1</a>.<a href="#section-7-2" class="pilcrow">¶</a></p>
<p id="section-7-3">The JP resolves the alias to the IPv6 address of the 
JRC that it learned when it acted as a pledge and joined the network.
This allows the JP to reach the JRC at the network layer and forward the requests on behalf of the pledge.<a href="#section-7-3" class="pilcrow">¶</a></p>
<div id="statelessness-of-the-jp">
<section id="section-7.1">
        <h3 id="name-statelessness-of-the-jp">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-statelessness-of-the-jp" class="section-name selfRef">Statelessness of the JP</a>
        </h3>
<p id="section-7.1-1">The CoAP proxy defined in <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span> 
keeps per-client state information in order to forward the response towards the originator of the request.
This state information includes at least
    the CoAP token,
    the IPv6 address of the client, and
    the UDP source port number.
Since the JP can be a constrained device that acts as a CoAP proxy, 
memory limitations make it prone to a DoS attack.<a href="#section-7.1-1" class="pilcrow">¶</a></p>
<p id="section-7.1-2">This DoS vector on the JP can be mitigated by making the JP act as a stateless CoAP proxy, where "state" encompasses the information related to individual pledges.
The JP can wrap the state it needs to keep for a given pledge throughout the network stack in a "state object" and include it as a CoAP token in the forwarded request to the JRC.
The JP may use the CoAP token as defined in <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span>, 
if the size of the serialized state object permits, or use the extended 
CoAP token defined in <span>[<a href="#RFC8974" class="xref">RFC8974</a>]</span> 
to transport the state object.
The JRC and any other potential proxy on the JP-JRC path <span class="bcp14">MUST</span> 
support extended token lengths, as defined in <span>[<a href="#RFC8974" class="xref">RFC8974</a>]</span>.
Since the CoAP token is echoed back in the response, the JP is able to decode the state object and configure the state needed to forward the response to the pledge.
The information that the JP needs to encode in the state object to operate 
in a fully stateless manner with respect to a given pledge is implementation specific.<a href="#section-7.1-2" class="pilcrow">¶</a></p>
<p id="section-7.1-3">It is <span class="bcp14">RECOMMENDED</span> that the JP operates in a 
stateless manner and signals the per-pledge state within the CoAP token 
for every request that it forwards into the network on behalf of unauthenticated pledges.
When the JP is operating in a stateless manner, the security considerations from 
<span>[<a href="#RFC8974" class="xref">RFC8974</a>]</span> apply, and the type of the CoAP message that the JP forwards on behalf of the pledge <span class="bcp14">MUST</span> be non-confirmable (NON), regardless of the message type received from the pledge.
The use of a non-confirmable message by the JP alleviates the JP from keeping CoAP message exchange state.
The retransmission burden is then entirely shifted to the pledge.
A JP that operates in a stateless manner still needs to keep congestion control state with the JRC, see <a href="#sec_considerations" class="xref">Section 9</a>.
Recommended values of CoAP settings for use during the join process, both by the pledge and the JP, are given in <a href="#parameters" class="xref">Section 7.2</a>.<a href="#section-7.1-3" class="pilcrow">¶</a></p>
<p id="section-7.1-4">Note that in some networking stack implementations, a fully (per-pledge) stateless operation of the JP may be challenging from the implementation's point of view.
In those cases, the JP may operate as a stateful proxy that stores 
the per-pledge state until the response is received or timed out, but this comes at a price of a DoS vector.<a href="#section-7.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="parameters">
<section id="section-7.2">
        <h3 id="name-recommended-settings">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-recommended-settings" class="section-name selfRef">Recommended Settings</a>
        </h3>
<p id="section-7.2-1">This section gives <span class="bcp14">RECOMMENDED</span> values of CoAP settings during the join process.<a href="#section-7.2-1" class="pilcrow">¶</a></p>
<span id="name-recommended-coap-settings"></span><table class="center" id="table-1">
          <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-recommended-coap-settings" class="selfRef">Recommended CoAP settings.</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Name</th>
              <th class="text-left" rowspan="1" colspan="1">Default Value</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">ACK_TIMEOUT</td>
              <td class="text-left" rowspan="1" colspan="1">10 seconds</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">ACK_RANDOM_FACTOR</td>
              <td class="text-left" rowspan="1" colspan="1">1.5</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">MAX_RETRANSMIT</td>
              <td class="text-left" rowspan="1" colspan="1">4</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">NSTART</td>
              <td class="text-left" rowspan="1" colspan="1">1</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">DEFAULT_LEISURE</td>
              <td class="text-left" rowspan="1" colspan="1">5 seconds</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">PROBING_RATE</td>
              <td class="text-left" rowspan="1" colspan="1">1 byte/second</td>
            </tr>
          </tbody>
        </table>
<p id="section-7.2-3">These values may be configured to values specific to the deployment.
The default values have been chosen to accommodate a wide range of deployments, taking into account dense networks.<a href="#section-7.2-3" class="pilcrow">¶</a></p>
<p id="section-7.2-4">The PROBING_RATE value at the JP is controlled by the join rate parameter, see <a href="#configuration_object" class="xref">Section 8.4.2</a>.
Following <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span>, the average data rate in sending to the JRC must not exceed PROBING_RATE.
For security reasons, the average data rate <span class="bcp14">SHOULD</span> 
be measured over a rather short window, e.g., ACK_TIMEOUT, 
see <a href="#sec_considerations" class="xref">Section 9</a>.<a href="#section-7.2-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="oscore_sec_context">
<section id="section-7.3">
        <h3 id="name-oscore">
<a href="#section-7.3" class="section-number selfRef">7.3. </a><a href="#name-oscore" class="section-name selfRef">OSCORE</a>
        </h3>
<p id="section-7.3-1">Before the (6LBR) pledge and the JRC start exchanging CoAP messages protected with OSCORE, they need to derive the OSCORE security context from the provisioned parameters, as discussed in <a href="#provisioning" class="xref">Section 3</a>.<a href="#section-7.3-1" class="pilcrow">¶</a></p>
<p id="section-7.3-2">The OSCORE security context <span class="bcp14">MUST</span> be derived per 
<span><a href="https://www.rfc-editor.org/rfc/rfc8613#section-3" class="relref">Section 3</a> of [<a href="#RFC8613" class="xref">RFC8613</a>]</span>.<a href="#section-7.3-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.3-3.1">The Master Secret <span class="bcp14">MUST</span> be the PSK.<a href="#section-7.3-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.3-3.2">The Master Salt <span class="bcp14">MUST</span> be the empty byte string.<a href="#section-7.3-3.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.3-3.3">The ID Context <span class="bcp14">MUST</span> be set to the pledge identifier.<a href="#section-7.3-3.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.3-3.4">The ID of the pledge <span class="bcp14">MUST</span> be set to the empty byte string.
This identifier is used as the OSCORE Sender ID of the pledge in the security context derivation, since the pledge initially acts as a CoAP client.<a href="#section-7.3-3.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.3-3.5">The ID of the JRC <span class="bcp14">MUST</span> be set to the byte string 0x4a5243 ("JRC" in ASCII).
This identifier is used as the OSCORE Recipient ID of the pledge in the security context derivation, as the JRC initially acts as a CoAP server.<a href="#section-7.3-3.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.3-3.6">The Algorithm <span class="bcp14">MUST</span> be set to the value 
from <span>[<a href="#RFC8152" class="xref">RFC8152</a>]</span>, agreed to out-of-band 
by the same mechanism used to provision the PSK.
The default is AES-CCM-16-64-128.<a href="#section-7.3-3.6" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.3-3.7">The key derivation function <span class="bcp14">MUST</span> be agreed out-of-band by the same mechanism used to provision the PSK.
Default is HKDF SHA-256 <span>[<a href="#RFC5869" class="xref">RFC5869</a>]</span>.<a href="#section-7.3-3.7" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-7.3-4">Since the pledge's OSCORE Sender ID is 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 the OSCORE option.
The derivation in <span>[<a href="#RFC8613" class="xref">RFC8613</a>]</span> results in OSCORE keys and a Common Initialization Vector (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 <span>[<a href="#RFC8613" class="xref">RFC8613</a>]</span>.<a href="#section-7.3-4" class="pilcrow">¶</a></p>
<p id="section-7.3-5">Implementations <span class="bcp14">MUST</span> ensure that multiple CoAP requests, including to different JRCs, are properly incrementing the sequence numbers, so that the same sequence number is never reused in distinct requests protected under the same PSK.
The pledge typically sends requests to different JRCs if it is not provisioned with the network identifier and attempts to join one network at a time.
Failure to comply will break the security guarantees of the Authenticated Encryption with Associated Data (AEAD) algorithm because of nonce reuse.<a href="#section-7.3-5" class="pilcrow">¶</a></p>
<p id="section-7.3-6">This OSCORE security context is used for the
    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 client and the joined node as a CoAP server, as discussed in <a href="#update" class="xref">Section 8.2</a>.
Note that when the (6LBR) pledge and the JRC change roles between 
CoAP client and CoAP server, the same OSCORE security context as 
initially derived remains in use, and the derived parameters are unchanged, 
for example, Sender ID when sending and Recipient ID when receiving 
(see <span><a href="https://www.rfc-editor.org/rfc/rfc8613#section-3.1" class="relref">Section 3.1</a> of [<a href="#RFC8613" class="xref">RFC8613</a>]</span>).
A (6LBR) pledge is expected to have exactly one OSCORE security context with the JRC.<a href="#section-7.3-6" class="pilcrow">¶</a></p>
<div id="persistency">
<section id="section-7.3.1">
          <h4 id="name-replay-window-and-persisten">
<a href="#section-7.3.1" class="section-number selfRef">7.3.1. </a><a href="#name-replay-window-and-persisten" class="section-name selfRef">Replay Window and Persistency</a>
          </h4>
<p id="section-7.3.1-1">Both the (6LBR) pledge and the JRC <span class="bcp14">MUST</span> 
implement a replay-protection mechanism.
The use of the default OSCORE replay-protection mechanism specified in 
<span><a href="https://www.rfc-editor.org/rfc/rfc8613#section-3.2.2" class="relref">Section 3.2.2</a> of [<a href="#RFC8613" class="xref">RFC8613</a>]</span> is <span class="bcp14">RECOMMENDED</span>.<a href="#section-7.3.1-1" class="pilcrow">¶</a></p>
<p id="section-7.3.1-2">Implementations <span class="bcp14">MUST</span> ensure that mutable OSCORE context parameters (Sender Sequence Number, Replay Window) are stored in persistent memory.
A technique detailed in <span><a href="https://www.rfc-editor.org/rfc/rfc8613#appendix-B.1.1" class="relref">Appendix B.1.1</a> of [<a href="#RFC8613" class="xref">RFC8613</a>]</span> 
that prevents reuse of sequence numbers <span class="bcp14">MUST</span> be implemented.
Each update of the OSCORE Replay Window <span class="bcp14">MUST</span> be written to persistent memory.<a href="#section-7.3.1-2" class="pilcrow">¶</a></p>
<p id="section-7.3.1-3">This is an important security requirement in order to guarantee nonce uniqueness and resistance to replay attacks across reboots and rejoins.
Traffic between the (6LBR) pledge and the JRC is rare, making security outweigh the cost of writing to persistent memory.<a href="#section-7.3.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="oscore_error_handling">
<section id="section-7.3.2">
          <h4 id="name-oscore-error-handling">
<a href="#section-7.3.2" class="section-number selfRef">7.3.2. </a><a href="#name-oscore-error-handling" class="section-name selfRef">OSCORE Error Handling</a>
          </h4>
<p id="section-7.3.2-1">Errors raised by OSCORE during the join process <span class="bcp14">MUST</span> be silently dropped, with no error response being signaled.
The pledge <span class="bcp14">MUST</span> silently discard any response not protected with OSCORE, including error codes.<a href="#section-7.3.2-1" class="pilcrow">¶</a></p>
<p id="section-7.3.2-2">Such errors may happen for a number of reasons, including
    failed lookup of an appropriate security context (e.g., the pledge attempting to join a wrong network),
    failed decryption,
    positive Replay Window lookup,
    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.<a href="#section-7.3.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="mti_algos">
<section id="section-7.3.3">
          <h4 id="name-mandatory-to-implement-algo">
<a href="#section-7.3.3" class="section-number selfRef">7.3.3. </a><a href="#name-mandatory-to-implement-algo" class="section-name selfRef">Mandatory-to-Implement Algorithms</a>
          </h4>
<p id="section-7.3.3-1">The mandatory-to-implement AEAD algorithm for use with OSCORE is AES-CCM-16-64-128 from <span>[<a href="#RFC8152" class="xref">RFC8152</a>]</span>.
This is the algorithm used for securing IEEE Std 802.15.4 frames, and hardware acceleration 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.<a href="#section-7.3.3-1" class="pilcrow">¶</a></p>
<p id="section-7.3.3-2">The mandatory-to-implement hash algorithm is SHA-256 <span>[<a href="#RFC4231" class="xref">RFC4231</a>]</span>.
The mandatory-to-implement key derivation function is HKDF <span>[<a href="#RFC5869" class="xref">RFC5869</a>]</span>, instantiated with a SHA-256 hash.
See <a href="#lightweight" class="xref">Appendix B</a> for implementation guidance when code footprint is important.<a href="#section-7.3.3-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="join_protocol">
<section id="section-8">
      <h2 id="name-constrained-join-protocol-c">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-constrained-join-protocol-c" class="section-name selfRef">Constrained Join Protocol (CoJP)</a>
      </h2>
<p id="section-8-1">The Constrained Join Protocol (CoJP) is a lightweight protocol over CoAP <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span> and a secure channel provided by OSCORE <span>[<a href="#RFC8613" class="xref">RFC8613</a>]</span>.
CoJP allows a (6LBR) pledge to request admission into a network managed by the JRC.
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 node that formerly acted as a (6LBR) pledge.
For example, network-wide rekeying can be implemented by updating the keying material on each node.<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2">CoJP relies on the security properties provided by OSCORE.
This includes end-to-end confidentiality, data authenticity, replay protection, and a secure binding of responses to requests.<a href="#section-8-2" class="pilcrow">¶</a></p>
<span id="name-abstract-layering-of-cojp"></span><div id="fig-stack">
<figure id="figure-2">
        <div class="artwork art-text alignCenter" id="section-8-3.1">
<pre>
+-----------------------------------+
|  Constrained Join Protocol (CoJP) |
+-----------------------------------+
+-----------------------------------+  \
|         Requests / Responses      |  |
|-----------------------------------|  |
|               OSCORE              |  | CoAP
|-----------------------------------|  |
|           Messaging Layer         |  |
+-----------------------------------+  /
+-----------------------------------+
|                UDP                |
+-----------------------------------+
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-abstract-layering-of-cojp" class="selfRef">Abstract layering of CoJP.</a>
        </figcaption></figure>
</div>
<p id="section-8-4">When a (6LBR) pledge requests admission to a given network, it undergoes the CoJP join exchange that consists of:<a href="#section-8-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-8-5.1">The Join Request message, sent by the (6LBR) pledge to the JRC, potentially proxied by the JP.
The Join Request message and its mapping to CoAP is specified in <a href="#join_request" class="xref">Section 8.1.1</a>.<a href="#section-8-5.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-8-5.2">The Join Response message, sent by the JRC to the (6LBR) pledge, if the JRC successfully processes the Join Request using OSCORE 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 and its mapping to CoAP is specified in <a href="#join_response" class="xref">Section 8.1.2</a>.<a href="#section-8-5.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-8-6">When the JRC needs to update the parameters of a joined node 
that formerly acted as a (6LBR) pledge, it executes the CoJP parameter update exchange 
that consists of the following:<a href="#section-8-6" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-8-7.1">The Parameter Update message, sent by the JRC to the joined node that formerly acted as a (6LBR) pledge.
The Parameter Update message and its mapping to CoAP is specified in <a href="#parameter_update" class="xref">Section 8.2.1</a>.<a href="#section-8-7.1" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-8-8">The payload of CoJP messages is encoded with CBOR <span>[<a href="#RFC8949" class="xref">RFC8949</a>]</span>.
The CBOR data structures that may appear as the payload of different CoJP messages are specified in <a href="#cbor_objects" class="xref">Section 8.4</a>.<a href="#section-8-8" class="pilcrow">¶</a></p>
<div id="join">
<section id="section-8.1">
        <h3 id="name-join-exchange">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-join-exchange" class="section-name selfRef">Join Exchange</a>
        </h3>
<p id="section-8.1-1">This section specifies the messages exchanged when the (6LBR) pledge requests admission and configuration parameters from the JRC.<a href="#section-8.1-1" class="pilcrow">¶</a></p>
<div id="join_request">
<section id="section-8.1.1">
          <h4 id="name-join-request-message">
<a href="#section-8.1.1" class="section-number selfRef">8.1.1. </a><a href="#name-join-request-message" class="section-name selfRef">Join Request Message</a>
          </h4>
<p id="section-8.1.1-1">The Join Request message that the (6LBR) pledge sends <span class="bcp14">SHALL</span> be mapped to a CoAP request:<a href="#section-8.1.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-8.1.1-2.1">The request method is POST.<a href="#section-8.1.1-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-8.1.1-2.2">The type is Confirmable (CON).<a href="#section-8.1.1-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-8.1.1-2.3">The Proxy-Scheme option is set to "coap".<a href="#section-8.1.1-2.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-8.1.1-2.4">The Uri-Host option is set to "6tisch.arpa".
This is an anycast type of identifier of the JRC that is resolved to its IPv6 address by the JP or the 6LBR pledge.<a href="#section-8.1.1-2.4" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-8.1.1-2.5">The Uri-Path option is set to "j".<a href="#section-8.1.1-2.5" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-8.1.1-2.6">The OSCORE option <span class="bcp14">SHALL</span> be set according to <span>[<a href="#RFC8613" class="xref">RFC8613</a>]</span>.
  The OSCORE security context used is the one derived in <a href="#oscore_sec_context" class="xref">Section 7.3</a>.
  The OSCORE 'kid context' allows the JRC to retrieve the security context for a given pledge.<a href="#section-8.1.1-2.6" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-8.1.1-2.7">The payload is a Join_Request CBOR object, as defined in <a href="#join_request_object" class="xref">Section 8.4.1</a>.<a href="#section-8.1.1-2.7" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-8.1.1-3">Since the Join Request is a confirmable message, the transmission at (6LBR) pledge will be controlled by CoAP's retransmission mechanism.
The JP, when operating in a stateless manner, forwards this Join Request as a non-confirmable (NON) CoAP message, as specified in <a href="#join_proxy" class="xref">Section 7</a>.
If the CoAP implementation at the (6LBR) pledge declares the 
message transmission a failure, the (6LBR) pledge <span class="bcp14">SHOULD</span> 
attempt to join a 6TiSCH network advertised with a different network identifier.
See <a href="#parameters" class="xref">Section 7.2</a> for recommended values of CoAP settings to use during the join exchange.<a href="#section-8.1.1-3" class="pilcrow">¶</a></p>
<p id="section-8.1.1-4">If all join attempts to advertised networks have failed, the (6LBR) pledge <span class="bcp14">SHOULD</span> signal the presence of an error condition, through some out-of-band mechanism.<a href="#section-8.1.1-4" class="pilcrow">¶</a></p>
<p id="section-8.1.1-5">BCP 190 <span>[<a href="#RFC8820" class="xref">RFC8820</a>]</span> 
provides guidelines on URI design and ownership.  It recommends that 
whenever a third party wants to mandate a URI to web authority that 
it <span class="bcp14">SHOULD</span> go under "/.well-known" (per <span>[<a href="#RFC8615" class="xref">RFC8615</a>]</span>).
In the case of CoJP, the Uri-Host option is always set to "6tisch.arpa", 
and based upon the recommendations in <span><a href="https://www.rfc-editor.org/rfc/rfc8820#section-1" class="relref">Section 1</a> of [<a href="#RFC8820" class="xref">RFC8820</a>]</span>, 
it is asserted that this document is the owner of the CoJP service.
As such, the concerns of <span>[<a href="#RFC8820" class="xref">RFC8820</a>]</span> do not apply, 
and thus the Uri-Path is only "j".<a href="#section-8.1.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="join_response">
<section id="section-8.1.2">
          <h4 id="name-join-response-message">
<a href="#section-8.1.2" class="section-number selfRef">8.1.2. </a><a href="#name-join-response-message" class="section-name selfRef">Join Response Message</a>
          </h4>
<p id="section-8.1.2-1">The Join Response message that the JRC sends <span class="bcp14">SHALL</span> be mapped to a CoAP response:<a href="#section-8.1.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-8.1.2-2.1">The Response Code is 2.04 (Changed).<a href="#section-8.1.2-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-8.1.2-2.2">The payload is a Configuration CBOR object, as defined in <a href="#configuration_object" class="xref">Section 8.4.2</a>.<a href="#section-8.1.2-2.2" class="pilcrow">¶</a>
</li>
          </ul>
</section>
</div>
</section>
</div>
<div id="update">
<section id="section-8.2">
        <h3 id="name-parameter-update-exchange">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-parameter-update-exchange" class="section-name selfRef">Parameter Update Exchange</a>
        </h3>
<p id="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.
This section specifies a generic mechanism when this parameter update is initiated by the JRC.<a href="#section-8.2-1" class="pilcrow">¶</a></p>
<p id="section-8.2-2">At the time of the join, the (6LBR) pledge acts as a 
CoAP client and requests the network parameters through a representation 
of the "/j" resource exposed by the JRC.
In order for the update of these parameters to happen, the JRC needs to asynchronously contact the joined node.
The use of the CoAP Observe option for this purpose is not feasible due to the change in the IPv6 address when the pledge becomes the joined node and obtains a global address.<a href="#section-8.2-2" class="pilcrow">¶</a></p>
<p id="section-8.2-3">Instead, once the (6LBR) pledge receives and successfully validates the Join Response and so becomes a joined node, it becomes a CoAP server.
The joined node creates a CoAP service at the Uri-Host value of "6tisch.arpa", and the joined node exposes the "/j" resource that is used by the JRC to update 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.<a href="#section-8.2-3" class="pilcrow">¶</a></p>
<div id="parameter_update">
<section id="section-8.2.1">
          <h4 id="name-parameter-update-message">
<a href="#section-8.2.1" class="section-number selfRef">8.2.1. </a><a href="#name-parameter-update-message" class="section-name selfRef">Parameter Update Message</a>
          </h4>
<p id="section-8.2.1-1">The Parameter Update message that the JRC sends to the joined node <span class="bcp14">SHALL</span> be mapped to a CoAP request:<a href="#section-8.2.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-8.2.1-2.1">The request method is POST.<a href="#section-8.2.1-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-8.2.1-2.2">The type is Confirmable (CON).<a href="#section-8.2.1-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-8.2.1-2.3">The Uri-Host option is set to "6tisch.arpa".<a href="#section-8.2.1-2.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-8.2.1-2.4">The Uri-Path option is set to "j".<a href="#section-8.2.1-2.4" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-8.2.1-2.5">The OSCORE option <span class="bcp14">SHALL</span> be set according to <span>[<a href="#RFC8613" class="xref">RFC8613</a>]</span>.
  The OSCORE security context used is the one derived in <a href="#oscore_sec_context" class="xref">Section 7.3</a>.
  When a joined node receives a request with the Sender ID set to 0x4a5243 (ID of the JRC), it is able to correctly retrieve the security context with the JRC.<a href="#section-8.2.1-2.5" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-8.2.1-2.6">The payload is a Configuration CBOR object, as defined in <a href="#configuration_object" class="xref">Section 8.4.2</a>.<a href="#section-8.2.1-2.6" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-8.2.1-3">The JRC has implicit knowledge of the global IPv6 address 
of the joined node, as it knows the pledge identifier that the joined 
node used when it acted as a pledge and the IPv6 network prefix.
The JRC uses this implicitly derived IPv6 address of the joined node to directly address CoAP messages to it.<a href="#section-8.2.1-3" class="pilcrow">¶</a></p>
<p id="section-8.2.1-4">If the JRC does not receive a response to a 
Parameter Update message, it attempts multiple retransmissions as 
configured by the underlying CoAP retransmission mechanism triggered for confirmable messages.
Finally, if the CoAP implementation declares the transmission a failure, 
the JRC may consider this as a hint that the joined node is no longer in the network.
How the JRC decides when to stop attempting to contact a previously 
joined node is out of scope of this specification, but the security 
considerations on the reuse of assigned resources apply, as discussed 
in <a href="#sec_considerations" class="xref">Section 9</a>.<a href="#section-8.2.1-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="error-handling">
<section id="section-8.3">
        <h3 id="name-error-handling">
<a href="#section-8.3" class="section-number selfRef">8.3. </a><a href="#name-error-handling" class="section-name selfRef">Error Handling</a>
        </h3>
<div id="cojp_error_handling">
<section id="section-8.3.1">
          <h4 id="name-cojp-cbor-object-processing">
<a href="#section-8.3.1" class="section-number selfRef">8.3.1. </a><a href="#name-cojp-cbor-object-processing" class="section-name selfRef">CoJP CBOR Object Processing</a>
          </h4>
<p id="section-8.3.1-1">CoJP CBOR objects are transported within both CoAP requests and responses.
This section describes handling the cases in which certain CoJP CBOR object 
parameters are not supported by the implementation or their processing fails.
See <a href="#oscore_error_handling" class="xref">Section 7.3.2</a> for the handling of errors that may be raised by the underlying OSCORE implementation.<a href="#section-8.3.1-1" class="pilcrow">¶</a></p>
<p id="section-8.3.1-2">When such a parameter is detected in a CoAP request (Join Request message, Parameter Update message), a Diagnostic Response message <span class="bcp14">MUST</span> be returned.
A Diagnostic Response message maps to a CoAP response and is specified in <a href="#error_response_message" class="xref">Section 8.3.2</a>.<a href="#section-8.3.1-2" class="pilcrow">¶</a></p>
<p id="section-8.3.1-3">When a parameter that cannot be acted upon is encountered while processing a CoJP object in a CoAP response (Join Response message), a (6LBR) pledge <span class="bcp14">SHOULD</span> reattempt to join.
In this case, the (6LBR) pledge <span class="bcp14">SHOULD</span> include the Unsupported Configuration CBOR object within the Join Request object in the following Join Request message.
The Unsupported Configuration CBOR object is self-contained and enables the (6LBR) pledge to signal any parameters that the implementation of the networking stack may not support.
A (6LBR) pledge <span class="bcp14">MUST NOT</span> attempt more than COJP_MAX_JOIN_ATTEMPTS number of attempts to join if the processing of the Join Response message fails each time.
If the COJP_MAX_JOIN_ATTEMPTS number of attempts is reached without 
success, the (6LBR) pledge <span class="bcp14">SHOULD</span> signal the presence 
of an error condition through some out-of-band mechanism.<a href="#section-8.3.1-3" class="pilcrow">¶</a></p>
<p id="section-8.3.1-4">Note that COJP_MAX_JOIN_ATTEMPTS relates to the 
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.<a href="#section-8.3.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="error_response_message">
<section id="section-8.3.2">
          <h4 id="name-diagnostic-response-message">
<a href="#section-8.3.2" class="section-number selfRef">8.3.2. </a><a href="#name-diagnostic-response-message" class="section-name selfRef">Diagnostic Response Message</a>
          </h4>
<p id="section-8.3.2-1">The Diagnostic Response message is returned for any CoJP request when the processing of the payload failed.
The Diagnostic Response message is protected by OSCORE as any other CoJP  message.<a href="#section-8.3.2-1" class="pilcrow">¶</a></p>
<p id="section-8.3.2-2">The Diagnostic Response message <span class="bcp14">SHALL</span> be mapped to a CoAP response:<a href="#section-8.3.2-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-8.3.2-3.1">The Response Code is 4.00 (Bad Request).<a href="#section-8.3.2-3.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-8.3.2-3.2">The payload is an Unsupported Configuration CBOR object, 
as defined in <a href="#unsupported_configuration_object" class="xref">Section 8.4.5</a>, 
containing more information about the parameter that triggered the sending of this message.<a href="#section-8.3.2-3.2" class="pilcrow">¶</a>
</li>
          </ul>
</section>
</div>
<div id="failure_handling">
<section id="section-8.3.3">
          <h4 id="name-failure-handling">
<a href="#section-8.3.3" class="section-number selfRef">8.3.3. </a><a href="#name-failure-handling" class="section-name selfRef">Failure Handling</a>
          </h4>
<p id="section-8.3.3-1">The parameter update exchange may be triggered at any time 
during the network lifetime, which may span several years.
During this period, a joined node or the JRC may experience unexpected 
events such as reboots or complete failures.<a href="#section-8.3.3-1" class="pilcrow">¶</a></p>
<p id="section-8.3.3-2">This document mandates that the mutable parameters in the 
security context are written to persistent memory (see 
<a href="#persistency" class="xref">Section 7.3.1</a>) by both the JRC and pledges 
(joined nodes).
As the pledge (joined node) is typically a constrained device that handles 
the write operations to persistent memory in a predictable manner, the 
retrieval of mutable security-context parameters is feasible across reboots 
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 Window.
The JRC may be hosted on a generic machine where the write operation to 
persistent memory may lead to unpredictable delays due to caching.
If a reboot event occurs at the JRC before the cached data is written 
to persistent memory, the loss of mutable security-context parameters 
is likely, which consequently poses the risk of AEAD nonce reuse.<a href="#section-8.3.3-2" class="pilcrow">¶</a></p>
<p id="section-8.3.3-3">In the event of a complete device failure, where the mutable 
security-context parameters cannot be retrieved, it is expected that a 
failed joined node will be replaced with a new physical device, using 
a new pledge identifier and a PSK.
When such a failure event occurs at the JRC, it is possible that the 
static information on provisioned pledges, like PSKs and pledge identifiers, 
can be retrieved through available backups.
However, it is likely that the information about joined nodes, their 
assigned short identifiers and mutable security-context parameters, 
is lost.
  If this is the case, the network administrator <span class="bcp14">MUST</span> force  
  all the networks managed by the failed JRC to rejoin through out-of-band
  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.<a href="#section-8.3.3-3" class="pilcrow">¶</a></p>
<p id="section-8.3.3-4">In order to recover from such a failure event, the reinitialized JRC can trigger the renegotiation of the OSCORE security context through the procedure described in  
<span><a href="https://www.rfc-editor.org/rfc/rfc8613#appendix-B.2" class="relref">Appendix B.2</a> of [<a href="#RFC8613" class="xref">RFC8613</a>]</span>.
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 the concatenation of two nonces, one that it received from the JRC and the other that the pledge generates locally.
After verifying the Join Request with the new ID Context and the 
derived OSCORE security context, the JRC should consequently map 
the new ID Context to the previously used pledge identifier.
How the JRC handles this mapping is out of scope of this document.<a href="#section-8.3.3-4" class="pilcrow">¶</a></p>
<p id="section-8.3.3-5">The use of the procedure specified in 
<span><a href="https://www.rfc-editor.org/rfc/rfc8613#appendix-B.2" class="relref">Appendix B.2</a> of [<a href="#RFC8613" class="xref">RFC8613</a>]</span> 
is <span class="bcp14">RECOMMENDED</span> in order to handle the failure events or 
any other event that may lead to the loss of mutable security-context parameters.
The length of nonces exchanged using this procedure <span class="bcp14">MUST</span> be at least 8 bytes.<a href="#section-8.3.3-5" class="pilcrow">¶</a></p>
<p id="section-8.3.3-6">The procedure requires both the pledge and the JRC 
to have good sources of randomness.
While this is typically not an issue at the JRC side, the constrained 
device hosting the pledge may pose limitations in this regard.
If the procedure outlined in 
<span><a href="https://www.rfc-editor.org/rfc/rfc8613#appendix-B.2" class="relref">Appendix B.2</a> of [<a href="#RFC8613" class="xref">RFC8613</a>]</span> 
is not supported by the pledge, the network administrator <span class="bcp14">MUST</span> 
reprovision the concerned devices with freshly generated parameters 
through out-of-band means.<a href="#section-8.3.3-6" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="cbor_objects">
<section id="section-8.4">
        <h3 id="name-cojp-objects">
<a href="#section-8.4" class="section-number selfRef">8.4. </a><a href="#name-cojp-objects" class="section-name selfRef">CoJP Objects</a>
        </h3>
<p id="section-8.4-1">This section specifies the structure of CoJP CBOR objects 
that may be carried as the payload of CoJP messages.
Some of these objects may be received both as part of the 
CoJP join exchange when the device operates as a (CoJP) pledge or 
as part of the parameter update exchange when the device operates 
as a joined (6LBR) node.<a href="#section-8.4-1" class="pilcrow">¶</a></p>
<div id="join_request_object">
<section id="section-8.4.1">
          <h4 id="name-join-request-object">
<a href="#section-8.4.1" class="section-number selfRef">8.4.1. </a><a href="#name-join-request-object" class="section-name selfRef">Join Request Object</a>
          </h4>
<p id="section-8.4.1-1">The Join_Request structure is built on a CBOR map object.<a href="#section-8.4.1-1" class="pilcrow">¶</a></p>
<p id="section-8.4.1-2">The set of parameters that can appear in a Join_Request object is summarized below.
The labels can be found in the "Constrained Join Protocol (CoJP) Parameters" registry, 
<a href="#iana_cojp_registry" class="xref">Section 11.1</a>.<a href="#section-8.4.1-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-8.4.1-3">
            <dt id="section-8.4.1-3.1">role:</dt>
            <dd style="margin-left: 1.5em" id="section-8.4.1-3.2">The identifier of the role that the pledge requests 
to play in the network once it joins, encoded as an unsigned integer.
Possible values are specified in <a href="#table_role_values" class="xref">Table 3</a>.
This parameter <span class="bcp14">MAY</span> be included.
If the parameter is omitted, the default value of 0, 
i.e., the role "6TiSCH Node", <span class="bcp14">MUST</span> be assumed.<a href="#section-8.4.1-3.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.4.1-3.3">network identifier:</dt>
            <dd style="margin-left: 1.5em" id="section-8.4.1-3.4">The identifier of the network, as discussed in 
<a href="#provisioning" class="xref">Section 3</a>, 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 frames.
This parameter <span class="bcp14">MUST</span> be included in a Join_Request object 
regardless of the role parameter value.<a href="#section-8.4.1-3.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.4.1-3.5">unsupported configuration:</dt>
            <dd style="margin-left: 1.5em" id="section-8.4.1-3.6">The identifier of the parameters that are not supported by 
the implementation, encoded as an Unsupported_Configuration object described in 
<a href="#unsupported_configuration_object" class="xref">Section 8.4.5</a>.
This parameter <span class="bcp14">MAY</span> be included.
If a (6LBR) pledge previously attempted to join and received a valid 
Join Response message over OSCORE but failed to act on its payload 
(Configuration object), it <span class="bcp14">SHOULD</span> include this parameter 
to facilitate the recovery and debugging.<a href="#section-8.4.1-3.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-8.4.1-4"><a href="#table_join_req_params" class="xref">Table 2</a> 
summarizes the parameters that may appear in a Join_Request object.<a href="#section-8.4.1-4" class="pilcrow">¶</a></p>
<span id="name-summary-of-join_request-par"></span><div id="table_join_req_params">
<table class="center" id="table-2">
            <caption>
<a href="#table-2" class="selfRef">Table 2</a>:
<a href="#name-summary-of-join_request-par" class="selfRef">Summary of Join_Request parameters.</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Name</th>
                <th class="text-left" rowspan="1" colspan="1">Label</th>
                <th class="text-left" rowspan="1" colspan="1">CBOR Type</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">role</td>
                <td class="text-left" rowspan="1" colspan="1">1</td>
                <td class="text-left" rowspan="1" colspan="1">unsigned integer</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">network identifier</td>
                <td class="text-left" rowspan="1" colspan="1">5</td>
                <td class="text-left" rowspan="1" colspan="1">byte string</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">unsupported configuration</td>
                <td class="text-left" rowspan="1" colspan="1">8</td>
                <td class="text-left" rowspan="1" colspan="1">array</td>
              </tr>
            </tbody>
          </table>
</div>
<p id="section-8.4.1-6">The CDDL fragment that represents the text above for the Join_Request follows:<a href="#section-8.4.1-6" class="pilcrow">¶</a></p>
<div id="section-8.4.1-7">
<pre class="sourcecode">
Join_Request = {
    ? 1 : uint,                       ; role
      5 : bstr,                       ; network identifier
    ? 8 : Unsupported_Configuration   ; unsupported configuration
}
</pre><a href="#section-8.4.1-7" class="pilcrow">¶</a>
</div>
<span id="name-role-values"></span><div id="table_role_values">
<table class="center" id="table-3">
            <caption>
<a href="#table-3" class="selfRef">Table 3</a>:
<a href="#name-role-values" class="selfRef">Role values.</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Name</th>
                <th class="text-left" rowspan="1" colspan="1">Value</th>
                <th class="text-left" rowspan="1" colspan="1">Description</th>
                <th class="text-left" rowspan="1" colspan="1">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">6TiSCH Node</td>
                <td class="text-left" rowspan="1" colspan="1">0</td>
                <td class="text-left" rowspan="1" colspan="1">The pledge requests to play the role of a regular 6TiSCH node, i.e., non-6LBR node.</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9031</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">6LBR</td>
                <td class="text-left" rowspan="1" colspan="1">1</td>
                <td class="text-left" rowspan="1" colspan="1">The pledge requests to play the role of 6LoWPAN Border Router (6LBR).</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9031</td>
              </tr>
            </tbody>
          </table>
</div>
</section>
</div>
<div id="configuration_object">
<section id="section-8.4.2">
          <h4 id="name-configuration-object">
<a href="#section-8.4.2" class="section-number selfRef">8.4.2. </a><a href="#name-configuration-object" class="section-name selfRef">Configuration Object</a>
          </h4>
<p id="section-8.4.2-1">The Configuration structure is built on a CBOR map object.
The set of parameters that can appear in a Configuration object is summarized below.
The labels can be found in "Constrained Join Protocol (CoJP) Parameters" registry, <a href="#iana_cojp_registry" class="xref">Section 11.1</a>.<a href="#section-8.4.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-8.4.2-2">
            <dt id="section-8.4.2-2.1">link-layer key set:</dt>
            <dd style="margin-left: 1.5em" id="section-8.4.2-2.2">An array encompassing a set of cryptographic keys 
and their identifiers that are currently in use in the network 
or that are scheduled to be used in the future.
The encoding of individual keys is described in <a href="#ll_keys" class="xref">Section 8.4.3</a>.
The link-layer key set parameter <span class="bcp14">MAY</span> be included in a Configuration object.
When present, the link-layer key set parameter <span class="bcp14">MUST</span> contain at least one key.
This parameter is also used to implement rekeying in the network.
The installation and use of keys differs for the 6LBR and 
other (regular) nodes, and this is explained in Sections <a href="#keychanging6lbr" class="xref">8.4.3.1</a> 
and <a href="#keychanging6lr" class="xref">8.4.3.2</a>.<a href="#section-8.4.2-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.4.2-2.3">short identifier: </dt>
            <dd style="margin-left: 1.5em" id="section-8.4.2-2.4">A compact identifier assigned to the pledge.
The short identifier structure is described in <a href="#short_identifier" class="xref">Section 8.4.4</a>.
The short identifier parameter <span class="bcp14">MAY</span> be included in a Configuration object.<a href="#section-8.4.2-2.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.4.2-2.5">JRC address:</dt>
            <dd style="margin-left: 1.5em" id="section-8.4.2-2.6">The IPv6 address of the JRC, encoded as a byte string, with the length of 16 bytes.
If the length of the byte string is different from 16, the parameter <span class="bcp14">MUST</span> be discarded.
If the JRC is not co-located with the 6LBR and has a different IPv6 address than the 6LBR, 
this parameter <span class="bcp14">MUST</span> 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 <span class="bcp14">MAY</span> be included.
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 control traffic.
See <a href="#netreq" class="xref">Section 6</a>.<a href="#section-8.4.2-2.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.4.2-2.7">blacklist:</dt>
            <dd style="margin-left: 1.5em" id="section-8.4.2-2.8">An array encompassing a list of pledge identifiers 
that are blacklisted by the JRC, with each pledge identifier encoded as a byte string.
The blacklist parameter <span class="bcp14">MAY</span> be included in a Configuration object.
When present, the array <span class="bcp14">MUST</span> contain zero or more byte strings encoding pledge identifiers.
The joined node <span class="bcp14">MUST</span> silently drop any link-layer frames 
originating from the pledge identifiers enclosed in the blacklist parameter.
When this parameter is received, its value <span class="bcp14">MUST</span> overwrite any previously 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 forwarded into the network.
If the JRC decides to remove a given pledge identifier from a blacklist, 
it omits the pledge identifier in the blacklist parameter value it sends next.
Since the blacklist parameter carries the pledge identifiers, privacy considerations apply.
See <a href="#privacy_considerations" class="xref">Section 10</a>.<a href="#section-8.4.2-2.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.4.2-2.9">join rate:</dt>
            <dd style="margin-left: 1.5em" id="section-8.4.2-2.10">The average data rate (in units of bytes/second) of join traffic 
forwarded into the network that should not be exceeded when a joined node operates 
as a JP, encoded as an unsigned integer.
The join rate parameter <span class="bcp14">MAY</span> be included in a Configuration object.
This parameter allows the JRC to configure different nodes in the network to 
operate as JP and to act in case of an attack by throttling the rate at which JP 
forwards unauthenticated traffic into the network.
When this parameter is present in a Configuration object, the value <span class="bcp14">MUST</span> 
be used to set the PROBING_RATE of CoAP at the joined node for communication with the JRC.
If this parameter is set to zero, a joined node <span class="bcp14">MUST</span> silently drop 
any join traffic coming from unauthenticated pledges.
If this parameter is omitted, the value of positive infinity <span class="bcp14">SHOULD</span> be assumed.
A node operating as a JP <span class="bcp14">MAY</span> use another mechanism that is out of scope 
of this specification to configure the PROBING_RATE of CoAP in the absence of a 
join rate parameter from the Configuration object.<a href="#section-8.4.2-2.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-8.4.2-3"><a href="#table_configuration_params" class="xref">Table 4</a> 
summarizes the parameters that may appear in a Configuration object.<a href="#section-8.4.2-3" class="pilcrow">¶</a></p>
<span id="name-summary-of-configuration-pa"></span><div id="table_configuration_params">
<table class="center" id="table-4">
            <caption>
<a href="#table-4" class="selfRef">Table 4</a>:
<a href="#name-summary-of-configuration-pa" class="selfRef">Summary of Configuration parameters.</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Name</th>
                <th class="text-left" rowspan="1" colspan="1">Label</th>
                <th class="text-left" rowspan="1" colspan="1">CBOR Type</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">link-layer key set</td>
                <td class="text-left" rowspan="1" colspan="1">2</td>
                <td class="text-left" rowspan="1" colspan="1">array</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">short identifier</td>
                <td class="text-left" rowspan="1" colspan="1">3</td>
                <td class="text-left" rowspan="1" colspan="1">array</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">JRC address</td>
                <td class="text-left" rowspan="1" colspan="1">4</td>
                <td class="text-left" rowspan="1" colspan="1">byte string</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">blacklist</td>
                <td class="text-left" rowspan="1" colspan="1">6</td>
                <td class="text-left" rowspan="1" colspan="1">array</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">join rate</td>
                <td class="text-left" rowspan="1" colspan="1">7</td>
                <td class="text-left" rowspan="1" colspan="1">unsigned integer</td>
              </tr>
            </tbody>
          </table>
</div>
<p id="section-8.4.2-5">The CDDL fragment that represents the text above for the Configuration follows.
The structures Link_Layer_Key and Short_Identifier are specified in 
Sections <a href="#ll_keys" class="xref">8.4.3</a> and <a href="#short_identifier" class="xref">8.4.4</a>,
respectively.<a href="#section-8.4.2-5" class="pilcrow">¶</a></p>
<div id="section-8.4.2-6">
<pre class="sourcecode">
Configuration = {
    ? 2 : [ +Link_Layer_Key ],   ; link-layer key set
    ? 3 : Short_Identifier,      ; short identifier
    ? 4 : bstr,                  ; JRC address
    ? 6 : [ *bstr ],             ; blacklist
    ? 7 : uint                   ; join rate
}
</pre><a href="#section-8.4.2-6" class="pilcrow">¶</a>
</div>
<span id="name-cojp-parameters-map-labels"></span><div id="table_cojp_parameters_labels">
<table class="center" id="table-5">
            <caption>
<a href="#table-5" class="selfRef">Table 5</a>:
<a href="#name-cojp-parameters-map-labels" class="selfRef">CoJP parameters map labels.</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Name</th>
                <th class="text-left" rowspan="1" colspan="1">Label</th>
                <th class="text-left" rowspan="1" colspan="1">CBOR type</th>
                <th class="text-left" rowspan="1" colspan="1">Description</th>
                <th class="text-left" rowspan="1" colspan="1">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">role</td>
                <td class="text-left" rowspan="1" colspan="1">1</td>
                <td class="text-left" rowspan="1" colspan="1">unsigned integer</td>
                <td class="text-left" rowspan="1" colspan="1">Identifies the role parameter</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9031</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">link-layer key set</td>
                <td class="text-left" rowspan="1" colspan="1">2</td>
                <td class="text-left" rowspan="1" colspan="1">array</td>
                <td class="text-left" rowspan="1" colspan="1">Identifies the array carrying one or more link-layer cryptographic keys</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9031</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">short identifier</td>
                <td class="text-left" rowspan="1" colspan="1">3</td>
                <td class="text-left" rowspan="1" colspan="1">array</td>
                <td class="text-left" rowspan="1" colspan="1">Identifies the assigned short identifier</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9031</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">JRC address</td>
                <td class="text-left" rowspan="1" colspan="1">4</td>
                <td class="text-left" rowspan="1" colspan="1">byte string</td>
                <td class="text-left" rowspan="1" colspan="1">Identifies the IPv6 address of the JRC</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9031</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">network identifier</td>
                <td class="text-left" rowspan="1" colspan="1">5</td>
                <td class="text-left" rowspan="1" colspan="1">byte string</td>
                <td class="text-left" rowspan="1" colspan="1">Identifies the network identifier parameter</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9031</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">blacklist</td>
                <td class="text-left" rowspan="1" colspan="1">6</td>
                <td class="text-left" rowspan="1" colspan="1">array</td>
                <td class="text-left" rowspan="1" colspan="1">Identifies the blacklist parameter</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9031</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">join rate</td>
                <td class="text-left" rowspan="1" colspan="1">7</td>
                <td class="text-left" rowspan="1" colspan="1">unsigned integer</td>
                <td class="text-left" rowspan="1" colspan="1">Identifier the join rate parameter</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9031</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">unsupported configuration</td>
                <td class="text-left" rowspan="1" colspan="1">8</td>
                <td class="text-left" rowspan="1" colspan="1">array</td>
                <td class="text-left" rowspan="1" colspan="1">Identifies the unsupported configuration parameter</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9031</td>
              </tr>
            </tbody>
          </table>
</div>
</section>
</div>
<div id="ll_keys">
<section id="section-8.4.3">
          <h4 id="name-link-layer-key">
<a href="#section-8.4.3" class="section-number selfRef">8.4.3. </a><a href="#name-link-layer-key" class="section-name selfRef">Link-Layer Key</a>
          </h4>
<p id="section-8.4.3-1">The Link_Layer_Key structure encompasses the parameters needed to configure the link-layer security module:
    the key identifier;
    the value of the cryptographic key;
    the link-layer algorithm identifier and the security level and the frame types 
         with which it should be used for both outgoing and incoming security operations;
    and any additional information that may be needed to configure the key.<a href="#section-8.4.3-1" class="pilcrow">¶</a></p>
<p id="section-8.4.3-2">For encoding compactness, the Link_Layer_Key object is not enclosed in a top-level CBOR object.
Rather, it is transported as a sequence of CBOR elements <span>[<a href="#RFC8742" class="xref">RFC8742</a>]</span>, some being optional.<a href="#section-8.4.3-2" class="pilcrow">¶</a></p>
<p id="section-8.4.3-3">The set of parameters that can appear in a Link_Layer_Key object is summarized below, in order:<a href="#section-8.4.3-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-8.4.3-4">
            <dt id="section-8.4.3-4.1">key_id:</dt>
            <dd style="margin-left: 1.5em" id="section-8.4.3-4.2">The identifier of the key, encoded as a CBOR unsigned integer.
This parameter <span class="bcp14">MUST</span> be included.
If the decoded CBOR unsigned integer value is larger than the maximum link-layer 
key identifier, the key is considered invalid.
If the key is considered invalid, the key <span class="bcp14">MUST</span> be discarded,
and the implementation <span class="bcp14">MUST</span> signal the error as specified in 
<a href="#cojp_error_handling" class="xref">Section 8.3.1</a>.<a href="#section-8.4.3-4.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.4.3-4.3">key_usage:</dt>
            <dd style="margin-left: 1.5em" id="section-8.4.3-4.4">The identifier of the link-layer algorithm, security level, and 
link-layer frame types that can be used with the key, encoded as an integer.
This parameter <span class="bcp14">MAY</span> be included.
Possible values and the corresponding link-layer settings are specified in the
IANA "Constrained Join Protocol (CoJP) Key Usage" registry (<a href="#iana_cojp_key_usage_registry" class="xref">Section 11.2</a>).
If the parameter is omitted, the default value of 0 (6TiSCH-K1K2-ENC-MIC32) 
from <a href="#table_key_usage_values" class="xref">Table 6</a> <span class="bcp14">MUST</span> be assumed.
This default value has been chosen because it results in byte savings 
in the most constrained settings; its selection  does not imply a recommendation for its general usage.<a href="#section-8.4.3-4.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.4.3-4.5">key_value:</dt>
            <dd style="margin-left: 1.5em" id="section-8.4.3-4.6">The value of the cryptographic key, encoded as a byte string.
This parameter <span class="bcp14">MUST</span> be included.
If the length of the byte string is different than the corresponding key length 
for a given algorithm specified by the key_usage parameter, the key 
<span class="bcp14">MUST</span> be discarded, and the implementation <span class="bcp14">MUST</span> 
signal the error as specified in <a href="#cojp_error_handling" class="xref">Section 8.3.1</a>.<a href="#section-8.4.3-4.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.4.3-4.7">key_addinfo:</dt>
            <dd style="margin-left: 1.5em" id="section-8.4.3-4.8">Additional information needed to configure the link-layer key, 
encoded as a byte string.
This parameter <span class="bcp14">MAY</span> be included.
The processing of this parameter is dependent on the link-layer technology 
in use and a particular keying mode.<a href="#section-8.4.3-4.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="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.<a href="#section-8.4.3-5" class="pilcrow">¶</a></p>
<p id="section-8.4.3-6">The CDDL fragment for the Link_Layer_Key that 
represents the text above follows:<a href="#section-8.4.3-6" class="pilcrow">¶</a></p>
<div id="section-8.4.3-7">
<pre class="sourcecode">
Link_Layer_Key = (
      key_id             : uint,
    ? key_usage          : int,
      key_value          : bstr,
    ? key_addinfo        : bstr,
)
</pre><a href="#section-8.4.3-7" class="pilcrow">¶</a>
</div>
<span id="name-key-usage-values"></span><div id="table_key_usage_values">
<table class="center" id="table-6">
            <caption>
<a href="#table-6" class="selfRef">Table 6</a>:
<a href="#name-key-usage-values" class="selfRef">Key Usage values.</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Name</th>
                <th class="text-left" rowspan="1" colspan="1">Value</th>
                <th class="text-left" rowspan="1" colspan="1">Algorithm</th>
                <th class="text-left" rowspan="1" colspan="1">Description</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">6TiSCH-K1K2-ENC-MIC32</td>
                <td class="text-left" rowspan="1" colspan="1">0</td>
                <td class="text-left" rowspan="1" colspan="1">IEEE802154-AES-CCM-128</td>
                <td class="text-left" rowspan="1" colspan="1">Use MIC-32 for EBs, ENC-MIC-32 for DATA and ACKNOWLEDGMENT.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">6TiSCH-K1K2-ENC-MIC64</td>
                <td class="text-left" rowspan="1" colspan="1">1</td>
                <td class="text-left" rowspan="1" colspan="1">IEEE802154-AES-CCM-128</td>
                <td class="text-left" rowspan="1" colspan="1">Use MIC-64 for EBs, ENC-MIC-64 for DATA and ACKNOWLEDGMENT.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">6TiSCH-K1K2-ENC-MIC128</td>
                <td class="text-left" rowspan="1" colspan="1">2</td>
                <td class="text-left" rowspan="1" colspan="1">IEEE802154-AES-CCM-128</td>
                <td class="text-left" rowspan="1" colspan="1">Use MIC-128 for EBs, ENC-MIC-128 for DATA and ACKNOWLEDGMENT.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">6TiSCH-K1K2-MIC32</td>
                <td class="text-left" rowspan="1" colspan="1">3</td>
                <td class="text-left" rowspan="1" colspan="1">IEEE802154-AES-CCM-128</td>
                <td class="text-left" rowspan="1" colspan="1">Use MIC-32 for EBs, DATA and ACKNOWLEDGMENT.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">6TiSCH-K1K2-MIC64</td>
                <td class="text-left" rowspan="1" colspan="1">4</td>
                <td class="text-left" rowspan="1" colspan="1">IEEE802154-AES-CCM-128</td>
                <td class="text-left" rowspan="1" colspan="1">Use MIC-64 for EBs, DATA and ACKNOWLEDGMENT.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">6TiSCH-K1K2-MIC128</td>
                <td class="text-left" rowspan="1" colspan="1">5</td>
                <td class="text-left" rowspan="1" colspan="1">IEEE802154-AES-CCM-128</td>
                <td class="text-left" rowspan="1" colspan="1">Use MIC-128 for EBs, DATA and ACKNOWLEDGMENT.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">6TiSCH-K1-MIC32</td>
                <td class="text-left" rowspan="1" colspan="1">6</td>
                <td class="text-left" rowspan="1" colspan="1">IEEE802154-AES-CCM-128</td>
                <td class="text-left" rowspan="1" colspan="1">Use MIC-32 for EBs.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">6TiSCH-K1-MIC64</td>
                <td class="text-left" rowspan="1" colspan="1">7</td>
                <td class="text-left" rowspan="1" colspan="1">IEEE802154-AES-CCM-128</td>
                <td class="text-left" rowspan="1" colspan="1">Use MIC-64 for EBs.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">6TiSCH-K1-MIC128</td>
                <td class="text-left" rowspan="1" colspan="1">8</td>
                <td class="text-left" rowspan="1" colspan="1">IEEE802154-AES-CCM-128</td>
                <td class="text-left" rowspan="1" colspan="1">Use MIC-128 for EBs.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">6TiSCH-K2-MIC32</td>
                <td class="text-left" rowspan="1" colspan="1">9</td>
                <td class="text-left" rowspan="1" colspan="1">IEEE802154-AES-CCM-128</td>
                <td class="text-left" rowspan="1" colspan="1">Use MIC-32 for DATA and ACKNOWLEDGMENT.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">6TiSCH-K2-MIC64</td>
                <td class="text-left" rowspan="1" colspan="1">10</td>
                <td class="text-left" rowspan="1" colspan="1">IEEE802154-AES-CCM-128</td>
                <td class="text-left" rowspan="1" colspan="1">Use MIC-64 for DATA and ACKNOWLEDGMENT.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">6TiSCH-K2-MIC128</td>
                <td class="text-left" rowspan="1" colspan="1">11</td>
                <td class="text-left" rowspan="1" colspan="1">IEEE802154-AES-CCM-128</td>
                <td class="text-left" rowspan="1" colspan="1">Use MIC-128 for DATA and ACKNOWLEDGMENT.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">6TiSCH-K2-ENC-MIC32</td>
                <td class="text-left" rowspan="1" colspan="1">12</td>
                <td class="text-left" rowspan="1" colspan="1">IEEE802154-AES-CCM-128</td>
                <td class="text-left" rowspan="1" colspan="1">Use ENC-MIC-32 for DATA and ACKNOWLEDGMENT.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">6TiSCH-K2-ENC-MIC64</td>
                <td class="text-left" rowspan="1" colspan="1">13</td>
                <td class="text-left" rowspan="1" colspan="1">IEEE802154-AES-CCM-128</td>
                <td class="text-left" rowspan="1" colspan="1">Use ENC-MIC-64 for DATA and ACKNOWLEDGMENT.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">6TiSCH-K2-ENC-MIC128</td>
                <td class="text-left" rowspan="1" colspan="1">14</td>
                <td class="text-left" rowspan="1" colspan="1">IEEE802154-AES-CCM-128</td>
                <td class="text-left" rowspan="1" colspan="1">Use ENC-MIC-128 for DATA and ACKNOWLEDGMENT.</td>
              </tr>
            </tbody>
          </table>
</div>
<div id="keychanging6lbr">
<section id="section-8.4.3.1">
            <h5 id="name-rekeying-of-6lbrs">
<a href="#section-8.4.3.1" class="section-number selfRef">8.4.3.1. </a><a href="#name-rekeying-of-6lbrs" class="section-name selfRef">Rekeying of 6LBRs</a>
            </h5>
<p id="section-8.4.3.1-1">When the 6LBR receives the Configuration object containing 
a link-layer key set, it <span class="bcp14">MUST</span> 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.<a href="#section-8.4.3.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="keychanging6lr">
<section id="section-8.4.3.2">
            <h5 id="name-rekeying-of-6lns">
<a href="#section-8.4.3.2" class="section-number selfRef">8.4.3.2. </a><a href="#name-rekeying-of-6lns" class="section-name selfRef">Rekeying of 6LNs</a>
            </h5>
<p id="section-8.4.3.2-1">When a regular 6LN receives the Configuration object 
with a link-layer key set, it <span class="bcp14">MUST</span> install the new keys.
The 6LN will use both the old and the new keys to decrypt and authenticate any incoming traffic that arrives based upon the key identifier in the packet.
It <span class="bcp14">MUST</span> continue to use the old keys for all outgoing 
traffic until it has detected that the network has switched to the new key set.<a href="#section-8.4.3.2-1" class="pilcrow">¶</a></p>
<p id="section-8.4.3.2-2">The detection of the network switch is based 
upon the receipt of traffic secured with the new keys.
Upon the reception and the successful security processing of a link-layer 
frame secured with a key from the new key set, a 6LN <span class="bcp14">MUST</span> 
then switch to sending all outgoing traffic using the keys from the 
new set.
The 6LN <span class="bcp14">MUST</span> remove any keys it had installed 
from the previous key set after waiting COJP_REKEYING_GUARD_TIME since  
it started using the new key set.<a href="#section-8.4.3.2-2" class="pilcrow">¶</a></p>
<p id="section-8.4.3.2-3">Sending traffic with the new keys signals to other 
downstream nodes to switch to their new key, causing
a ripple of key updates around each 6LBR.<a href="#section-8.4.3.2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="use-in-ieee-std-802154">
<section id="section-8.4.3.3">
            <h5 id="name-use-in-ieee-std-802154">
<a href="#section-8.4.3.3" class="section-number selfRef">8.4.3.3. </a><a href="#name-use-in-ieee-std-802154" class="section-name selfRef">Use in IEEE Std 802.15.4</a>
            </h5>
<p id="section-8.4.3.3-1">When Link_Layer_Key is used in the context of <span>[<a href="#IEEE802.15.4" class="xref">IEEE802.15.4</a>]</span>, the following considerations apply.<a href="#section-8.4.3.3-1" class="pilcrow">¶</a></p>
<p id="section-8.4.3.3-2">Signaling of different keying modes of <span>[<a href="#IEEE802.15.4" class="xref">IEEE802.15.4</a>]</span> is done based on the parameter values present in a Link_Layer_Key object.
For instance, the value of the key_id parameter in combination with key_addinfo denotes which of the four Key ID modes of <span>[<a href="#IEEE802.15.4" class="xref">IEEE802.15.4</a>]</span> is used and how.<a href="#section-8.4.3.3-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-8.4.3.3-3">
              <dt id="section-8.4.3.3-3.1">Key ID Mode 0x00 (Implicit, pairwise):</dt>
              <dd style="margin-left: 1.5em" id="section-8.4.3.3-3.2">The key_id parameter <span class="bcp14">MUST</span> be set to 0.
The key_addinfo parameter <span class="bcp14">MUST</span> be present.
The key_addinfo parameter <span class="bcp14">MUST</span> be set to the link-layer 
address(es) of a single peer with whom the key should be used.
Depending on the configuration of the network, key_addinfo may carry 
the peer's long link-layer address (i.e., pledge identifier), 
short link-layer address, or their concatenation with the long address being encoded first.
Which address type(s) is carried is determined from the length of the byte string.<a href="#section-8.4.3.3-3.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-8.4.3.3-3.3">Key ID Mode 0x01 (Key Index):</dt>
              <dd style="margin-left: 1.5em" id="section-8.4.3.3-3.4">The key_id parameter <span class="bcp14">MUST</span> be set to a value different from 0.
The key_addinfo parameter <span class="bcp14">MUST NOT</span> be present.<a href="#section-8.4.3.3-3.4" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-8.4.3.3-3.5">Key ID Mode 0x02 (4-byte Explicit Key Source):</dt>
              <dd style="margin-left: 1.5em" id="section-8.4.3.3-3.6">The key_id parameter <span class="bcp14">MUST</span> be set to a value different from 0.
The key_addinfo parameter <span class="bcp14">MUST</span> be present.
The key_addinfo parameter <span class="bcp14">MUST</span> be set to a byte string, exactly 4 bytes long.
The key_addinfo parameter carries the Key Source parameter used to configure 
<span>[<a href="#IEEE802.15.4" class="xref">IEEE802.15.4</a>]</span>.<a href="#section-8.4.3.3-3.6" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-8.4.3.3-3.7">Key ID Mode 0x03 (8-byte Explicit Key Source):</dt>
              <dd style="margin-left: 1.5em" id="section-8.4.3.3-3.8">The key_id parameter <span class="bcp14">MUST</span> be set to a value different from 0.
The key_addinfo parameter <span class="bcp14">MUST</span> be present.
The key_addinfo parameter <span class="bcp14">MUST</span> be set to a byte string, exactly 8 bytes long.
The key_addinfo parameter carries the Key Source parameter used to configure 
<span>[<a href="#IEEE802.15.4" class="xref">IEEE802.15.4</a>]</span>.<a href="#section-8.4.3.3-3.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
<p id="section-8.4.3.3-4">In all cases, the key_usage parameter determines how a 
particular key should be used with respect to incoming and outgoing security policies.<a href="#section-8.4.3.3-4" class="pilcrow">¶</a></p>
<p id="section-8.4.3.3-5">For Key ID Modes 0x01 through 0x03, the key_id parameter 
sets the "secKeyIndex" parameter of <span>[<a href="#IEEE802.15.4" class="xref">IEEE802.15.4</a>]</span> 
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 <span>[<a href="#IEEE802.15.4" class="xref">IEEE802.15.4</a>]</span> and is therefore considered invalid.<a href="#section-8.4.3.3-5" class="pilcrow">¶</a></p>
<p id="section-8.4.3.3-6">Key ID Mode 0x00 (Implicit, pairwise) 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.<a href="#section-8.4.3.3-6" class="pilcrow">¶</a></p>
<p id="section-8.4.3.3-7">Implementations <span class="bcp14">MUST</span> use different 
link-layer keys when using different authentication tag (MIC) lengths, 
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.
See Annex B.4.3 of <span>[<a href="#IEEE802.15.4" class="xref">IEEE802.15.4</a>]</span> for more information.<a href="#section-8.4.3.3-7" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="short_identifier">
<section id="section-8.4.4">
          <h4 id="name-short-identifier">
<a href="#section-8.4.4" class="section-number selfRef">8.4.4. </a><a href="#name-short-identifier" class="section-name selfRef">Short Identifier</a>
          </h4>
<p id="section-8.4.4-1">The Short_Identifier object represents an identifier assigned to the pledge.
It is encoded as a CBOR array object and contains, in order:<a href="#section-8.4.4-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-8.4.4-2">
            <dt id="section-8.4.4-2.1">identifier:</dt>
            <dd style="margin-left: 1.5em" id="section-8.4.4-2.2">The short identifier assigned to the pledge, encoded as a byte string.
This parameter <span class="bcp14">MUST</span> be included.
The identifier <span class="bcp14">MUST</span> be unique in the set of all identifiers assigned 
in a network that is managed by a JRC.
If the identifier is invalid, the decoder <span class="bcp14">MUST</span> silently 
ignore the Short_Identifier object.<a href="#section-8.4.4-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.4.4-2.3">lease_time:</dt>
            <dd style="margin-left: 1.5em" id="section-8.4.4-2.4">The validity of the identifier in hours after the reception 
of the CBOR object, encoded as a CBOR unsigned integer.
This parameter <span class="bcp14">MAY</span> be included.
The node <span class="bcp14">MUST</span> 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 interval.
The JRC updates the lease by executing the parameter update exchange with the node 
and including the Short_Identifier in the Configuration object, as described in 
<a href="#update" class="xref">Section 8.2</a>.
If the lease expires, then the node <span class="bcp14">SHOULD</span> initiate a new join exchange, 
as described in <a href="#join" class="xref">Section 8.1</a>.
If this parameter is omitted, then the value of positive infinity <span class="bcp14">MUST</span> 
be assumed, meaning that the identifier is valid for as long as the node participates 
in the network.<a href="#section-8.4.4-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-8.4.4-3">The CDDL fragment for the Short_Identifier that 
represents the text above follows:<a href="#section-8.4.4-3" class="pilcrow">¶</a></p>
<div id="section-8.4.4-4">
<pre class="sourcecode">
Short_Identifier = [
      identifier        : bstr,
    ? lease_time        : uint
]
</pre><a href="#section-8.4.4-4" class="pilcrow">¶</a>
</div>
<div id="use-in-ieee-std-802154-1">
<section id="section-8.4.4.1">
            <h5 id="name-use-in-ieee-std-802154-2">
<a href="#section-8.4.4.1" class="section-number selfRef">8.4.4.1. </a><a href="#name-use-in-ieee-std-802154-2" class="section-name selfRef">Use in IEEE Std 802.15.4</a>
            </h5>
<p id="section-8.4.4.1-1">When the Short_Identifier is used in the context of <span>[<a href="#IEEE802.15.4" class="xref">IEEE802.15.4</a>]</span>, the following considerations apply.<a href="#section-8.4.4.1-1" class="pilcrow">¶</a></p>
<p id="section-8.4.4.1-2">The identifier <span class="bcp14">MUST</span> be used to set the 
short address of the IEEE Std 802.15.4 module.
When operating in TSCH mode, the identifier <span class="bcp14">MUST</span> be unique in the set of all identifiers assigned in multiple networks that share link-layer key(s).
If the length of the byte string corresponding to the identifier 
parameter is different from 2, the identifier is considered invalid.
The values 0xfffe and 0xffff are reserved by <span>[<a href="#IEEE802.15.4" class="xref">IEEE802.15.4</a>]</span>, 
and their use is considered invalid.<a href="#section-8.4.4.1-2" class="pilcrow">¶</a></p>
<p id="section-8.4.4.1-3">The security properties offered by the 
<span>[<a href="#IEEE802.15.4" class="xref">IEEE802.15.4</a>]</span> link-layer in TSCH mode are 
conditioned on the uniqueness requirement of the short identifier (i.e., short address).
The short address is one of the inputs in the construction of the nonce, which is 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.
For this reason, practices where the pledge generates the short identifier locally are not safe and are likely to result in the loss of link-layer security properties.<a href="#section-8.4.4.1-3" class="pilcrow">¶</a></p>
<p id="section-8.4.4.1-4">The JRC <span class="bcp14">MUST</span> ensure that at any 
given time there are never two of the same short identifiers being 
used under the same link-layer key.
If the lease_time parameter of a given Short_Identifier object is 
set to positive infinity, care needs to be taken that the corresponding 
identifier is not assigned to another node until the JRC is certain 
that it is no longer in use, potentially through out-of-band signaling.
If the lease_time parameter expires for any reason, the JRC should take 
into consideration potential ongoing transmissions by the joined node, 
which may be hanging in the queues, before assigning the same identifier 
to another node.<a href="#section-8.4.4.1-4" class="pilcrow">¶</a></p>
<p id="section-8.4.4.1-5">Care needs to be taken on how the pledge (joined node) configures the expiration of the lease.
Since units of the lease_time parameter are in hours after the reception of the CBOR object, the pledge needs to convert the received time to the corresponding Absolute Slot Number in the network.
The joined node (pledge) <span class="bcp14">MUST</span> only use the 
Absolute Slot Number as the appropriate reference of time to determine whether the assigned short identifier is still valid.<a href="#section-8.4.4.1-5" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="unsupported_configuration_object">
<section id="section-8.4.5">
          <h4 id="name-unsupported-configuration-o">
<a href="#section-8.4.5" class="section-number selfRef">8.4.5. </a><a href="#name-unsupported-configuration-o" class="section-name selfRef">Unsupported Configuration Object</a>
          </h4>
<p id="section-8.4.5-1">The Unsupported_Configuration object is encoded as a CBOR array, containing at least one Unsupported_Parameter object.
Each Unsupported_Parameter object is a sequence of CBOR elements without an enclosing top-level CBOR object for compactness.
The set of parameters that appear in an Unsupported_Parameter object is summarized below, in order:<a href="#section-8.4.5-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-8.4.5-2">
            <dt id="section-8.4.5-2.1">code:</dt>
            <dd style="margin-left: 1.5em" id="section-8.4.5-2.2">Indicates the capability of acting on the 
parameter signaled by parameter_label, encoded as an integer.
This parameter <span class="bcp14">MUST</span> be included.
Possible values of this parameter are specified in the 
IANA "Constrained Join Protocol (CoJP) Unsupported Configuration Codes" registry 
(<a href="#iana_cojp_unsupported_code_registry" class="xref">Section 11.3</a>).<a href="#section-8.4.5-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.4.5-2.3">parameter_label:</dt>
            <dd style="margin-left: 1.5em" id="section-8.4.5-2.4">Indicates the parameter.  This parameter 
<span class="bcp14">MUST</span> be included.  Possible values of this 
parameter are specified in the label column of the 
IANA "Constrained Join Protocol (CoJP) Parameters" registry" (<a href="#iana_cojp_registry" class="xref">Section 11.1</a>).<a href="#section-8.4.5-2.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.4.5-2.5">parameter_addinfo:</dt>
            <dd style="margin-left: 1.5em" id="section-8.4.5-2.6">Additional information about the parameter 
that cannot be acted upon.
This parameter <span class="bcp14">MUST</span> be included.
If the code is set to "Unsupported", parameter_addinfo gives 
additional information to the JRC.
If the parameter indicated by parameter_label cannot be acted upon 
regardless of its value, parameter_addinfo <span class="bcp14">MUST</span> 
be set to null, signaling to the JRC that it <span class="bcp14">SHOULD NOT</span> 
attempt to configure the parameter again.
If the pledge can act on the parameter, but cannot configure the 
setting indicated by the parameter value, the pledge can hint this 
to the JRC.
In this case, parameter_addinfo <span class="bcp14">MUST</span> be set to the 
value of the parameter that cannot be acted upon following the 
normative parameter structure specified in this document.
For example, it is possible to include the link-layer key set 
object, signaling that either a subset or the entire key set that 
 was received cannot be acted upon. 
In that case, the value of parameter_addinfo follows the 
link-layer key set structure defined in 
<a href="#configuration_object" class="xref">Section 8.4.2</a>.
If the code is set to "Malformed", parameter_addinfo <span class="bcp14">MUST</span> 
be set to null, signaling to the JRC that it <span class="bcp14">SHOULD NOT</span> 
attempt to configure the parameter again.<a href="#section-8.4.5-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-8.4.5-3">The CDDL fragment 
for the Unsupported_Configuration and Unsupported_Parameter objects 
that represents the text above 
follows:<a href="#section-8.4.5-3" class="pilcrow">¶</a></p>
<div id="section-8.4.5-4">
<pre class="sourcecode">
Unsupported_Configuration = [
       + parameter           : Unsupported_Parameter
]

Unsupported_Parameter = (
         code                : int,
         parameter_label     : int,
         parameter_addinfo   : nil / any
)
</pre><a href="#section-8.4.5-4" class="pilcrow">¶</a>
</div>
<span id="name-unsupported-configuration-c"></span><div id="table_unsupported_code_values">
<table class="center" id="table-7">
            <caption>
<a href="#table-7" class="selfRef">Table 7</a>:
<a href="#name-unsupported-configuration-c" class="selfRef">Unsupported Configuration code values.</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Name</th>
                <th class="text-left" rowspan="1" colspan="1">Value</th>
                <th class="text-left" rowspan="1" colspan="1">Description</th>
                <th class="text-left" rowspan="1" colspan="1">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">Unsupported</td>
                <td class="text-left" rowspan="1" colspan="1">0</td>
                <td class="text-left" rowspan="1" colspan="1">The indicated setting is not supported by the networking stack implementation.</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9031</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">Malformed</td>
                <td class="text-left" rowspan="1" colspan="1">1</td>
                <td class="text-left" rowspan="1" colspan="1">The indicated parameter value is malformed.</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9031</td>
              </tr>
            </tbody>
          </table>
</div>
</section>
</div>
</section>
</div>
<div id="recommended-settings">
<section id="section-8.5">
        <h3 id="name-recommended-settings-2">
<a href="#section-8.5" class="section-number selfRef">8.5. </a><a href="#name-recommended-settings-2" class="section-name selfRef">Recommended Settings</a>
        </h3>
<p id="section-8.5-1">This section gives <span class="bcp14">RECOMMENDED</span> values of CoJP settings.<a href="#section-8.5-1" class="pilcrow">¶</a></p>
<span id="name-recommended-cojp-settings"></span><table class="center" id="table-8">
          <caption>
<a href="#table-8" class="selfRef">Table 8</a>:
<a href="#name-recommended-cojp-settings" class="selfRef">Recommended CoJP settings.</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Name</th>
              <th class="text-left" rowspan="1" colspan="1">Default Value</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">COJP_MAX_JOIN_ATTEMPTS</td>
              <td class="text-left" rowspan="1" colspan="1">4</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">COJP_REKEYING_GUARD_TIME</td>
              <td class="text-left" rowspan="1" colspan="1">12 seconds</td>
            </tr>
          </tbody>
        </table>
<p id="section-8.5-3">The COJP_REKEYING_GUARD_TIME value <span class="bcp14">SHOULD</span> take into account possible retransmissions at the link layer due to imperfect wireless links.<a href="#section-8.5-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sec_considerations">
<section id="section-9">
      <h2 id="name-security-considerations">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-9-1">Since this document uses the pledge identifier 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 managed 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 <a href="#privacy_considerations" class="xref">Section 10</a>.<a href="#section-9-1" class="pilcrow">¶</a></p>
<p id="section-9-2">This document further mandates that the (6LBR) pledge and the JRC are provisioned with unique PSKs.
While the process of provisioning PSKs to all pledges can result in a substantial 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 derivation.
This derivation process results in OSCORE keys that are important for mutual authentication of the (6LBR) pledge and the JRC.
The resulting security context shared between the pledge (joined node) 
and the JRC is used for the purpose of joining and is long-lived in 
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 possible.<a href="#section-9-2" class="pilcrow">¶</a></p>
<p id="section-9-3">Note that while OSCORE provides replay protection, it does not 
provide an indication of freshness in the presence of an attacker 
that can drop and/or reorder traffic.
Since the Join Request contains no randomness, and the 
sequence number is predictable, the JRC could in principle anticipate 
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 
the request is received.
This could be relevant in the case when the JRC was temporarily compromised 
and control was subsequently regained by the legitimate owner.<a href="#section-9-3" class="pilcrow">¶</a></p>
<p id="section-9-4">It is of utmost importance to avoid unsafe practices when generating and provisioning PSKs.
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 compromise of the entire batch, with the attacker having the ability to impersonate a legitimate device and join the network, 
generate bogus data, and disturb the network operation.
Additionally, some vendors use methods such as scrambling or hashing  
device serial numbers or their EUI-64 identifiers to generate "unique" PSKs.
Without any secret information involved, the effort that the attacker needs to invest into breaking these unsafe derivation methods is quite low, resulting in the 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 is <span class="bcp14">RECOMMENDED</span>, see <span>[<a href="#NIST800-90A" class="xref">NIST800-90A</a>]</span> for different mechanisms using deterministic methods.<a href="#section-9-4" class="pilcrow">¶</a></p>
<p id="section-9-5">The JP forwards the unauthenticated join traffic into the network.
A data cap on the JP prevents it from forwarding more traffic than the network can 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.
The data cap can be configured by the JRC by including a join rate parameter 
in the Join Response, and it is implemented through the CoAP's PROBING_RATE setting.
The use of a data cap at a JP forces attackers to use more than one JP if they wish to overwhelm the network.
Marking the join traffic packets with a nonzero DSCP allows the 
network to carry the traffic if it has capacity, but it encourages 
the network to drop the extra traffic rather than add bandwidth due to that traffic.<a href="#section-9-5" class="pilcrow">¶</a></p>
<p id="section-9-6">The shared nature of the "minimal" cell used for the join traffic makes the network prone to a DoS attack by congesting the JP with bogus traffic.
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 pledge the possibility to use the best available link for joining.
How a network node decides to become a JP is out of scope of this specification.<a href="#section-9-6" class="pilcrow">¶</a></p>
<p id="section-9-7">At the beginning of the join process, the pledge has no 
means of verifying the content in the EB and has to accept it at "face value".
If the pledge tries to join an attacker's network, 
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 EBs and try to join using the next seemingly valid EB.
This blacklist alleviates the issue but is effectively limited by 
the node's available memory.
Note that this temporary blacklist is different from the one 
communicated as part of the CoJP Configuration object as it helps 
the pledge fight a DoS attack.
The bogus beacons prolong the join time of the pledge and so does the 
time spent in "minimal" duty cycle mode <span>[<a href="#RFC8180" class="xref">RFC8180</a>]</span>.
The blacklist communicated as part of the CoJP Configuration object 
helps the JP fight a DoS attack by a malicious pledge.<a href="#section-9-7" class="pilcrow">¶</a></p>
<p id="section-9-8">During the network lifetime, the JRC may at any time initiate a parameter update exchange with a joined node.
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 Sender ID of the JRC.
A passive attacker may use the OSCORE Sender ID to identify the 
Parameter Update traffic if the link-layer protection does not provide confidentiality.
A countermeasure against such a traffic-analysis attack is to 
use encryption at the link layer.
Note that the join traffic does not undergo link-layer protection 
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.<a href="#section-9-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="privacy_considerations">
<section id="section-10">
      <h2 id="name-privacy-considerations">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-privacy-considerations" class="section-name selfRef">Privacy Considerations</a>
      </h2>
<p id="section-10-1">The join solution specified in this document relies on the uniqueness of the pledge identifier in the set of all pledge identifiers managed by a JRC.
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 management but comes with certain privacy risks.
The implications are thoroughly discussed in <span>[<a href="#RFC7721" class="xref">RFC7721</a>]</span> 
and comprise correlation of activities over time, location tracking, address scanning, 
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.
However, after the join process completes, the use of EUI-64 
in the form of a Layer 2 or Layer 3 address extends the 
aforementioned privacy threats to the long term.<a href="#section-10-1" class="pilcrow">¶</a></p>
<p id="section-10-2">As an optional mitigation technique, the Join Response message 
may contain a short address that is assigned by the JRC to the (6LBR) pledge.
The assigned short address <span class="bcp14">SHOULD</span> be uncorrelated with the long-term pledge identifier.
The short address is encrypted in the response.
Once the join process completes, the new node may use the short addresses for all further Layer 2 (and Layer 3) operations.
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 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 based on timing information with a non-negligible probability.
This probability decreases with an increasing number of pledges joining concurrently.<a href="#section-10-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="iana-considerations">
<section id="section-11">
      <h2 id="name-iana-considerations">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-11-1">This document allocates a well-known name under 
the .arpa name space according to the rules given in <span>[<a href="#RFC3172" class="xref">RFC3172</a>]</span> and <span>[<a href="#RFC6761" class="xref">RFC6761</a>]</span>.
The name "6tisch.arpa" is requested.
No subdomains are expected, and addition of any such subdomains
requires the publication of an IETF Standards Track RFC.
No A, AAAA, or PTR record is requested.<a href="#section-11-1" class="pilcrow">¶</a></p>
<div id="iana_cojp_registry">
<section id="section-11.1">
        <h3 id="name-constrained-join-protocol-co">
<a href="#section-11.1" class="section-number selfRef">11.1. </a><a href="#name-constrained-join-protocol-co" class="section-name selfRef">Constrained Join Protocol (CoJP) Parameters</a>
        </h3>
<p id="section-11.1-1">This section defines a subregistry within the 
"IPv6 Over the TSCH Mode of IEEE 802.15.4 (6TiSCH)" registry with the 
name "Constrained Join Protocol (CoJP) Parameters".<a href="#section-11.1-1" class="pilcrow">¶</a></p>
<p id="section-11.1-2">The columns of the registry are:<a href="#section-11.1-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-11.1-3">
          <dt id="section-11.1-3.1">Name:</dt>
          <dd style="margin-left: 1.5em" id="section-11.1-3.2">This is a descriptive name that enables an easier reference to the item.
It is not used in the encoding. The name <span class="bcp14">MUST</span> be unique.<a href="#section-11.1-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-11.1-3.3">Label:</dt>
          <dd style="margin-left: 1.5em" id="section-11.1-3.4">The value to be used to identify this parameter.
The label is an integer. The label <span class="bcp14">MUST</span> be unique.<a href="#section-11.1-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-11.1-3.5">CBOR Type:</dt>
          <dd style="margin-left: 1.5em" id="section-11.1-3.6">This field contains the CBOR type for the field.<a href="#section-11.1-3.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-11.1-3.7">Description:</dt>
          <dd style="margin-left: 1.5em" id="section-11.1-3.8">This field contains a brief description for the field. The description <span class="bcp14">MUST</span> be unique.<a href="#section-11.1-3.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-11.1-3.9">Reference:</dt>
          <dd style="margin-left: 1.5em" id="section-11.1-3.10">This field contains a pointer to the public specification for the field, if one exists.<a href="#section-11.1-3.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-11.1-4">This registry is populated with the values 
in <a href="#table_cojp_parameters_labels" class="xref">Table 5</a>.<a href="#section-11.1-4" class="pilcrow">¶</a></p>
<p id="section-11.1-5">The amending formula for this subregistry is: 
Different ranges of values use different registration policies <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.
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 Specification Required.
Integer values greater than 65535 are designated as Expert Review.
Integer values less than -65536 are marked as Private Use.<a href="#section-11.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="iana_cojp_key_usage_registry">
<section id="section-11.2">
        <h3 id="name-constrained-join-protocol-coj">
<a href="#section-11.2" class="section-number selfRef">11.2. </a><a href="#name-constrained-join-protocol-coj" class="section-name selfRef">Constrained Join Protocol (CoJP) Key Usage</a>
        </h3>
<p id="section-11.2-1">This section defines a subregistry within the 
"IPv6 Over the TSCH Mode of IEEE 802.15.4 (6TiSCH)" registry with the 
name "Constrained Join Protocol (CoJP) Key Usage".<a href="#section-11.2-1" class="pilcrow">¶</a></p>
<p id="section-11.2-2">The columns of this registry are:<a href="#section-11.2-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-11.2-3">
          <dt id="section-11.2-3.1">Name:</dt>
          <dd style="margin-left: 1.5em" id="section-11.2-3.2">This is a descriptive name that enables easier reference to the item.
It is not used in the encoding. The name <span class="bcp14">MUST</span> be unique.<a href="#section-11.2-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-11.2-3.3">Value:</dt>
          <dd style="margin-left: 1.5em" id="section-11.2-3.4">This is the value used to identify the key usage setting.
These values <span class="bcp14">MUST</span> be unique.  The value is an integer.<a href="#section-11.2-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-11.2-3.5">Algorithm:</dt>
          <dd style="margin-left: 1.5em" id="section-11.2-3.6">This is a descriptive name of the link-layer algorithm in use and uniquely determines the key length.
The name is not used in the encoding. The algorithm <span class="bcp14">MUST</span> be unique.<a href="#section-11.2-3.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-11.2-3.7">Description:</dt>
          <dd style="margin-left: 1.5em" id="section-11.2-3.8">This field contains a description of the key usage setting.
The field should describe in enough detail how the key is to be used with different frame types, specific for the link-layer technology in question. The description <span class="bcp14">MUST</span> be unique.<a href="#section-11.2-3.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-11.2-3.9">Reference:</dt>
          <dd style="margin-left: 1.5em" id="section-11.2-3.10">This contains a pointer to the public specification for the field, if one exists.<a href="#section-11.2-3.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-11.2-4">This registry is populated with the values in <a href="#table_key_usage_values" class="xref">Table 6</a>.<a href="#section-11.2-4" class="pilcrow">¶</a></p>
<p id="section-11.2-5">The amending formula for this subregistry is: 
Different ranges of values use different registration policies <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.
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 Specification Required.
Integer values greater than 65535 are designated as Expert Review.
Integer values less than -65536 are marked as Private Use.<a href="#section-11.2-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="iana_cojp_unsupported_code_registry">
<section id="section-11.3">
        <h3 id="name-constrained-join-protocol-cojp">
<a href="#section-11.3" class="section-number selfRef">11.3. </a><a href="#name-constrained-join-protocol-cojp" class="section-name selfRef">Constrained Join Protocol (CoJP) Unsupported Configuration Codes</a>
        </h3>
<p id="section-11.3-1">This section defines a subregistry within the 
"IPv6 Over the TSCH Mode of IEEE 802.15.4 (6TiSCH)" registry with the 
name "Constrained Join Protocol (CoJP) Unsupported Configuration Codes".<a href="#section-11.3-1" class="pilcrow">¶</a></p>
<p id="section-11.3-2">The columns of this registry are:<a href="#section-11.3-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-11.3-3">
          <dt id="section-11.3-3.1">Name:</dt>
          <dd style="margin-left: 1.5em" id="section-11.3-3.2">This is a descriptive name that enables easier reference to the item.
It is not used in the encoding.
The name <span class="bcp14">MUST</span> be unique.<a href="#section-11.3-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-11.3-3.3">Value:</dt>
          <dd style="margin-left: 1.5em" id="section-11.3-3.4">This is the value used to identify the diagnostic code.
These values <span class="bcp14">MUST</span> be unique.
The value is an integer.<a href="#section-11.3-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-11.3-3.5">Description:</dt>
          <dd style="margin-left: 1.5em" id="section-11.3-3.6">This is a descriptive human-readable name.
The description <span class="bcp14">MUST</span> be unique.
It is not used in the encoding.<a href="#section-11.3-3.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-11.3-3.7">Reference:</dt>
          <dd style="margin-left: 1.5em" id="section-11.3-3.8">This contains a pointer to the public specification for the field, if one exists.<a href="#section-11.3-3.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-11.3-4">This registry is to be populated with the values in <a href="#table_unsupported_code_values" class="xref">Table 7</a>.<a href="#section-11.3-4" class="pilcrow">¶</a></p>
<p id="section-11.3-5">The amending formula for this subregistry is: 
Different ranges of values use different registration policies <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.
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 Specification Required.
Integer values greater than 65535 are designated as Expert Review.
Integer values less than -65536 are marked as Private Use.<a href="#section-11.3-5" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<section id="section-12">
      <h2 id="name-references">
<a href="#section-12" class="section-number selfRef">12. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-12.1">
        <h3 id="name-normative-references">
<a href="#section-12.1" class="section-number selfRef">12.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="IEEE802.15.4">[IEEE802.15.4]</dt>
        <dd>
<span class="refAuthor">IEEE</span>, <span class="refTitle">"IEEE Standard for Low-Rate Wireless Networks"</span>, <span class="seriesInfo">IEEE Standard 802.15.4-2015</span>, <span class="seriesInfo">DOI 10.1109/IEEESTD.2016.7460875</span>, <time datetime="2016-04" class="refDate">April 2016</time>, <span>&lt;<a href="https://ieeexplore.ieee.org/document/7460875">https://ieeexplore.ieee.org/document/7460875</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2597">[RFC2597]</dt>
        <dd>
<span class="refAuthor">Heinanen, J.</span>, <span class="refAuthor">Baker, F.</span>, <span class="refAuthor">Weiss, W.</span>, and <span class="refAuthor">J. Wroclawski</span>, <span class="refTitle">"Assured Forwarding PHB Group"</span>, <span class="seriesInfo">RFC 2597</span>, <span class="seriesInfo">DOI 10.17487/RFC2597</span>, <time datetime="1999-06" class="refDate">June 1999</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2597">https://www.rfc-editor.org/info/rfc2597</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3172">[RFC3172]</dt>
        <dd>
<span class="refAuthor">Huston, G., Ed.</span>, <span class="refTitle">"Management Guidelines &amp; Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")"</span>, <span class="seriesInfo">BCP 52</span>, <span class="seriesInfo">RFC 3172</span>, <span class="seriesInfo">DOI 10.17487/RFC3172</span>, <time datetime="2001-09" class="refDate">September 2001</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3172">https://www.rfc-editor.org/info/rfc3172</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5869">[RFC5869]</dt>
        <dd>
<span class="refAuthor">Krawczyk, H.</span> and <span class="refAuthor">P. Eronen</span>, <span class="refTitle">"HMAC-based Extract-and-Expand Key Derivation Function (HKDF)"</span>, <span class="seriesInfo">RFC 5869</span>, <span class="seriesInfo">DOI 10.17487/RFC5869</span>, <time datetime="2010-05" class="refDate">May 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5869">https://www.rfc-editor.org/info/rfc5869</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6761">[RFC6761]</dt>
        <dd>
<span class="refAuthor">Cheshire, S.</span> and <span class="refAuthor">M. Krochmal</span>, <span class="refTitle">"Special-Use Domain Names"</span>, <span class="seriesInfo">RFC 6761</span>, <span class="seriesInfo">DOI 10.17487/RFC6761</span>, <time datetime="2013-02" class="refDate">February 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6761">https://www.rfc-editor.org/info/rfc6761</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7252">[RFC7252]</dt>
        <dd>
<span class="refAuthor">Shelby, Z.</span>, <span class="refAuthor">Hartke, K.</span>, and <span class="refAuthor">C. Bormann</span>, <span class="refTitle">"The Constrained Application Protocol (CoAP)"</span>, <span class="seriesInfo">RFC 7252</span>, <span class="seriesInfo">DOI 10.17487/RFC7252</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7252">https://www.rfc-editor.org/info/rfc7252</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7554">[RFC7554]</dt>
        <dd>
<span class="refAuthor">Watteyne, T., Ed.</span>, <span class="refAuthor">Palattella, M.</span>, and <span class="refAuthor">L. Grieco</span>, <span class="refTitle">"Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement"</span>, <span class="seriesInfo">RFC 7554</span>, <span class="seriesInfo">DOI 10.17487/RFC7554</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7554">https://www.rfc-editor.org/info/rfc7554</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8085">[RFC8085]</dt>
        <dd>
<span class="refAuthor">Eggert, L.</span>, <span class="refAuthor">Fairhurst, G.</span>, and <span class="refAuthor">G. Shepherd</span>, <span class="refTitle">"UDP Usage Guidelines"</span>, <span class="seriesInfo">BCP 145</span>, <span class="seriesInfo">RFC 8085</span>, <span class="seriesInfo">DOI 10.17487/RFC8085</span>, <time datetime="2017-03" class="refDate">March 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8085">https://www.rfc-editor.org/info/rfc8085</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8126">[RFC8126]</dt>
        <dd>
<span class="refAuthor">Cotton, M.</span>, <span class="refAuthor">Leiba, B.</span>, and <span class="refAuthor">T. Narten</span>, <span class="refTitle">"Guidelines for Writing an IANA Considerations Section in RFCs"</span>, <span class="seriesInfo">BCP 26</span>, <span class="seriesInfo">RFC 8126</span>, <span class="seriesInfo">DOI 10.17487/RFC8126</span>, <time datetime="2017-06" class="refDate">June 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8152">[RFC8152]</dt>
        <dd>
<span class="refAuthor">Schaad, J.</span>, <span class="refTitle">"CBOR Object Signing and Encryption (COSE)"</span>, <span class="seriesInfo">RFC 8152</span>, <span class="seriesInfo">DOI 10.17487/RFC8152</span>, <time datetime="2017-07" class="refDate">July 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8152">https://www.rfc-editor.org/info/rfc8152</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8180">[RFC8180]</dt>
        <dd>
<span class="refAuthor">Vilajosana, X., Ed.</span>, <span class="refAuthor">Pister, K.</span>, and <span class="refAuthor">T. Watteyne</span>, <span class="refTitle">"Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration"</span>, <span class="seriesInfo">BCP 210</span>, <span class="seriesInfo">RFC 8180</span>, <span class="seriesInfo">DOI 10.17487/RFC8180</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8180">https://www.rfc-editor.org/info/rfc8180</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8505">[RFC8505]</dt>
        <dd>
<span class="refAuthor">Thubert, P., Ed.</span>, <span class="refAuthor">Nordmark, E.</span>, <span class="refAuthor">Chakrabarti, S.</span>, and <span class="refAuthor">C. Perkins</span>, <span class="refTitle">"Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery"</span>, <span class="seriesInfo">RFC 8505</span>, <span class="seriesInfo">DOI 10.17487/RFC8505</span>, <time datetime="2018-11" class="refDate">November 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8505">https://www.rfc-editor.org/info/rfc8505</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8613">[RFC8613]</dt>
        <dd>
<span class="refAuthor">Selander, G.</span>, <span class="refAuthor">Mattsson, J.</span>, <span class="refAuthor">Palombini, F.</span>, and <span class="refAuthor">L. Seitz</span>, <span class="refTitle">"Object Security for Constrained RESTful Environments (OSCORE)"</span>, <span class="seriesInfo">RFC 8613</span>, <span class="seriesInfo">DOI 10.17487/RFC8613</span>, <time datetime="2019-07" class="refDate">July 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8613">https://www.rfc-editor.org/info/rfc8613</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8820">[RFC8820]</dt>
        <dd>
<span class="refAuthor">Nottingham, M.</span>, <span class="refTitle">"URI Design and Ownership"</span>, <span class="seriesInfo">BCP 190</span>, <span class="seriesInfo">RFC 8820</span>, <span class="seriesInfo">DOI 10.17487/RFC8820</span>, <time datetime="2020-06" class="refDate">June 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8820">https://www.rfc-editor.org/info/rfc8820</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8949">[RFC8949]</dt>
        <dd>
<span class="refAuthor">Bormann, C.</span> and <span class="refAuthor">P. Hoffman</span>, <span class="refTitle">"Concise Binary Object Representation (CBOR)"</span>, <span class="seriesInfo">STD 94</span>, <span class="seriesInfo">RFC 8949</span>, <span class="seriesInfo">DOI 10.17487/RFC8949</span>, <time datetime="2020-12" class="refDate">December 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8949">https://www.rfc-editor.org/info/rfc8949</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8974">[RFC8974]</dt>
        <dd>
<span class="refAuthor">Hartke, K.</span> and <span class="refAuthor">M. Richardson</span>, <span class="refTitle">"Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP)"</span>, <span class="seriesInfo">RFC 8974</span>, <span class="seriesInfo">DOI 10.17487/RFC8974</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8974">https://www.rfc-editor.org/info/rfc8974</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9030">[RFC9030]</dt>
      <dd>
<span class="refAuthor">Thubert, P., Ed.</span>, <span class="refTitle">"An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)"</span>, <span class="seriesInfo">RFC 9030</span>, <span class="seriesInfo">DOI 10.17487/RFC9030</span>, <time datetime="2021-05" class="refDate">May 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9030">https://www.rfc-editor.org/info/rfc9030</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-12.2">
        <h3 id="name-informative-references">
<a href="#section-12.2" class="section-number selfRef">12.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="NIST800-90A">[NIST800-90A]</dt>
        <dd>
<span class="refAuthor">National Institute of Standards and Technology</span>, <span class="refTitle">"Recommendation for Random Number Generation Using Deterministic Random Bit Generators"</span>, <span class="refContent">Special Publication 800-90A, Revision 1</span>, <span class="seriesInfo">DOI 10.6028/NIST.SP.800-90Ar1</span>, <time datetime="2015-06" class="refDate">June 2015</time>, <span>&lt;<a href="https://doi.org/10.6028/NIST.SP.800-90Ar1">https://doi.org/10.6028/NIST.SP.800-90Ar1</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4231">[RFC4231]</dt>
        <dd>
<span class="refAuthor">Nystrom, M.</span>, <span class="refTitle">"Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512"</span>, <span class="seriesInfo">RFC 4231</span>, <span class="seriesInfo">DOI 10.17487/RFC4231</span>, <time datetime="2005-12" class="refDate">December 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4231">https://www.rfc-editor.org/info/rfc4231</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4944">[RFC4944]</dt>
        <dd>
<span class="refAuthor">Montenegro, G.</span>, <span class="refAuthor">Kushalnagar, N.</span>, <span class="refAuthor">Hui, J.</span>, and <span class="refAuthor">D. Culler</span>, <span class="refTitle">"Transmission of IPv6 Packets over IEEE 802.15.4 Networks"</span>, <span class="seriesInfo">RFC 4944</span>, <span class="seriesInfo">DOI 10.17487/RFC4944</span>, <time datetime="2007-09" class="refDate">September 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4944">https://www.rfc-editor.org/info/rfc4944</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6550">[RFC6550]</dt>
        <dd>
<span class="refAuthor">Winter, T., Ed.</span>, <span class="refAuthor">Thubert, P., Ed.</span>, <span class="refAuthor">Brandt, A.</span>, <span class="refAuthor">Hui, J.</span>, <span class="refAuthor">Kelsey, R.</span>, <span class="refAuthor">Levis, P.</span>, <span class="refAuthor">Pister, K.</span>, <span class="refAuthor">Struik, R.</span>, <span class="refAuthor">Vasseur, JP.</span>, and <span class="refAuthor">R. Alexander</span>, <span class="refTitle">"RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks"</span>, <span class="seriesInfo">RFC 6550</span>, <span class="seriesInfo">DOI 10.17487/RFC6550</span>, <time datetime="2012-03" class="refDate">March 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6550">https://www.rfc-editor.org/info/rfc6550</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6762">[RFC6762]</dt>
        <dd>
<span class="refAuthor">Cheshire, S.</span> and <span class="refAuthor">M. Krochmal</span>, <span class="refTitle">"Multicast DNS"</span>, <span class="seriesInfo">RFC 6762</span>, <span class="seriesInfo">DOI 10.17487/RFC6762</span>, <time datetime="2013-02" class="refDate">February 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6762">https://www.rfc-editor.org/info/rfc6762</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7721">[RFC7721]</dt>
        <dd>
<span class="refAuthor">Cooper, A.</span>, <span class="refAuthor">Gont, F.</span>, and <span class="refAuthor">D. Thaler</span>, <span class="refTitle">"Security and Privacy Considerations for IPv6 Address Generation Mechanisms"</span>, <span class="seriesInfo">RFC 7721</span>, <span class="seriesInfo">DOI 10.17487/RFC7721</span>, <time datetime="2016-03" class="refDate">March 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7721">https://www.rfc-editor.org/info/rfc7721</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8415">[RFC8415]</dt>
        <dd>
<span class="refAuthor">Mrugalski, T.</span>, <span class="refAuthor">Siodelski, M.</span>, <span class="refAuthor">Volz, B.</span>, <span class="refAuthor">Yourtchenko, A.</span>, <span class="refAuthor">Richardson, M.</span>, <span class="refAuthor">Jiang, S.</span>, <span class="refAuthor">Lemon, T.</span>, and <span class="refAuthor">T. Winters</span>, <span class="refTitle">"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"</span>, <span class="seriesInfo">RFC 8415</span>, <span class="seriesInfo">DOI 10.17487/RFC8415</span>, <time datetime="2018-11" class="refDate">November 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8415">https://www.rfc-editor.org/info/rfc8415</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8480">[RFC8480]</dt>
        <dd>
<span class="refAuthor">Wang, Q., Ed.</span>, <span class="refAuthor">Vilajosana, X.</span>, and <span class="refAuthor">T. Watteyne</span>, <span class="refTitle">"6TiSCH Operation Sublayer (6top) Protocol (6P)"</span>, <span class="seriesInfo">RFC 8480</span>, <span class="seriesInfo">DOI 10.17487/RFC8480</span>, <time datetime="2018-11" class="refDate">November 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8480">https://www.rfc-editor.org/info/rfc8480</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8610">[RFC8610]</dt>
        <dd>
<span class="refAuthor">Birkholz, H.</span>, <span class="refAuthor">Vigano, C.</span>, and <span class="refAuthor">C. Bormann</span>, <span class="refTitle">"Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures"</span>, <span class="seriesInfo">RFC 8610</span>, <span class="seriesInfo">DOI 10.17487/RFC8610</span>, <time datetime="2019-06" class="refDate">June 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8610">https://www.rfc-editor.org/info/rfc8610</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8615">[RFC8615]</dt>
        <dd>
<span class="refAuthor">Nottingham, M.</span>, <span class="refTitle">"Well-Known Uniform Resource Identifiers (URIs)"</span>, <span class="seriesInfo">RFC 8615</span>, <span class="seriesInfo">DOI 10.17487/RFC8615</span>, <time datetime="2019-05" class="refDate">May 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8615">https://www.rfc-editor.org/info/rfc8615</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8742">[RFC8742]</dt>
        <dd>
<span class="refAuthor">Bormann, C.</span>, <span class="refTitle">"Concise Binary Object Representation (CBOR) Sequences"</span>, <span class="seriesInfo">RFC 8742</span>, <span class="seriesInfo">DOI 10.17487/RFC8742</span>, <time datetime="2020-02" class="refDate">February 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8742">https://www.rfc-editor.org/info/rfc8742</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8990">[RFC8990]</dt>
      <dd>
<span class="refAuthor">Bormann, C.</span>, <span class="refAuthor">Carpenter, B., Ed.</span>, and <span class="refAuthor">B. Liu, Ed.</span>, <span class="refTitle">"GeneRic Autonomic Signaling Protocol (GRASP)"</span>, <span class="seriesInfo">RFC 8990</span>, <span class="seriesInfo">DOI 10.17487/RFC8990</span>, <time datetime="2021-05" class="refDate">May 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8990">https://www.rfc-editor.org/info/rfc8990</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="example">
<section id="section-appendix.a">
      <h2 id="name-example">
<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-example" class="section-name selfRef">Example</a>
      </h2>
<p id="section-appendix.a-1"><a href="#fig_example" class="xref">Figure 3</a> illustrates a successful join protocol exchange.
The pledge instantiates the OSCORE context and derives the OSCORE keys and nonces from the PSK.
It uses the instantiated context to protect the Join Request addressed with
    a Proxy-Scheme option,
    the well-known host name of the JRC in the Uri-Host option, and
    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.
The JP learned the IPv6 address of the JRC when it acted as a pledge and joined the network.
Once the JRC receives the request, it looks up the correct context based on the 'kid context' parameter.
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.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<p id="section-appendix.a-2">Once the JP receives the Join Response, it authenticates the state within the CoAP token before deciding where to forward.
The JP sets its internal state to that found in the token and 
forwards the Join Response to the correct pledge.
Note that the JP does not possess the key to decrypt the CoJP object (configuration) present in the payload.
At the pledge, the Join Response is matched to the Join Request 
and verified for replay protection using OSCORE processing rules.
In this example, the Join Response does not contain the IPv6 address 
of the JRC, hence the pledge understands that the JRC is co-located with the 6LBR.<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
<span id="name-example-of-a-successful-joi"></span><div id="fig_example">
<figure id="figure-3">
        <div class="artwork art-text alignCenter" id="section-appendix.a-3.1">
<pre>
  &lt;-----E2E OSCORE------&gt;
Client      Proxy     Server
Pledge       JP        JRC
  |          |          |
  |  Join    |          |            Code: 0.02 (POST)
  | Request  |          |           Token: -
  +---------&gt;|          |    Proxy-Scheme: coap
  |          |          |        Uri-Host: 6tisch.arpa
  |          |          |          OSCORE: kid: -,
  |          |          |                  kid_context: EUI-64,
  |          |          |                  Partial IV: 1
  |          |          |         Payload: { Code: 0.02 (POST),
  |          |          |                    Uri-Path: "j",
  |          |          |                    join_request, &lt;Tag&gt; }
  |          |          |
  |          |  Join    |            Code: 0.02 (POST)
  |          | Request  |           Token: opaque state
  |          +---------&gt;|          OSCORE: kid: -,
  |          |          |                  kid_context: EUI-64,
  |          |          |                  Partial IV: 1
  |          |          |         Payload: { Code: 0.02 (POST),
  |          |          |                    Uri-Path: "j",
  |          |          |                    join_request, &lt;Tag&gt; }
  |          |          |
  |          |          |
  |          |  Join    |            Code: 2.04 (Changed)
  |          | Response |           Token: opaque state
  |          |&lt;---------+          OSCORE: -
  |          |          |         Payload: { Code: 2.04 (Changed),
  |          |          |                    configuration, &lt;Tag&gt; }
  |          |          |
  |          |          |
  |  Join    |          |            Code: 2.04 (Changed)
  | Response |          |           Token: -
  |&lt;---------+          |          OSCORE: -
  |          |          |         Payload: { Code: 2.04 (Changed),
  |          |          |                    configuration, &lt;Tag&gt; }
  |          |          |
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-example-of-a-successful-joi" class="selfRef">Example of a successful join protocol exchange. { ... } denotes authenticated encryption, &lt;Tag&gt; denotes the authentication tag.</a>
        </figcaption></figure>
</div>
<p id="section-appendix.a-4">Where the join_request object is:<a href="#section-appendix.a-4" class="pilcrow">¶</a></p>
<div id="section-appendix.a-5">
<pre class="sourcecode">
join_request:
{
   5 : h'cafe' / PAN ID of the network pledge is attempting to join /
}
</pre><a href="#section-appendix.a-5" class="pilcrow">¶</a>
</div>
<p id="section-appendix.a-6">Since the role parameter is not present, the default role of "6TiSCH Node" is implied.<a href="#section-appendix.a-6" class="pilcrow">¶</a></p>
<p id="section-appendix.a-7">The join_request object is converted to h'a10542cafe' with a size of 5 bytes.<a href="#section-appendix.a-7" class="pilcrow">¶</a></p>
<p id="section-appendix.a-8">And the configuration object is the following:<a href="#section-appendix.a-8" class="pilcrow">¶</a></p>
<div id="section-appendix.a-9">
<pre class="sourcecode">
configuration:
{
   2 : [           / link-layer key set /
         1,        / key_id /
         h'e6bf4287c2d7618d6a9687445ffd33e6' / key_value /
       ],
   3 : [           / short identifier /
         h'af93'   / assigned short address /
       ]
}
</pre><a href="#section-appendix.a-9" class="pilcrow">¶</a>
</div>
<p id="section-appendix.a-10">Since the key_usage parameter is not present in the link-layer key set object, the default value of "6TiSCH-K1K2-ENC-MIC32" is implied.
Since the key_addinfo parameter is not present and key_id is 
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.<a href="#section-appendix.a-10" class="pilcrow">¶</a></p>
<p id="section-appendix.a-11">The configuration object is converted to the following:<a href="#section-appendix.a-11" class="pilcrow">¶</a></p>
<p id="section-appendix.a-12">h'a202820150e6bf4287c2d7618d6a9687445ffd33e6038142af93' with a size of 26 bytes.<a href="#section-appendix.a-12" class="pilcrow">¶</a></p>
</section>
</div>
<div id="lightweight">
<section id="section-appendix.b">
      <h2 id="name-lightweight-implementation-">
<a href="#section-appendix.b" class="section-number selfRef">Appendix B. </a><a href="#name-lightweight-implementation-" class="section-name selfRef">Lightweight Implementation Option</a>
      </h2>
<p id="section-appendix.b-1">In environments where optimizing the implementation footprint is important, it is possible to implement this specification without having the implementations of HKDF <span>[<a href="#RFC5869" class="xref">RFC5869</a>]</span> and SHA <span>[<a href="#RFC4231" class="xref">RFC4231</a>]</span> on constrained devices.
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 
of the (6LBR) pledge during the provisioning phase.
In that case, the derived OSCORE security context parameters are 
written directly into the (6LBR) pledge, without requiring the PSK to 
be provisioned to the (6LBR) pledge.<a href="#section-appendix.b-1" class="pilcrow">¶</a></p>
<p id="section-appendix.b-2">The use of HKDF to derive OSCORE security context parameters 
ensures that the resulting OSCORE keys have good security properties 
and are unique as long as the input varies for different pledges.
This specification ensures the uniqueness by mandating
    unique pledge identifiers
    and a unique PSK for each (6LBR) pledge.
From the AEAD nonce reuse viewpoint, having a unique pledge identifier is a sufficient condition.
However, as discussed in <a href="#sec_considerations" class="xref">Section 9</a>, the use of a single PSK shared among many devices is a common security pitfall.
The compromise of this shared PSK on a single device would lead to the compromise of the entire batch.
When using the implementation/deployment scheme outlined above, 
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 
level of security comparable to the scenario in which each pledge 
is provisioned with a unique PSK.
In this case, there is still a latent risk of the shared PSK being 
compromised on the provisioning device, which would compromise all devices in the batch.<a href="#section-appendix.b-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="acknowledgments">
<section id="section-appendix.c">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="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.<a href="#section-appendix.c-1" class="pilcrow">¶</a></p>
<p id="section-appendix.c-2">The following individuals provided input to this document (in alphabetic order):
<span class="contact-name">Christian Amsüss</span>,
<span class="contact-name">Tengfei Chang</span>,
<span class="contact-name">Roman Danyliw</span>,
<span class="contact-name">Linda Dunbar</span>,
<span class="contact-name">Vijay Gurbani</span>,
<span class="contact-name">Klaus Hartke</span>,
<span class="contact-name">Barry Leiba</span>,
<span class="contact-name">Benjamin Kaduk</span>,
<span class="contact-name">Tero Kivinen</span>,
<span class="contact-name">Mirja Kühlewind</span>,
<span class="contact-name">John Mattsson</span>,
<span class="contact-name">Hilarie Orman</span>,
<span class="contact-name">Alvaro Retana</span>,
<span class="contact-name">Adam Roach</span>,
<span class="contact-name">Jim Schaad</span>,
<span class="contact-name">Göran Selander</span>,
<span class="contact-name">Yasuyuki Tanaka</span>,
<span class="contact-name">Pascal Thubert</span>,
<span class="contact-name">William Vignat</span>,
<span class="contact-name">Xavier Vilajosana</span>,
<span class="contact-name">Éric Vyncke</span>, and
<span class="contact-name">Thomas Watteyne</span>.<a href="#section-appendix.c-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.d">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Mališa Vučinić (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">Inria</span></div>
<div dir="auto" class="left"><span class="street-address">2 Rue Simone Iff</span></div>
<div dir="auto" class="left">
<span class="postal-code">75012</span> <span class="locality">Paris</span>
</div>
<div dir="auto" class="left"><span class="country-name">France</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:malisa.vucinic@inria.fr" class="email">malisa.vucinic@inria.fr</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Jonathan Simon</span></div>
<div dir="auto" class="left"><span class="org">Analog Devices</span></div>
<div dir="auto" class="left"><span class="street-address">32990 Alvarado-Niles Road, Suite 910</span></div>
<div dir="auto" class="left">
<span class="locality">Union City</span>, <span class="region">CA</span> <span class="postal-code">94587</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:jonathan.simon@analog.com" class="email">jonathan.simon@analog.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Kris Pister</span></div>
<div dir="auto" class="left"><span class="org">University of California Berkeley</span></div>
<div dir="auto" class="left"><span class="street-address">512 Cory Hall</span></div>
<div dir="auto" class="left">
<span class="locality">Berkeley</span>, <span class="region">CA</span> <span class="postal-code">94720</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:pister@eecs.berkeley.edu" class="email">pister@eecs.berkeley.edu</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Michael Richardson</span></div>
<div dir="auto" class="left"><span class="org">Sandelman Software Works</span></div>
<div dir="auto" class="left"><span class="street-address">470 Dawson Avenue</span></div>
<div dir="auto" class="left">
<span class="locality">Ottawa</span> <span class="region">ON</span> <span class="postal-code">K1Z5V7</span>
</div>
<div dir="auto" class="left"><span class="country-name">Canada</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:mcr+ietf@sandelman.ca" class="email">mcr+ietf@sandelman.ca</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>