File: rfc8953.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 (2142 lines) | stat: -rw-r--r-- 91,204 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 8953: Coordinating Attack Response at Internet Scale 2 (CARIS2) Workshop Report</title>
<meta content="Kathleen M. Moriarty" name="author">
<meta content="
       The Coordinating Attack Response at Internet Scale (CARIS) 2
      workshop, sponsored by the Internet Society, took place on 28 February
      and 1 March 2019 in Cambridge, Massachusetts, USA. Participants spanned
      regional, national, international, and enterprise Computer Security
      Incident Response Teams (CSIRTs), operators, service providers, network
      and security operators, transport operators and researchers, incident
      response researchers, vendors, and participants from standards
      communities. This workshop continued the work started at the first CARIS
      workshop, with a focus on scaling incident prevention and detection as
      the Internet industry moves to a stronger and a more ubiquitous
      deployment of session encryption. 
    " name="description">
<meta content="xml2rfc 3.5.0" name="generator">
<meta content="Network Management" name="keyword">
<meta content="Attack Response" name="keyword">
<meta content="CARIS" name="keyword">
<meta content="Incident" name="keyword">
<meta content="8953" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.5.0
    Python 3.6.10
    appdirs 1.4.4
    ConfigArgParse 1.2.3
    google-i18n-address 2.3.5
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.2
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.19.0
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.3.1
    requests 2.22.0
    setuptools 40.6.2
    six 1.14.0
    WeasyPrint 51
-->
<link href="rfc8953.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

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

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

*/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.refInstance {
  margin-bottom: 1.25em;
}

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

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

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

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

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

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

/* pagination */
@media print {
  body {

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

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

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

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

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

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

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

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

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

}

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8953" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-moriarty-caris2-04" 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 8953</td>
<td class="center">CARIS2 Report</td>
<td class="right">December 2020</td>
</tr></thead>
<tfoot><tr>
<td class="left">Moriarty</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">Independent Submission</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc8953" class="eref">8953</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2020-12" class="published">December 2020</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Author:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">K. Moriarty</div>
<div class="org">Center for Internet Security</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8953</h1>
<h1 id="title">Coordinating Attack Response at Internet Scale 2 (CARIS2) Workshop Report</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">The Coordinating Attack Response at Internet Scale (CARIS) 2
      workshop, sponsored by the Internet Society, took place on 28 February
      and 1 March 2019 in Cambridge, Massachusetts, USA. Participants spanned
      regional, national, international, and enterprise Computer Security
      Incident Response Teams (CSIRTs), operators, service providers, network
      and security operators, transport operators and researchers, incident
      response researchers, vendors, and participants from standards
      communities. This workshop continued the work started at the first CARIS
      workshop, with a focus on scaling incident prevention and detection as
      the Internet industry moves to a stronger and a more ubiquitous
      deployment of session encryption.<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 is a contribution to the RFC Series, independently of any
            other RFC stream.  The RFC Editor has chosen to publish this
            document at its discretion and makes no statement about its value
            for implementation or deployment.  Documents approved for
            publication by the RFC Editor are not 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/rfc8953">https://www.rfc-editor.org/info/rfc8953</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) 2020 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.<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="toc ulEmpty compact">
<li class="toc ulEmpty compact" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty compact" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-accepted-papers" class="xref">Accepted Papers</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty compact" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1" class="keepWithNext"><a href="#section-3" class="xref">3</a>.  <a href="#name-caris2-goals" class="xref">CARIS2 Goals</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty compact" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-workshop-collaboration" class="xref">Workshop Collaboration</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty compact">
<li class="toc ulEmpty compact" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-breakout-1-results-standard" class="xref">Breakout 1 Results: Standardization and Adoption</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty compact">
<li class="toc ulEmpty compact" id="section-toc.1-1.4.2.1.2.1">
                    <p id="section-toc.1-1.4.2.1.2.1.1"><a href="#section-4.1.1" class="xref">4.1.1</a>.  <a href="#name-wide-adoption" class="xref">Wide Adoption</a><a href="#section-toc.1-1.4.2.1.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty compact" id="section-toc.1-1.4.2.1.2.2">
                    <p id="section-toc.1-1.4.2.1.2.2.1"><a href="#section-4.1.2" class="xref">4.1.2</a>.  <a href="#name-limited-adoption" class="xref">Limited Adoption</a><a href="#section-toc.1-1.4.2.1.2.2.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-breakout-2-results-preventa" class="xref">Breakout 2 Results: Preventative Protocols and Scaling Defense</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-breakout-3-results-incident" class="xref">Breakout 3 Results: Incident Response Coordination</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.4.2.4">
                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-breakout-4-results-monitori" class="xref">Breakout 4 Results: Monitoring and Measurement</a><a href="#section-toc.1-1.4.2.4.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty compact">
<li class="toc ulEmpty compact" id="section-toc.1-1.4.2.4.2.1">
                    <p id="section-toc.1-1.4.2.4.2.1.1"><a href="#section-4.4.1" class="xref">4.4.1</a>.  <a href="#name-ip-address-reputation" class="xref">IP Address Reputation</a><a href="#section-toc.1-1.4.2.4.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty compact" id="section-toc.1-1.4.2.4.2.2">
                    <p id="section-toc.1-1.4.2.4.2.2.1"><a href="#section-4.4.2" class="xref">4.4.2</a>.  <a href="#name-server-name-authentication-" class="xref">Server Name Authentication Reputation C (SNARC)</a><a href="#section-toc.1-1.4.2.4.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty compact" id="section-toc.1-1.4.2.4.2.3">
                    <p id="section-toc.1-1.4.2.4.2.3.1"><a href="#section-4.4.3" class="xref">4.4.3</a>.  <a href="#name-logging" class="xref">Logging</a><a href="#section-toc.1-1.4.2.4.2.3.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty compact" id="section-toc.1-1.4.2.4.2.4">
                    <p id="section-toc.1-1.4.2.4.2.4.1"><a href="#section-4.4.4" class="xref">4.4.4</a>.  <a href="#name-fingerprinting" class="xref">Fingerprinting</a><a href="#section-toc.1-1.4.2.4.2.4.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="toc ulEmpty compact" id="section-toc.1-1.4.2.5">
                <p id="section-toc.1-1.4.2.5.1"><a href="#section-4.5" class="xref">4.5</a>.  <a href="#name-taxonomy-and-gaps-session" class="xref">Taxonomy and Gaps Session</a><a href="#section-toc.1-1.4.2.5.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty compact" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-next-steps" class="xref">Next Steps</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty compact" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-summary" class="xref">Summary</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty compact" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty compact" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty compact" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty compact">
<li class="toc ulEmpty compact" id="section-toc.1-1.9.2.1">
                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty compact" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty compact" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-authors-address" class="xref">Author's Address</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">The Coordinating Attack Response at Internet Scale (CARIS) 2
      workshop <span>[<a href="#CARISEvent" class="xref">CARISEvent</a>]</span>, sponsored by the
      Internet Society, took place on 28 February and 1 
      March 2019 in Cambridge, Massachusetts, USA. Participants spanned
      regional, national, international, and enterprise Computer Security
      Incident Response Teams (CSIRTs), operators, 
      service providers, network and security operators, transport operators
      and researchers, incident response researchers, vendors, and
      participants from standards communities. This workshop continued the
      work started at the first CARIS workshop <span>[<a href="#RFC8073" class="xref">RFC8073</a>]</span>, with a focus on scaling 
      incident prevention and detection as the Internet industry moves to
      a stronger and a more ubiquitous deployment of session encryption.

      Considering the related initiative to form a research group (Stopping
      Malware and Researching Threats <span>[<a href="#SMART" class="xref">SMART</a>]</span>) in the
      Internet Research Task Force (IRTF), the focus on prevention included
      consideration of research opportunities to improve protocols and
      determine if there are ways to improve attack detection during
      the protocol design phase that could later influence protocol
      development in the IETF. This is one way to think about scaling
      response, through prevention and allowing for new methods to evolve for
      detection in a post-encrypted world.

Although the proposed SMART Research Group has not yet progressed, the work to better
scale incident response continues through the projects proposed at CARIS2 as
well as in future CARIS workshops.<a href="#section-1-1" class="pilcrow">¶</a></p>
</section>
<section id="section-2">
      <h2 id="name-accepted-papers">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-accepted-papers" class="section-name selfRef">Accepted Papers</a>
      </h2>
<p id="section-2-1">Researchers from around the world submitted position and research
      papers summarizing key aspects of their work to help form the shared
      content of the workshop. 

The accepted papers may be found at <span>[<a href="#CARISEvent" class="xref">CARISEvent</a>]</span> and include:<a href="#section-2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2-2.1">
          <p id="section-2-2.1.1">Visualizing Security Automation: <span class="contact-name">Takeshi         Takahashi</span>, NICT, Japan<a href="#section-2-2.1.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-2-2.2">
          <p id="section-2-2.2.1">Automating Severity Determination: <span class="contact-name">Hideaki         Kanehara</span>, NICT, Japan<a href="#section-2-2.2.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-2-2.3">
          <p id="section-2-2.3.1">OASIS's OpenC2: Draper and DoD<a href="#section-2-2.3.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-2-2.4">
          <p id="section-2-2.4.1">Automated IoT Security: <span class="contact-name">Oscar Garcia-Morchon</span> and
          <span class="contact-name">Thorsten Dahm</span><a href="#section-2-2.4.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-2-2.5">
          <p id="section-2-2.5.1">Taxonomies and Gaps: <span class="contact-name">Kirsty P.</span>, UK NCSC<a href="#section-2-2.5.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-2-2.6">
          <p id="section-2-2.6.1">FIRST: <span class="contact-name">Thomas Schreck</span>, Siemens<a href="#section-2-2.6.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-2-2.7">
          <p id="section-2-2.7.1">NetSecWarriors: <span class="contact-name">Tim April</span>, Akamai<a href="#section-2-2.7.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-2-2.8">
          <p id="section-2-2.8.1">Measured Approaches to IPv6 Address Anonymization and Identity
        Association: <span class="contact-name">Dave Plonka</span> and <span class="contact-name">Arthur Berger</span>, Akamai<a href="#section-2-2.8.1" class="pilcrow">¶</a></p>
</li>
      </ul>
<p id="section-2-3">The program committee worked to fill in the agenda with meaningful
      and complementary sessions to round out the theme and encourage
      collaboration to advance research toward the goals of the workshop.
      These sessions included:<a href="#section-2-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2-4.1">
          <p id="section-2-4.1.1"> Manufacturer Usage Description (MUD) <span>[<a href="#RFC8520" class="xref">RFC8520</a>]</span>: <span class="contact-name">Eliot Lear</span>, Cisco<a href="#section-2-4.1.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-2-4.2">
          <p id="section-2-4.2.1">TF-CSIRT: <span class="contact-name">Mirjam Kühne</span>, RIPE NCC<a href="#section-2-4.2.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-2-4.3">
          <p id="section-2-4.3.1">M2M Sharing Revolution: <span class="contact-name">Scott Pinkerton</span>,
        DoE ANL<a href="#section-2-4.3.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-2-4.4">
          <p id="section-2-4.4.1">Comparing OpenC2 with existing efforts, e.g., <span><a href="#I2NSF" class="xref">I2NSF</a> [<a href="#I2NSF" class="xref">I2NSF</a>]</span>: <span class="contact-name">Chris Inacio</span><a href="#section-2-4.4.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-2-4.5">
          <p id="section-2-4.5.1">Alternate Sharing and Mitigation Models: <span class="contact-name">Kathleen Moriarty</span>, Dell EMC<a href="#section-2-4.5.1" class="pilcrow">¶</a></p>
</li>
      </ul>
<p id="section-2-5">The presentations provided interesting background to familiarize
      workshop attendees with current research work, challenges that must be
      addressed for forward progress, and opportunities to collaborate in the
      desire to better scale attack response and prevention.<a href="#section-2-5" class="pilcrow">¶</a></p>
</section>
<section id="section-3">
      <h2 id="name-caris2-goals">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-caris2-goals" class="section-name selfRef">CARIS2 Goals</a>
      </h2>
<p id="section-3-1">The goal of each CARIS workshop has been to focus on the challenge of
 improving the overall security posture.  The approach has been to
 identify intrinsic or built-in protection capabilities for improved defense,
 automation, and scaling attack response through collaboration and
 improved architectural patterns.  

It has been assumed that additional training will likely not address the lack
of information security professionals to fill the job gap.  Currently, there
is approximately a <span><a href="#deficit" class="xref">three-million-person deficit</a> [<a href="#deficit" class="xref">deficit</a>]</span>
for security professionals worldwide, and that is only expected to grow. In
preparing for the workshop, the chair and program committee considered that
this gap cannot be filled through training but requires measures to reduce the
number of information security professionals needed through new architectures
and research toward attack prevention. CARIS2 was specifically focused on the
industry shift toward the increased use of stronger session encryption (<span><a href="#RFC8446" class="xref">TLS 1.3</a> [<a href="#RFC8446" class="xref">RFC8446</a>]</span>, <span><a href="#I-D.ietf-quic-transport" class="xref">QUIC</a> [<a href="#I-D.ietf-quic-transport" class="xref">QUIC</a>]</span>, <span><a href="#RFC8548" class="xref">tcpcrypt</a> [<a href="#RFC8548" class="xref">RFC8548</a>]</span>, etc.) and how prevention and detection can
advance in this new paradigm. As such, the goals for this workshop
included:<a href="#section-3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3-2.1">
          <p id="section-3-2.1.1">Scale attack response, including ways to improve prevention, as
          the Internet shifts to use of stronger and more ubiquitous
          encryption.<a href="#section-3-2.1.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3-2.1.2.1">Determine research opportunities<a href="#section-3-2.1.2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3-2.1.2.2">Consider methods to improve protocols and provide guidance
            toward goal. For instance, are there ways to build detection of
            threats into protocols, since they cannot be monitored on the wire
            in the future?<a href="#section-3-2.1.2.2" class="pilcrow">¶</a>
</li>
          </ul>
</li>
        <li class="normal" id="section-3-2.2">Identify promising research ideas to seed a research agenda to
          input to the proposed IRTF SMART Research Group.<a href="#section-3-2.2" class="pilcrow">¶</a>
</li>
      </ul>
</section>
<section id="section-4">
      <h2 id="name-workshop-collaboration">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-workshop-collaboration" class="section-name selfRef">Workshop Collaboration</a>
      </h2>
<p id="section-4-1">Both CARIS workshops brought together a set of individuals who had
   not previously collaborated toward the goals of scaling attack
   response. 

 This is important as the participants span various areas of Internet
 technology work, conduct research, provide a global perspective, have access
 to varying data sets and infrastructure, and are influential in their area of
 expertise.

The specific goals, contributions, and participants of the CARIS2 workshop
were all considered in the design of the breakout sessions to both identify
and advance research through collaboration.

The breakout sessions varied in format to keep attendees engaged and
collaborating; some involved the full set of attendees while others utilized
groups.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">
   The workshop focused on identifying potential areas for collaboration and
   advancing research.<a href="#section-4-2" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-4-3">
      <li id="section-4-3.1">Standardization and Adoption: identify widely adopted and pervasive
      standard protocols and data formats as well as those that failed.<a href="#section-4-3.1" class="pilcrow">¶</a>
</li>
        <li id="section-4-3.2">Preventative Protocols and Scaling Defense: identify protocols to
      address automation at scale.<a href="#section-4-3.2" class="pilcrow">¶</a>
</li>
        <li id="section-4-3.3">Incident Response Coordination: brainstorm what potential areas
      of research or future workshops could be held to improve on the
      scalability of incident response.<a href="#section-4-3.3" class="pilcrow">¶</a>
</li>
        <li id="section-4-3.4">Monitoring and Measurement: brainstorm methods to perform
      monitoring and measurement with the heightened need and requirement to
      address privacy.<a href="#section-4-3.4" class="pilcrow">¶</a>
</li>
        <li id="section-4-3.5">Taxonomy and Gaps: brainstorm a way forward for the proposed SMART
      Research Group.<a href="#section-4-3.5" class="pilcrow">¶</a>
</li>
      </ol>
<div id="breakout_1">
<section id="section-4.1">
        <h3 id="name-breakout-1-results-standard">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-breakout-1-results-standard" class="section-name selfRef">Breakout 1 Results: Standardization and Adoption</a>
        </h3>
<p id="section-4.1-1">This breakout session considered points raised in the preceding
        talks on hurdles for automating security controls, detection, and
        response; the teams presenting noted several challenges they still
        face today. The breakout session worked toward identifying standard protocols
        and data formats that succeeded in achieving adoption as well as
        several that failed or only achieved limited adoption. The results
        from the evaluation were interesting and could aid in achieving
        greater adoption when new work areas are developed.  The following
 subsections detail the results.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<section id="section-4.1.1">
          <h4 id="name-wide-adoption">
<a href="#section-4.1.1" class="section-number selfRef">4.1.1. </a><a href="#name-wide-adoption" class="section-name selfRef">Wide Adoption</a>
          </h4>
<p id="section-4.1.1-1">
   The Transport Layer Security (TLS) protocol has replaced the Secure Sockets
   Layer (SSL) protocol.<a href="#section-4.1.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1.1-2">Observations: There was a clear need for session encryption at the
        transport layer to protect application data. E-commerce was a driving
        force at the time with a downside to those who did not adopt. Other
        positive attributes that aided adoption were modular design, clean
        interfaces, and being first to market.<a href="#section-4.1.1-2" class="pilcrow">¶</a></p>
<p id="section-4.1.1-3">The Simple Network Management Protocol (SNMP) enables configuration
        management of devices with extension points for private configuration
        and management settings. SNMP is widely adopted and is only now, after
        decades, being replaced by a newer alternative, YANG (a data modeling
 language) that facilitates configuration management via the Network
 Configuration Protocol (NETCONF) or RESTCONF. SNMP facilitated an
        answer to a needed problem set: configuration, telemetry, and network
        management. Its development considered the connection between the
        user, vendor, and developers. Challenges did surface for adoption from
        SNMPv1.1 to 1.2, as there was no compelling reason for adoption. SNMPv3
        gained adoption due to its resilience to attacks by providing
        protection through improved authentication and encryption.<a href="#section-4.1.1-3" class="pilcrow">¶</a></p>
<p id="section-4.1.1-4">IP Flow Information Export (IPFIX) was identified as achieving wide
        adoption for several reasons. The low cost of entry, wide vendor
        support, diverse user base, and wide set of use cases spanning
        multiple technology areas were some of the key drivers cited.<a href="#section-4.1.1-4" class="pilcrow">¶</a></p>
<p id="section-4.1.1-5">X.509 was explored for its success in gaining adoption. The
        solution being abstract from crypto, open, customizable, and
        extensible were some of the reasons cited for its successful adoption.
        The team deemed it a good solution to a good problem and observed that
        government adoption aided its success.<a href="#section-4.1.1-5" class="pilcrow">¶</a></p>
</section>
<section id="section-4.1.2">
          <h4 id="name-limited-adoption">
<a href="#section-4.1.2" class="section-number selfRef">4.1.2. </a><a href="#name-limited-adoption" class="section-name selfRef">Limited Adoption</a>
          </h4>
<p id="section-4.1.2-1">Next, each team evaluated solutions that have not enjoyed wide
        adoption.<a href="#section-4.1.2-1" class="pilcrow">¶</a></p>
<p id="section-4.1.2-2">Although Structured Threat Information eXpression (STIX) and
 the Incident Object Description Exchange Format (IODEF) are somewhat similar in their goals, the
        standards were selected for evaluation by two separate groups with
        some common findings.<a href="#section-4.1.2-2" class="pilcrow">¶</a></p>
<p id="section-4.1.2-3">STIX
 has had limited adoption by the financial sector but no 
        single, definitive end user. The standard is still in development with
        the US government as the primary developer in partnership with OASIS.
        There is interest in using STIX to manage content, but users don't
        really care about what technology is used for the exchange. The
        initial goals may not wind up matching the end result for STIX, as
        managing content may be the primary use case.<a href="#section-4.1.2-3" class="pilcrow">¶</a></p>
<p id="section-4.1.2-4">IODEF was specified
        by National Research and Education Networks (NRENs) and Computer
 Security Incident Response Teams (CSIRTs) and formalized in the
 IETF <span>[<a href="#RFC7970" class="xref">RFC7970</a>]</span>. The user is the 
        security operations center (SOC). While there are several
        implementations, it is not widely adopted. In terms of exchange, users
        are more interested in indicators than full event information, and this
        applies to STIX as well. Sharing and trust are additional hurdles as
        many are not willing to disclose information.<a href="#section-4.1.2-4" class="pilcrow">¶</a></p>
<p id="section-4.1.2-5">DNS-Based Authentication of Named Entities (DANE) has DNSSEC as a
        dependency, which is a hurdle toward adoption (too many
        dependencies). It has a roll-your-own adoption model, which is risky.
        While there are some large pockets of adoption, there is still much
        work to do to gain widespread adoption. A regulatory requirement gave
        rise to partial adoption in Germany, which naturally resulted in
        production of documentation written in German -- possibly giving rise
        to further adoption in German-speaking countries. There has also been
        progress made in the Netherlands through the creation of a website:
        <span>&lt;<a href="internet.nl">internet.nl</a>&gt;</span>. The website allows you to test your website for a
        number of standards (IPv6, DNSSEC, DANE, etc.). <span>&lt;<a href="internet.nl">internet.nl</a>&gt;</span> is a
        collaboration of industry organizations, companies, and the government
        in the Netherlands and is available for worldwide use.<a href="#section-4.1.2-5" class="pilcrow">¶</a></p>
<p id="section-4.1.2-6">IP version 6 (IPv6) has struggled, and the expense of running a dual
        stack was one of the highest concerns on the list discussed in the
 workshop breakout. The end user for IPv6 is 
        everyone, and the breakout team considered it too ambiguous. Too many new requirements have been added
        over its 20-year life. The scope of necessary adoption is large with
        many peripheral devices. Government requirements for support have
        helped somewhat with improved interoperability and adoption, but
        features like NAT being added to IPv4 slowed adoption. With no new
        features being added to IPv4 and lessons learned, there's still a
        possibility for success.<a href="#section-4.1.2-6" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<section id="section-4.2">
        <h3 id="name-breakout-2-results-preventa">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-breakout-2-results-preventa" class="section-name selfRef">Breakout 2 Results: Preventative Protocols and Scaling Defense</a>
        </h3>
<p id="section-4.2-1">This breakout session followed the sessions on MUD, Protocol for
        Automated Vulnerability Assessment (PAVA), and Protocol for Automatic
        Security Configuration (PASC), which have themes of automation at scale. MUD
        was designed for Internet of Things (IoT), and as such, scaling was a major consideration.
        The PAVA and PASC work builds off of MUD and maintains some of the
        same themes. This breakout session was focused on groups brainstorming
        preventative measures and enabling vendors to deploy mitigations.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2-2">One group dove a bit deeper into MUD and layer 2 (L2) discovery.
        MUD changes sets of filtering control
        management to the vendor or intermediary MUD vendors for a predictable
        platform that scales well.  While the overall value of MUD is clear, the
        use of MUD and what traffic is expected for a particular device should be considered
        sensitive information, as it could be used to exploit a device. MUD has
        an option of using L2 discovery to share MUD files. L2 discovery, like
        the Dynamic Host Configuration Protocol (DHCP), is not encrypted from
        the local client to the DHCP server at this point in time (there is
        some interest to correct this, but it hasn't received enough support
        yet). As a result, it is possible to leak information and reveal data
        about the devices for which the MUD files would be applied. This could
        multicast out information such as network characteristics, firmware
        versions, manufacturers, etc. 



There was some discussion on the use of 802.11 to improve connections <span>[<a href="#IEEE802.11" class="xref">IEEE802.11</a>]</span>. Several participants from this group plan to research
this further and identify options to prevent information leakage while
achieving the stated goals of MUD.<a href="#section-4.2-2" class="pilcrow">¶</a></p>
<p id="section-4.2-3">The next group discussed a proposal one of the participants had
        already begun developing, namely privacy for rendezvous service. The
        basic idea was to encrypt Server Name Indication (SNI) using DNS to obtain public keys. The
        suffix on server IPv6 would be unique to a TLS session (information
        missing). The discussion on this proposal was fruitful, as the full set
        of attendees engaged, with special interest from the incident
        responders to be involved in early review cycles. Incident responders
        are very interested to understand how protocols will change and to
        assess the overall impact of changes on privacy and security
        operations. Even if there are no changes to the protocol proposals
        stemming from this review, the group discussion landed on this being a
        valuable exchange to understand early the impacts of changes for
        incident detection and mitigation, to devise new strategies, and to
        provide assessments on the impact of protocol changes on security in
        the round.<a href="#section-4.2-3" class="pilcrow">¶</a></p>
<p id="section-4.2-4">
 The third group reported back on trust exchanges relying heavily on
 relationships between individuals.  They were concerned with scaling the
 trust model and finding ways to do that better.  The group dove deeper into
 this topic.<a href="#section-4.2-4" class="pilcrow">¶</a></p>
<p id="section-4.2-5">The fourth group discussed useful data for incident
        responders. This built on the first breakout session (<a href="#breakout_1" class="xref">Section 4.1</a>). The group
        determined that indicators of compromise (IoCs) are what most
        organizations and groups are able to successfully exchange. Ideally,
        these would be fixed and programmable. They discussed developing a
        richer format for sharing event threats. When reporting back to the group,
        a successful solution used in the EU was mentioned: the <span><a href="#MISP" class="xref">Malware
 Information Sharing Platform (MISP)</a> [<a href="#MISP" class="xref">MISP</a>]</span>. This 
        will be considered in the review of existing efforts to determine if
        anything new is needed.<a href="#section-4.2-5" class="pilcrow">¶</a></p>
</section>
<section id="section-4.3">
        <h3 id="name-breakout-3-results-incident">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-breakout-3-results-incident" class="section-name selfRef">Breakout 3 Results: Incident Response Coordination</a>
        </h3>
<p id="section-4.3-1">Incident response coordination currently does not scale. This
        breakout session focused on brainstorming incident response and
        coordination, looking specifically at what works well for teams today,
        what is holding them back, and what risks loom ahead. Output from this
        session could be used to generate research and to dive deeper in a
        dedicated workshop on these topics.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3-2">Supporting:<a href="#section-4.3-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.3-3.1">Trust between individuals in incident response teams<a href="#section-4.3-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-3.2">Volume of strong signals and automated discovery<a href="#section-4.3-3.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-3.3">Need to protect network as a forcing function<a href="#section-4.3-3.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-3.4">Law and legal catalyst, motivator to stay on top<a href="#section-4.3-3.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-3.5">Current efforts supported by profit and company interests, but
            those may shift<a href="#section-4.3-3.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-3.6">Fear initially results in activity or in terms of the diagram
   used, a burst of wind, but eventually leads to complacency<a href="#section-4.3-3.6" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.3-4">What creates drag:<a href="#section-4.3-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.3-5.1">Lack of clear Key Performance Indicators (KPIs)<a href="#section-4.3-5.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-5.2">Too many standards<a href="#section-4.3-5.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-5.3">Potential for regional borders to impact data flows<a href="#section-4.3-5.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-5.4">Ease of use for end users<a href="#section-4.3-5.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-5.5">Speed to market without security considerations<a href="#section-4.3-5.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-5.6">Legal framework slow to adapt<a href="#section-4.3-5.6" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-5.7">Disconnect in actual/perceived risk<a href="#section-4.3-5.7" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-5.8">Regulatory requirements preventing data sharing<a href="#section-4.3-5.8" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-5.9">Lack of clarity in shared information<a href="#section-4.3-5.9" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-5.10">Behind the problem/reactionary<a href="#section-4.3-5.10" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-5.11">Lack of resources/participation<a href="#section-4.3-5.11" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-5.12">Monoculture narrows focus<a href="#section-4.3-5.12" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.3-6">Looming problems:<a href="#section-4.3-6" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.3-7.1">Dynamic threat landscape<a href="#section-4.3-7.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-7.2">Liability<a href="#section-4.3-7.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-7.3">Vocabulary collision<a href="#section-4.3-7.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-7.4">Lack of target/adversary clarity<a href="#section-4.3-7.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-7.5">Bifurcation of Internet<a href="#section-4.3-7.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-7.6">Government regulation<a href="#section-4.3-7.6" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-7.7">Confusion around metrics<a href="#section-4.3-7.7" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-7.8">Sensitivity of intelligence (trust)<a href="#section-4.3-7.8" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-7.9">Lack of skilled analysts<a href="#section-4.3-7.9" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-7.10">Lack of "fraud loss" data sharing<a href="#section-4.3-7.10" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-7.11">Stakeholder/leader confusion<a href="#section-4.3-7.11" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-7.12">Unknown impact of emerging technologies<a href="#section-4.3-7.12" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-7.13">Overcentralization of the Internet<a href="#section-4.3-7.13" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-7.14">New technologies and protocols<a href="#section-4.3-7.14" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-7.15">Changes in application-layer configurations (e.g., browser
            resolvers)<a href="#section-4.3-7.15" class="pilcrow">¶</a>
</li>
        </ul>
</section>
<section id="section-4.4">
        <h3 id="name-breakout-4-results-monitori">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-breakout-4-results-monitori" class="section-name selfRef">Breakout 4 Results: Monitoring and Measurement</a>
        </h3>
<p id="section-4.4-1">The fourth breakout session followed <span class="contact-name">Dave Plonka</span>'s talk on IPv6 aggregation
        to provide privacy for IPv6 sessions. Essentially, IPv6 provides
        additional capabilities for monitoring sessions end to end. Dave and
        his coauthor, <span class="contact-name">Arthur Berger</span>, primarily focus on measurement research
        but found a way to aggregate sessions to assist with maintaining user
        privacy. If you can devise methods to perform management and
        measurement, or even perform security functions, while accommodating
        methods to protect privacy, a stronger result is likely. This also
        precludes the need for additional privacy improvement work to defeat
        measurement objectives.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<p id="section-4.4-2">This breakout session was focused on devising methods to perform monitoring
        and measurement, coupled with advancing privacy considerations. The
        full group listed out options for protocols to explore and ranked
        them, with the four highest then explored by the breakout groups. Groups
        agreed to work further on the proposed ideas.<a href="#section-4.4-2" class="pilcrow">¶</a></p>
<section id="section-4.4.1">
          <h4 id="name-ip-address-reputation">
<a href="#section-4.4.1" class="section-number selfRef">4.4.1. </a><a href="#name-ip-address-reputation" class="section-name selfRef">IP Address Reputation</a>
          </h4>
<p id="section-4.4.1-1">There is a need to understand address assignment and configuration
        for hosts and services, especially with IPv6 <span>[<a href="#PlonkaBergerCARIS2" class="xref">PlonkaBergerCARIS2</a>]</span> in (1) sharing IP-address-related 
        information to inform attack response efforts while still protecting
        the privacy of victims and possible attackers and (2) mitigating
        abuse by altering the treatment, e.g., dropping or rate-limiting, of
        packets. Currently, there is no database that analysts and researchers
        can consult to, for instance, determine the lifetimes of IPv6 addresses
        or the prefix length at which the address is expected to be stable
        over time. The researchers propose either introducing a new database (compare
        PeeringDB) or extending existing databases (e.g., the regional
 Internet registries (RIRs)) to
        contain such information and allowing arbitrary queries. The prefix
        information would either be provided by networks that are willing or
        based on measurement algorithms that reverse-engineer reasonable
        values based on Internet measurements <span>[<a href="#PlonkaBergerKIP" class="xref">PlonkaBergerKIP</a>]</span>. 


In the former case, the incentive of networks to provide such information is
to ensure that privacy of their users is respected and to limit collateral
damage caused by access control lists affecting more of that network's
addresses than necessary, e.g., in the face of abuse.


This is an early idea; <span class="contact-name">Dave Plonka</span> is the lead contact
for those interested in helping to develop this further.<a href="#section-4.4.1-1" class="pilcrow">¶</a></p>
</section>
<section id="section-4.4.2">
          <h4 id="name-server-name-authentication-">
<a href="#section-4.4.2" class="section-number selfRef">4.4.2. </a><a href="#name-server-name-authentication-" class="section-name selfRef">Server Name Authentication Reputation C (SNARC)</a>
          </h4>
<p id="section-4.4.2-1">SNARC is a mechanism to
 assign value to trust indicators, used to
        make decisions about good or bad actors. 


The mechanism would be able to distinguish between client and server
connections and would be human readable. In addition, it builds on zero trust
networking and avoids consolidation, thus supporting legitimate new players.



SNARC has a similar theme to the IP reputation/BGP ranking idea mentioned
above.

SNARC is not currently defined by an RFC; however, such an RFC would help
customers and design teams on existing solutions.

The group plans to research visual aspects and underlying principles as they
begin work on this idea.  They plan to begin work in several stages,
researching "trust" indicators, "trust" value calculations, and research
actions to apply to "trust".

The overarching goal is to address blind trust, one of the challenges
identified with information/incident exchanges. <span class="contact-name">Trent Adams</span> is the lead contact for those interested in working with this
team.<a href="#section-4.4.2-1" class="pilcrow">¶</a></p>
</section>
<section id="section-4.4.3">
          <h4 id="name-logging">
<a href="#section-4.4.3" class="section-number selfRef">4.4.3. </a><a href="#name-logging" class="section-name selfRef">Logging</a>
          </h4>
<p id="section-4.4.3-1">The group presented the possibility of injecting logging
        capabilities at compile time for applications, resulting in a more
        consistent set of logs, covering an agreed set of conditions. Using
        a log-injecting compiler would increase logging for those
        applications and improve the uniformity of logged activity. Increasing
        logging capabilities at the endpoint is necessary as the shift toward
        increased use of encrypted transport continues. <span class="contact-name">Nalini         Elkins</span> is the lead contact for those interested
        in developing this further.<a href="#section-4.4.3-1" class="pilcrow">¶</a></p>
</section>
<section id="section-4.4.4">
          <h4 id="name-fingerprinting">
<a href="#section-4.4.4" class="section-number selfRef">4.4.4. </a><a href="#name-fingerprinting" class="section-name selfRef">Fingerprinting</a>
          </h4>
<p id="section-4.4.4-1">Fingerprinting has been used for numerous applications on the Web,
        including security, and will become of increasing importance with the
        deployment of stronger encryption. Fingerprinting provides a method to
        identify traffic without using decryption. The group discussed privacy
        considerations and balancing how you achieve the security benefits
        (identifying malicious traffic, information leakage, threat
        indicators, etc.). They are interested in deriving methods to validate
        the authenticity without identifying the source of traffic. They are
        also concerned with scaling issues. <span class="contact-name">William         Weinstein</span> is the lead contact for those interested in working
        with this team.<a href="#section-4.4.4-1" class="pilcrow">¶</a></p>
</section>
</section>
<section id="section-4.5">
        <h3 id="name-taxonomy-and-gaps-session">
<a href="#section-4.5" class="section-number selfRef">4.5. </a><a href="#name-taxonomy-and-gaps-session" class="section-name selfRef">Taxonomy and Gaps Session</a>
        </h3>
<p id="section-4.5-1">At the start of the second day of the workshop, <span class="contact-name">Kirsty Paine</span> and <span class="contact-name">Mirjam Kühne</span>
        prepared (and Kirsty led) a workshop-style session to discuss
        taxonomies used in incident response, attacks, and threat detection,
        comparing solutions and identifying gaps. 

  The primary objective was to determine a path forward by selecting the
  language to be used in the proposed SMART Research Group.


 Several taxonomies were presented for review and discussion. The topic
 remains open, but the following key points were highlighted by
 participants:<a href="#section-4.5-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.5-2.1">A single taxonomy might not be the way to go, because which
            taxonomy you use depends on what problem you are trying to solve,
            e.g., attribution of the attack, mitigation steps, technical
            features, or organizational impact measurements.<a href="#section-4.5-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.5-2.2">A tool to map between taxonomies should be automated, as there
            are requirements within groups or nations to use specific
            taxonomies.<a href="#section-4.5-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.5-2.3">The level of detail needed for reporting to management and for
            the analyst investigating the incident can be very different. At
            the workshop, one attendee mentioned that, for management reporting,
            they only use 8 categories to lighten the load on analysts,
            whereas some of the taxonomies contain 52 categories.<a href="#section-4.5-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.5-2.4">How you plan to use the taxonomy matters and may vary between
            use cases. Take, for instance, sharing data with external entities
            versus internal only. The taxonomy selected depends on what you
            plan to do with it. Some stated a need for attribute-based dynamic
            anthologies as opposed to rigid taxonomies used by others. A rigid
            taxonomy did not work for many from feedback in the session.<a href="#section-4.5-2.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.5-2.5">
            <span>[<a href="#RFC4949" class="xref">RFC4949</a>]</span> was briefly discussed as a possibility; however, there
            is a clear need to update terminology in this publication around
            this space in particular. This is likely to be raised in the Security
     Area Advisory Group (SAAG) during the open mic session,
            hopefully with proposed new definitions to demonstrate the issue
            and evolution of terms over time.<a href="#section-4.5-2.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.5-2.6">
  Within a taxonomy, prioritization matters to understand the impact of
  threats or an attack.  How do you map that between differing taxonomies?
  What is the problem to be solved, and what tooling is required?<a href="#section-4.5-2.6" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.5-2.7">Attack attribution had varying degrees of interest. 


Some felt the public sector cared more about attribution, not about
individuals.  They were interested in possible motivations behind an attack
and determining if there were other likely victims based on these motivations.

Understanding if the source was an individual actor, organized crime, or a
nation state mattered.<a href="#section-4.5-2.7" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.5-3">The result of this discussion was not to narrow down to one
        taxonomy but to think about mappings between taxonomies and the use
        cases for exchanging or sharing information, eventually giving rise to
        a common method to discuss threats and attacks. Researchers need a
        common vocabulary, not necessarily a common taxonomy.<a href="#section-4.5-3" class="pilcrow">¶</a></p>
</section>
</section>
<section id="section-5">
      <h2 id="name-next-steps">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-next-steps" class="section-name selfRef">Next Steps</a>
      </h2>
<p id="section-5-1">The next steps from the CARIS2 workshop are twofold:<a href="#section-5-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-5-2">
      <li id="section-5-2.1">The research
      initiatives spawned from the second CARIS workshop require further exploration
      and development. Fostering this development and creating communities
      around each proposed project is the first step, with reports back out to
      the SMART mailing list.<a href="#section-5-2.1" class="pilcrow">¶</a>
</li>
        <li id="section-5-2.2">The second initiative will be planning for the next CARIS workshop.<a href="#section-5-2.2" class="pilcrow">¶</a>
</li>
      </ol>
</section>
<section id="section-6">
      <h2 id="name-summary">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-summary" class="section-name selfRef">Summary</a>
      </h2>
<p id="section-6-1">When wrapping up the workshop, we reviewed the list of agreed projects to
      get a feel for actual interest as a follow up. Through the course of the
      two-day workshop, a larger set of potential research items had
      been generated, and this gave participants a chance to reassess commitments to
      better have them match expected outcomes. The highest ranking projects in
      terms of interest to drive the ideas forward included the following:<a href="#section-6-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6-2.1">Traffic fingerprinting<a href="#section-6-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-2.2">SNARC<a href="#section-6-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-2.3">Attack coordination solutions and automated security<a href="#section-6-2.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-2.4">Cryptographic rendezvous<a href="#section-6-2.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-2.5">L2 discovery<a href="#section-6-2.5" class="pilcrow">¶</a>
</li>
      </ul>
</section>
<section id="section-7">
      <h2 id="name-security-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-7-1">There are no security considerations, as this is an informational
      workshop summary report.<a href="#section-7-1" class="pilcrow">¶</a></p>
</section>
<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 has no IANA actions.<a href="#section-8-1" class="pilcrow">¶</a></p>
</section>
<section id="section-9">
      <h2 id="name-references">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-9.1">
        <h3 id="name-informative-references">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="CARISEvent">[CARISEvent]</dt>
        <dd>
<span class="refAuthor">Internet Society</span>, <span class="refTitle">"CARIS2: Coordinating Attack Response at Internet Scale"</span>, <time datetime="2019-02" class="refDate">February 2019</time>, <span>&lt;<a href="https://www.internetsociety.org/events/caris2">https://www.internetsociety.org/events/caris2</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="deficit">[deficit]</dt>
        <dd>
<span class="refAuthor">Morgan, S.</span>, <span class="refTitle">"Cybersecurity Talent Crunch To Create 3.5 Million Unfilled Jobs Globally By 2021"</span>, <time datetime="2019-10" class="refDate">October 2019</time>, <span>&lt;<a href="https://cybersecurityventures.com/jobs/">https://cybersecurityventures.com/jobs/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I2NSF">[I2NSF]</dt>
        <dd>
<span class="refAuthor">IETF</span>, <span class="refTitle">"Interface to Network Security Functions (i2nsf)"</span>, <span>&lt;<a href="https://datatracker.ietf.org/wg/i2nsf/about">https://datatracker.ietf.org/wg/i2nsf/about</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IEEE802.11">[IEEE802.11]</dt>
        <dd>
<span class="refAuthor">IEEE</span>, <span class="refTitle">"IEEE 802.11 WIRELESS LOCAL AREA NETWORKS"</span>, <span>&lt;<a href="https://www.ieee802.org/11/">https://www.ieee802.org/11/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="MISP">[MISP]</dt>
        <dd>
<span class="refAuthor">MISP</span>, <span class="refTitle">"Malware Information Sharing Platform"</span>, <span>&lt;<a href="https://www.misp-project.org/">https://www.misp-project.org/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="PlonkaBergerCARIS2">[PlonkaBergerCARIS2]</dt>
        <dd>
<span class="refAuthor">Plonka, D.</span><span class="refAuthor"> and A. Berger</span>, <span class="refTitle">"Measured Approaches to IPv6 Address Anonymization and Identity Association"</span>, <span class="refContent">CARIS2 Paper Submission</span>, <time datetime="2019-03" class="refDate">March 2019</time>, <span>&lt;<a href="https://www.internetsociety.org/events/caris2">https://www.internetsociety.org/events/caris2</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="PlonkaBergerKIP">[PlonkaBergerKIP]</dt>
        <dd>
<span class="refAuthor">Plonka, D.</span><span class="refAuthor"> and A. Berger</span>, <span class="refTitle">"kIP: a Measured Approach to IPv6 Address Anonymization"</span>, <time datetime="2017-07" class="refDate">July 2017</time>, <span>&lt;<a href="https://arxiv.org/abs/1707.03900">https://arxiv.org/abs/1707.03900</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-quic-transport">[QUIC]</dt>
        <dd>
<span class="refAuthor">Iyengar, J.</span><span class="refAuthor"> and M. Thomson</span>, <span class="refTitle">"QUIC: A UDP-Based Multiplexed and Secure Transport"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-quic-transport-33</span>, <time datetime="2020-12-13" class="refDate">13 December 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-quic-transport-33">https://tools.ietf.org/html/draft-ietf-quic-transport-33</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4949">[RFC4949]</dt>
        <dd>
<span class="refAuthor">Shirey, R.</span>, <span class="refTitle">"Internet Security Glossary, Version 2"</span>, <span class="seriesInfo">FYI 36</span>, <span class="seriesInfo">RFC 4949</span>, <span class="seriesInfo">DOI 10.17487/RFC4949</span>, <time datetime="2007-08" class="refDate">August 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4949">https://www.rfc-editor.org/info/rfc4949</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7970">[RFC7970]</dt>
        <dd>
<span class="refAuthor">Danyliw, R.</span>, <span class="refTitle">"The Incident Object Description Exchange Format Version 2"</span>, <span class="seriesInfo">RFC 7970</span>, <span class="seriesInfo">DOI 10.17487/RFC7970</span>, <time datetime="2016-11" class="refDate">November 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7970">https://www.rfc-editor.org/info/rfc7970</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8073">[RFC8073]</dt>
        <dd>
<span class="refAuthor">Moriarty, K.</span><span class="refAuthor"> and M. Ford</span>, <span class="refTitle">"Coordinating Attack Response at Internet Scale (CARIS) Workshop Report"</span>, <span class="seriesInfo">RFC 8073</span>, <span class="seriesInfo">DOI 10.17487/RFC8073</span>, <time datetime="2017-03" class="refDate">March 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8073">https://www.rfc-editor.org/info/rfc8073</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="RFC8520">[RFC8520]</dt>
        <dd>
<span class="refAuthor">Lear, E.</span><span class="refAuthor">, Droms, R.</span><span class="refAuthor">, and D. Romascanu</span>, <span class="refTitle">"Manufacturer Usage Description Specification"</span>, <span class="seriesInfo">RFC 8520</span>, <span class="seriesInfo">DOI 10.17487/RFC8520</span>, <time datetime="2019-03" class="refDate">March 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8520">https://www.rfc-editor.org/info/rfc8520</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8548">[RFC8548]</dt>
        <dd>
<span class="refAuthor">Bittau, A.</span><span class="refAuthor">, Giffin, D.</span><span class="refAuthor">, Handley, M.</span><span class="refAuthor">, Mazieres, D.</span><span class="refAuthor">, Slack, Q.</span><span class="refAuthor">, and E. Smith</span>, <span class="refTitle">"Cryptographic Protection of TCP Streams (tcpcrypt)"</span>, <span class="seriesInfo">RFC 8548</span>, <span class="seriesInfo">DOI 10.17487/RFC8548</span>, <time datetime="2019-05" class="refDate">May 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8548">https://www.rfc-editor.org/info/rfc8548</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="SMART">[SMART]</dt>
      <dd>
<span class="refAuthor">IRTF</span>, <span class="refTitle">"Stopping Malware and Researching Threats (smart)"</span>, <span>&lt;<a href="https://datatracker.ietf.org/group/smart/about/">https://datatracker.ietf.org/group/smart/about/</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<section id="section-appendix.a">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="section-appendix.a-1">Thank you to each of the CARIS2 workshop participants who brought their ideas,
      energy, and willingness to collaborate to advance attack response at
      Internet scale.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<p id="section-appendix.a-2">A big thank you to each member of the program committee for your
      review of program materials, papers, and guidance on the workshop
      format: <span class="contact-name">Mat Ford</span> (Internet Society, UK); <span class="contact-name">Jamie Gillespie</span> (APNIC, AU);
      <span class="contact-name">Chris Inacio</span> (CERT/CC, US); <span class="contact-name">Mirja Kühlewind</span> (ETH Zurich, CH); <span class="contact-name">Mirjam       Kühne</span> (RIPE NCC, NL); <span class="contact-name">Carlos Martinez</span> (LACNIC,
      UY); <span class="contact-name">Kathleen M. Moriarty</span>, Chair
      (Dell EMC); <span class="contact-name">Kirsty Paine</span> (NCSC, UK); and
      <span class="contact-name">Takeshi Takahashi</span> (NICT, JP).<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
<p id="section-appendix.a-3">Thank you to <span class="contact-name">Megan Hyland</span> (Dell EMC) for her review and guidance on
      the format of breakout sessions and tools to enable successful
      collaboration.<a href="#section-appendix.a-3" class="pilcrow">¶</a></p>
<p id="section-appendix.a-4">Thank you to the minute takers, <span class="contact-name">Akashaya Khare</span>
      and <span class="contact-name">Thinh Nguyen</span> (Dell EMC OCTO Cambridge Dojo team).<a href="#section-appendix.a-4" class="pilcrow">¶</a></p>
</section>
<div id="authors-addresses">
<section id="section-appendix.b">
      <h2 id="name-authors-address">
<a href="#name-authors-address" class="section-name selfRef">Author's Address</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Kathleen M. Moriarty</span></div>
<div dir="auto" class="left"><span class="org">Center for Internet Security</span></div>
<div dir="auto" class="left"><span class="street-address">31 Tech Valley Drive</span></div>
<div dir="auto" class="left">
<span class="locality">East Greenbush</span>, <span class="region">NY</span> <span class="postal-code">12061</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:kathleen.moriarty.ietf@gmail.com" class="email">kathleen.moriarty.ietf@gmail.com</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>