File: rfc9175.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 (2911 lines) | stat: -rw-r--r-- 154,930 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 9175: Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token Processing</title>
<meta content="Christian Amsüss" name="author">
<meta content="John Preuß Mattsson" name="author">
<meta content="Göran Selander" name="author">
<meta content="
       This document specifies enhancements to the Constrained Application Protocol
      (CoAP) that mitigate security issues in particular use cases. The Echo option enables
      a CoAP server to verify the freshness of a request or to force a client to
      demonstrate reachability at its claimed network address. The Request-Tag option
      allows the CoAP server to match block-wise message fragments belonging to the same
      request. This document updates RFC 7252 with respect to the following: processing
      requirements for client Tokens, forbidding non-secure reuse of Tokens to ensure response-to-request binding when CoAP is used with a security protocol, and
      amplification mitigation (where the use of the Echo option is now recommended). 
    " name="description">
<meta content="xml2rfc 3.12.2" name="generator">
<meta content="OSCORE" name="keyword">
<meta content="block-wise" name="keyword">
<meta content="DTLS" name="keyword">
<meta content="freshness" name="keyword">
<meta content="delay" name="keyword">
<meta content="denial-of-service" name="keyword">
<meta content="amplification" name="keyword">
<meta content="Message Body Integrity" name="keyword">
<meta content="Concurrent Block-Wise" name="keyword">
<meta content="Request-Response Binding" name="keyword">
<meta content="Token Reuse" name="keyword">
<meta content="9175" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.12.2
    Python 3.6.15
    appdirs 1.4.4
    ConfigArgParse 1.4.1
    google-i18n-address 2.4.0
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.3
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.15.1
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.4.1
    requests 2.24.0
    setuptools 40.5.0
    six 1.14.0
    WeasyPrint 52.5
-->
<link href="rfc9175.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.ulBare, li.ulBare {
  margin-left: 0em !important;
}
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;
}
/* Fix PDF info block run off issue */
@media print {
  #identifiers dd {
    float: none;
  }
}
#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: auto;
  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/rfc9175" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-core-echo-request-tag-14" 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 9175</td>
<td class="center">Echo, Request-Tag, and Token Processing</td>
<td class="right">February 2022</td>
</tr></thead>
<tfoot><tr>
<td class="left">Amsüss, 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/rfc9175" class="eref">9175</a></dd>
<dt class="label-updates">Updates:</dt>
<dd class="updates">
<a href="https://www.rfc-editor.org/rfc/rfc7252" class="eref">7252</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="2022-02" class="published">February 2022</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">C. Amsüss</div>
</div>
<div class="author">
      <div class="author-name">J. Preuß Mattsson</div>
<div class="org">Ericsson AB</div>
</div>
<div class="author">
      <div class="author-name">G. Selander</div>
<div class="org">Ericsson AB</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9175</h1>
<h1 id="title">Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token Processing</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document specifies enhancements to the Constrained Application Protocol
      (CoAP) that mitigate security issues in particular use cases. The Echo option enables
      a CoAP server to verify the freshness of a request or to force a client to
      demonstrate reachability at its claimed network address. The Request-Tag option
      allows the CoAP server to match block-wise message fragments belonging to the same
      request. This document updates RFC 7252 with respect to the following: processing
      requirements for client Tokens, forbidding non-secure reuse of Tokens to ensure response-to-request binding when CoAP is used with a security protocol, and
      amplification mitigation (where the use of the Echo option is now recommended).<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/rfc9175">https://www.rfc-editor.org/info/rfc9175</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) 2022 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 Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised 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="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" 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>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-terminology" class="xref">Terminology</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-request-freshness-and-the-e" class="xref">Request Freshness and the Echo Option</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1">
                <p id="section-toc.1-1.2.2.1.1" class="keepWithNext"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-request-freshness" class="xref">Request Freshness</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.2">
                <p id="section-toc.1-1.2.2.2.1"><a href="#section-2.2" class="xref">2.2</a>.  <a href="#name-the-echo-option" class="xref">The Echo Option</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.2.2.1">
                    <p id="section-toc.1-1.2.2.2.2.1.1"><a href="#section-2.2.1" class="xref">2.2.1</a>.  <a href="#name-echo-option-format" class="xref">Echo Option Format</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.3">
                <p id="section-toc.1-1.2.2.3.1"><a href="#section-2.3" class="xref">2.3</a>.  <a href="#name-echo-processing" class="xref">Echo Processing</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.4">
                <p id="section-toc.1-1.2.2.4.1"><a href="#section-2.4" class="xref">2.4</a>.  <a href="#name-applications-of-the-echo-op" class="xref">Applications of the Echo Option</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.5">
                <p id="section-toc.1-1.2.2.5.1"><a href="#section-2.5" class="xref">2.5</a>.  <a href="#name-characterization-of-echo-ap" class="xref">Characterization of Echo Applications</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.5.2.1">
                    <p id="section-toc.1-1.2.2.5.2.1.1"><a href="#section-2.5.1" class="xref">2.5.1</a>.  <a href="#name-time-based-versus-event-bas" class="xref">Time-Based versus Event-Based Freshness</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.5.2.2">
                    <p id="section-toc.1-1.2.2.5.2.2.1"><a href="#section-2.5.2" class="xref">2.5.2</a>.  <a href="#name-authority-over-used-informa" class="xref">Authority over Used Information</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.5.2.3">
                    <p id="section-toc.1-1.2.2.5.2.3.1"><a href="#section-2.5.3" class="xref">2.5.3</a>.  <a href="#name-protection-by-a-security-pr" class="xref">Protection by a Security Protocol</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.6">
                <p id="section-toc.1-1.2.2.6.1"><a href="#section-2.6" class="xref">2.6</a>.  <a href="#name-updated-amplification-mitig" class="xref">Updated Amplification Mitigation Requirements for Servers</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-protecting-message-bodies-u" class="xref">Protecting Message Bodies Using Request Tags</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-fragmented-message-body-int" class="xref">Fragmented Message Body Integrity</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-the-request-tag-option" class="xref">The Request-Tag Option</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2.2.1">
                    <p id="section-toc.1-1.3.2.2.2.1.1"><a href="#section-3.2.1" class="xref">3.2.1</a>.  <a href="#name-request-tag-option-format" class="xref">Request-Tag Option Format</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.3">
                <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>.  <a href="#name-request-tag-processing-by-s" class="xref">Request-Tag Processing by Servers</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.4">
                <p id="section-toc.1-1.3.2.4.1"><a href="#section-3.4" class="xref">3.4</a>.  <a href="#name-setting-the-request-tag" class="xref">Setting the Request-Tag</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.5">
                <p id="section-toc.1-1.3.2.5.1"><a href="#section-3.5" class="xref">3.5</a>.  <a href="#name-applications-of-the-request" class="xref">Applications of the Request-Tag Option</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.5.2.1">
                    <p id="section-toc.1-1.3.2.5.2.1.1"><a href="#section-3.5.1" class="xref">3.5.1</a>.  <a href="#name-body-integrity-based-on-pay" class="xref">Body Integrity Based on Payload Integrity</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.5.2.2">
                    <p id="section-toc.1-1.3.2.5.2.2.1"><a href="#section-3.5.2" class="xref">3.5.2</a>.  <a href="#name-multiple-concurrent-block-w" class="xref">Multiple Concurrent Block-Wise Operations</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.5.2.3">
                    <p id="section-toc.1-1.3.2.5.2.3.1"><a href="#section-3.5.3" class="xref">3.5.3</a>.  <a href="#name-simplified-block-wise-handl" class="xref">Simplified Block-Wise Handling for Constrained Proxies</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.6">
                <p id="section-toc.1-1.3.2.6.1"><a href="#section-3.6" class="xref">3.6</a>.  <a href="#name-rationale-for-the-option-pr" class="xref">Rationale for the Option Properties</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.7">
                <p id="section-toc.1-1.3.2.7.1"><a href="#section-3.7" class="xref">3.7</a>.  <a href="#name-rationale-for-introducing-t" class="xref">Rationale for Introducing the Option</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.8">
                <p id="section-toc.1-1.3.2.8.1"><a href="#section-3.8" class="xref">3.8</a>.  <a href="#name-block2-and-etag-processing" class="xref">Block2 and ETag Processing</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" 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-token-processing-for-secure" class="xref">Token Processing for Secure Request-Response Binding</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" 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-request-response-binding" class="xref">Request-Response Binding</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" 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-updated-token-processing-re" class="xref">Updated Token Processing Requirements for Clients</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" 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-security-considerations" class="xref">Security Considerations</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" 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-token-reuse" class="xref">Token Reuse</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" 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-privacy-considerations" class="xref">Privacy Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" 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-iana-considerations" class="xref">IANA Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" 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-references" class="xref">References</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" 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-normative-references" class="xref">Normative References</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" 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-informative-references" class="xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#appendix-A" class="xref">Appendix A</a>.  <a href="#name-methods-for-generating-echo" class="xref">Methods for Generating Echo Option Values</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#appendix-B" class="xref">Appendix B</a>.  <a href="#name-request-tag-message-size-im" class="xref">Request-Tag Message Size Impact</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#appendix-C" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#appendix-D" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="intro">
<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">The initial suite of specifications for the Constrained Application Protocol (CoAP)
      (<span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span>, <span>[<a href="#RFC7641" class="xref">RFC7641</a>]</span>, and
      <span>[<a href="#RFC7959" class="xref">RFC7959</a>]</span>) was designed with the assumption that
      security could be provided on a separate layer, in particular, by using DTLS <span>[<a href="#RFC6347" class="xref">RFC6347</a>]</span>. However, for some use cases, additional
      functionality or extra processing is needed to support secure CoAP operations. This
      document specifies security enhancements to CoAP.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">This document specifies two CoAP options, the Echo option and the Request-Tag
      option. The Echo option enables a CoAP server to verify the freshness of a request,
      which can be used to synchronize state, or to force a client to demonstrate
      reachability at its claimed network address. The Request-Tag option allows the CoAP
      server to match message fragments belonging to the same request, fragmented using the
      CoAP block-wise transfer mechanism, which mitigates attacks and enables concurrent
      block-wise operations. These options in themselves do not replace the need for a
      security protocol; they specify the format and processing of data that, when
      integrity protected using, e.g., DTLS <span>[<a href="#RFC6347" class="xref">RFC6347</a>]</span>, TLS
      <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span>, or Object Security for Constrained
      RESTful Environments (OSCORE) <span>[<a href="#RFC8613" class="xref">RFC8613</a>]</span>, provide the additional security features.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">This document updates <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span> with a
      recommendation that servers use the Echo option to mitigate amplification attacks.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">The document also updates the Token processing requirements for clients specified
      in <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span>. The updated processing forbids
      non-secure reuse of Tokens to ensure binding of responses to requests when CoAP is
      used with security, thus mitigating error cases and attacks where the client may
      erroneously associate the wrong response to a request.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">Each of the following sections provides a more-detailed introduction to the topic
      at hand in its first subsection.<a href="#section-1-5" class="pilcrow">¶</a></p>
<div id="terminology">
<section id="section-1.1">
        <h3 id="name-terminology">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
        </h3>
<p id="section-1.1-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-1.1-1" class="pilcrow">¶</a></p>
<p id="section-1.1-2">Like <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span>, this document relies
 on the Representational State Transfer <span>[<a href="#REST" class="xref">REST</a>]</span>
 architecture of the Web.<a href="#section-1.1-2" class="pilcrow">¶</a></p>
<p id="section-1.1-3">Unless otherwise specified, the terms "client" and "server" refer to "CoAP
 client" and "CoAP server", respectively, as defined in <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span>.<a href="#section-1.1-3" class="pilcrow">¶</a></p>
<p id="section-1.1-4">A message's "freshness" is a measure of when a message was sent on a timescale
 of the recipient. A server that receives a request can either verify that the
 request is fresh or determine that it cannot be verified that the request is fresh.
 What is considered a fresh message is application dependent;
 exemplary uses are "no more than 42 seconds ago" or "after this server's last
 reboot".<a href="#section-1.1-4" class="pilcrow">¶</a></p>
<p id="section-1.1-5">The terms "payload" and "body" of a message are used as in <span>[<a href="#RFC7959" class="xref">RFC7959</a>]</span>.  The complete interchange of a request and a
 response body is called a (REST) "operation". An operation fragmented using <span>[<a href="#RFC7959" class="xref">RFC7959</a>]</span> is called a "block-wise operation". A
 block-wise operation that is fragmenting the request body is called a "block-wise
 request operation".  A block-wise operation that is fragmenting the response body
 is called a "block-wise response operation".<a href="#section-1.1-5" class="pilcrow">¶</a></p>
<p id="section-1.1-6">Two request messages are said to be "matchable" if they occur between the same
 endpoint pair, have the same code, and have the same set of options, with the
 exception that elective NoCacheKey options and options involved in block-wise
 transfer (Block1, Block2, and Request-Tag) need not be the same.
        Two blockwise request operations are said to be matchable if their request
 messages are matchable.<a href="#section-1.1-6" class="pilcrow">¶</a></p>
<p id="section-1.1-7">Two matchable block-wise request operations are said to be "concurrent" if a
 block of
 the second request is exchanged even though the client still intends to exchange
 further blocks in the first operation. (Concurrent block-wise request operations
 from a single endpoint are impossible with the options of <span>[<a href="#RFC7959" class="xref">RFC7959</a>]</span> -- see the last paragraphs of Sections <a href="https://www.rfc-editor.org/rfc/rfc7959#section-2.4" class="relref">2.4</a> and <a href="https://www.rfc-editor.org/rfc/rfc7959#section-2.5" class="relref">2.5</a> -- because the second operation's block overwrites any state
 of the first exchange.)<a href="#section-1.1-7" class="pilcrow">¶</a></p>
<p id="section-1.1-8">The Echo and Request-Tag options are defined in this document.<a href="#section-1.1-8" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="echo">
<section id="section-2">
      <h2 id="name-request-freshness-and-the-e">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-request-freshness-and-the-e" class="section-name selfRef">Request Freshness and the Echo Option</a>
      </h2>
<div id="req-fresh">
<section id="section-2.1">
        <h3 id="name-request-freshness">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-request-freshness" class="section-name selfRef">Request Freshness</a>
        </h3>
<p id="section-2.1-1">A CoAP server receiving a request is, in general, not able to verify when the
 request was sent by the CoAP client. This remains true even if the request was
 protected with a security protocol, such as DTLS. This makes CoAP requests
 vulnerable to certain delay attacks that are particularly perilous in the case of
 actuators <span>[<a href="#I-D.mattsson-core-coap-attacks" class="xref">COAP-ATTACKS</a>]</span>. Some
 attacks can be mitigated by establishing fresh session keys, e.g., performing a DTLS
 handshake for each request, but, in general, this is not a solution suitable for
 constrained environments, for example, due to increased message overhead and
 latency. Additionally, if there are proxies, fresh DTLS session keys between the
 server
 and the proxy do not say anything about when the client made the request. In a
 general hop-by-hop setting, freshness may need to be verified in each hop.<a href="#section-2.1-1" class="pilcrow">¶</a></p>
<p id="section-2.1-2">A straightforward mitigation of potential delayed requests is that the CoAP
 server rejects a request the first time it appears and asks the CoAP client to
 prove that it intended to make the request at this point in time.<a href="#section-2.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="the-echo-option">
<section id="section-2.2">
        <h3 id="name-the-echo-option">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-the-echo-option" class="section-name selfRef">The Echo Option</a>
        </h3>
<p id="section-2.2-1">This document defines the Echo option, a lightweight challenge-response
 mechanism for CoAP that enables a CoAP server to verify the freshness of a request.
 A fresh request is one whose age has not yet exceeded the freshness requirements
 set by the server. The freshness requirements are application specific and may vary
 based on resource, method, and parameters outside of CoAP, such as policies. The
 Echo option value is a challenge from the server to the client included in a CoAP
 response and echoed back to the server in one or more CoAP requests.<a href="#section-2.2-1" class="pilcrow">¶</a></p>
<p id="section-2.2-2">This mechanism is not only important in the case of actuators, or other use
 cases where the CoAP operations require freshness of requests, but also in general
 for synchronizing state between a CoAP client and server, cryptographically
 verifying
 the aliveness of the client or forcing a client to demonstrate reachability at its
 claimed network address. The same functionality can be provided by echoing
 freshness indicators in CoAP payloads, but this only works for methods and response
 codes defined to have a payload. The Echo option provides a convention to transfer
 freshness indicators that works for all methods and response codes.<a href="#section-2.2-2" class="pilcrow">¶</a></p>
<div id="echo-format">
<section id="section-2.2.1">
          <h4 id="name-echo-option-format">
<a href="#section-2.2.1" class="section-number selfRef">2.2.1. </a><a href="#name-echo-option-format" class="section-name selfRef">Echo Option Format</a>
          </h4>
<p id="section-2.2.1-1">The Echo option is elective, safe to forward, not part of the cache-key, and
   not repeatable (see <a href="#echo-table" class="xref">Table 1</a>, which extends
   Table 4 of <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span>).<a href="#section-2.2.1-1" class="pilcrow">¶</a></p>
<span id="name-echo-option-summary"></span><div id="echo-table">
<table class="left" id="table-1">
            <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-echo-option-summary" class="selfRef">Echo Option Summary</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">No.</th>
                <th class="text-left" rowspan="1" colspan="1">C</th>
                <th class="text-left" rowspan="1" colspan="1">U</th>
                <th class="text-left" rowspan="1" colspan="1">N</th>
                <th class="text-left" rowspan="1" colspan="1">R</th>
                <th class="text-left" rowspan="1" colspan="1">Name</th>
                <th class="text-left" rowspan="1" colspan="1">Format</th>
                <th class="text-left" rowspan="1" colspan="1">Length</th>
                <th class="text-left" rowspan="1" colspan="1">Default</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">252</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
                <td class="text-left" rowspan="1" colspan="1"></td>
                <td class="text-left" rowspan="1" colspan="1">x</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
                <td class="text-left" rowspan="1" colspan="1">Echo</td>
                <td class="text-left" rowspan="1" colspan="1">opaque</td>
                <td class="text-left" rowspan="1" colspan="1">1-40</td>
                <td class="text-left" rowspan="1" colspan="1">(none)</td>
              </tr>
            </tbody>
          </table>
</div>
<p id="section-2.2.1-3">C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable<a href="#section-2.2.1-3" class="pilcrow">¶</a></p>
<p id="section-2.2.1-4">The Echo option value is generated by a server, and its content and structure
   are implementation specific. Different methods for generating Echo option values
   are outlined in <a href="#echo-state" class="xref">Appendix A</a>. Clients and
   intermediaries <span class="bcp14">MUST</span> treat an Echo option value as opaque and make
   no assumptions about its content or structure.<a href="#section-2.2.1-4" class="pilcrow">¶</a></p>
<p id="section-2.2.1-5">When receiving an Echo option in a request, the server <span class="bcp14">MUST</span> be
   able to verify that the Echo option value (a) was generated by the server or some
   other party that the server trusts and (b) fulfills the freshness requirements
   of the application. Depending on the freshness requirements, the server may verify
   exactly when the Echo option value was generated (time-based freshness) or verify
   that the Echo option was generated after a specific event (event-based
   freshness). As the request is bound to the Echo option value, the server can
   determine that the request is not older than the Echo option value.<a href="#section-2.2.1-5" class="pilcrow">¶</a></p>
<p id="section-2.2.1-6">When the Echo option is used with OSCORE <span>[<a href="#RFC8613" class="xref">RFC8613</a>]</span>, it <span class="bcp14">MAY</span> be an Inner or Outer option, and the
   Inner and Outer values are independent. OSCORE servers <span class="bcp14">MUST</span> only
   produce Inner Echo options unless they are merely testing for reachability of the
   client (the same as proxies may do). The Inner option is encrypted and integrity
   protected between the endpoints, whereas the Outer option is not protected by
   OSCORE. As always with OSCORE, Outer options are visible to (and may be acted on
   by) all proxies and are visible on all links where no additional encryption
   (like TLS between client and proxy) is used.<a href="#section-2.2.1-6" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="echo-proc">
<section id="section-2.3">
        <h3 id="name-echo-processing">
<a href="#section-2.3" class="section-number selfRef">2.3. </a><a href="#name-echo-processing" class="section-name selfRef">Echo Processing</a>
        </h3>
<p id="section-2.3-1">The Echo option <span class="bcp14">MAY</span> be included in any request or response (see
 <a href="#echo-app" class="xref">Section 2.4</a> for different applications).<a href="#section-2.3-1" class="pilcrow">¶</a></p>
<p id="section-2.3-2">The application decides under what conditions a CoAP request to a resource is
 required to be fresh. These conditions can, for example, include what resource is
 requested, the request method and other data in the request, and conditions in the
 environment, such as the state of the server or the time of the day.<a href="#section-2.3-2" class="pilcrow">¶</a></p>
<p id="section-2.3-3">If a certain request is required to be fresh, the request does not contain a
 fresh Echo option value, and the server cannot verify the freshness of the request
 in some other way, the server <span class="bcp14">MUST NOT</span> process the request further
 and <span class="bcp14">SHOULD</span> send a 4.01 (Unauthorized) response with an Echo option.
 The server <span class="bcp14">MAY</span> include the same Echo option value in several
 different response messages and to different clients. Examples of this could be
 time-based freshness (when several responses are sent closely after each other) or
 event-based freshness (with no event taking place between the responses).<a href="#section-2.3-3" class="pilcrow">¶</a></p>
<p id="section-2.3-4">The server may use request freshness provided by the Echo option to verify the
 aliveness of a client or to synchronize state. The server may also include the Echo
 option in a response to force a client to demonstrate reachability at its claimed
 network address. Note that the Echo option does not bind a request to any
 particular previous response but provides an indication that the client had access
 to the previous response at the time when it created the request.<a href="#section-2.3-4" class="pilcrow">¶</a></p>
<p id="section-2.3-5">Upon receiving a 4.01 (Unauthorized) response with the Echo option, the client
 <span class="bcp14">SHOULD</span> resend the original request with the addition of an Echo
 option with the received Echo option value. The client <span class="bcp14">MAY</span> send a
 different request compared to the original request. Upon receiving any other
 response with the Echo option, the client <span class="bcp14">SHOULD</span> echo the Echo
 option value in the next request to the server. The client <span class="bcp14">MAY</span>
 include the same Echo option value in several different requests to the server or
 discard it at any time (especially to avoid tracking; see <a href="#priv-cons" class="xref">Section 6</a>).<a href="#section-2.3-5" class="pilcrow">¶</a></p>
<p id="section-2.3-6">A client <span class="bcp14">MUST</span> only send Echo option values to endpoints it
 received them
 from (where, as defined in <span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-1.2" class="relref">Section 1.2</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span>, the security association is part of the endpoint). In
 OSCORE processing, that means sending Echo option values from Outer options (or
 from non-OSCORE responses) back in Outer options and sending those from Inner
 options in Inner options in the same security context.<a href="#section-2.3-6" class="pilcrow">¶</a></p>
<p id="section-2.3-7">Upon receiving a request with the Echo option, the server determines if the
 request is required to be fresh. If not, the Echo option <span class="bcp14">MAY</span> be
 ignored. If the request is required to be fresh and the server cannot verify the
 freshness of the request in some other way, the server <span class="bcp14">MUST</span> use the
 Echo option to verify that the request is fresh. If the server cannot verify that
 the request is fresh, the request is not processed further, and an error message
 <span class="bcp14">MAY</span> be sent. The error message <span class="bcp14">SHOULD</span> include a new
 Echo option.<a href="#section-2.3-7" class="pilcrow">¶</a></p>
<p id="section-2.3-8">One way for the server to verify freshness is to bind the Echo option value to a
 specific point in time and verify that the request is not older than a certain
 threshold T. The server can verify this by checking that (t1 - t0) &lt; T, where t1
 is the request receive time and t0 is the time when the Echo option value was
 generated. An example message flow over DTLS is shown <a href="#echo-figure-time" class="xref">Figure 1</a>.<a href="#section-2.3-8" class="pilcrow">¶</a></p>
<span id="name-example-message-flow-for-ti"></span><div id="echo-figure-time">
<figure id="figure-1">
          <div class="alignCenter art-text artwork" id="section-2.3-9.1">
<pre>
Client   Server
   |       |
   +------&gt;|        Code: 0.03 (PUT)
   |  PUT  |       Token: 0x41
   |       |    Uri-Path: lock
   |       |     Payload: 0 (Unlock)
   |       |
   |&lt;------+        Code: 4.01 (Unauthorized)
   |  4.01 |       Token: 0x41
   |       |        Echo: 0x00000009437468756c687521 (t0 = 9, +MAC)
   |       |
   | ...   | The round trips take 1 second, time is now t1 = 10.
   |       |
   +------&gt;|        Code: 0.03 (PUT)
   |  PUT  |       Token: 0x42
   |       |    Uri-Path: lock
   |       |        Echo: 0x00000009437468756c687521 (t0 = 9, +MAC)
   |       |     Payload: 0 (Unlock)
   |       |
   |       | Verify MAC, compare t1 - t0 = 1 &lt; T =&gt; permitted.
   |       |
   |&lt;------+        Code: 2.04 (Changed)
   |  2.04 |       Token: 0x42
   |       |
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-example-message-flow-for-ti" class="selfRef">Example Message Flow for Time-Based Freshness Using the
   'Integrity‑Protected Timestamp' Construction of Appendix A</a>
          </figcaption></figure>
</div>
<p id="section-2.3-10">Another way for the server to verify freshness is to maintain a cache of values
 associated to events. The size of the cache is defined by the application. In the
 following, we assume the cache size is 1, in which case, freshness is defined as
 "no new event has taken place". At each event, a new value is written into the
 cache. The cache values <span class="bcp14">MUST</span> be different or chosen in a way so the
 probability for collisions is negligible.
 The server verifies freshness by checking that e0 equals e1, where e0 is the cached
 value when the Echo option value was generated, and e1 is the cached value at the
 reception of the request. An example message flow over DTLS is shown in <a href="#echo-figure-event" class="xref">Figure 2</a>.<a href="#section-2.3-10" class="pilcrow">¶</a></p>
<span id="name-example-message-flow-for-ev"></span><div id="echo-figure-event">
<figure id="figure-2">
          <div class="alignCenter art-text artwork" id="section-2.3-11.1">
<pre>
Client   Server
   |       |
   +------&gt;|        Code: 0.03 (PUT)
   |  PUT  |       Token: 0x41
   |       |    Uri-Path: lock
   |       |     Payload: 0 (Unlock)
   |       |
   |&lt;------+        Code: 4.01 (Unauthorized)
   |  4.01 |       Token: 0x41
   |       |        Echo: 0x05 (e0 = 5, number of total lock
   |       |                            operations performed)
   |       |
   | ...   | No alterations happen to the lock state, e1 has the
   |       | same value e1 = 5.
   |       |
   +------&gt;|        Code: 0.03 (PUT)
   |  PUT  |       Token: 0x42
   |       |    Uri-Path: lock
   |       |        Echo: 0x05
   |       |     Payload: 0 (Unlock)
   |       |
   |       | Compare e1 = e0 =&gt; permitted.
   |       |
   |&lt;------+        Code: 2.04 (Changed)
   |  2.04 |       Token: 0x42
   |       |        Echo: 0x06 (e2 = 6, to allow later locking
   |       |                            without more round trips)
   |       |
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-example-message-flow-for-ev" class="selfRef">Example Message Flow for Event-Based Freshness Using the 'Persistent
   Counter' Construction of Appendix A</a>
          </figcaption></figure>
</div>
<p id="section-2.3-12">When used to serve freshness requirements (including client aliveness and state
 synchronizing), the Echo option value <span class="bcp14">MUST</span> be integrity protected
 between the intended endpoints, e.g., using DTLS, TLS, or an OSCORE Inner option
 <span>[<a href="#RFC8613" class="xref">RFC8613</a>]</span>.
 When used to demonstrate reachability
 at a claimed network address, the Echo option <span class="bcp14">SHOULD</span> be a Message
 Authentication Code (MAC) of the
 claimed address but <span class="bcp14">MAY</span> be unprotected. Combining different Echo
 applications can necessitate different choices; see <a href="#echo-state" class="xref">Appendix A</a>, item 2 for an example.<a href="#section-2.3-12" class="pilcrow">¶</a></p>
<p id="section-2.3-13">An Echo option <span class="bcp14">MAY</span> be sent with a successful response, i.e., even though
 the request satisfied any freshness requirements on the operation. This is called a
 "preemptive" Echo option value and is useful when the server anticipates that the client
 will need to demonstrate freshness relative to the current response in the near future.<a href="#section-2.3-13" class="pilcrow">¶</a></p>
<p id="section-2.3-14">A CoAP-to-CoAP proxy <span class="bcp14">MAY</span> set an Echo option on responses, both on
 forwarded ones that had no Echo option or ones generated by the proxy (from cache
 or as an error). If it does so, it <span class="bcp14">MUST</span> remove the Echo option it
 recognizes as one generated by itself on follow-up requests. When it receives an
 Echo option in a response, it <span class="bcp14">MAY</span> forward it to the client (and, not
 recognizing it as its own in future requests, relay it in the other direction as
 well) or process it on its own. If it does so, it <span class="bcp14">MUST</span> ensure that
 the client's request was generated (or is regenerated) after the Echo option value
 used
 to send to the server was first seen. (In most cases, this means that the proxy
 needs to ask the client to repeat the request with a new Echo option value.)<a href="#section-2.3-14" class="pilcrow">¶</a></p>
<p id="section-2.3-15">The CoAP server side of CoAP-to-HTTP proxies <span class="bcp14">MAY</span> request
 freshness, especially if they have reason to assume that access may require it
 (e.g., because it is a PUT or POST); how this is determined is out of scope for this
 document. The CoAP client side of HTTP-to-CoAP proxies <span class="bcp14">MUST</span> respond
 to Echo challenges itself if the proxy knows from the recent establishing of the
 connection that the HTTP request is fresh. Otherwise, it <span class="bcp14">MUST NOT</span>
 repeat an unsafe request and <span class="bcp14">SHOULD</span> respond with a 503 (Service
 Unavailable) with a Retry-After value of 0 seconds and terminate any underlying
 Keep-Alive connection. If
 the HTTP request arrived in early data, the proxy <span class="bcp14">SHOULD</span> use a 425
 (Too Early) response instead (see <span>[<a href="#RFC8470" class="xref">RFC8470</a>]</span>). The
 proxy <span class="bcp14">MAY</span> also use other mechanisms to establish freshness of the
 HTTP request that are not specified here.<a href="#section-2.3-15" class="pilcrow">¶</a></p>
</section>
</div>
<div id="echo-app">
<section id="section-2.4">
        <h3 id="name-applications-of-the-echo-op">
<a href="#section-2.4" class="section-number selfRef">2.4. </a><a href="#name-applications-of-the-echo-op" class="section-name selfRef">Applications of the Echo Option</a>
        </h3>
<p id="section-2.4-1">Unless otherwise noted, all these applications require a security protocol to be
 used and the Echo option to be protected by it.<a href="#section-2.4-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-2.4-2">
          <li id="section-2.4-2.1">
            <p id="section-2.4-2.1.1">Actuation requests often require freshness guarantees to avoid accidental or
     malicious delayed actuator actions. In general, all unsafe methods (e.g.,
     POST, PUT, and DELETE) may require freshness guarantees for secure operation.<a href="#section-2.4-2.1.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2.4-2.1.2.1">The same Echo option value may be used for multiple actuation requests
       to the
       same server, as long as the total time since the Echo option value was
       generated is below the freshness threshold.<a href="#section-2.4-2.1.2.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-2.4-2.1.2.2">For actuator applications with low delay tolerance, to avoid additional
       round trips for multiple requests in rapid sequence, the server may send
       preemptive Echo option values in successful requests, irrespectively of
       whether or not the
       request contained an Echo option. The client then uses the Echo option
       with the new value in the next actuation request, and the server compares the
       receive time accordingly.<a href="#section-2.4-2.1.2.2" class="pilcrow">¶</a>
</li>
            </ul>
</li>
          <li id="section-2.4-2.2">
            <p id="section-2.4-2.2.1">A server may use the Echo option to synchronize properties (such as state or
     time) with a requesting client. A server <span class="bcp14">MUST NOT</span> synchronize a
     property with a client that is not the authority of the property being
     synchronized. For example, if access to a server resource is dependent on time,
     then the server <span class="bcp14">MUST NOT</span> synchronize time with a client
     requesting access unless the client is a time authority for the server.<a href="#section-2.4-2.2.1" class="pilcrow">¶</a></p>
<p id="section-2.4-2.2.2">Note that the state to be synchronized is not carried inside the Echo option.
     Any explicit state information needs to be carried along in the messages the
     Echo option value is sent in; the Echo mechanism only provides a partial order
     on the messages' processing.<a href="#section-2.4-2.2.2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2.4-2.2.3.1">If a server reboots during operation, it may need to synchronize
       state or
       time before continuing the interaction. For example, with OSCORE, it is
       possible to reuse a partly persistently stored security context by
       synchronizing the Partial IV (sequence number) using the Echo option, as
       specified in <span><a href="https://www.rfc-editor.org/rfc/rfc8613#section-7.5" class="relref">Section 7.5</a> of [<a href="#RFC8613" class="xref">RFC8613</a>]</span>.<a href="#section-2.4-2.2.3.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-2.4-2.2.3.2">A device joining a CoAP group communication <span>[<a href="#I-D.ietf-core-groupcomm-bis" class="xref">GROUP-COAP</a>]</span> protected with OSCORE
       <span>[<a href="#I-D.ietf-core-oscore-groupcomm" class="xref">GROUP-OSCORE</a>]</span> may be
       required to initially synchronize its replay window state with a client by
       using the Echo option in a unicast response to a multicast request. The
       client receiving the response with the Echo option includes the Echo option
       value in a subsequent unicast request to the responding server.<a href="#section-2.4-2.2.3.2" class="pilcrow">¶</a>
</li>
            </ul>
</li>
          <li id="section-2.4-2.3">
            <p id="section-2.4-2.3.1">An attacker can perform a denial-of-service attack by putting a victim's
     address in the source address of a CoAP request and sending the request to a
     resource with a large amplification factor. The amplification factor is the
     ratio between the size of the request and the total size of the response(s) to
     that request. A server that provides a large amplification factor to an
     unauthenticated peer <span class="bcp14">SHOULD</span> mitigate amplification attacks, as
     described in <span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-11.3" class="relref">Section 11.3</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span>. One way
     to mitigate such attacks is for the server to respond to the alleged source
     address of the request with an Echo option in a short response message (e.g.,
     4.01 (Unauthorized)), thereby requesting the client to verify its source
     address. This
     needs to be done only once per endpoint and limits the range of potential
     victims from the general Internet to endpoints that have been previously in
     contact with the server. For this application, the Echo option can be used in
     messages that are not integrity protected, for example, during discovery. (This
     is formally recommended in <a href="#ampl-mit" class="xref">Section 2.6</a>.)<a href="#section-2.4-2.3.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2.4-2.3.2.1">In the presence of a proxy, a server will not be able to distinguish
       different origin client endpoints, i.e., the client from which a request
       originates. Following from the recommendation above, a
       proxy that provides a large amplification factor to unauthenticated peers
       <span class="bcp14">SHOULD</span> mitigate amplification attacks. The proxy
       <span class="bcp14">SHOULD</span> use the Echo option to verify origin reachability, as
       described in
       <a href="#echo-proc" class="xref">Section 2.3</a>. The proxy <span class="bcp14">MAY</span>
       forward safe requests immediately to have a cached result available when the
       client's repeated request arrives.<a href="#section-2.4-2.3.2.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-2.4-2.3.2.2">
                <p id="section-2.4-2.3.2.2.1">Amplification mitigation is a trade-off between giving leverage to an
 attacker and causing overhead. An amplification factor of 3 (i.e., don't
 send more than three times the number of bytes received until the peer's
 address is confirmed) is considered acceptable for unconstrained
 applications in <span>[<a href="#RFC9000" class="xref">RFC9000</a>], <a href="https://www.rfc-editor.org/rfc/rfc9000#section-8" class="relref">Section 8</a></span>.<a href="#section-2.4-2.3.2.2.1" class="pilcrow">¶</a></p>
<p id="section-2.4-2.3.2.2.2">When that limit is applied and no further context is available, a safe
 default is sending initial responses no larger than 136 bytes in CoAP
 serialization. (The number is assuming Ethernet, IP, and UDP headers of
 14, 40, and 8 bytes, respectively, with 4 bytes added for the CoAP header.
 Triple that minus the
 non-CoAP headers gives the 136 bytes.) Given the token also takes up space
 in the request, responding with 132 bytes after the token is safe as
 well.<a href="#section-2.4-2.3.2.2.2" class="pilcrow">¶</a></p>
</li>
              <li class="normal" id="section-2.4-2.3.2.3">When an Echo response is sent to mitigate amplification, it
       <span class="bcp14">MUST</span> be sent as a piggybacked or Non-confirmable response,
       never as a separate one (which would cause amplification due to
       retransmission).<a href="#section-2.4-2.3.2.3" class="pilcrow">¶</a>
</li>
            </ul>
</li>
          <li id="section-2.4-2.4">A server may want to use the request freshness provided by the Echo option
   to verify the aliveness of a client. Note that, in a deployment with hop-by-hop
   security and proxies, the server can only verify aliveness of the closest
   proxy.<a href="#section-2.4-2.4" class="pilcrow">¶</a>
</li>
        </ol>
</section>
</div>
<div id="characterization-of-echo-applications">
<section id="section-2.5">
        <h3 id="name-characterization-of-echo-ap">
<a href="#section-2.5" class="section-number selfRef">2.5. </a><a href="#name-characterization-of-echo-ap" class="section-name selfRef">Characterization of Echo Applications</a>
        </h3>
<p id="section-2.5-1">Use cases for the Echo option can be characterized by several criteria that help
 determine the required properties of the Echo option value. These criteria apply
 both to those listed in <a href="#echo-app" class="xref">Section 2.4</a> and any novel
 applications. They provide rationale for the statements in the former and guidance
 for the latter.<a href="#section-2.5-1" class="pilcrow">¶</a></p>
<div id="time-versus-event-based-freshness">
<section id="section-2.5.1">
          <h4 id="name-time-based-versus-event-bas">
<a href="#section-2.5.1" class="section-number selfRef">2.5.1. </a><a href="#name-time-based-versus-event-bas" class="section-name selfRef">Time-Based versus Event-Based Freshness</a>
          </h4>
<p id="section-2.5.1-1">The property a client demonstrates by sending an Echo option value is that the
   request was sent after a certain point in time or after some event happened on
   the server.<a href="#section-2.5.1-1" class="pilcrow">¶</a></p>
<p id="section-2.5.1-2">When events are counted, they form something that can be used as a monotonic
   but very non-uniform time line. With highly regular events and low-resolution
   time, the distinction between time-based and event-based freshness can be blurred:
   "no longer than a month ago" is similar to "since the last full moon".<a href="#section-2.5.1-2" class="pilcrow">¶</a></p>
<p id="section-2.5.1-3">In an extreme form of event-based freshness,
   the server can place an event whenever an Echo option value is used.
   This makes the Echo option value effectively single use.<a href="#section-2.5.1-3" class="pilcrow">¶</a></p>
<p id="section-2.5.1-4">Event-based and time-based freshness can be combined in a single Echo option
   value,
   e.g., by encrypting a timestamp with a key that changes with every event
   to obtain semantics in the style of "usable once but only for 5 minutes".<a href="#section-2.5.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="source-of-truth">
<section id="section-2.5.2">
          <h4 id="name-authority-over-used-informa">
<a href="#section-2.5.2" class="section-number selfRef">2.5.2. </a><a href="#name-authority-over-used-informa" class="section-name selfRef">Authority over Used Information</a>
          </h4>
<p id="section-2.5.2-1">Information conveyed to the server in the request Echo option value has
   different
   authority depending on the application. Understanding who or what is the
   authoritative source of that information helps the server implementor decide the
   necessary protection of the Echo option value.<a href="#section-2.5.2-1" class="pilcrow">¶</a></p>
<p id="section-2.5.2-2">If all that is conveyed to the server is information that the client is
   authorized to provide arbitrarily (which is another way of saying that the
   server has to trust the client on whatever the Echo option is being used for),
   then the server can issue Echo option values that do not need to be protected on
   their own. They still need to be covered by the security protocol that covers
   the rest of the message, but the Echo option value can be just short enough to
   be unique between this server and client.<a href="#section-2.5.2-2" class="pilcrow">¶</a></p>
<p id="section-2.5.2-3">For example, the client's OSCORE Sender Sequence Number (as used in <span>[<a href="#RFC8613" class="xref">RFC8613</a>], <a href="https://www.rfc-editor.org/rfc/rfc8613#appendix-B.1.2" class="relref">Appendix B.1.2</a></span>) is such information.<a href="#section-2.5.2-3" class="pilcrow">¶</a></p>
<p id="section-2.5.2-4">In most other cases, there is information conveyed for which the server is the
   authority ("the request must not be older than five minutes" is counted on the
   server's clock, not the client's) or which even involve the network (as when
   performing amplification mitigation). In these cases, the Echo option value
   itself needs
   to be protected against forgery by the client, e.g., by using a sufficiently
   large, random value or a MAC, as described in <a href="#echo-state" class="xref">Appendix A</a>, items 1 and 2.<a href="#section-2.5.2-4" class="pilcrow">¶</a></p>
<p id="section-2.5.2-5">For some applications, the server may be able to trust the client to also act
   as the authority (e.g., when using time-based freshness purely to mitigate request
   delay attacks); these need careful case-by-case evaluation.<a href="#section-2.5.2-5" class="pilcrow">¶</a></p>
<p id="section-2.5.2-6">To issue Echo option values without integrity protection of its own, the server needs to trust the
   client to never produce requests with attacker-controlled Echo option values.
   The provisions of <a href="#echo-proc" class="xref">Section 2.3</a> (saying that an
   Echo option value may only be sent as received from the same server) allow that.
   The requirement stated there for the client to treat the Echo option value as
   opaque
   holds for these applications like for all others.<a href="#section-2.5.2-6" class="pilcrow">¶</a></p>
<p id="section-2.5.2-7">When the client is the sole authority over the synchronized property,
   the server can still use time or events to issue new Echo option values.
   Then, the request's Echo option value not so much proves the indicated freshness
   to the
   server but reflects the client's intention to indicate reception of responses
   containing that value when sending the later ones.<a href="#section-2.5.2-7" class="pilcrow">¶</a></p>
<p id="section-2.5.2-8">Note that a single Echo option value can be used for multiple purposes (e.g.,
   to both get
   the sequence number information and perform amplification mitigation). In
   this case, the stricter protection requirements apply.<a href="#section-2.5.2-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="protection-by-a-security-protocol">
<section id="section-2.5.3">
          <h4 id="name-protection-by-a-security-pr">
<a href="#section-2.5.3" class="section-number selfRef">2.5.3. </a><a href="#name-protection-by-a-security-pr" class="section-name selfRef">Protection by a Security Protocol</a>
          </h4>
<p id="section-2.5.3-1">For meaningful results, the Echo option needs to be used in combination with a
   security protocol in almost all applications.<a href="#section-2.5.3-1" class="pilcrow">¶</a></p>
<p id="section-2.5.3-2">When the information extracted by the server is only about a part of the
   system outside of any security protocol, then the Echo option can also be used
   without a security protocol (in case of OSCORE, as an Outer option).<a href="#section-2.5.3-2" class="pilcrow">¶</a></p>
<p id="section-2.5.3-3">The only known application satisfying this requirement is network address
   reachability, where unprotected Echo option values are used both by servers
   (e.g., during
   setup of a security context) and proxies (which do not necessarily have a
   security association with their clients) for amplification mitigation.<a href="#section-2.5.3-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="ampl-mit">
<section id="section-2.6">
        <h3 id="name-updated-amplification-mitig">
<a href="#section-2.6" class="section-number selfRef">2.6. </a><a href="#name-updated-amplification-mitig" class="section-name selfRef">Updated Amplification Mitigation Requirements for Servers</a>
        </h3>
<p id="section-2.6-1">This section updates the amplification mitigation requirements for servers in
 <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span> to recommend the use of the Echo option to
 mitigate amplification attacks. The requirements for clients are not updated. <span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-11.3" class="relref">Section 11.3</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span> is updated by adding the
 following text:<a href="#section-2.6-1" class="pilcrow">¶</a></p>
<blockquote id="section-2.6-2">A CoAP server <span class="bcp14">SHOULD</span> mitigate potential amplification
 attacks by responding to unauthenticated clients with 4.01 (Unauthorized) including
 an Echo option, as described in item 3 in <a href="#echo-app" class="xref">Section 2.4</a> of RFC 9175.<a href="#section-2.6-2" class="pilcrow">¶</a>
</blockquote>
</section>
</div>
</section>
</div>
<div id="request-tag">
<section id="section-3">
      <h2 id="name-protecting-message-bodies-u">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-protecting-message-bodies-u" class="section-name selfRef">Protecting Message Bodies Using Request Tags</a>
      </h2>
<div id="body-int">
<section id="section-3.1">
        <h3 id="name-fragmented-message-body-int">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-fragmented-message-body-int" class="section-name selfRef">Fragmented Message Body Integrity</a>
        </h3>
<p id="section-3.1-1">CoAP was designed to work over unreliable transports, such as UDP, and includes
 a lightweight reliability feature to handle messages that are lost or arrive out
 of order. In order for a security protocol to support CoAP operations over
 unreliable transports, it must allow out-of-order delivery of messages.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.1-2">The block-wise transfer mechanism <span>[<a href="#RFC7959" class="xref">RFC7959</a>]</span>
 extends CoAP by defining the transfer of a large resource representation (CoAP
 message body) as a sequence of blocks (CoAP message payloads). The mechanism uses a
 pair of CoAP options, Block1 and Block2, pertaining to the request and response
 payload, respectively. The block-wise functionality does not support the detection
 of interchanged blocks between different message bodies to the same resource having
 the same block number. This remains true even when CoAP is used together with a
 security protocol (such as DTLS or OSCORE) within the replay window <span>[<a href="#I-D.mattsson-core-coap-attacks" class="xref">COAP-ATTACKS</a>]</span>, which is a
 vulnerability of the block-wise functionality of CoAP <span>[<a href="#RFC7959" class="xref">RFC7959</a>]</span>.<a href="#section-3.1-2" class="pilcrow">¶</a></p>
<p id="section-3.1-3">A straightforward mitigation of mixing up blocks from different messages is to
 use unique identifiers for different message bodies, which would provide equivalent
 protection to the case where the complete body fits into a single payload. The ETag
 option <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span>, set by the CoAP server,
 identifies a response body fragmented using the Block2 option.<a href="#section-3.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="the-request-tag-option">
<section id="section-3.2">
        <h3 id="name-the-request-tag-option">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-the-request-tag-option" class="section-name selfRef">The Request-Tag Option</a>
        </h3>
<p id="section-3.2-1">This document defines the Request-Tag option for identifying request bodies,
 similar to ETag, but ephemeral and set by the CoAP client. The Request-Tag is
 intended for use as a short-lived identifier for keeping apart distinct block-wise
 request operations on one resource from one client, addressing the issue described
 in <a href="#body-int" class="xref">Section 3.1</a>. It enables the receiving server to
 reliably assemble request payloads (blocks) to their message bodies and, if it
 chooses to support it, to reliably process simultaneous block-wise request
 operations on a single resource. The requests must be integrity protected if they
 should protect against interchange of blocks between different message bodies. The
 Request-Tag option is mainly used in requests that carry the Block1 option and in
 Block2 requests following these.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<p id="section-3.2-2">In essence, it is an implementation of the "proxy-safe elective option" used
 just to "vary the cache key", as suggested in <span>[<a href="#RFC7959" class="xref">RFC7959</a>], <a href="https://www.rfc-editor.org/rfc/rfc7959#section-2.4" class="relref">Section 2.4</a></span>.<a href="#section-3.2-2" class="pilcrow">¶</a></p>
<div id="req-tag-format">
<section id="section-3.2.1">
          <h4 id="name-request-tag-option-format">
<a href="#section-3.2.1" class="section-number selfRef">3.2.1. </a><a href="#name-request-tag-option-format" class="section-name selfRef">Request-Tag Option Format</a>
          </h4>
<p id="section-3.2.1-1">The Request-Tag option is elective, safe to forward, repeatable, and
   part of the cache key (see <a href="#req-tag-table" class="xref">Table 2</a>, which
   extends Table 4 of <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span>).<a href="#section-3.2.1-1" class="pilcrow">¶</a></p>
<span id="name-request-tag-option-summary"></span><div id="req-tag-table">
<table class="left" id="table-2">
            <caption>
<a href="#table-2" class="selfRef">Table 2</a>:
<a href="#name-request-tag-option-summary" class="selfRef">Request-Tag Option Summary</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">No.</th>
                <th class="text-left" rowspan="1" colspan="1">C</th>
                <th class="text-left" rowspan="1" colspan="1">U</th>
                <th class="text-left" rowspan="1" colspan="1">N</th>
                <th class="text-left" rowspan="1" colspan="1">R</th>
                <th class="text-left" rowspan="1" colspan="1">Name</th>
                <th class="text-left" rowspan="1" colspan="1">Format</th>
                <th class="text-left" rowspan="1" colspan="1">Length</th>
                <th class="text-left" rowspan="1" colspan="1">Default</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">292</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
                <td class="text-left" rowspan="1" colspan="1"></td>
                <td class="text-left" rowspan="1" colspan="1"></td>
                <td class="text-left" rowspan="1" colspan="1">x</td>
                <td class="text-left" rowspan="1" colspan="1">Request-Tag</td>
                <td class="text-left" rowspan="1" colspan="1">opaque</td>
                <td class="text-left" rowspan="1" colspan="1">0-8</td>
                <td class="text-left" rowspan="1" colspan="1">(none)</td>
              </tr>
            </tbody>
          </table>
</div>
<p id="section-3.2.1-3">C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable<a href="#section-3.2.1-3" class="pilcrow">¶</a></p>
<p id="section-3.2.1-4">Request-Tag, like the Block options, is both a class E and a class U option in
   terms of OSCORE processing (see <span><a href="https://www.rfc-editor.org/rfc/rfc8613#section-4.1" class="relref">Section 4.1</a> of [<a href="#RFC8613" class="xref">RFC8613</a>]</span>). The Request-Tag <span class="bcp14">MAY</span> be an Inner or Outer option.
   It influences the Inner or Outer block operations, respectively. The Inner and
   Outer values are therefore independent of each other. The Inner option is
   encrypted and integrity protected between the client and server, and it provides
   message
   body identification in case of end-to-end fragmentation of requests. The Outer
   option is visible to proxies and labels message bodies in case of hop-by-hop
   fragmentation of requests.<a href="#section-3.2.1-4" class="pilcrow">¶</a></p>
<p id="section-3.2.1-5">The Request-Tag option is only used in the request messages of block-wise
   operations.<a href="#section-3.2.1-5" class="pilcrow">¶</a></p>
<p id="section-3.2.1-6">The Request-Tag mechanism can be applied independently on the server and
   client sides of CoAP-to-CoAP proxies, as are the Block options. However, given it
   is safe to forward, a proxy is free to just forward it when processing an
   operation.
   CoAP-to-HTTP proxies and HTTP-to-CoAP proxies can use Request-Tag on their CoAP
   sides; it is not applicable to HTTP requests.<a href="#section-3.2.1-6" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="request-tag-processing">
<section id="section-3.3">
        <h3 id="name-request-tag-processing-by-s">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-request-tag-processing-by-s" class="section-name selfRef">Request-Tag Processing by Servers</a>
        </h3>
<p id="section-3.3-1">The Request-Tag option does not require any particular processing on the server
 side outside of the processing already necessary for any unknown elective
 proxy-safe cache-key option. The option varies the properties that distinguish
 block-wise operations (which includes all options except Block1, Block2, and all
 operations that are elective NoCacheKey). Thus, the server cannot treat messages
 with a different list of Request-Tag options as belonging to the same operation.<a href="#section-3.3-1" class="pilcrow">¶</a></p>
<p id="section-3.3-2">To keep utilizing the cache, a server (including proxies) <span class="bcp14">MAY</span>
 discard the Request-Tag option from an assembled block-wise request when consulting
 its cache, as the option relates to the operation on the wire and not its semantics.
 For example, a FETCH request with the same body as an older one can be served from
 the cache if the older's Max-Age has not expired yet, even if the second operation
 uses a Request-Tag and the first did not. (This is similar to the situation about
 ETag in that it is formally part of the cache key, but implementations that are
 aware of its meaning can cache more efficiently (see <span>[<a href="#RFC7252" class="xref">RFC7252</a>], <a href="https://www.rfc-editor.org/rfc/rfc7252#section-5.4.2" class="relref">Section 5.4.2</a></span>).<a href="#section-3.3-2" class="pilcrow">¶</a></p>
<p id="section-3.3-3">A server receiving a Request-Tag <span class="bcp14">MUST</span> treat it as opaque and make
 no assumptions about its content or structure.<a href="#section-3.3-3" class="pilcrow">¶</a></p>
<p id="section-3.3-4">Two messages carrying the same Request-Tag is a necessary but not sufficient
 condition for being part of the same operation. For one, a server may still treat
 them as independent messages when it sends 2.01 (Created) and 2.04 (Changed)
 responses for every block.
 Also, a client that lost interest in an old operation but wants to start over can
 overwrite the server's old state with a new initial (num=0) Block1 request and the
 same Request-Tag under some circumstances. Likewise, that results in the new
 message not being part of the old operation.<a href="#section-3.3-4" class="pilcrow">¶</a></p>
<p id="section-3.3-5">As it has always been, a server that can only serve a limited number of
 block-wise operations at the same time can delay the start of the operation by
 replying with 5.03 (Service Unavailable) and a Max-Age indicating how long it
 expects the existing operation to go on, or it can forget about the state
 established with the older operation and respond with 4.08 (Request Entity
 Incomplete) to later blocks on the first operation.<a href="#section-3.3-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="setting-the-request-tag">
<section id="section-3.4">
        <h3 id="name-setting-the-request-tag">
<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-setting-the-request-tag" class="section-name selfRef">Setting the Request-Tag</a>
        </h3>
<p id="section-3.4-1">For each separate block-wise request operation, the client can choose a
 Request-Tag value or choose not to set a Request-Tag. It needs to be set to the
 same value (or unset) in all messages belonging to the same operation; otherwise,
 they are treated as separate operations by the server.<a href="#section-3.4-1" class="pilcrow">¶</a></p>
<p id="section-3.4-2">Starting a request operation matchable to a previous operation and even using
 the same Request-Tag value is called "request tag recycling". The absence of a
 Request-Tag option is viewed as a value distinct from all values with a single
 Request-Tag option set; starting a request operation matchable to a previous
 operation where neither has a Request-Tag option therefore constitutes request tag
 recycling just as well (also called "recycling the absent option").<a href="#section-3.4-2" class="pilcrow">¶</a></p>
<p id="section-3.4-3">Clients that use Request-Tag for a particular purpose (like in <a href="#req-tag-applications" class="xref">Section 3.5</a>) <span class="bcp14">MUST NOT</span> recycle a
 request tag unless the first operation has concluded. What constitutes a
 concluded
 operation depends on the purpose and is defined accordingly; see examples in <a href="#req-tag-applications" class="xref">Section 3.5</a>.<a href="#section-3.4-3" class="pilcrow">¶</a></p>
<p id="section-3.4-4">When Block1 and Block2 are combined in an operation, the Request-Tag of the
 Block1 phase is set in the Block2 phase as well; otherwise, the request would
 have a different set of options and would not be recognized any more.<a href="#section-3.4-4" class="pilcrow">¶</a></p>
<p id="section-3.4-5">Clients are encouraged to generate compact messages. This means sending messages
 without Request-Tag options whenever possible and using short values when the
 absent option cannot be recycled.<a href="#section-3.4-5" class="pilcrow">¶</a></p>
<p id="section-3.4-6">Note that Request-Tag options can be present in request messages that carry no
 Block options (for example, because a proxy unaware of Request-Tag reassembled them).<a href="#section-3.4-6" class="pilcrow">¶</a></p>
<p id="section-3.4-7">The Request-Tag option <span class="bcp14">MUST NOT</span> be present in response
 messages.<a href="#section-3.4-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="req-tag-applications">
<section id="section-3.5">
        <h3 id="name-applications-of-the-request">
<a href="#section-3.5" class="section-number selfRef">3.5. </a><a href="#name-applications-of-the-request" class="section-name selfRef">Applications of the Request-Tag Option</a>
        </h3>
<div id="body-integrity">
<section id="section-3.5.1">
          <h4 id="name-body-integrity-based-on-pay">
<a href="#section-3.5.1" class="section-number selfRef">3.5.1. </a><a href="#name-body-integrity-based-on-pay" class="section-name selfRef">Body Integrity Based on Payload Integrity</a>
          </h4>
<p id="section-3.5.1-1">When a client fragments a request body into multiple message payloads, even if
   the individual messages are integrity protected, it is still possible for an
   attacker to maliciously replace a later operation's blocks with an earlier
   operation's blocks (see <span><a href="https://datatracker.ietf.org/doc/html/draft-mattsson-core-coap-attacks-01#section-2.5" class="relref">Section 2.5</a> of [<a href="#I-D.mattsson-core-coap-attacks" class="xref">COAP-ATTACKS</a>]</span>). Therefore, the integrity protection of each
   block does not extend to the operation's request body.<a href="#section-3.5.1-1" class="pilcrow">¶</a></p>
<p id="section-3.5.1-2">In order to gain that protection, use the Request-Tag mechanism as follows:<a href="#section-3.5.1-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.5.1-3.1">The individual exchanges <span class="bcp14">MUST</span> be integrity protected
     end to end between the client and server.<a href="#section-3.5.1-3.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.5.1-3.2">
              <p id="section-3.5.1-3.2.1">The client <span class="bcp14">MUST NOT</span> recycle a request tag in a new
       operation unless the previous operation matchable to the new one has concluded.<a href="#section-3.5.1-3.2.1" class="pilcrow">¶</a></p>
<p id="section-3.5.1-3.2.2">If any future security mechanisms allow a block-wise transfer to continue
       after an endpoint's details (like the IP address) have changed, then
       the client <span class="bcp14">MUST</span> consider messages matchable if they were sent
       to any endpoint address using the new operation's security
       context.<a href="#section-3.5.1-3.2.2" class="pilcrow">¶</a></p>
</li>
            <li class="normal" id="section-3.5.1-3.3">
              <p id="section-3.5.1-3.3.1">The client <span class="bcp14">MUST NOT</span> regard a block-wise request operation
       as concluded unless all of the messages the client has sent in the operation
       would be regarded as invalid by the server if they were replayed.<a href="#section-3.5.1-3.3.1" class="pilcrow">¶</a></p>
<p id="section-3.5.1-3.3.2">When security services are provided by OSCORE, these confirmations
       typically result either from the client receiving an OSCORE response message
       matching the request (an empty Acknowledgement (ACK) is insufficient) or
       because the message's
       sequence number is old enough to be outside the server's receive window.<a href="#section-3.5.1-3.3.2" class="pilcrow">¶</a></p>
<p id="section-3.5.1-3.3.3">When security services are provided by DTLS, this can only be confirmed if
       there was no CoAP retransmission of the request, the request was responded
       to, and the server uses replay protection.<a href="#section-3.5.1-3.3.3" class="pilcrow">¶</a></p>
</li>
          </ul>
<p id="section-3.5.1-4">Authors of other documents (e.g., applications of <span>[<a href="#RFC8613" class="xref">RFC8613</a>]</span>) are invited to mandate this subsection's behavior for clients
   that execute block-wise interactions over secured transports. In this way, the
   server can rely on a conforming client to set the Request-Tag option when
   required and thereby have confidence in the integrity of the assembled body.<a href="#section-3.5.1-4" class="pilcrow">¶</a></p>
<p id="section-3.5.1-5">Note that this mechanism is implicitly implemented when the security layer
   guarantees ordered delivery (e.g., CoAP over TLS <span>[<a href="#RFC8323" class="xref">RFC8323</a>]</span>). This is because, with each message, any earlier message
   cannot be replayed any more, so the client never needs to set the Request-Tag
   option unless it wants to perform concurrent operations.<a href="#section-3.5.1-5" class="pilcrow">¶</a></p>
<p id="section-3.5.1-6">Body integrity only makes sense in applications that have stateful block-wise
   transfers. On applications where all the state is in the application (e.g.,
   because rather than POSTing a large representation to a collection in a stateful
   block-wise transfer, a collection item is created first, then written to once and
   available when written completely), clients need not concern themselves with body
   integrity and thus the Request-Tag.<a href="#section-3.5.1-6" class="pilcrow">¶</a></p>
<p id="section-3.5.1-7">Body integrity is largely independent from replay protection. When no replay
   protection is available (it is optional in DTLS), a full block-wise operation may
   be replayed, but, by adhering to the above, no operations will be mixed up.
   The only link between body integrity and replay protection is that, without replay
   protection, recycling is not possible.<a href="#section-3.5.1-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="multiple-concurrent-block-wise-operations">
<section id="section-3.5.2">
          <h4 id="name-multiple-concurrent-block-w">
<a href="#section-3.5.2" class="section-number selfRef">3.5.2. </a><a href="#name-multiple-concurrent-block-w" class="section-name selfRef">Multiple Concurrent Block-Wise Operations</a>
          </h4>
<p id="section-3.5.2-1">CoAP clients, especially CoAP proxies, may initiate a block-wise request
   operation to a resource, to which a previous one is already in progress, which
   the new request should not cancel. A CoAP proxy would be in such a situation when
   it forwards operations with the same cache-key options but possibly different
   payloads.<a href="#section-3.5.2-1" class="pilcrow">¶</a></p>
<p id="section-3.5.2-2">For those cases, Request-Tag is the proxy-safe elective option suggested in
   the last paragraph of
   <span><a href="https://www.rfc-editor.org/rfc/rfc7959#section-2.4" class="relref">Section 2.4</a> of [<a href="#RFC7959" class="xref">RFC7959</a>]</span>.<a href="#section-3.5.2-2" class="pilcrow">¶</a></p>
<p id="section-3.5.2-3">When initializing a new block-wise operation, a client has to look at other
   active operations:<a href="#section-3.5.2-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.5.2-4.1">If any of them is matchable to the new one, and the client neither wants to
     cancel the old one nor postpone the new one, it can pick a Request-Tag value
     (including the absent option) that is not in use by the other matchable
     operations for the new operation.<a href="#section-3.5.2-4.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.5.2-4.2">Otherwise, it can start the new operation without setting the Request-Tag
     option on it.<a href="#section-3.5.2-4.2" class="pilcrow">¶</a>
</li>
          </ul>
</section>
</div>
<div id="simpleproxy">
<section id="section-3.5.3">
          <h4 id="name-simplified-block-wise-handl">
<a href="#section-3.5.3" class="section-number selfRef">3.5.3. </a><a href="#name-simplified-block-wise-handl" class="section-name selfRef">Simplified Block-Wise Handling for Constrained Proxies</a>
          </h4>
<p id="section-3.5.3-1">The Block options were defined to be unsafe to forward because a proxy that
   would forward blocks as plain messages would risk mixing up clients' requests.<a href="#section-3.5.3-1" class="pilcrow">¶</a></p>
<p id="section-3.5.3-2">In some cases, for example, when forwarding block-wise request operations,
   appending a Request-Tag value unique to the client can satisfy the requirements
   on the proxy that come from the presence of a Block option.<a href="#section-3.5.3-2" class="pilcrow">¶</a></p>
<p id="section-3.5.3-3">This is particularly useful to proxies that strive for stateless operations,
   as described in <span>[<a href="#RFC8974" class="xref">RFC8974</a>], <a href="https://www.rfc-editor.org/rfc/rfc8974#section-4" class="relref">Section 4</a></span>.<a href="#section-3.5.3-3" class="pilcrow">¶</a></p>
<p id="section-3.5.3-4">The precise classification of cases in which such a Request-Tag option is
   sufficient is not trivial, especially when both request and response body are
   fragmented, and is out of scope for this document.<a href="#section-3.5.3-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="rationale-for-the-option-properties">
<section id="section-3.6">
        <h3 id="name-rationale-for-the-option-pr">
<a href="#section-3.6" class="section-number selfRef">3.6. </a><a href="#name-rationale-for-the-option-pr" class="section-name selfRef">Rationale for the Option Properties</a>
        </h3>
<p id="section-3.6-1">The Request-Tag option can be elective, because to servers unaware of the
 Request-Tag option, operations with differing request tags will not be
 matchable.<a href="#section-3.6-1" class="pilcrow">¶</a></p>
<p id="section-3.6-2">The Request-Tag option can be safe to forward but part of the cache key, because
 proxies unaware of the Request-Tag option will consider operations with differing
 request tags unmatchable but can still forward them.<a href="#section-3.6-2" class="pilcrow">¶</a></p>
<p id="section-3.6-3">The Request-Tag option is repeatable because this easily allows several cascaded
 stateless proxies to each put in an origin address. They can perform the steps of
 <a href="#simpleproxy" class="xref">Section 3.5.3</a> without the need to create an option
 value that is the concatenation of the received option and their own value
 and can simply add a new Request-Tag option unconditionally.<a href="#section-3.6-3" class="pilcrow">¶</a></p>
<p id="section-3.6-4">In draft versions of this document, the Request-Tag option used to be critical
 and unsafe to forward. That design was based on an erroneous understanding of which
 blocks could be composed according to <span>[<a href="#RFC7959" class="xref">RFC7959</a>]</span>.<a href="#section-3.6-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="rationale-for-introducing-the-option">
<section id="section-3.7">
        <h3 id="name-rationale-for-introducing-t">
<a href="#section-3.7" class="section-number selfRef">3.7. </a><a href="#name-rationale-for-introducing-t" class="section-name selfRef">Rationale for Introducing the Option</a>
        </h3>
<p id="section-3.7-1">An alternative that was considered to the Request-Tag option for coping with the
 problem of fragmented message body integrity (<a href="#body-integrity" class="xref">Section 3.5.1</a>) was to update <span>[<a href="#RFC7959" class="xref">RFC7959</a>]</span> to say
 that blocks could only be assembled if their fragments' order corresponded to the
 sequence numbers.<a href="#section-3.7-1" class="pilcrow">¶</a></p>
<p id="section-3.7-2">That approach would have been difficult to roll out reliably on DTLS,
 where many implementations do not expose sequence numbers, and would still not
 prevent attacks like in <span><a href="https://datatracker.ietf.org/doc/html/draft-mattsson-core-coap-attacks-01#section-2.5.2" class="relref">Section 2.5.2</a> of [<a href="#I-D.mattsson-core-coap-attacks" class="xref">COAP-ATTACKS</a>]</span>.<a href="#section-3.7-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="etag">
<section id="section-3.8">
        <h3 id="name-block2-and-etag-processing">
<a href="#section-3.8" class="section-number selfRef">3.8. </a><a href="#name-block2-and-etag-processing" class="section-name selfRef">Block2 and ETag Processing</a>
        </h3>
<p id="section-3.8-1">The same security properties as in <a href="#body-integrity" class="xref">Section 3.5.1</a> can be obtained for block-wise response operations. The threat
 model here does not depend on an attacker; a client can construct a wrong
 representation by assembling it from blocks from different resource states. That
 can happen when a resource is modified during a transfer or when some blocks are
 still valid in the client's cache.<a href="#section-3.8-1" class="pilcrow">¶</a></p>
<p id="section-3.8-2">Rules stating that response body reassembly is conditional on matching ETag
 values are already in place from <span><a href="https://www.rfc-editor.org/rfc/rfc7959#section-2.4" class="relref">Section 2.4</a> of [<a href="#RFC7959" class="xref">RFC7959</a>]</span>.<a href="#section-3.8-2" class="pilcrow">¶</a></p>
<p id="section-3.8-3">To gain protection equivalent to that described in <a href="#body-integrity" class="xref">Section 3.5.1</a>, a server <span class="bcp14">MUST</span> use the Block2 option in
 conjunction with the ETag option (<span>[<a href="#RFC7252" class="xref">RFC7252</a>], <a href="https://www.rfc-editor.org/rfc/rfc7252#section-5.10.6" class="relref">Section 5.10.6</a></span>) and <span class="bcp14">MUST NOT</span> use the same ETag value for
 different representations of a resource.<a href="#section-3.8-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="token">
<section id="section-4">
      <h2 id="name-token-processing-for-secure">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-token-processing-for-secure" class="section-name selfRef">Token Processing for Secure Request-Response Binding</a>
      </h2>
<div id="req-resp-bind">
<section id="section-4.1">
        <h3 id="name-request-response-binding">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-request-response-binding" class="section-name selfRef">Request-Response Binding</a>
        </h3>
<p id="section-4.1-1">A fundamental requirement of secure REST operations is that the client can bind
 a response to a particular request. If this is not ensured, a client may
 erroneously associate the wrong response to a request. The wrong response may be an
 old response for the same resource or a response for a completely different
 resource (e.g., see <span><a href="https://datatracker.ietf.org/doc/html/draft-mattsson-core-coap-attacks-01#section-2.3" class="relref">Section 2.3</a> of [<a href="#I-D.mattsson-core-coap-attacks" class="xref">COAP-ATTACKS</a>]</span>). For example, a request for the alarm status "GET /status" may be
 associated to a prior response "on", instead of the correct response "off".<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">In HTTP/1.1, this type of binding is always assured by the ordered and reliable
 delivery, as well as mandating that the server sends responses in the same order
 that the requests were received. The same is not true for CoAP, where the server (or
 an attacker) can return responses in any order and where there can be any number of
 responses to a request (e.g., see <span>[<a href="#RFC7641" class="xref">RFC7641</a>]</span>). In
 CoAP, concurrent requests are differentiated by their Token. Note that the CoAP
 Message ID cannot be used for this purpose since those are typically different for
 the REST request and corresponding response in case of "separate response" (see
 <span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-2.2" class="relref">Section 2.2</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span>).<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<p id="section-4.1-3">CoAP <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span> does not treat the Token as a
 cryptographically important value and does not give stricter guidelines than that
 the Tokens currently "in use" <span class="bcp14">SHOULD</span> (not <span class="bcp14">SHALL</span>) be
 unique. If used with a security protocol not providing bindings between requests
 and responses (e.g., DTLS and TLS), Token reuse may result in situations where a
 client matches a response to the wrong request. Note that mismatches can also
 happen for other reasons than a malicious attacker, e.g., delayed delivery or a
 server sending notifications to an uninterested client.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
<p id="section-4.1-4">A straightforward mitigation is to mandate clients to not reuse Tokens until the
 traffic keys have been replaced. The following section formalizes that.<a href="#section-4.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="updated-token-processing-requirements-for-clients">
<section id="section-4.2">
        <h3 id="name-updated-token-processing-re">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-updated-token-processing-re" class="section-name selfRef">Updated Token Processing Requirements for Clients</a>
        </h3>
<p id="section-4.2-1">As described in <a href="#req-resp-bind" class="xref">Section 4.1</a>, the client must
 be able to verify that a response corresponds to a particular request. This section
 updates the Token processing requirements for clients in <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span> to always assure a cryptographically secure binding of responses
 to requests for secure REST operations like "coaps". The Token processing for
 servers is not updated. Token processing in <span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-5.3.1" class="relref">Section 5.3.1</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span> is updated by adding the following text:<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<blockquote id="section-4.2-2">
          <p id="section-4.2-2.1">When CoAP is used with a security protocol not providing bindings between
 requests and responses, the Tokens have cryptographic importance. The client
 <span class="bcp14">MUST</span> make sure that Tokens are not used in a way so that responses
 risk being associated with the wrong request.<a href="#section-4.2-2.1" class="pilcrow">¶</a></p>
<p id="section-4.2-2.2">One easy way to accomplish this is to implement the Token (or part of the Token)
 as a sequence number, starting at zero for each new or rekeyed secure connection.
 This approach <span class="bcp14">SHOULD</span> be followed.<a href="#section-4.2-2.2" class="pilcrow">¶</a></p>
</blockquote>
</section>
</div>
</section>
</div>
<div id="sec-cons">
<section id="section-5">
      <h2 id="name-security-considerations">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-5-1">The freshness assertion of the Echo option comes from the client reproducing the
      same value of the Echo option in a request as it received in a previous response. If
      the Echo option value is a large random number, then there is a high probability
      that the request is generated after having seen the response. If the Echo option
      value of the response can be guessed, e.g., if based on a small random number or a
      counter (see <a href="#echo-state" class="xref">Appendix A</a>), then it is possible to
      compose a request with the right Echo option value ahead of time. Using guessable
      Echo option values is only permissible in a narrow set of cases described in <a href="#source-of-truth" class="xref">Section 2.5.2</a>. Echo option values <span class="bcp14">MUST</span>
      be set by the CoAP server such that the risk associated with unintended reuse can be
      managed.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">If uniqueness of the Echo option value is based on randomness, then the
      availability of a
      secure pseudorandom number generator and truly random seeds are essential for the
      security of the Echo option. If no true random number generator is available, a truly
      random seed must be provided from an external source. As each pseudorandom number
      must only be used once, an implementation needs to get a new truly random seed after
      reboot or continuously store the state in nonvolatile memory. See <span>[<a href="#RFC8613" class="xref">RFC8613</a>], <a href="https://www.rfc-editor.org/rfc/rfc8613#appendix-B.1.1" class="relref">Appendix B.1.1</a></span> for issues and approaches for
      writing to nonvolatile memory.<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3">A single active Echo option value with 64 (pseudo)random bits gives the same theoretical
      security level as a 64-bit MAC (as used in, e.g., AES_128_CCM_8). If a random unique
      Echo option value is intended, the Echo option value <span class="bcp14">SHOULD</span> contain 64
      (pseudo)random bits that are not predictable for any other party than the server. A
      server <span class="bcp14">MAY</span> use different security levels for different use cases
      (client aliveness, request freshness, state synchronization, network address
      reachability, etc.).<a href="#section-5-3" class="pilcrow">¶</a></p>
<p id="section-5-4">The security provided by the Echo and Request-Tag options depends on the security
      protocol used. CoAP and HTTP proxies require (D)TLS to be terminated at the proxies.
      The proxies are therefore able to manipulate, inject, delete, or reorder options or
      packets. The security claims in such architectures only hold under the assumption
      that all intermediaries are fully trusted and have not been compromised.<a href="#section-5-4" class="pilcrow">¶</a></p>
<p id="section-5-5">Echo option values without the protection of randomness or a MAC are limited to cases
      when the client is the trusted source of all derived properties (as per <a href="#source-of-truth" class="xref">Section 2.5.2</a>). Using them needs per-application
      consideration of both the impact of a malicious client and of implementation errors
      in clients. These Echo option values are the only legitimate case for Echo option
      values shorter
      than four bytes, which are not necessarily secret. They <span class="bcp14">MUST NOT</span> be
      used unless the Echo option values in the request are integrity protected, as per <a href="#echo-proc" class="xref">Section 2.3</a>.<a href="#section-5-5" class="pilcrow">¶</a></p>
<p id="section-5-6">Servers <span class="bcp14">SHOULD</span> use a monotonic clock to generate timestamps and
      compute round-trip times. Use of non-monotonic clocks is not secure, as the server
      will accept expired Echo option values if the clock is moved backward. The server
      will also reject fresh Echo option values if the clock is moved forward.
      Non-monotonic clocks <span class="bcp14">MAY</span> be used as long as they have deviations that
      are acceptable given the freshness requirements. If the deviations from a monotonic
      clock are known, it may be possible to adjust the threshold accordingly.<a href="#section-5-6" class="pilcrow">¶</a></p>
<p id="section-5-7">An attacker may be able to affect the server's system time in various ways, such as
      setting up a fake NTP server or broadcasting false time signals to radio-controlled
      clocks.<a href="#section-5-7" class="pilcrow">¶</a></p>
<p id="section-5-8">For the purpose of generating timestamps for the Echo option, a server
      <span class="bcp14">MAY</span> set
      a timer at reboot and use the time since reboot, choosing the granularity such that
      different requests arrive at different times. Servers <span class="bcp14">MAY</span>
      intermittently reset the timer and <span class="bcp14">MAY</span> generate a random offset
      applied to all timestamps. When resetting the timer, the server <span class="bcp14">MUST</span>
      reject all Echo option values that were created before the reset.<a href="#section-5-8" class="pilcrow">¶</a></p>
<p id="section-5-9">Servers that use the "List of Cached Random Values and Timestamps" method described
      in <a href="#echo-state" class="xref">Appendix A</a> may be vulnerable to resource
      exhaustion attacks. One way to minimize the state is to use the "Integrity-Protected
      Timestamp" method described in <a href="#echo-state" class="xref">Appendix A</a>.<a href="#section-5-9" class="pilcrow">¶</a></p>
<div id="token-reuse">
<section id="section-5.1">
        <h3 id="name-token-reuse">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-token-reuse" class="section-name selfRef">Token Reuse</a>
        </h3>
<p id="section-5.1-1">Reusing Tokens in a way so that responses are guaranteed to not be associated
 with the wrong request is not trivial. The server may process requests in any
 order and send multiple responses to the same request. An attacker may block,
 delay, and reorder messages. The use of a sequence number is therefore recommended
 when CoAP is used with a security protocol that does not provide bindings between
 requests and responses, such as DTLS or TLS.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<p id="section-5.1-2">For a generic response to a Confirmable request over DTLS, binding can only be
 claimed without out-of-band knowledge if:<a href="#section-5.1-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.1-3.1">the original request was never retransmitted and<a href="#section-5.1-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.1-3.2">the response was piggybacked in an Acknowledgement message (as a Confirmable
   or Non-confirmable response may have been transmitted multiple times).<a href="#section-5.1-3.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-5.1-4">If observation was used, the same holds for the registration, all
   reregistrations, and the cancellation.<a href="#section-5.1-4" class="pilcrow">¶</a></p>
<p id="section-5.1-5">(In addition, for observations, any responses using that Token and a DTLS
 sequence number earlier than the cancellation Acknowledgement message need to be
 discarded. This is typically not supported in DTLS implementations.)<a href="#section-5.1-5" class="pilcrow">¶</a></p>
<p id="section-5.1-6">In some setups, Tokens can be reused without the above constraints, as a
 different component in the setup provides the associations:<a href="#section-5.1-6" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.1-7.1">In CoAP over TLS, retransmissions are not handled by the CoAP layer and
   behave like a replay window size of 1. When a client is sending TLS-protected
   requests without Observe to a single server, the client can reuse a Token as soon
   as the previous response with that Token has been received.<a href="#section-5.1-7.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.1-7.2">Requests whose responses are cryptographically bound to the requests (like in
   OSCORE) can reuse Tokens indefinitely.<a href="#section-5.1-7.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-5.1-8">In all other cases, a sequence number approach is <span class="bcp14">RECOMMENDED</span>, as
 per <a href="#token" class="xref">Section 4</a>.<a href="#section-5.1-8" class="pilcrow">¶</a></p>
<p id="section-5.1-9">Tokens that cannot be reused need to be handled appropriately. This could be
 solved by increasing the Token as soon as the currently used Token cannot be
 reused or by keeping a list of all Tokens unsuitable for reuse.<a href="#section-5.1-9" class="pilcrow">¶</a></p>
<p id="section-5.1-10">When the Token (or part of the Token) contains a sequence number, the encoding
 of the sequence number has to be chosen in a way to avoid any collisions. This is
 especially true when the Token contains more information than just the sequence
 number, e.g., the serialized state, as in <span>[<a href="#RFC8974" class="xref">RFC8974</a>]</span>.<a href="#section-5.1-10" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="priv-cons">
<section id="section-6">
      <h2 id="name-privacy-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-privacy-considerations" class="section-name selfRef">Privacy Considerations</a>
      </h2>
<p id="section-6-1">Implementations <span class="bcp14">SHOULD NOT</span> put any privacy-sensitive information in
      the Echo or Request-Tag option values. Unencrypted timestamps could reveal
      information about the server, such as location, time since reboot, or that the
      server will accept expired certificates. Timestamps <span class="bcp14">MAY</span> be used if
      the Echo option is encrypted between the client and the server, e.g., in the case of
      DTLS without
      proxies or when using OSCORE with an Inner Echo option.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">Like HTTP cookies, the Echo option could potentially be abused as a tracking
      mechanism that identifies a client across requests. This is especially true for
      preemptive Echo option values. Servers <span class="bcp14">MUST NOT</span> use the Echo option to
      correlate requests for other purposes than freshness and reachability. Clients only
      send Echo option values to the same server from which the values were received. Compared to
      HTTP, CoAP clients are often authenticated and non-mobile, and servers can therefore
      often correlate requests based on the security context, the client credentials, or
      the network address. Especially when the Echo option increases a server's ability to
      correlate requests, clients <span class="bcp14">MAY</span> discard all preemptive Echo option values.<a href="#section-6-2" class="pilcrow">¶</a></p>
<p id="section-6-3">Publicly visible generated identifiers, even when opaque (as all defined in this
      document are), can leak information as described in <span>[<a href="#I-D.irtf-pearg-numeric-ids-generation" class="xref">NUMERIC-IDS</a>]</span>. To avoid the effects
      described there, the absent Request-Tag option should be recycled as much as possible.
      (That is generally possible as long as a security mechanism is in place -- even in the
      case of OSCORE outer block-wise transfers, as the OSCORE option's variation ensures
      that no matchable requests are created by different clients.) When an unprotected
      Echo option is used to demonstrate reachability, the recommended mechanism of <a href="#echo-proc" class="xref">Section 2.3</a> keeps the effects to a minimum.<a href="#section-6-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="iana">
<section id="section-7">
      <h2 id="name-iana-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-7-1">IANA has added the following option numbers to the "CoAP Option Numbers"
      registry defined by <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span>:<a href="#section-7-1" class="pilcrow">¶</a></p>
<span id="name-additions-to-coap-option-nu"></span><div id="iana-table">
<table class="left" id="table-3">
        <caption>
<a href="#table-3" class="selfRef">Table 3</a>:
<a href="#name-additions-to-coap-option-nu" class="selfRef">Additions to CoAP Option Numbers Registry</a>
        </caption>
<thead>
          <tr>
            <th class="text-left" rowspan="1" colspan="1">Number</th>
            <th class="text-left" rowspan="1" colspan="1">Name</th>
            <th class="text-left" rowspan="1" colspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">252</td>
            <td class="text-left" rowspan="1" colspan="1">Echo</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 9175</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">292</td>
            <td class="text-left" rowspan="1" colspan="1">Request-Tag</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 9175</td>
          </tr>
        </tbody>
      </table>
</div>
</section>
</div>
<section id="section-8">
      <h2 id="name-references">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-8.1">
        <h3 id="name-normative-references">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<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="RFC6347">[RFC6347]</dt>
        <dd>
<span class="refAuthor">Rescorla, E.</span> and <span class="refAuthor">N. Modadugu</span>, <span class="refTitle">"Datagram Transport Layer Security Version 1.2"</span>, <span class="seriesInfo">RFC 6347</span>, <span class="seriesInfo">DOI 10.17487/RFC6347</span>, <time datetime="2012-01" class="refDate">January 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6347">https://www.rfc-editor.org/info/rfc6347</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="RFC7959">[RFC7959]</dt>
        <dd>
<span class="refAuthor">Bormann, C.</span> and <span class="refAuthor">Z. Shelby, Ed.</span>, <span class="refTitle">"Block-Wise Transfers in the Constrained Application Protocol (CoAP)"</span>, <span class="seriesInfo">RFC 7959</span>, <span class="seriesInfo">DOI 10.17487/RFC7959</span>, <time datetime="2016-08" class="refDate">August 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7959">https://www.rfc-editor.org/info/rfc7959</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="RFC8470">[RFC8470]</dt>
        <dd>
<span class="refAuthor">Thomson, M.</span>, <span class="refAuthor">Nottingham, M.</span>, and <span class="refAuthor">W. Tarreau</span>, <span class="refTitle">"Using Early Data in HTTP"</span>, <span class="seriesInfo">RFC 8470</span>, <span class="seriesInfo">DOI 10.17487/RFC8470</span>, <time datetime="2018-09" class="refDate">September 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8470">https://www.rfc-editor.org/info/rfc8470</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>
</dl>
</section>
<section id="section-8.2">
        <h3 id="name-informative-references">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="I-D.mattsson-core-coap-attacks">[COAP-ATTACKS]</dt>
        <dd>
<span class="refAuthor">Preuß Mattsson, J.</span>, <span class="refAuthor">Fornehed, J.</span>, <span class="refAuthor">Selander, G.</span>, <span class="refAuthor">Palombini, F.</span>, and <span class="refAuthor">C. Amsüss</span>, <span class="refTitle">"Attacks on the Constrained Application Protocol (CoAP)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-mattsson-core-coap-attacks-01</span>, <time datetime="2021-07-27" class="refDate">27 July 2021</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-mattsson-core-coap-attacks-01">https://datatracker.ietf.org/doc/html/draft-mattsson-core-coap-attacks-01</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-core-groupcomm-bis">[GROUP-COAP]</dt>
        <dd>
<span class="refAuthor">Dijk, E.</span>, <span class="refAuthor">Wang, C.</span>, and <span class="refAuthor">M. Tiloca</span>, <span class="refTitle">"Group Communication for the Constrained Application Protocol (CoAP)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-core-groupcomm-bis-05</span>, <time datetime="2021-10-25" class="refDate">25 October 2021</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-core-groupcomm-bis-05">https://datatracker.ietf.org/doc/html/draft-ietf-core-groupcomm-bis-05</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-core-oscore-groupcomm">[GROUP-OSCORE]</dt>
        <dd>
<span class="refAuthor">Tiloca, M.</span>, <span class="refAuthor">Selander, G.</span>, <span class="refAuthor">Palombini, F.</span>, <span class="refAuthor">Preuß Mattsson, J.</span>, and <span class="refAuthor">J. Park</span>, <span class="refTitle">"Group OSCORE - Secure Group Communication for CoAP"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-core-oscore-groupcomm-13</span>, <time datetime="2021-10-25" class="refDate">25 October 2021</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-13">https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-13</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.irtf-pearg-numeric-ids-generation">[NUMERIC-IDS]</dt>
        <dd>
<span class="refAuthor">Gont, F.</span> and <span class="refAuthor">I. Arce</span>, <span class="refTitle">"On the Generation of Transient Numeric Identifiers"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-irtf-pearg-numeric-ids-generation-08</span>, <time datetime="2022-01-31" class="refDate">31 January 2022</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-irtf-pearg-numeric-ids-generation-08">https://datatracker.ietf.org/doc/html/draft-irtf-pearg-numeric-ids-generation-08</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="REST">[REST]</dt>
        <dd>
<span class="refAuthor">Fielding, R.</span>, <span class="refTitle">"Architectural Styles and the Design of Network-based Software Architectures"</span>, <time datetime="2000" class="refDate">2000</time>, <span>&lt;<a href="https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf">https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7641">[RFC7641]</dt>
        <dd>
<span class="refAuthor">Hartke, K.</span>, <span class="refTitle">"Observing Resources in the Constrained Application Protocol (CoAP)"</span>, <span class="seriesInfo">RFC 7641</span>, <span class="seriesInfo">DOI 10.17487/RFC7641</span>, <time datetime="2015-09" class="refDate">September 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7641">https://www.rfc-editor.org/info/rfc7641</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8323">[RFC8323]</dt>
        <dd>
<span class="refAuthor">Bormann, C.</span>, <span class="refAuthor">Lemay, S.</span>, <span class="refAuthor">Tschofenig, H.</span>, <span class="refAuthor">Hartke, K.</span>, <span class="refAuthor">Silverajan, B.</span>, and <span class="refAuthor">B. Raymor, Ed.</span>, <span class="refTitle">"CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets"</span>, <span class="seriesInfo">RFC 8323</span>, <span class="seriesInfo">DOI 10.17487/RFC8323</span>, <time datetime="2018-02" class="refDate">February 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8323">https://www.rfc-editor.org/info/rfc8323</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8446">[RFC8446]</dt>
        <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"The Transport Layer Security (TLS) Protocol Version 1.3"</span>, <span class="seriesInfo">RFC 8446</span>, <span class="seriesInfo">DOI 10.17487/RFC8446</span>, <time datetime="2018-08" class="refDate">August 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8446">https://www.rfc-editor.org/info/rfc8446</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="RFC9000">[RFC9000]</dt>
      <dd>
<span class="refAuthor">Iyengar, J., Ed.</span> and <span class="refAuthor">M. Thomson, Ed.</span>, <span class="refTitle">"QUIC: A UDP-Based Multiplexed and Secure Transport"</span>, <span class="seriesInfo">RFC 9000</span>, <span class="seriesInfo">DOI 10.17487/RFC9000</span>, <time datetime="2021-05" class="refDate">May 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9000">https://www.rfc-editor.org/info/rfc9000</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="echo-state">
<section id="appendix-A">
      <h2 id="name-methods-for-generating-echo">
<a href="#appendix-A" class="section-number selfRef">Appendix A. </a><a href="#name-methods-for-generating-echo" class="section-name selfRef">Methods for Generating Echo Option Values</a>
      </h2>
<p id="appendix-A-1">The content and structure of the Echo option value are implementation specific and
      determined by the server. Two simple mechanisms for time-based freshness and one for
      event-based freshness are outlined in this appendix. The "List of Cached Random
      Values and Timestamps" mechanism is
      <span class="bcp14">RECOMMENDED</span> in general. The "Integrity-Protected Timestamp"
      mechanism is <span class="bcp14">RECOMMENDED</span>
      in case the Echo option is encrypted between the client and the server.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
<p id="appendix-A-2">Different mechanisms have different trade-offs between the size of the Echo option
      value, the amount of server state, the amount of computation, and the security
      properties offered. A server <span class="bcp14">MAY</span> use different methods and security
      levels for different use cases (client aliveness, request freshness, state
      synchronization, network address reachability, etc.).<a href="#appendix-A-2" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="appendix-A-3">
 <li id="appendix-A-3.1">
          <p id="appendix-A-3.1.1">List of Cached Random Values and Timestamps. The Echo option value is a
   (pseudo)random byte string called r. The server caches a list containing the
   random byte strings and their initial transmission times. Assuming 72-bit random
   values
   and 32-bit timestamps, the size of the Echo option value is 9 bytes and the
   amount of server state is 13n bytes, where n is the number of active Echo option
   values. The security against an attacker guessing Echo option values is given by
   s = bit
   length of r - log2(n). The length of r and the maximum allowed n should be set so
   that the security level is harmonized with other parts of the deployment, e.g., s
   &gt;= 64. If the server loses time continuity, e.g., due to reboot, the entries
   in the old list <span class="bcp14">MUST</span> be deleted.<a href="#appendix-A-3.1.1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="appendix-A-3.1.2">
            <dt id="appendix-A-3.1.2.1">Echo option value:</dt>
            <dd style="margin-left: 1.5em" id="appendix-A-3.1.2.2">random value r<a href="#appendix-A-3.1.2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="appendix-A-3.1.2.3">Server State:</dt>
            <dd style="margin-left: 1.5em" id="appendix-A-3.1.2.4">random value r, timestamp t0<a href="#appendix-A-3.1.2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="appendix-A-3.1.3">This method is suitable for both time-based and event-based freshness (e.g.,
   by clearing the cache when an event occurs) and is independent of the client
   authority.<a href="#appendix-A-3.1.3" class="pilcrow">¶</a></p>
</li>
        <li id="appendix-A-3.2">
          <p id="appendix-A-3.2.1">Integrity-Protected Timestamp. The Echo option value is an
 integrity-protected
   timestamp. The timestamp can have a different resolution and range. A 32-bit
   timestamp can, e.g., give a resolution of 1 second with a range of 136 years. The
   (pseudo)random secret key is generated by the server and not shared with any
   other party. The use of truncated HMAC-SHA-256 is <span class="bcp14">RECOMMENDED</span>.
   With a 32-bit timestamp and a 64-bit MAC, the size of the Echo option value is 12
   bytes, and the server state is small and constant. The security against an
   attacker guessing Echo option values is given by the MAC length. If the server loses
   time continuity, e.g., due to reboot, the old key <span class="bcp14">MUST</span> be deleted
   and replaced by a new random secret key. Note that the privacy considerations in
   <a href="#priv-cons" class="xref">Section 6</a> may apply to the timestamp.
   Therefore, it might be important to encrypt it. Depending on the choice of
   encryption algorithms, this may require an initialization vector to be included
   in the Echo option value (see below).<a href="#appendix-A-3.2.1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="appendix-A-3.2.2">
            <dt id="appendix-A-3.2.2.1">Echo option value:</dt>
            <dd style="margin-left: 1.5em" id="appendix-A-3.2.2.2">timestamp t0, MAC(k, t0)<a href="#appendix-A-3.2.2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="appendix-A-3.2.2.3">Server State:</dt>
            <dd style="margin-left: 1.5em" id="appendix-A-3.2.2.4">secret key k<a href="#appendix-A-3.2.2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="appendix-A-3.2.3">This method is suitable for both time-based and event-based freshness (by the
   server remembering the time at which the event took place) and independent of
   the client authority.<a href="#appendix-A-3.2.3" class="pilcrow">¶</a></p>
<p id="appendix-A-3.2.4">If this method is used to additionally obtain network reachability of the
   client, the server <span class="bcp14">MUST</span> use the client's network address too, e.g.,
   as in MAC(k, t0, claimed network address).<a href="#appendix-A-3.2.4" class="pilcrow">¶</a></p>
</li>
        <li id="appendix-A-3.3">
          <p id="appendix-A-3.3.1">Persistent Counter. This can be used in OSCORE for sequence number recovery,
 per <span><a href="https://www.rfc-editor.org/rfc/rfc8613#appendix-B.1.2" class="relref">Appendix B.1.2</a> of [<a href="#RFC8613" class="xref">RFC8613</a>]</span>. The Echo option
 value is a simple counter without integrity protection of its own, serialized in
 uint format. The counter is incremented in a persistent way every time the state
 that needs to be synchronized is changed (in the case described in <span><a href="https://www.rfc-editor.org/rfc/rfc8613#appendix-B.1.2" class="relref">Appendix B.1.2</a> of [<a href="#RFC8613" class="xref">RFC8613</a>]</span>, when a reboot
 indicates that volatile state may have been lost). An example of how such a
 persistent counter can be implemented efficiently is the OSCORE server Sender
 Sequence Number mechanism described 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>.<a href="#appendix-A-3.3.1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="appendix-A-3.3.2">
            <dt id="appendix-A-3.3.2.1">Echo option value:</dt>
            <dd style="margin-left: 1.5em" id="appendix-A-3.3.2.2">counter<a href="#appendix-A-3.3.2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="appendix-A-3.3.2.3">Server State:</dt>
            <dd style="margin-left: 1.5em" id="appendix-A-3.3.2.4">counter<a href="#appendix-A-3.3.2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="appendix-A-3.3.3">This method is suitable only if the client is the authority over the
   synchronized property. Consequently, it cannot be used to show client aliveness.
   It provides statements from the client similar to event-based freshness (but
   without a proof of freshness).<a href="#appendix-A-3.3.3" class="pilcrow">¶</a></p>
</li>
      </ol>
<p id="appendix-A-4">Other mechanisms complying with the security and privacy considerations may be
   used. The use of encrypted timestamps in the Echo option provides additional
   protection but typically requires an initialization vector (a.k.a. nonce) as
   input to the encryption algorithm, which adds a slight complication to the
   procedure as well as overhead.<a href="#appendix-A-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="request-tag-message-size-impact">
<section id="appendix-B">
      <h2 id="name-request-tag-message-size-im">
<a href="#appendix-B" class="section-number selfRef">Appendix B. </a><a href="#name-request-tag-message-size-im" class="section-name selfRef">Request-Tag Message Size Impact</a>
      </h2>
<p id="appendix-B-1">In absence of concurrent operations, the Request-Tag mechanism for body integrity
      (<a href="#body-integrity" class="xref">Section 3.5.1</a>) incurs no overhead if no messages
      are lost (more precisely, in OSCORE, if no operations are aborted due to repeated
      transmission failure and, in DTLS, if no packets are lost and replay protection is
      active) or when block-wise request operations happen rarely (in OSCORE, if there is
      always only one request block-wise operation in the replay window).<a href="#appendix-B-1" class="pilcrow">¶</a></p>
<p id="appendix-B-2">In those situations, no message has any Request-Tag option set, and the
      Request-Tag value can be recycled indefinitely.<a href="#appendix-B-2" class="pilcrow">¶</a></p>
<p id="appendix-B-3">When the absence of a Request-Tag option cannot be recycled any more within a
      security context, the messages with a present but empty Request-Tag option can be
      used (1 byte overhead), and when that is used up, 256 values from 1-byte
      options (2 bytes overhead) are available.<a href="#appendix-B-3" class="pilcrow">¶</a></p>
<p id="appendix-B-4">In situations where that overhead is unacceptable (e.g., because the payloads
      are known to be at a fragmentation threshold), the absent Request-Tag value can be
      made usable again:<a href="#appendix-B-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-B-5.1">In DTLS, a new session can be established.<a href="#appendix-B-5.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-B-5.2">In OSCORE, the sequence number can be artificially increased so that all lost
 messages are outside of the replay window by the time the first request of the new
 operation gets processed, and all earlier operations can therefore be regarded as
 concluded.<a href="#appendix-B-5.2" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<div id="acknowledgements">
<section id="appendix-C">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="appendix-C-1">The authors want to thank <span class="contact-name">Carsten Bormann</span>, <span class="contact-name">Roman Danyliw</span>, <span class="contact-name">Benjamin Kaduk</span>, <span class="contact-name">Murray Kucherawy</span>, <span class="contact-name">Francesca Palombini</span>, and
      <span class="contact-name">Jim Schaad</span> for providing valuable input to the document.<a href="#appendix-C-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="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">Christian Amsüss</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:christian@amsuess.com" class="email">christian@amsuess.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">John Preuß Mattsson</span></div>
<div dir="auto" class="left"><span class="org">Ericsson AB</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:john.mattsson@ericsson.com" class="email">john.mattsson@ericsson.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Göran Selander</span></div>
<div dir="auto" class="left"><span class="org">Ericsson AB</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:goran.selander@ericsson.com" class="email">goran.selander@ericsson.com</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>