File: rfc9185.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 (2325 lines) | stat: -rw-r--r-- 100,011 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 9185: DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange</title>
<meta content="Paul E. Jones" name="author">
<meta content="Paul M. Ellenbogen" name="author">
<meta content="Nils H. Ohlmeier" name="author">
<meta content="
       This document defines a protocol for tunneling DTLS traffic in multimedia
conferences that enables a Media Distributor to facilitate key
exchange between an endpoint in a conference and the Key Distributor.
The protocol is designed to ensure that the keying material used for
hop-by-hop encryption and authentication is accessible to the Media
Distributor, while the keying material used for end-to-end encryption
and authentication is inaccessible to the Media Distributor. 
    " name="description">
<meta content="xml2rfc 3.12.2" name="generator">
<meta content="PERC" name="keyword">
<meta content="SRTP" name="keyword">
<meta content="RTP" name="keyword">
<meta content="DTLS" name="keyword">
<meta content="DTLS-SRTP" name="keyword">
<meta content="DTLS tunnel" name="keyword">
<meta content="conferencing" name="keyword">
<meta content="security" name="keyword">
<meta content="9185" 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="rfc9185.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/rfc9185" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-perc-dtls-tunnel-12" 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 9185</td>
<td class="center">DTLS Tunnel for PERC</td>
<td class="right">April 2022</td>
</tr></thead>
<tfoot><tr>
<td class="left">Jones, et al.</td>
<td class="center">Informational</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/rfc9185" class="eref">9185</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2022-04" class="published">April 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">P. Jones</div>
<div class="org">Cisco Systems</div>
</div>
<div class="author">
      <div class="author-name">P. Ellenbogen</div>
<div class="org">Princeton University</div>
</div>
<div class="author">
      <div class="author-name">N. Ohlmeier</div>
<div class="org">8x8, Inc.</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9185</h1>
<h1 id="title">DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document defines a protocol for tunneling DTLS traffic in multimedia
conferences that enables a Media Distributor to facilitate key
exchange between an endpoint in a conference and the Key Distributor.
The protocol is designed to ensure that the keying material used for
hop-by-hop encryption and authentication is accessible to the Media
Distributor, while the keying material used for end-to-end encryption
and authentication is inaccessible to the Media Distributor.<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 document is not an Internet Standards Track specification; it is
            published for informational purposes.<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).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see 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/rfc9185">https://www.rfc-editor.org/info/rfc9185</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>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-conventions-used-in-this-do" class="xref">Conventions Used in This Document</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1" class="keepWithNext"><a href="#section-3" class="xref">3</a>.  <a href="#name-tunneling-concept" class="xref">Tunneling Concept</a></p>
</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-example-message-flows" class="xref">Example Message Flows</a></p>
</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-tunneling-procedures" class="xref">Tunneling Procedures</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-endpoint-procedures" class="xref">Endpoint Procedures</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-tunnel-establishment-proced" class="xref">Tunnel Establishment Procedures</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.3">
                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-media-distributor-tunneling" class="xref">Media Distributor Tunneling Procedures</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.4">
                <p id="section-toc.1-1.5.2.4.1"><a href="#section-5.4" class="xref">5.4</a>.  <a href="#name-key-distributor-tunneling-p" class="xref">Key Distributor Tunneling Procedures</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.5">
                <p id="section-toc.1-1.5.2.5.1"><a href="#section-5.5" class="xref">5.5</a>.  <a href="#name-versioning-considerations" class="xref">Versioning Considerations</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-tunneling-protocol" class="xref">Tunneling Protocol</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.1">
                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-tunnelmessage-structure" class="xref">TunnelMessage Structure</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.2">
                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-supportedprofiles-message" class="xref">SupportedProfiles Message</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.3">
                <p id="section-toc.1-1.6.2.3.1"><a href="#section-6.3" class="xref">6.3</a>.  <a href="#name-unsupportedversion-message" class="xref">UnsupportedVersion Message</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.4">
                <p id="section-toc.1-1.6.2.4.1"><a href="#section-6.4" class="xref">6.4</a>.  <a href="#name-mediakeys-message" class="xref">MediaKeys Message</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.5">
                <p id="section-toc.1-1.6.2.5.1"><a href="#section-6.5" class="xref">6.5</a>.  <a href="#name-tunneleddtls-message" class="xref">TunneledDtls Message</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.6">
                <p id="section-toc.1-1.6.2.6.1"><a href="#section-6.6" class="xref">6.6</a>.  <a href="#name-endpointdisconnect-message" class="xref">EndpointDisconnect Message</a></p>
</li>
            </ul>
</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-example-binary-encoding" class="xref">Example Binary Encoding</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-iana-considerations" class="xref">IANA Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-references" class="xref">References</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.1">
                <p id="section-toc.1-1.10.2.1.1"><a href="#section-10.1" class="xref">10.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.10.2.2">
                <p id="section-toc.1-1.10.2.2.1"><a href="#section-10.2" class="xref">10.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.11">
            <p id="section-toc.1-1.11.1"><a href="#appendix-A" 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-B" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="introduction">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">An objective of Privacy-Enhanced RTP Conferencing (PERC) <span>[<a href="#RFC8871" class="xref">RFC8871</a>]</span> is to
ensure that endpoints in a multimedia conference have access to the
end-to-end (E2E) and hop-by-hop (HBH) keying material used to encrypt
and authenticate Real-time Transport Protocol (RTP) 
packets <span>[<a href="#RFC3550" class="xref">RFC3550</a>]</span>, while the Media Distributor has access only to the HBH
keying material for encryption and authentication.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">This specification defines a tunneling protocol that enables the Media
Distributor to tunnel DTLS messages <span>[<a href="#RFC9147" class="xref">RFC9147</a>]</span> between an endpoint
and a Key Distributor, thus allowing an endpoint to use DTLS for the Secure Real-time Transport Protocol (DTLS-SRTP)
<span>[<a href="#RFC5764" class="xref">RFC5764</a>]</span> for establishing encryption and authentication keys with
the Key Distributor.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">The tunnel established between the Media Distributor and Key
Distributor is a TLS connection <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span> that is established before any
messages are forwarded by the Media Distributor on behalf of
endpoints.  DTLS packets received from an endpoint are encapsulated by
the Media Distributor inside this tunnel as data to be sent to the Key
Distributor.  Likewise, when the Media Distributor receives data from
the Key Distributor over the tunnel, it extracts the DTLS message
inside and forwards the DTLS message to the endpoint.  In this way,
the DTLS association for the DTLS-SRTP procedures is established
between an endpoint and the Key Distributor, with the Media
Distributor forwarding DTLS messages between the two entities via the
established tunnel to the Key Distributor and having no visibility into
the confidential information exchanged.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">Following the existing DTLS-SRTP procedures, the endpoint and Key
Distributor will arrive at a selected cipher and keying material,
which are used for HBH encryption and authentication by both the
endpoint and the Media Distributor.  However, since the Media
Distributor would not have direct access to this information, the Key
Distributor explicitly shares the HBH key information with the Media
Distributor via the tunneling protocol defined in this document.
Additionally, the endpoint and Key Distributor will agree on a cipher
for E2E encryption and authentication.  The Key Distributor will
transmit keying material to the endpoint for E2E operations but will
not share that information with the Media Distributor.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">By establishing this TLS tunnel between the Media Distributor and Key
Distributor and implementing the protocol defined in this document, it
is possible for the Media Distributor to facilitate the establishment
of a secure DTLS association between an endpoint and the Key
Distributor in order for the endpoint to generate E2E and HBH keying
material.  At the same time, the Key Distributor can securely provide
the HBH keying material to the Media Distributor.<a href="#section-1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="conventions-used-in-this-document">
<section id="section-2">
      <h2 id="name-conventions-used-in-this-do">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-conventions-used-in-this-do" class="section-name selfRef">Conventions Used in This Document</a>
      </h2>
<p id="section-2-1">
    The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>", "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>", "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are to be interpreted as
    described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> 
    when, and only when, they appear in all capitals, as shown here.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">This document uses the terms "endpoint", "Media Distributor", and
"Key Distributor" defined in <span>[<a href="#RFC8871" class="xref">RFC8871</a>]</span>.<a href="#section-2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="tunneling-concept">
<section id="section-3">
      <h2 id="name-tunneling-concept">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-tunneling-concept" class="section-name selfRef">Tunneling Concept</a>
      </h2>
<p id="section-3-1">A TLS connection (tunnel) is established between the Media Distributor
  and the Key Distributor.  This tunnel is used to relay DTLS messages
  between the endpoint and Key Distributor, as depicted in
  <a href="#fig-tunnel" class="xref">Figure 1</a>:<a href="#section-3-1" class="pilcrow">¶</a></p>
<span id="name-tls-tunnel-to-key-distribut"></span><div id="fig-tunnel">
<figure id="figure-1">
        <div class="alignCenter art-ascii-art art-text artwork" id="section-3-2.1">
<pre>
                         +-------------+
                         |     Key     |
                         | Distributor |
                         +-------------+
                             # ^ ^ #
                             # | | # &lt;-- TLS Tunnel
                             # | | #
+----------+             +-------------+             +----------+
|          |     DTLS    |             |    DTLS     |          |
| Endpoint |&lt;------------|    Media    |------------&gt;| Endpoint |
|          |    to Key   | Distributor |   to Key    |          |
|          | Distributor |             | Distributor |          |
+----------+             +-------------+             +----------+
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-tls-tunnel-to-key-distribut" class="selfRef">TLS Tunnel to Key Distributor</a>
        </figcaption></figure>
</div>
<p id="section-3-3">The three entities involved in this communication flow are the
endpoint, the Media Distributor, and the Key Distributor.  The
behavior of each entity is described in <a href="#tunneling-procedures" class="xref">Section 5</a>.<a href="#section-3-3" class="pilcrow">¶</a></p>
<p id="section-3-4"> The Key Distributor is a logical function that might be co-resident
 with a key management server operated by an enterprise, might
 reside in one of the endpoints participating in the conference, or
 might reside at some other location that is trusted with E2E keying
 material.<a href="#section-3-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="example-message-flows">
<section id="section-4">
      <h2 id="name-example-message-flows">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-example-message-flows" class="section-name selfRef">Example Message Flows</a>
      </h2>
<p id="section-4-1">This section provides an example message flow to help clarify the
procedures described later in this document.  It is necessary that the
Key Distributor and Media Distributor establish a mutually
authenticated TLS connection for the purpose of sending tunneled
messages, though the complete TLS handshake for the tunnel is not
shown in <a href="#fig-message-flow" class="xref">Figure 2</a> because there is nothing new this document
introduces with regard to those procedures.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">Once the tunnel is established, it is possible for the Media
Distributor to relay the DTLS messages between the endpoint and the
Key Distributor.  <a href="#fig-message-flow" class="xref">Figure 2</a> shows a message flow wherein the
endpoint uses DTLS-SRTP to establish an association with the Key
Distributor.  In the process, the Media Distributor shares its
supported SRTP protection profile information (see <span>[<a href="#RFC5764" class="xref">RFC5764</a>]</span>), and
the Key Distributor shares the HBH keying material and selected cipher
with the Media Distributor.<a href="#section-4-2" class="pilcrow">¶</a></p>
<span id="name-sample-dtls-srtp-exchange-v"></span><div id="fig-message-flow">
<figure id="figure-2">
        <div class="alignCenter art-ascii-art art-text artwork" id="section-4-3.1">
<pre>
Endpoint              Media Distributor          Key Distributor
    |                         |                         |
    |                         |&lt;=======================&gt;|
    |                         |    TLS Connection Made  |
    |                         |                         |
    |                         |========================&gt;|
    |                         | SupportedProfiles       |
    |                         |                         |
    |------------------------&gt;|========================&gt;|
    | DTLS handshake message  | TunneledDtls            |
    |                         |                         |
         .... may be multiple handshake messages ...
    |                         |                         |
    |&lt;------------------------|&lt;========================|
    | DTLS handshake message  |            TunneledDtls |
    |                         |                         |
    |                         |                         |
    |                         |&lt;========================|
    |                         |               MediaKeys |
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-sample-dtls-srtp-exchange-v" class="selfRef">Sample DTLS-SRTP Exchange via the Tunnel</a>
        </figcaption></figure>
</div>
<p id="section-4-4">After the initial TLS connection has been established, each of the
messages on the right-hand side of <a href="#fig-message-flow" class="xref">Figure 2</a> is a tunneling
protocol message, as defined in <a href="#tunneling-protocol" class="xref">Section 6</a>.<a href="#section-4-4" class="pilcrow">¶</a></p>
<p id="section-4-5">SRTP protection profiles supported by the Media Distributor will be
sent in a <code>SupportedProfiles</code> message when the TLS tunnel is initially
established.  The Key Distributor will use that information to select
a common profile supported by both the endpoint and the Media
Distributor to ensure that HBH operations can be successfully
performed.<a href="#section-4-5" class="pilcrow">¶</a></p>
<p id="section-4-6">As DTLS messages are received from the endpoint by the Media
Distributor, they are forwarded to the Key Distributor encapsulated
inside a <code>TunneledDtls</code> message.  Likewise, as <code>TunneledDtls</code>
messages are received by the Media Distributor from the Key
Distributor, the encapsulated DTLS packet is forwarded to the
endpoint.<a href="#section-4-6" class="pilcrow">¶</a></p>
<p id="section-4-7">The Key Distributor will provide the SRTP keying material
<span>[<a href="#RFC3711" class="xref">RFC3711</a>]</span> to the Media Distributor for HBH operations via the <code>MediaKeys</code>
message.  The Media Distributor will extract this keying material from
the <code>MediaKeys</code> message when received and use it for HBH
encryption and authentication.<a href="#section-4-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="tunneling-procedures">
<section id="section-5">
      <h2 id="name-tunneling-procedures">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-tunneling-procedures" class="section-name selfRef">Tunneling Procedures</a>
      </h2>
<p id="section-5-1">The following subsections explain in detail the expected behavior of
the endpoint, the Media Distributor, and the Key Distributor.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">It is important to note that the tunneling protocol described in this
document is not an extension to TLS or DTLS.  Rather, it is a protocol that
transports DTLS messages generated by an endpoint or Key Distributor as data
inside of the TLS connection established between the Media Distributor and
Key Distributor.<a href="#section-5-2" class="pilcrow">¶</a></p>
<div id="endpoint-procedures">
<section id="section-5.1">
        <h3 id="name-endpoint-procedures">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-endpoint-procedures" class="section-name selfRef">Endpoint Procedures</a>
        </h3>
<p id="section-5.1-1">The endpoint follows the procedures outlined for DTLS-SRTP <span>[<a href="#RFC5764" class="xref">RFC5764</a>]</span>
in order to establish the cipher and keys used for encryption and
authentication, with the endpoint acting as the client and the Key
Distributor acting as the server.  The endpoint does not need to be
aware of the fact that DTLS messages it transmits toward the Media
Distributor are being tunneled to the Key Distributor.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<p id="section-5.1-2">The endpoint <span class="bcp14">MUST</span> include a unique identifier in the <code>tls-id</code>
Session Description Protocol (SDP) attribute <span>[<a href="#RFC8866" class="xref">RFC8866</a>]</span> in all offer and answer messages <span>[<a href="#RFC3264" class="xref">RFC3264</a>]</span>
that it generates, as per <span>[<a href="#RFC8842" class="xref">RFC8842</a>]</span>. Further, the
endpoint <span class="bcp14">MUST</span> include this same unique identifier in the
<code>external_session_id</code> extension <span>[<a href="#RFC8844" class="xref">RFC8844</a>]</span> in the
<code>ClientHello</code> message when establishing a DTLS association.<a href="#section-5.1-2" class="pilcrow">¶</a></p>
<p id="section-5.1-3">When receiving an <code>external_session_id</code> value from the Key Distributor, the
client <span class="bcp14">MUST</span> check to ensure that value matches the <code>tls-id</code> value
received in SDP.  If the values do not match, the endpoint <span class="bcp14">MUST</span>
consider any received keying material to be invalid and terminate the
DTLS association.<a href="#section-5.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="tunnel-establishment-procedures">
<section id="section-5.2">
        <h3 id="name-tunnel-establishment-proced">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-tunnel-establishment-proced" class="section-name selfRef">Tunnel Establishment Procedures</a>
        </h3>
<p id="section-5.2-1">Either the Media Distributor or Key Distributor initiates the
establishment of a TLS tunnel.  Which entity acts as the TLS client
when establishing the tunnel and what event triggers the establishment
of the tunnel are outside the scope of this document.  Further, how
the trust relationships are established between the Key Distributor
and Media Distributor are also outside the scope of this document.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<p id="section-5.2-2">A tunnel <span class="bcp14">MUST</span> be a mutually authenticated TLS connection.<a href="#section-5.2-2" class="pilcrow">¶</a></p>
<p id="section-5.2-3">The Media Distributor or Key Distributor <span class="bcp14">MUST</span> establish a tunnel
prior to forwarding tunneled DTLS messages.  Given the time-sensitive
nature of DTLS-SRTP procedures, a tunnel <span class="bcp14">SHOULD</span> be established
prior to the Media Distributor receiving a DTLS message from an
endpoint.<a href="#section-5.2-3" class="pilcrow">¶</a></p>
<p id="section-5.2-4">A single tunnel <span class="bcp14">MAY</span> be used to relay DTLS messages between any
number of endpoints and the Key Distributor.<a href="#section-5.2-4" class="pilcrow">¶</a></p>
<p id="section-5.2-5">A Media Distributor <span class="bcp14">MAY</span> have more than one tunnel established
between itself and one or more Key Distributors.  When multiple
tunnels are established, which tunnel or tunnels to use to send
messages for a given conference is outside the scope of this document.<a href="#section-5.2-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="media-distributor-tunneling-procedures">
<section id="section-5.3">
        <h3 id="name-media-distributor-tunneling">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-media-distributor-tunneling" class="section-name selfRef">Media Distributor Tunneling Procedures</a>
        </h3>
<p id="section-5.3-1">The first message transmitted over the tunnel is the
<code>SupportedProfiles</code> message (see <a href="#tunneling-protocol" class="xref">Section 6</a>).  This message informs
the Key Distributor about which DTLS-SRTP profiles the Media
Distributor supports.  This message <span class="bcp14">MUST</span> be sent each time a new
tunnel connection is established or, in the case of connection loss,
when a connection is re-established.  The Media Distributor <span class="bcp14">MUST</span>
support the same list of protection profiles for the duration of any
endpoint-initiated DTLS association and tunnel connection.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
<p id="section-5.3-2">The Media Distributor <span class="bcp14">MUST</span> assign a unique association identifier
for each endpoint-initiated DTLS association and include it in all
messages forwarded to the Key Distributor.  The Key Distributor will
subsequently include this identifier in all messages it sends so that
the Media Distributor can map messages received via a tunnel and
forward those messages to the correct endpoint.  The association
identifier <span class="bcp14">MUST</span> be a version 4 Universally Unique Identifier (UUID), as described in 
<span><a href="https://www.rfc-editor.org/rfc/rfc4122#section-4.4" class="relref">Section 4.4</a> of [<a href="#RFC4122" class="xref">RFC4122</a>]</span>.<a href="#section-5.3-2" class="pilcrow">¶</a></p>
<p id="section-5.3-3">When a DTLS message is received by the Media Distributor from an
endpoint, it forwards the UDP payload portion of that message to the
Key Distributor encapsulated in a <code>TunneledDtls</code> message.
The Media Distributor is not required to forward all messages received
from an endpoint for a given DTLS association through the same tunnel
if more than one tunnel has been established between it and a Key
Distributor.<a href="#section-5.3-3" class="pilcrow">¶</a></p>
<p id="section-5.3-4">When a <code>MediaKeys</code> message is received, the Media Distributor <span class="bcp14">MUST</span>
extract the cipher and keying material conveyed in order to
subsequently perform HBH encryption and authentication operations for
RTP and RTP Control Protocol (RTCP) packets sent between it and an endpoint.  Since the HBH
keying material will be different for each endpoint, the Media
Distributor uses the association identifier included by the Key
Distributor to ensure that the HBH keying material is used with the
correct endpoint.<a href="#section-5.3-4" class="pilcrow">¶</a></p>
<p id="section-5.3-5">The Media Distributor <span class="bcp14">MUST</span> forward all DTLS messages received from
either the endpoint or the Key Distributor (via the <code>TunneledDtls</code>
message) to ensure proper communication between those two entities.<a href="#section-5.3-5" class="pilcrow">¶</a></p>
<p id="section-5.3-6">When the Media Distributor detects an endpoint has disconnected or
when it receives conference control messages indicating the endpoint
is to be disconnected, the Media Distributor <span class="bcp14">MUST</span> send an
<code>EndpointDisconnect</code> message with the association identifier assigned
to the endpoint to the Key Distributor.  The Media Distributor
<span class="bcp14">SHOULD</span> take a loss of all RTP and RTCP packets as an indicator
that the endpoint has disconnected.  The particulars of how RTP and
RTCP are to be used to detect an endpoint disconnect, such as timeout
period, are not specified.  The Media Distributor <span class="bcp14">MAY</span> use
additional indicators to determine when an endpoint has disconnected.<a href="#section-5.3-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="key-distributor-tunneling-procedures">
<section id="section-5.4">
        <h3 id="name-key-distributor-tunneling-p">
<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-key-distributor-tunneling-p" class="section-name selfRef">Key Distributor Tunneling Procedures</a>
        </h3>
<p id="section-5.4-1">Each TLS tunnel established between the Media Distributor and the
Key Distributor <span class="bcp14">MUST</span> be mutually authenticated.<a href="#section-5.4-1" class="pilcrow">¶</a></p>
<p id="section-5.4-2">When the Media Distributor relays a DTLS message from an endpoint, the
Media Distributor will include an association identifier that is
unique per endpoint-originated DTLS association.  The association
identifier remains constant for the life of the DTLS association.  The
Key Distributor identifies each distinct endpoint-originated DTLS
association by the association identifier.<a href="#section-5.4-2" class="pilcrow">¶</a></p>
<p id="section-5.4-3">When processing an incoming endpoint association, the Key Distributor
<span class="bcp14">MUST</span> extract the <code>external_session_id</code> value transmitted in the
<code>ClientHello</code> message and match that against the <code>tls-id</code> value the endpoint
transmitted via SDP.  If the values in SDP and the <code>ClientHello</code> message do not match,
the DTLS association <span class="bcp14">MUST</span> be rejected.<a href="#section-5.4-3" class="pilcrow">¶</a></p>
<p id="section-5.4-4">The process through which the <code>tls-id</code> value in SDP is conveyed to
the Key Distributor is outside the scope of this document.<a href="#section-5.4-4" class="pilcrow">¶</a></p>
<p id="section-5.4-5">The Key Distributor <span class="bcp14">MUST</span> match the fingerprint of the certificate and
<code>external_session_id</code> <span>[<a href="#RFC8844" class="xref">RFC8844</a>]</span> received from the endpoint via DTLS with the
expected fingerprint <span>[<a href="#RFC8122" class="xref">RFC8122</a>]</span> and <code>tls-id</code> <span>[<a href="#RFC8842" class="xref">RFC8842</a>]</span> values received via
SDP.  It is through this process that the Key Distributor can be sure to
deliver the correct conference key to the endpoint.<a href="#section-5.4-5" class="pilcrow">¶</a></p>
<p id="section-5.4-6">The Key Distributor <span class="bcp14">MUST</span> report its own unique identifier in the
<code>external_session_id</code> extension.  This extension is sent in the
<code>EncryptedExtensions</code> message in DTLS 1.3 and the <code>ServerHello</code> message in
previous DTLS versions.  This value <span class="bcp14">MUST</span> also be conveyed back to
the client via SDP as a <code>tls-id</code> attribute.<a href="#section-5.4-6" class="pilcrow">¶</a></p>
<p id="section-5.4-7">The Key Distributor <span class="bcp14">MUST</span> encapsulate any DTLS message it sends to
an endpoint inside a <code>TunneledDtls</code> message (see
<a href="#tunneling-protocol" class="xref">Section 6</a>).  The Key Distributor is not required to transmit
all messages for a given DTLS association through the same tunnel if more
than one tunnel has been established between it and the Media Distributor.<a href="#section-5.4-7" class="pilcrow">¶</a></p>
<p id="section-5.4-8">The Key Distributor <span class="bcp14">MUST</span> use the same association identifier in
messages sent to an endpoint as was received in messages from that
endpoint.  This ensures the Media Distributor can forward the messages
to the correct endpoint.<a href="#section-5.4-8" class="pilcrow">¶</a></p>
<p id="section-5.4-9">The Key Distributor extracts tunneled DTLS messages from an endpoint
and acts on those messages as if that endpoint had established the
DTLS association directly with the Key Distributor.  The Key
Distributor is acting as the DTLS server, and the endpoint is acting as
the DTLS client.  The handling of the messages and certificates is
exactly the same as normal DTLS-SRTP procedures between endpoints.<a href="#section-5.4-9" class="pilcrow">¶</a></p>
<p id="section-5.4-10">The Key Distributor <span class="bcp14">MUST</span> send a <code>MediaKeys</code> message to the Media
Distributor immediately after the DTLS handshake completes.  The <code>MediaKeys</code>
message includes the selected cipher (i.e., protection profile), Master Key Identifier (MKI)
value <span>[<a href="#RFC3711" class="xref">RFC3711</a>]</span> (if any), HBH SRTP master keys, and SRTP master salt
values.  The Key Distributor <span class="bcp14">MUST</span> use the same association
identifier in the <code>MediaKeys</code> message as is used in the <code>TunneledDtls</code>
messages for the given endpoint.<a href="#section-5.4-10" class="pilcrow">¶</a></p>
<p id="section-5.4-11">There are presently two SRTP protection profiles defined for PERC,
namely <code>DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM</code> and
<code>DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM</code> <span>[<a href="#RFC8723" class="xref">RFC8723</a>]</span>.  As explained in <span><a href="https://www.rfc-editor.org/rfc/rfc8723#section-5.2" class="relref">Section 5.2</a> of [<a href="#RFC8723" class="xref">RFC8723</a>]</span>, the Media Distributor is only given the SRTP
master key for HBH operations.  As such, the SRTP master key
length advertised in the <code>MediaKeys</code> message is half the length of the key
normally associated with the selected "double" protection profile.<a href="#section-5.4-11" class="pilcrow">¶</a></p>
<p id="section-5.4-12">The Key Distributor uses the certificate fingerprint of the endpoint
along with the unique identifier received in the <code>external_session_id</code>
extension to determine with which conference a given DTLS association is
associated.<a href="#section-5.4-12" class="pilcrow">¶</a></p>
<p id="section-5.4-13">The Key Distributor <span class="bcp14">MUST</span> select a cipher that is supported by itself, the endpoint, and the Media Distributor to ensure proper HBH
operations.<a href="#section-5.4-13" class="pilcrow">¶</a></p>
<p id="section-5.4-14">When the DTLS association between the endpoint and the Key Distributor
is terminated, regardless of which entity initiated the termination,
the Key Distributor <span class="bcp14">MUST</span> send an <code>EndpointDisconnect</code> message
with the association identifier assigned to the endpoint to the Media
Distributor.<a href="#section-5.4-14" class="pilcrow">¶</a></p>
</section>
</div>
<div id="versioning-considerations">
<section id="section-5.5">
        <h3 id="name-versioning-considerations">
<a href="#section-5.5" class="section-number selfRef">5.5. </a><a href="#name-versioning-considerations" class="section-name selfRef">Versioning Considerations</a>
        </h3>
<p id="section-5.5-1">Since the Media Distributor sends the first message over the tunnel,
it effectively establishes the version of the protocol to be used.  If
that version is not supported by the Key Distributor, the Key
Distributor <span class="bcp14">MUST</span> transmit an <code>UnsupportedVersion</code> message containing
the highest version number supported and close the TLS connection.<a href="#section-5.5-1" class="pilcrow">¶</a></p>
<p id="section-5.5-2">The Media Distributor <span class="bcp14">MUST</span> take note of the version received in an
<code>UnsupportedVersion</code> message and use that version when attempting to
re-establish a failed tunnel connection.  Note that it is not
necessary for the Media Distributor to understand the newer version of
the protocol to understand that the first message received is an 
<code>UnsupportedVersion</code> message.  The Media Distributor can determine from the
first four octets received what the version number is and that the
message is an <code>UnsupportedVersion</code> message.  The rest of the data received, if
any, would be discarded and the connection closed (if not already
closed).<a href="#section-5.5-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="tunneling-protocol">
<section id="section-6">
      <h2 id="name-tunneling-protocol">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-tunneling-protocol" class="section-name selfRef">Tunneling Protocol</a>
      </h2>
<p id="section-6-1">Tunneled messages are transported via the TLS tunnel as application
data between the Media Distributor and the Key Distributor.  Tunnel
messages are specified using the format described in <span>[<a href="#RFC8446" class="xref">RFC8446</a>], <a href="https://www.rfc-editor.org/rfc/rfc8446#section-3" class="relref">Section 3</a></span>.  As in <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span>, all values are stored in network byte
(big endian) order; the uint32 represented by the hex bytes 01 02 03
04 is equivalent to the decimal value 16909060.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">This protocol defines several different messages, each of which
contains the following information:<a href="#section-6-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6-3.1">message type identifier<a href="#section-6-3.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-3.2">message body length<a href="#section-6-3.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-3.3">the message body<a href="#section-6-3.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-6-4">Each of the tunnel messages is a <code>TunnelMessage</code> structure with the
message type indicating the actual content of the message body.<a href="#section-6-4" class="pilcrow">¶</a></p>
<div id="tunnelmessage-structure">
<section id="section-6.1">
        <h3 id="name-tunnelmessage-structure">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-tunnelmessage-structure" class="section-name selfRef">TunnelMessage Structure</a>
        </h3>
<p id="section-6.1-1"><code>TunnelMessage</code> defines the structure of all messages sent via the tunnel
  protocol.  That structure includes a field called <code>msg_type</code> that identifies the
  specific type of message contained within <code>TunnelMessage</code>.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
<div id="section-6.1-2">
<pre class="lang-tls-presentation sourcecode">
enum {
    supported_profiles(1),
    unsupported_version(2),
    media_keys(3),
    tunneled_dtls(4),
    endpoint_disconnect(5),
    (255)
} MsgType;

opaque uuid[16];

struct {
    MsgType msg_type;
    uint16 length;
    select (MsgType) {
        case supported_profiles:  SupportedProfiles;
        case unsupported_version: UnsupportedVersion;
        case media_keys:          MediaKeys;
        case tunneled_dtls:       TunneledDtls;
        case endpoint_disconnect: EndpointDisconnect;
  } body;
} TunnelMessage;
</pre><a href="#section-6.1-2" class="pilcrow">¶</a>
</div>
<p id="section-6.1-3">The elements of <code>TunnelMessage</code> include:<a href="#section-6.1-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-6.1-4">
          <dt id="section-6.1-4.1">
<code>msg_type</code>:</dt>
          <dd style="margin-left: 1.5em" id="section-6.1-4.2">the type of message contained within the structure <code>body</code>.<a href="#section-6.1-4.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-6.1-4.3">
<code>length</code>:</dt>
          <dd style="margin-left: 1.5em" id="section-6.1-4.4">the length in octets of the following <code>body</code> of the message.<a href="#section-6.1-4.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-6.1-4.5">
<code>body</code>:</dt>
          <dd style="margin-left: 1.5em" id="section-6.1-4.6">the actual message being conveyed within this <code>TunnelMessage</code> structure.<a href="#section-6.1-4.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="supportedprofiles-message">
<section id="section-6.2">
        <h3 id="name-supportedprofiles-message">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-supportedprofiles-message" class="section-name selfRef">SupportedProfiles Message</a>
        </h3>
<p id="section-6.2-1">The <code>SupportedProfiles</code> message is defined as:<a href="#section-6.2-1" class="pilcrow">¶</a></p>
<div id="section-6.2-2">
<pre class="lang-tls-presentation sourcecode">
uint8 SRTPProtectionProfile[2]; /* from RFC 5764 */

struct {
    uint8 version;
    SRTPProtectionProfile protection_profiles&lt;2..2^16-1&gt;;
} SupportedProfiles;
</pre><a href="#section-6.2-2" class="pilcrow">¶</a>
</div>
<p id="section-6.2-3">The elements of <code>SupportedProfiles</code> include:<a href="#section-6.2-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-6.2-4">
          <dt id="section-6.2-4.1">
<code>version</code>:</dt>
          <dd style="margin-left: 1.5em" id="section-6.2-4.2">this document specifies version 0x00.<a href="#section-6.2-4.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-6.2-4.3">
<code>protection_profiles</code>:</dt>
          <dd style="margin-left: 1.5em" id="section-6.2-4.4">the list of two-octet SRTP protection profile
  values, as per <span>[<a href="#RFC5764" class="xref">RFC5764</a>]</span>, supported by the Media Distributor.<a href="#section-6.2-4.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="unsupportedversion-message">
<section id="section-6.3">
        <h3 id="name-unsupportedversion-message">
<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-unsupportedversion-message" class="section-name selfRef">UnsupportedVersion Message</a>
        </h3>
<p id="section-6.3-1">The <code>UnsupportedVersion</code> message is defined as:<a href="#section-6.3-1" class="pilcrow">¶</a></p>
<div id="section-6.3-2">
<pre class="lang-tls-presentation sourcecode">
struct {
    uint8 highest_version;
} UnsupportedVersion;
</pre><a href="#section-6.3-2" class="pilcrow">¶</a>
</div>
<p id="section-6.3-3"><code>UnsupportedVersion</code> contains this single element:<a href="#section-6.3-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-6.3-4">
          <dt id="section-6.3-4.1">
<code>highest_version</code>:</dt>
          <dd style="margin-left: 1.5em" id="section-6.3-4.2">indicates the highest version of the protocol supported
  by the Key Distributor.<a href="#section-6.3-4.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="mediakeys-message">
<section id="section-6.4">
        <h3 id="name-mediakeys-message">
<a href="#section-6.4" class="section-number selfRef">6.4. </a><a href="#name-mediakeys-message" class="section-name selfRef">MediaKeys Message</a>
        </h3>
<p id="section-6.4-1">The <code>MediaKeys</code> message is defined as:<a href="#section-6.4-1" class="pilcrow">¶</a></p>
<div id="section-6.4-2">
<pre class="lang-tls-presentation sourcecode">
struct {
    uuid association_id;
    SRTPProtectionProfile protection_profile;
    opaque mki&lt;0..255&gt;;
    opaque client_write_SRTP_master_key&lt;1..255&gt;;
    opaque server_write_SRTP_master_key&lt;1..255&gt;;
    opaque client_write_SRTP_master_salt&lt;1..255&gt;;
    opaque server_write_SRTP_master_salt&lt;1..255&gt;;
} MediaKeys;
</pre><a href="#section-6.4-2" class="pilcrow">¶</a>
</div>
<p id="section-6.4-3">The fields are described as follows:<a href="#section-6.4-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-6.4-4">
          <dt id="section-6.4-4.1">
<code>association_id</code>:</dt>
          <dd style="margin-left: 1.5em" id="section-6.4-4.2">a value that identifies a distinct DTLS association
  between an endpoint and the Key Distributor.<a href="#section-6.4-4.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-6.4-4.3">
<code>protection_profiles</code>:</dt>
          <dd style="margin-left: 1.5em" id="section-6.4-4.4">the value of the two-octet SRTP protection
  profile value, as per <span>[<a href="#RFC5764" class="xref">RFC5764</a>]</span>, used for this DTLS association.<a href="#section-6.4-4.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-6.4-4.5">
<code>mki</code>:</dt>
          <dd style="margin-left: 1.5em" id="section-6.4-4.6">master key identifier <span>[<a href="#RFC3711" class="xref">RFC3711</a>]</span>; a zero-length field indicates
  that no MKI value is present.<a href="#section-6.4-4.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-6.4-4.7">
<code>client_write_SRTP_master_key</code>:</dt>
          <dd style="margin-left: 1.5em" id="section-6.4-4.8">the value of the SRTP master key used by the client (endpoint).<a href="#section-6.4-4.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-6.4-4.9">
<code>server_write_SRTP_master_key</code>:</dt>
          <dd style="margin-left: 1.5em" id="section-6.4-4.10">the value of the SRTP master key used by the server (Media Distributor).<a href="#section-6.4-4.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-6.4-4.11">
<code>client_write_SRTP_master_salt</code>:</dt>
          <dd style="margin-left: 1.5em" id="section-6.4-4.12">the value of the SRTP master salt used by the client (endpoint).<a href="#section-6.4-4.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-6.4-4.13">
<code>server_write_SRTP_master_salt</code>:</dt>
          <dd style="margin-left: 1.5em" id="section-6.4-4.14">the value of the SRTP master salt used by the server (Media Distributor).<a href="#section-6.4-4.14" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="tunneleddtls-message">
<section id="section-6.5">
        <h3 id="name-tunneleddtls-message">
<a href="#section-6.5" class="section-number selfRef">6.5. </a><a href="#name-tunneleddtls-message" class="section-name selfRef">TunneledDtls Message</a>
        </h3>
<p id="section-6.5-1">The <code>TunneledDtls</code> message is defined as:<a href="#section-6.5-1" class="pilcrow">¶</a></p>
<div id="section-6.5-2">
<pre class="lang-tls-presentation sourcecode">
struct {
    uuid association_id;
    opaque dtls_message&lt;1..2^16-1&gt;;
} TunneledDtls;
</pre><a href="#section-6.5-2" class="pilcrow">¶</a>
</div>
<p id="section-6.5-3">The fields are described as follows:<a href="#section-6.5-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-6.5-4">
          <dt id="section-6.5-4.1">
<code>association_id</code>:</dt>
          <dd style="margin-left: 1.5em" id="section-6.5-4.2">a value that identifies a distinct DTLS association
  between an endpoint and the Key Distributor.<a href="#section-6.5-4.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-6.5-4.3">
<code>dtls_message</code>:</dt>
          <dd style="margin-left: 1.5em" id="section-6.5-4.4">the content of the DTLS message received by the
  endpoint or to be sent to the endpoint, including one or more complete
  DTLS records.<a href="#section-6.5-4.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="endpointdisconnect-message">
<section id="section-6.6">
        <h3 id="name-endpointdisconnect-message">
<a href="#section-6.6" class="section-number selfRef">6.6. </a><a href="#name-endpointdisconnect-message" class="section-name selfRef">EndpointDisconnect Message</a>
        </h3>
<p id="section-6.6-1">The <code>EndpointDisconnect</code> message is defined as:<a href="#section-6.6-1" class="pilcrow">¶</a></p>
<div id="section-6.6-2">
<pre class="lang-tls-presentation sourcecode">
struct {
    uuid association_id;
} EndpointDisconnect;
</pre><a href="#section-6.6-2" class="pilcrow">¶</a>
</div>
<p id="section-6.6-3">The field is described as follows:<a href="#section-6.6-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-6.6-4">
          <dt id="section-6.6-4.1">
<code>association_id</code>:</dt>
          <dd style="margin-left: 1.5em" id="section-6.6-4.2">a value that identifies a distinct DTLS association
  between an endpoint and the Key Distributor.<a href="#section-6.6-4.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
<div id="example-binary-encoding">
<section id="section-7">
      <h2 id="name-example-binary-encoding">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-example-binary-encoding" class="section-name selfRef">Example Binary Encoding</a>
      </h2>
<p id="section-7-1">The <code>TunnelMessage</code> is encoded in binary, following the procedures
  specified in <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span>.  This section provides an example of what
  the bits on the wire would look like for the <code>SupportedProfiles</code>
  message that advertises support for both
  <code>DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM</code> and
  <code>DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM</code> <span>[<a href="#RFC8723" class="xref">RFC8723</a>]</span>.<a href="#section-7-1" class="pilcrow">¶</a></p>
<div id="section-7-2">
<pre class="sourcecode">
TunnelMessage:
         message_type: 0x01
               length: 0x0007
    SupportedProfiles:
                   version:  0x00
       protection_profiles:  0x0004 (length)
                             0x0009000A (value)
</pre><a href="#section-7-2" class="pilcrow">¶</a>
</div>
<p id="section-7-3">Thus, the encoding on the wire, presented here in network byte order,
would be this stream of octets:<a href="#section-7-3" class="pilcrow">¶</a></p>
<div id="section-7-4">
<pre class="sourcecode">
0x0100070000040009000A
</pre><a href="#section-7-4" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="iana-considerations">
<section id="section-8">
      <h2 id="name-iana-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-8-1">This document establishes the "Datagram Transport Layer Security (DTLS) Tunnel Protocol Message Types for Privacy Enhanced Conferencing" registry to contain message type
  values used in the DTLS tunnel protocol.  These message type values are a
  single octet in length.  This document defines the values shown in
  <a href="#message_types" class="xref">Table 1</a> below, leaving the balance of possible values
  reserved for future specifications:<a href="#section-8-1" class="pilcrow">¶</a></p>
<span id="name-message-type-values-for-the"></span><div id="message_types">
<table class="center" id="table-1">
        <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-message-type-values-for-the" class="selfRef">Message Type Values for the DTLS Tunnel Protocol</a>
        </caption>
<thead>
          <tr>
            <th class="text-center" rowspan="1" colspan="1">MsgType</th>
            <th class="text-left" rowspan="1" colspan="1">Description</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-center" rowspan="1" colspan="1">0x01</td>
            <td class="text-left" rowspan="1" colspan="1">Supported SRTP Protection Profiles</td>
          </tr>
          <tr>
            <td class="text-center" rowspan="1" colspan="1">0x02</td>
            <td class="text-left" rowspan="1" colspan="1">Unsupported Version</td>
          </tr>
          <tr>
            <td class="text-center" rowspan="1" colspan="1">0x03</td>
            <td class="text-left" rowspan="1" colspan="1">Media Keys</td>
          </tr>
          <tr>
            <td class="text-center" rowspan="1" colspan="1">0x04</td>
            <td class="text-left" rowspan="1" colspan="1">Tunneled DTLS</td>
          </tr>
          <tr>
            <td class="text-center" rowspan="1" colspan="1">0x05</td>
            <td class="text-left" rowspan="1" colspan="1">Endpoint Disconnect</td>
          </tr>
        </tbody>
      </table>
</div>
<p id="section-8-3">The value 0x00 is reserved, and all values in the range 0x06 to 0xFF are
available for allocation.  The procedures for updating this table are those
defined as "IETF Review" in <span><a href="https://www.rfc-editor.org/rfc/rfc8126#section-4.8" class="relref">Section 4.8</a> of [<a href="#RFC8126" class="xref">RFC8126</a>]</span>.<a href="#section-8-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="security-considerations">
<section id="section-9">
      <h2 id="name-security-considerations">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-9-1">Since the procedures in this document rely on TLS <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span> for transport
security, the security considerations for TLS should be reviewed when
implementing the protocol defined in this document.<a href="#section-9-1" class="pilcrow">¶</a></p>
<p id="section-9-2">While the tunneling protocol defined in this document does not use
DTLS-SRTP <span>[<a href="#RFC5764" class="xref">RFC5764</a>]</span> directly, it does convey and negotiate some of the
same information (e.g., protection profile data).  As such, a review of the
security considerations found in that document may be useful.<a href="#section-9-2" class="pilcrow">¶</a></p>
<p id="section-9-3">This document describes a means of securely exchanging keying material and
cryptographic transforms for both E2E and HBH encryption and authentication of
media between an endpoint and a Key Distributor via a Media Distributor.
Additionally, the procedures result in delivering HBH information to the
intermediary Media Distributor.  The Key Distributor and endpoint are the only
two entities with access to both the E2E and HBH keys, while the Media
Distributor has access to only HBH information.  <span><a href="https://www.rfc-editor.org/rfc/rfc8871#section-8.2" class="relref">Section 8.2</a> of [<a href="#RFC8871" class="xref">RFC8871</a>]</span>
enumerates various attacks against which one must guard when implementing a
Media Distributor; these scenarios are important to note.<a href="#section-9-3" class="pilcrow">¶</a></p>
<p id="section-9-4">A requirement in this document is that a TLS connection between the Media
Distributor and the Key Distributor be mutually authenticated.  The reason
for this requirement is to ensure that only an authorized Media Distributor
receives the HBH keying material.  If an unauthorized Media Distributor gains
access to the HBH keying material, it can easily cause service degradation or
denial by transmitting HBH-valid packets that ultimately fail E2E
authentication or replay protection checks (see <span><a href="https://www.rfc-editor.org/rfc/rfc3711#section-3.3.2" class="relref">Section 3.3.2</a> of [<a href="#RFC3711" class="xref">RFC3711</a>]</span>).
Even if service does not appear degraded in any way, transmitting and
processing bogus packets are a waste of both computational and network
resources.<a href="#section-9-4" class="pilcrow">¶</a></p>
<p id="section-9-5">The procedures defined in this document assume that the Media Distributor
will properly convey DTLS messages between the endpoint and Key Distributor.
Should it fail in that responsibility by forwarding DTLS messages from
endpoint A advertised as being from endpoint B, this will result in
a failure at the DTLS layer of those DTLS sessions.  This could be an additional
attack vector that Key Distributor implementations should consider.<a href="#section-9-5" class="pilcrow">¶</a></p>
<p id="section-9-6">While E2E keying material passes through the Media Distributor via the protocol
defined in this document, the Media Distributor has no means of gaining access
to that information and therefore cannot affect the E2E media processing
function in the endpoint except to present it with invalid or replayed data.
That said, any entity along the path that interferes with the DTLS exchange
between the endpoint and the Key Distributor, including a malicious Media
Distributor that is not properly authorized, could prevent an endpoint from
properly communicating with the Key Distributor and therefore prevent
successful conference participation.<a href="#section-9-6" class="pilcrow">¶</a></p>
<p id="section-9-7">It is worth noting that a compromised Media Distributor can convey
information to an adversary, such as participant IP addresses,
negotiated protection profiles, or other metadata.
  While <span>[<a href="#RFC8871" class="xref">RFC8871</a>]</span> explains that
a malicious or compromised Media Distributor can disrupt communications,
an additional attack vector introduced by this protocol is the potential
disruption of DTLS negotiation or premature removal of a participant from
a conference by sending an <code>EndpointDisconnect</code> message to the
Key Distributor.<a href="#section-9-7" class="pilcrow">¶</a></p>
<p id="section-9-8">The Key Distributor should be aware of the possibility that a malicious
Media Distributor might transmit an <code>EndpointDisconnect</code> message to the Key
Distributor  when the endpoint is in fact still connected.<a href="#section-9-8" class="pilcrow">¶</a></p>
<p id="section-9-9">While the Security Considerations section of <span>[<a href="#RFC8871" class="xref">RFC8871</a>]</span> describes various
attacks one needs to consider with respect to the Key Distributor and
denial of service, use of this protocol introduces another possible
attack vector.  Consider the case where a malicious endpoint sends unsolicited
DTLS-SRTP messages to a Media Distributor.  The Media Distributor will normally
forward those messages to the Key Distributor and, if found invalid, such
messages only serve to consume resources on both the Media Distributor and
Key Distributor.<a href="#section-9-9" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-10">
      <h2 id="name-references">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-10.1">
        <h3 id="name-normative-references">
<a href="#section-10.1" class="section-number selfRef">10.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="RFC3711">[RFC3711]</dt>
        <dd>
<span class="refAuthor">Baugher, M.</span>, <span class="refAuthor">McGrew, D.</span>, <span class="refAuthor">Naslund, M.</span>, <span class="refAuthor">Carrara, E.</span>, and <span class="refAuthor">K. Norrman</span>, <span class="refTitle">"The Secure Real-time Transport Protocol (SRTP)"</span>, <span class="seriesInfo">RFC 3711</span>, <span class="seriesInfo">DOI 10.17487/RFC3711</span>, <time datetime="2004-03" class="refDate">March 2004</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3711">https://www.rfc-editor.org/info/rfc3711</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4122">[RFC4122]</dt>
        <dd>
<span class="refAuthor">Leach, P.</span>, <span class="refAuthor">Mealling, M.</span>, and <span class="refAuthor">R. Salz</span>, <span class="refTitle">"A Universally Unique IDentifier (UUID) URN Namespace"</span>, <span class="seriesInfo">RFC 4122</span>, <span class="seriesInfo">DOI 10.17487/RFC4122</span>, <time datetime="2005-07" class="refDate">July 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4122">https://www.rfc-editor.org/info/rfc4122</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5764">[RFC5764]</dt>
        <dd>
<span class="refAuthor">McGrew, D.</span> and <span class="refAuthor">E. Rescorla</span>, <span class="refTitle">"Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)"</span>, <span class="seriesInfo">RFC 5764</span>, <span class="seriesInfo">DOI 10.17487/RFC5764</span>, <time datetime="2010-05" class="refDate">May 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5764">https://www.rfc-editor.org/info/rfc5764</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8122">[RFC8122]</dt>
        <dd>
<span class="refAuthor">Lennox, J.</span> and <span class="refAuthor">C. Holmberg</span>, <span class="refTitle">"Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)"</span>, <span class="seriesInfo">RFC 8122</span>, <span class="seriesInfo">DOI 10.17487/RFC8122</span>, <time datetime="2017-03" class="refDate">March 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8122">https://www.rfc-editor.org/info/rfc8122</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="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="RFC8723">[RFC8723]</dt>
        <dd>
<span class="refAuthor">Jennings, C.</span>, <span class="refAuthor">Jones, P.</span>, <span class="refAuthor">Barnes, R.</span>, and <span class="refAuthor">A.B. Roach</span>, <span class="refTitle">"Double Encryption Procedures for the Secure Real-Time Transport Protocol (SRTP)"</span>, <span class="seriesInfo">RFC 8723</span>, <span class="seriesInfo">DOI 10.17487/RFC8723</span>, <time datetime="2020-04" class="refDate">April 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8723">https://www.rfc-editor.org/info/rfc8723</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8842">[RFC8842]</dt>
        <dd>
<span class="refAuthor">Holmberg, C.</span> and <span class="refAuthor">R. Shpount</span>, <span class="refTitle">"Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)"</span>, <span class="seriesInfo">RFC 8842</span>, <span class="seriesInfo">DOI 10.17487/RFC8842</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8842">https://www.rfc-editor.org/info/rfc8842</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8844">[RFC8844]</dt>
        <dd>
<span class="refAuthor">Thomson, M.</span> and <span class="refAuthor">E. Rescorla</span>, <span class="refTitle">"Unknown Key-Share Attacks on Uses of TLS with the Session Description Protocol (SDP)"</span>, <span class="seriesInfo">RFC 8844</span>, <span class="seriesInfo">DOI 10.17487/RFC8844</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8844">https://www.rfc-editor.org/info/rfc8844</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8871">[RFC8871]</dt>
        <dd>
<span class="refAuthor">Jones, P.</span>, <span class="refAuthor">Benham, D.</span>, and <span class="refAuthor">C. Groves</span>, <span class="refTitle">"A Solution Framework for Private Media in Privacy-Enhanced RTP Conferencing (PERC)"</span>, <span class="seriesInfo">RFC 8871</span>, <span class="seriesInfo">DOI 10.17487/RFC8871</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8871">https://www.rfc-editor.org/info/rfc8871</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9147">[RFC9147]</dt>
      <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refAuthor">Tschofenig, H.</span>, and <span class="refAuthor">N. Modadugu</span>, <span class="refTitle">"The Datagram Transport Layer Security (DTLS) Protocol Version 1.3"</span>, <span class="seriesInfo">RFC 9147</span>, <span class="seriesInfo">DOI 10.17487/RFC9147</span>, <time datetime="2022-04" class="refDate">April 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9147">https://www.rfc-editor.org/info/rfc9147</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-10.2">
        <h3 id="name-informative-references">
<a href="#section-10.2" class="section-number selfRef">10.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="RFC3264">[RFC3264]</dt>
        <dd>
<span class="refAuthor">Rosenberg, J.</span> and <span class="refAuthor">H. Schulzrinne</span>, <span class="refTitle">"An Offer/Answer Model with Session Description Protocol (SDP)"</span>, <span class="seriesInfo">RFC 3264</span>, <span class="seriesInfo">DOI 10.17487/RFC3264</span>, <time datetime="2002-06" class="refDate">June 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3264">https://www.rfc-editor.org/info/rfc3264</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3550">[RFC3550]</dt>
        <dd>
<span class="refAuthor">Schulzrinne, H.</span>, <span class="refAuthor">Casner, S.</span>, <span class="refAuthor">Frederick, R.</span>, and <span class="refAuthor">V. Jacobson</span>, <span class="refTitle">"RTP: A Transport Protocol for Real-Time Applications"</span>, <span class="seriesInfo">STD 64</span>, <span class="seriesInfo">RFC 3550</span>, <span class="seriesInfo">DOI 10.17487/RFC3550</span>, <time datetime="2003-07" class="refDate">July 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3550">https://www.rfc-editor.org/info/rfc3550</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8126">[RFC8126]</dt>
        <dd>
<span class="refAuthor">Cotton, M.</span>, <span class="refAuthor">Leiba, B.</span>, and <span class="refAuthor">T. Narten</span>, <span class="refTitle">"Guidelines for Writing an IANA Considerations Section in RFCs"</span>, <span class="seriesInfo">BCP 26</span>, <span class="seriesInfo">RFC 8126</span>, <span class="seriesInfo">DOI 10.17487/RFC8126</span>, <time datetime="2017-06" class="refDate">June 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8866">[RFC8866]</dt>
      <dd>
<span class="refAuthor">Begen, A.</span>, <span class="refAuthor">Kyzivat, P.</span>, <span class="refAuthor">Perkins, C.</span>, and <span class="refAuthor">M. Handley</span>, <span class="refTitle">"SDP: Session Description Protocol"</span>, <span class="seriesInfo">RFC 8866</span>, <span class="seriesInfo">DOI 10.17487/RFC8866</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8866">https://www.rfc-editor.org/info/rfc8866</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="acknowledgements">
<section id="appendix-A">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="appendix-A-1">The authors would like to thank <span class="contact-name">David Benham</span> and <span class="contact-name">Cullen Jennings</span> for reviewing this document and providing constructive
  comments.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="appendix-B">
      <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">Paul E. Jones</span></div>
<div dir="auto" class="left"><span class="org">Cisco Systems, Inc.</span></div>
<div dir="auto" class="left"><span class="street-address">7025 Kit Creek Rd.</span></div>
<div dir="auto" class="left">
<span class="locality">Research Triangle Park</span>, <span class="region">North Carolina</span> <span class="postal-code">27709</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+1%20919%20476%202048" class="tel">+1 919 476 2048</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:paulej@packetizer.com" class="email">paulej@packetizer.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Paul M. Ellenbogen</span></div>
<div dir="auto" class="left"><span class="org">Princeton University</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+1%20206%20851%202069" class="tel">+1 206 851 2069</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:pe5@cs.princeton.edu" class="email">pe5@cs.princeton.edu</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Nils H. Ohlmeier</span></div>
<div dir="auto" class="left"><span class="org">8x8, Inc.</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+1%20408%20659%206457" class="tel">+1 408 659 6457</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:nils@ohlmeier.org" class="email">nils@ohlmeier.org</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>