File: rfc9319.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 (2044 lines) | stat: -rw-r--r-- 87,658 bytes
<!DOCTYPE html>
<html lang="en" class="BCP RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 9319: The Use of maxLength in the Resource Public Key Infrastructure (RPKI)</title>
<meta content="Yossi Gilad" name="author">
<meta content="Sharon Goldberg" name="author">
<meta content="Kotikalapudi Sriram" name="author">
<meta content="Job Snijders" name="author">
<meta content="Ben Maddison" name="author">
<meta content='
       This document recommends ways to reduce the forged-origin hijack
      attack surface by prudently limiting the set of IP prefixes that are
      included in a Route Origin Authorization (ROA). One recommendation is to
      avoid using the maxLength attribute in ROAs except in some specific
      cases. The recommendations complement and extend those in RFC 7115. This
      document also discusses the creation of ROAs for facilitating the use of
      Distributed Denial of Service (DDoS) mitigation services. Considerations
      related to ROAs and RPKI-based Route Origin Validation (RPKI-ROV) in the context of
      destination-based Remotely Triggered Discard Route (RTDR) (elsewhere
      referred to as "Remotely Triggered Black Hole") filtering are also
      highlighted.
       
    ' name="description">
<meta content="xml2rfc 3.15.1" name="generator">
<meta content="Secure Internet routing" name="keyword">
<meta content="Resource public key infrastructure" name="keyword">
<meta content="9319" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.15.1
    Python 3.9.13
    appdirs 1.4.4
    ConfigArgParse 1.5.3
    google-i18n-address 2.5.1
    html5lib 1.1
    intervaltree 3.1.0
    Jinja2 3.1.2
    kitchen 1.2.6
    lxml 4.9.0
    MarkupSafe 2.1.1
    pycountry 22.3.5
    PyYAML 6.0
    requests 2.28.0
    setuptools 44.1.1
    six 1.16.0
    weasyprint 56.1
-->
<link href="rfc9319.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 {
  display: table;
  border: none;
  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 {
  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;
  }
  pre.breakable {
    break-inside: auto;
  }
  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 {
  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,
  .artwork > pre,
  .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 {
  break-inside: avoid;
}
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/rfc9319" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpkimaxlen-15" rel="prev">
  </head>
<body class="xml2rfc">
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 9319</td>
<td class="center">RPKI maxLength</td>
<td class="right">October 2022</td>
</tr></thead>
<tfoot><tr>
<td class="left">Gilad, et al.</td>
<td class="center">Best Current Practice</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/rfc9319" class="eref">9319</a></dd>
<dt class="label-bcp">BCP:</dt>
<dd class="bcp">185</dd>
<dt class="label-category">Category:</dt>
<dd class="category">Best Current Practice</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2022-10" class="published">October 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">Y. Gilad</div>
<div class="org">Hebrew University of Jerusalem</div>
</div>
<div class="author">
      <div class="author-name">S. Goldberg</div>
<div class="org">Boston University</div>
</div>
<div class="author">
      <div class="author-name">K. Sriram</div>
<div class="org">USA NIST</div>
</div>
<div class="author">
      <div class="author-name">J. Snijders</div>
<div class="org">Fastly</div>
</div>
<div class="author">
      <div class="author-name">B. Maddison</div>
<div class="org">Workonline Communications</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9319</h1>
<h1 id="title">The Use of maxLength in the Resource Public Key Infrastructure (RPKI)</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document recommends ways to reduce the forged-origin hijack
      attack surface by prudently limiting the set of IP prefixes that are
      included in a Route Origin Authorization (ROA). One recommendation is to
      avoid using the maxLength attribute in ROAs except in some specific
      cases. The recommendations complement and extend those in RFC 7115. This
      document also discusses the creation of ROAs for facilitating the use of
      Distributed Denial of Service (DDoS) mitigation services. Considerations
      related to ROAs and RPKI-based Route Origin Validation (RPKI-ROV) in the context of
      destination-based Remotely Triggered Discard Route (RTDR) (elsewhere
      referred to as "Remotely Triggered Black Hole") filtering are also
      highlighted.<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 memo documents an Internet Best Current Practice.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further information
            on BCPs is available in Section 2 of RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc9319">https://www.rfc-editor.org/info/rfc9319</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="auto internal xref">1</a>.  <a href="#name-introduction" class="internal xref">Introduction</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="auto internal xref">1.1</a>.  <a href="#name-requirements" class="internal xref">Requirements</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.2">
                <p id="section-toc.1-1.1.2.2.1" class="keepWithNext"><a href="#section-1.2" class="auto internal xref">1.2</a>.  <a href="#name-documentation-prefixes" class="internal xref">Documentation Prefixes</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="auto internal xref">2</a>.  <a href="#name-suggested-reading" class="internal xref">Suggested Reading</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="auto internal xref">3</a>.  <a href="#name-forged-origin-sub-prefix-hi" class="internal xref">Forged-Origin Sub-Prefix Hijack</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="auto internal xref">4</a>.  <a href="#name-measurements-of-the-rpki" class="internal xref">Measurements of the RPKI</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="auto internal xref">5</a>.  <a href="#name-recommendations-about-minim" class="internal xref">Recommendations about Minimal ROAs and maxLength</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="auto internal xref">5.1</a>.  <a href="#name-facilitating-ad-hoc-routing" class="internal xref">Facilitating Ad Hoc Routing Changes and DDoS Mitigation</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="auto internal xref">5.2</a>.  <a href="#name-defensive-de-aggregation-in" class="internal xref">Defensive De-aggregation in Response to Prefix Hijacks</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="auto internal xref">6</a>.  <a href="#name-considerations-for-rtdr-fil" class="internal xref">Considerations for RTDR Filtering Scenarios</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="auto internal xref">7</a>.  <a href="#name-user-interface-design-recom" class="internal xref">User Interface Design Recommendations</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="auto internal xref">8</a>.  <a href="#name-operational-considerations" class="internal xref">Operational 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="auto internal xref">9</a>.  <a href="#name-security-considerations" class="internal 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="auto internal xref">10</a>. <a href="#name-iana-considerations" class="internal xref">IANA Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-11" class="auto internal xref">11</a>. <a href="#name-references" class="internal xref">References</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.1">
                <p id="section-toc.1-1.11.2.1.1"><a href="#section-11.1" class="auto internal xref">11.1</a>.  <a href="#name-normative-references" class="internal xref">Normative References</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.2">
                <p id="section-toc.1-1.11.2.2.1"><a href="#section-11.2" class="auto internal xref">11.2</a>.  <a href="#name-informative-references" class="internal xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#appendix-A" class="auto internal xref"></a><a href="#name-acknowledgments" class="internal xref">Acknowledgments</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#appendix-B" class="auto internal xref"></a><a href="#name-authors-addresses" class="internal xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="intro">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">The Resource Public Key Infrastructure (RPKI) <span>[<a href="#RFC6480" class="cite xref">RFC6480</a>]</span> uses Route Origin Authorizations (ROAs) to create a
      cryptographically verifiable mapping from an IP prefix to a set of
      Autonomous Systems (ASes) that are authorized to originate that prefix.
      Each ROA contains a set of IP prefixes and the AS number of one of the
      ASes authorized to originate all the IP prefixes in the set <span>[<a href="#RFC6482" class="cite xref">RFC6482</a>]</span>.  The ROA is cryptographically signed by the party
      that holds a certificate for the set of IP prefixes.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">The ROA format also supports a maxLength attribute. According to
      <span>[<a href="#RFC6482" class="cite xref">RFC6482</a>]</span>, "When
      present, the maxLength specifies the maximum length of the IP address
      prefix that the AS is authorized to advertise."  Thus, rather than
      requiring the ROA to list each prefix that the AS is authorized to
      originate, the maxLength attribute provides a shorthand that authorizes
      an AS to originate a set of IP prefixes.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">However, measurements of RPKI deployments have found that the use of
      the maxLength attribute in ROAs tends to lead to security problems.
      In particular, measurements taken in June 2017 showed that of the
      prefixes specified in ROAs that use the maxLength attribute, 84% were
      vulnerable to a forged-origin sub-prefix hijack <span>[<a href="#GSG17" class="cite xref">GSG17</a>]</span>.  The forged-origin prefix or sub-prefix hijack
      involves inserting the legitimate AS as specified in the ROA as the
      origin AS in the AS_PATH; the hijack can be launched against any IP
      prefix/sub-prefix that has a ROA. Consider a prefix/sub-prefix that has
      a ROA that is unused (i.e., not announced in BGP by a legitimate AS). A
      forged-origin hijack involving such a prefix/sub-prefix can propagate
      widely throughout the Internet. On the other hand, if the
      prefix/sub-prefix were announced by the legitimate AS, then the
      propagation of the forged-origin hijack is somewhat limited because of
      its increased AS_PATH length relative to the legitimate announcement. Of
      course, forged-origin hijacks are harmful in both cases, but the extent
      of harm is greater for unannounced prefixes. See <a href="#hijack" class="auto internal xref">Section 3</a>
      for detailed discussion.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">For this reason, this document recommends that, whenever possible,
      operators <span class="bcp14">SHOULD</span> use "minimal ROAs" that authorize only
      those IP prefixes that are actually originated in BGP, and no other
      prefixes. Further, it recommends ways to reduce the forged-origin attack
      surface by prudently limiting the address space that is included in
      ROAs. One recommendation is to avoid using the maxLength attribute in
      ROAs except in some specific cases. The recommendations complement and
      extend those in <span>[<a href="#RFC7115" class="cite xref">RFC7115</a>]</span>. The document also discusses
      the creation of ROAs for facilitating the use of DDoS mitigation
      services.  Considerations related to ROAs and RPKI-ROV in the context of
      destination-based Remotely Triggered Discard Route (RTDR) (elsewhere
      referred to as "Remotely Triggered Black Hole") filtering are also
      highlighted.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">Please note that the term "RPKI-based Route Origin Validation" and
      the corresponding acronym "RPKI-ROV" that are used in this document mean the
      same as the term "Prefix Origin Validation" used in <span>[<a href="#RFC6811" class="cite xref">RFC6811</a>]</span>.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">One ideal place to implement the ROA-related recommendations is in
      the user interfaces for configuring ROAs. Recommendations for
      implementors of such user interfaces are provided in <a href="#ui" class="auto internal xref">Section 7</a>.<a href="#section-1-6" class="pilcrow">¶</a></p>
<p id="section-1-7">The practices described in this document require no changes
      to the RPKI specifications and will not increase the number of signed
      ROAs in the RPKI because ROAs already support lists of IP prefixes <span>[<a href="#RFC6482" class="cite xref">RFC6482</a>]</span>.<a href="#section-1-7" class="pilcrow">¶</a></p>
<section id="section-1.1">
        <h3 id="name-requirements">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-requirements" class="section-name selfRef">Requirements</a>
        </h3>
<p id="section-1.1-1">The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>",
        "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>",
        "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
        "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document
        are to be interpreted as described in BCP 14 <span>[<a href="#RFC2119" class="cite xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="cite xref">RFC8174</a>]</span> when, and only when, they
        appear in all capitals, as shown here.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
</section>
<section id="section-1.2">
        <h3 id="name-documentation-prefixes">
<a href="#section-1.2" class="section-number selfRef">1.2. </a><a href="#name-documentation-prefixes" class="section-name selfRef">Documentation Prefixes</a>
        </h3>
<p id="section-1.2-1">The documentation prefixes recommended in <span>[<a href="#RFC5737" class="cite xref">RFC5737</a>]</span> are
        insufficient for use as example prefixes in this document. Therefore,
        this document uses the address space defined in <span>[<a href="#RFC1918" class="cite xref">RFC1918</a>]</span> for
        constructing example prefixes.<a href="#section-1.2-1" class="pilcrow">¶</a></p>
<p id="section-1.2-2">Note that although the examples in this document are presented
        using IPv4 prefixes, all the analysis thereof and the recommendations
        made are equally valid for the equivalent IPv6 cases.<a href="#section-1.2-2" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<section id="section-2">
      <h2 id="name-suggested-reading">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-suggested-reading" class="section-name selfRef">Suggested Reading</a>
      </h2>
<p id="section-2-1">It is assumed that the reader understands BGP <span>[<a href="#RFC4271" class="cite xref">RFC4271</a>]</span>, RPKI <span>[<a href="#RFC6480" class="cite xref">RFC6480</a>]</span>, ROAs <span>[<a href="#RFC6482" class="cite xref">RFC6482</a>]</span>, RPKI-ROV <span>[<a href="#RFC6811" class="cite xref">RFC6811</a>]</span>, and BGPsec <span>[<a href="#RFC8205" class="cite xref">RFC8205</a>]</span>.<a href="#section-2-1" class="pilcrow">¶</a></p>
</section>
<div id="hijack">
<section id="section-3">
      <h2 id="name-forged-origin-sub-prefix-hi">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-forged-origin-sub-prefix-hi" class="section-name selfRef">Forged-Origin Sub-Prefix Hijack</a>
      </h2>
<p id="section-3-1">A detailed description and discussion of forged-origin sub-prefix
      hijacks are presented here, especially considering the case when the
      sub-prefix is not announced in BGP.  The forged-origin sub-prefix hijack
      is relevant to a scenario in which:<a href="#section-3-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="olPercent" id="section-3-2">
      <dt>(1)</dt>
<dd id="section-3-2.1">the RPKI <span>[<a href="#RFC6480" class="cite xref">RFC6480</a>]</span> is deployed, and<a href="#section-3-2.1" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt>(2)</dt>
<dd id="section-3-2.2">routers use RPKI-ROV to drop invalid
      routes <span>[<a href="#RFC6811" class="cite xref">RFC6811</a>]</span>, but<a href="#section-3-2.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt>(3)</dt>
<dd id="section-3-2.3">BGPsec <span>[<a href="#RFC8205" class="cite xref">RFC8205</a>]</span> (or any similar method
      to validate the truthfulness of the BGP AS_PATH attribute) is not
      deployed.<a href="#section-3-2.3" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-3-3">Note that this set of assumptions accurately describes a substantial
      and growing number of large Internet networks at the time of writing.<a href="#section-3-3" class="pilcrow">¶</a></p>
<p id="section-3-4">The forged-origin sub-prefix hijack <span>[<a href="#RFC7115" class="cite xref">RFC7115</a>]</span>
        <span>[<a href="#GCHSS" class="cite xref">GCHSS</a>]</span> is described here using a running example.<a href="#section-3-4" class="pilcrow">¶</a></p>
<p id="section-3-5">Consider the IP prefix 192.168.0.0/16, which is allocated to an
      organization that also operates AS 64496.  In BGP, AS 64496 originates
      the IP prefix 192.168.0.0/16 as well as its sub-prefix 192.168.225.0/24.
      Therefore, the RPKI should contain a ROA authorizing AS 64496 to
      originate these two IP prefixes.<a href="#section-3-5" class="pilcrow">¶</a></p>
<p id="section-3-6">Suppose, however, the organization issues and publishes a ROA
      including a maxLength value of 24:<a href="#section-3-6" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-3-7">ROA:(192.168.0.0/16-24, AS 64496)<a href="#section-3-7" class="pilcrow">¶</a></p>
<p id="section-3-8">We refer to the above as a "loose ROA" since it authorizes AS 64496
      to originate any sub-prefix of 192.168.0.0/16 up to and including length
      /24, rather than only those prefixes that are intended to be announced
      in BGP.<a href="#section-3-8" class="pilcrow">¶</a></p>
<p id="section-3-9">Because AS 64496 only originates two prefixes in BGP (192.168.0.0/16
      and 192.168.225.0/24), all other prefixes authorized by the loose ROA
      (for instance, 192.168.0.0/24) are vulnerable to the following
      forged-origin sub-prefix hijack <span>[<a href="#RFC7115" class="cite xref">RFC7115</a>]</span> <span>[<a href="#GCHSS" class="cite xref">GCHSS</a>]</span>:<a href="#section-3-9" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-3-10">The hijacker AS 64511 sends a BGP announcement
      "192.168.0.0/24: AS 64511, AS 64496", falsely claiming that AS 64511 is
      a neighbor of AS 64496 and that AS 64496 originates the IP prefix
      192.168.0.0/24. In fact, the IP prefix 192.168.0.0/24 is not originated
      by AS 64496.<a href="#section-3-10" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-3-11">The hijacker's BGP announcement is valid according to the
      RPKI since the ROA (192.168.0.0/16-24, AS 64496) authorizes AS 64496 to
      originate BGP routes for 192.168.0.0/24.<a href="#section-3-11" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-3-12">Because AS 64496 does not actually originate a route for
      192.168.0.0/24, the hijacker's route is the only route for
      192.168.0.0/24. Longest-prefix-match routing ensures that the hijacker's
      route to the sub-prefix 192.168.0.0/24 is always preferred over the
      legitimate route to 192.168.0.0/16 originated by AS 64496.<a href="#section-3-12" class="pilcrow">¶</a></p>
<p id="section-3-13">Thus, the hijacker's route propagates through the Internet, and
      traffic destined for IP addresses in 192.168.0.0/24 will be delivered to
      the hijacker.<a href="#section-3-13" class="pilcrow">¶</a></p>
<p id="section-3-14">The forged-origin sub-prefix hijack would have failed if a minimal
      ROA as described in <a href="#recommendations" class="auto internal xref">Section 5</a> was used instead of the loose ROA.  In this
      example, a minimal ROA would be:<a href="#section-3-14" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-3-15">ROA:(192.168.0.0/16, 192.168.225.0/24, AS 64496)<a href="#section-3-15" class="pilcrow">¶</a></p>
<p id="section-3-16">This ROA is "minimal" because it includes only those IP prefixes that AS 64496 originates in BGP, but no other IP prefixes <span>[<a href="#RFC6907" class="cite xref">RFC6907</a>]</span>.<a href="#section-3-16" class="pilcrow">¶</a></p>
<p id="section-3-17">The minimal ROA renders AS 64511's BGP announcement invalid because:<a href="#section-3-17" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="olPercent" id="section-3-18">
        <dt>(1)</dt>
<dd id="section-3-18.1">this ROA "covers" the attacker's announcement (since
        192.168.0.0/24 is a sub-prefix of 192.168.0.0/16), and<a href="#section-3-18.1" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt>(2)</dt>
<dd id="section-3-18.2">there is no ROA "matching" the attacker's announcement (there is
        no ROA for AS 64511 and IP prefix 192.168.0.0/24) <span>[<a href="#RFC6811" class="cite xref">RFC6811</a>]</span>.<a href="#section-3-18.2" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-3-19">If routers ignore invalid BGP announcements, the minimal ROA above
      ensures that the sub-prefix hijack will fail.<a href="#section-3-19" class="pilcrow">¶</a></p>
<p id="section-3-20">Thus, if a minimal ROA had been used, the attacker would be forced
      to launch a forged-origin prefix hijack in order to attract traffic as
      follows:<a href="#section-3-20" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-3-21">The hijacker AS 64511 sends a BGP announcement
      "192.168.0.0/16: AS 64511, AS 64496", falsely claiming that AS 64511 is
      a neighbor of AS 64496.<a href="#section-3-21" class="pilcrow">¶</a></p>
<p id="section-3-22">This forged-origin prefix hijack is significantly less damaging than
      the forged-origin sub-prefix hijack:<a href="#section-3-22" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-3-23">AS 64496 legitimately originates 192.168.0.0/16 in BGP, so
      the hijacker AS 64511 is not presenting the only route to
      192.168.0.0/16.<a href="#section-3-23" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-3-24">Moreover, the path originated by AS 64511 is one hop
      longer than the path originated by the legitimate origin AS 64496.<a href="#section-3-24" class="pilcrow">¶</a></p>
<p id="section-3-25">As discussed in <span>[<a href="#LSG16" class="cite xref">LSG16</a>]</span>, this means that the hijacker
      will attract less traffic than it would have in the forged-origin
      sub-prefix hijack where the hijacker presents the only route to the
      hijacked sub-prefix.<a href="#section-3-25" class="pilcrow">¶</a></p>
<p id="section-3-26">In summary, a forged-origin sub-prefix hijack has the same impact as
      a regular sub-prefix hijack, despite the increased AS_PATH length of the
      illegitimate route.  A forged-origin sub-prefix hijack is also more
      damaging than the forged-origin prefix hijack.<a href="#section-3-26" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-4">
      <h2 id="name-measurements-of-the-rpki">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-measurements-of-the-rpki" class="section-name selfRef">Measurements of the RPKI</a>
      </h2>
<p id="section-4-1">Network measurements taken in June 2017 showed that 12% of the IP
      prefixes authorized in ROAs have a maxLength value longer than their prefix
      length.  Of these, the vast majority (84%) were non-minimal, as they
      included sub-prefixes that are not announced in BGP by the legitimate
      AS and were thus vulnerable to forged-origin sub-prefix hijacks.  See
      <span>[<a href="#GSG17" class="cite xref">GSG17</a>]</span> for details.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">These measurements suggest that operators commonly misconfigure the
      maxLength attribute and unwittingly open themselves up to forged-origin
      sub-prefix hijacks.  That is, they are exposing a much larger attack
      surface for forged-origin hijacks than necessary.<a href="#section-4-2" class="pilcrow">¶</a></p>
</section>
<div id="recommendations">
<section id="section-5">
      <h2 id="name-recommendations-about-minim">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-recommendations-about-minim" class="section-name selfRef">Recommendations about Minimal ROAs and maxLength</a>
      </h2>
<p id="section-5-1">Operators <span class="bcp14">SHOULD</span> use minimal ROAs whenever possible.
      A minimal ROA contains only those IP prefixes that are actually
      originated by an AS in BGP and no other IP prefixes.  See <a href="#hijack" class="auto internal xref">Section 3</a> for an example.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">In general, operators <span class="bcp14">SHOULD</span> avoid using the maxLength
      attribute in their ROAs, since its inclusion will usually make the ROA
      non-minimal.<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3">One such exception may be when all more specific prefixes permitted
      by the maxLength value are actually announced by the AS in the ROA.  Another
      exception is where: (a) the maxLength value is substantially larger compared
      to the specified prefix length in the ROA, and (b) a large number of
      more specific prefixes in that range are announced by the AS in the
      ROA. In practice, this case should occur rarely (if at all). Operator
      discretion is necessary in this case.<a href="#section-5-3" class="pilcrow">¶</a></p>
<p id="section-5-4">This practice requires no changes to the RPKI specifications and need
      not increase the number of signed ROAs in the RPKI because ROAs already
      support lists of IP prefixes <span>[<a href="#RFC6482" class="cite xref">RFC6482</a>]</span>.  See <span>[<a href="#GSG17" class="cite xref">GSG17</a>]</span> for further discussion of why this practice will have
      minimal impact on the performance of the RPKI ecosystem.<a href="#section-5-4" class="pilcrow">¶</a></p>
<p id="section-5-5">Operators that implement these recommendations and have existing
      ROAs published in the RPKI system <span class="bcp14">MUST</span> perform a review
      of such objects, especially where they make use of the maxLength
      attribute, to ensure that the set of included prefixes is "minimal" with
      respect to the current BGP origination and routing policies.  Published
      ROAs <span class="bcp14">MUST</span> be replaced as necessary.  Such an exercise
      <span class="bcp14">MUST</span> be repeated whenever the operator makes changes to
      either policy.<a href="#section-5-5" class="pilcrow">¶</a></p>
<div id="nominimal">
<section id="section-5.1">
        <h3 id="name-facilitating-ad-hoc-routing">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-facilitating-ad-hoc-routing" class="section-name selfRef">Facilitating Ad Hoc Routing Changes and DDoS Mitigation</a>
        </h3>
<p id="section-5.1-1">Operational requirements may require that a route for an IP prefix
        be originated on an ad hoc basis, with little or no prior warning.  An
        example of such a situation arises when an operator wishes to make use
        of DDoS mitigation services that use BGP to redirect traffic via a
        "scrubbing center".<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<p id="section-5.1-2">In order to ensure that such ad hoc routing changes are effective,
        a ROA validating the new route should exist. However, a difficulty
        arises due to the fact that newly created objects in the RPKI are made
        visible to relying parties considerably more slowly than routing
        updates in BGP.<a href="#section-5.1-2" class="pilcrow">¶</a></p>
<p id="section-5.1-3">Ideally, it would not be necessary to pre-create the ROA, which
        validates the ad hoc route, and instead create it "on the fly" as
        required. However, this is practical only if the latency imposed by
        the propagation of RPKI data is guaranteed to be within acceptable
        limits in the circumstances.  For time-critical interventions such as
        responding to a DDoS attack, this is unlikely to be the case.<a href="#section-5.1-3" class="pilcrow">¶</a></p>
<p id="section-5.1-4">Thus, the ROA in question will usually need to be created well in
        advance of the routing intervention, but such a ROA will be
        non-minimal, since it includes an IP prefix that is sometimes (but not
        always) originated in BGP.<a href="#section-5.1-4" class="pilcrow">¶</a></p>
<p id="section-5.1-5">In this case, the ROA <span class="bcp14">SHOULD</span> only include:<a href="#section-5.1-5" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="olPercent" id="section-5.1-6">
          <dt>(1)</dt>
<dd id="section-5.1-6.1">the set of IP prefixes that are always originated in BGP,
          and<a href="#section-5.1-6.1" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt>(2)</dt>
<dd id="section-5.1-6.2">the set of IP prefixes that are sometimes, but not always,
          originated in BGP.<a href="#section-5.1-6.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-5.1-7">The ROA <span class="bcp14">SHOULD NOT</span> include any IP prefixes that the
        operator knows will not be originated in BGP.  In general, the ROA
        <span class="bcp14">SHOULD NOT</span> make use of the maxLength attribute unless
        doing so has no impact on the set of included prefixes.<a href="#section-5.1-7" class="pilcrow">¶</a></p>
<p id="section-5.1-8">The running example is now extended to illustrate one situation
        where it is not possible to issue a minimal ROA.<a href="#section-5.1-8" class="pilcrow">¶</a></p>
<p id="section-5.1-9">Consider the following scenario prior to the deployment of RPKI.
        Suppose AS 64496 announced 192.168.0.0/16 and has a contract with a
        DDoS mitigation service provider that
        holds AS 64500.  Further, assume that the DDoS mitigation service
        contract applies to all IP addresses covered by 192.168.0.0/22.  When
        a DDoS attack is detected and reported by AS 64496, AS 64500
        immediately originates 192.168.0.0/22, thus attracting all the DDoS
        traffic to itself.  The traffic is scrubbed at AS 64500 and then sent
        back to AS 64496 over a backhaul link.  Notice that, during a DDoS
        attack, the DDoS mitigation service provider AS 64500 originates a /22
        prefix that is longer than AS 64496's /16 prefix, so all the
        traffic (destined to addresses in 192.168.0.0/22) that normally goes
        to AS 64496 goes to AS 64500 instead.  In some deployments, the
        origination of the /22 route is performed by AS 64496 and announced
        only to AS 64500, which then announces transit for that prefix.  This
        variation does not change the properties considered here.<a href="#section-5.1-9" class="pilcrow">¶</a></p>
<p id="section-5.1-10">First, suppose the RPKI only had the minimal ROA for AS 64496, as
        described in <a href="#hijack" class="auto internal xref">Section 3</a>.  However, if there is no ROA
        authorizing AS 64500 to announce the /22 prefix, then the DDoS
        mitigation (and traffic scrubbing) scheme would not work.  That is, if
        AS 64500 originates the /22 prefix in BGP during DDoS attacks, the
        announcement would be invalid <span>[<a href="#RFC6811" class="cite xref">RFC6811</a>]</span>.<a href="#section-5.1-10" class="pilcrow">¶</a></p>
<p id="section-5.1-11">Therefore, the RPKI should have two ROAs: one for AS 64496 and one
        for AS 64500.<a href="#section-5.1-11" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-5.1-12">ROA:(192.168.0.0/16, 192.168.225.0/24, AS 64496)<a href="#section-5.1-12" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-5.1-13">ROA:(192.168.0.0/22, AS 64500)<a href="#section-5.1-13" class="pilcrow">¶</a></p>
<p id="section-5.1-14">Neither ROA uses the maxLength attribute, but the second ROA is
        not "minimal" because it contains a /22 prefix that is not originated
        by anyone in BGP during normal operations.  The /22 prefix is only
        originated by AS 64500 as part of its DDoS mitigation service during a
        DDoS attack.<a href="#section-5.1-14" class="pilcrow">¶</a></p>
<p id="section-5.1-15">Notice, however, that this scheme does not come without risks.
        Namely, all IP addresses in 192.168.0.0/22 are vulnerable to a
        forged-origin sub-prefix hijack during normal operations when the /22
        prefix is not originated.  (The hijacker AS 64511 would send the BGP
        announcement "192.168.0.0/22: AS 64511, AS 64500", falsely claiming
        that AS 64511 is a neighbor of AS 64500 and falsely claiming that AS
        64500 originates 192.168.0.0/22.)<a href="#section-5.1-15" class="pilcrow">¶</a></p>
<p id="section-5.1-16">In some situations, the DDoS mitigation service at AS 64500 might
        want to limit the amount of DDoS traffic that it attracts and scrubs.
        Suppose that a DDoS attack only targets IP addresses in
        192.168.0.0/24.  Then, the DDoS mitigation service at AS 64500 only
        wants to attract the traffic designated for the /24 prefix that is
        under attack, but not the entire /22 prefix.  To allow for this, the
        RPKI should have two ROAs: one for AS 64496 and one for AS 64500.<a href="#section-5.1-16" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-5.1-17">ROA:(192.168.0.0/16, 192.168.225.0/24, AS 64496)<a href="#section-5.1-17" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-5.1-18">ROA:(192.168.0.0/22-24, AS 64500)<a href="#section-5.1-18" class="pilcrow">¶</a></p>
<p id="section-5.1-19">The second ROA uses the maxLength attribute because it is designed
        to explicitly enable AS 64500 to originate any /24 sub-prefix of
        192.168.0.0/22.<a href="#section-5.1-19" class="pilcrow">¶</a></p>
<p id="section-5.1-20">As before, the second ROA is not "minimal" because it contains
        prefixes that are not originated by anyone in BGP during normal
        operations. Also, all IP addresses in 192.168.0.0/22 are
        vulnerable to a forged-origin sub-prefix hijack during normal
        operations when the /22 prefix is not originated.<a href="#section-5.1-20" class="pilcrow">¶</a></p>
<p id="section-5.1-21">The use of the maxLength attribute in this second ROA also comes with additional
        risk.  While it permits the DDoS mitigation service at AS 64500 to
        originate prefix 192.168.0.0/24 during a DDoS attack in that space, it
        also makes the other /24 prefixes covered by the /22 prefix (i.e.,
        192.168.1.0/24, 192.168.2.0/24, and 192.168.3.0/24) vulnerable to
        forged-origin sub-prefix attacks.<a href="#section-5.1-21" class="pilcrow">¶</a></p>
</section>
</div>
<div id="deaggr">
<section id="section-5.2">
        <h3 id="name-defensive-de-aggregation-in">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-defensive-de-aggregation-in" class="section-name selfRef">Defensive De-aggregation in Response to Prefix Hijacks</a>
        </h3>
<p id="section-5.2-1">When responding to certain classes of prefix hijack (in particular,
        the forged-origin sub-prefix hijack described above), it may be
        desirable for the victim to perform "defensive de-aggregation",
        i.e., to begin originating more-specific prefixes in order to compete
        with the hijack routes for selection as the best path in networks that
        are not performing RPKI-ROV <span>[<a href="#RFC6811" class="cite xref">RFC6811</a>]</span>.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<p id="section-5.2-2">In topologies where at least one AS on every path between the
        victim and hijacker filters RPKI-ROV invalid prefixes, it may be the case
        that the existence of a minimal ROA issued by the victim prevents the
        defensive more-specific prefixes from being propagated to the networks
        topologically close to the attacker, thus hampering the effectiveness
        of this response.<a href="#section-5.2-2" class="pilcrow">¶</a></p>
<p id="section-5.2-3">Nevertheless, this document recommends that, where possible, network
        operators publish minimal ROAs even in the face of this risk. This is
        because:<a href="#section-5.2-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.2-4.1">Minimal ROAs offer the best possible protection against the
          immediate impact of such an attack, rendering the need for such a
          response less likely;<a href="#section-5.2-4.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.2-4.2">Increasing RPKI-ROV adoption by network operators will, over time,
          decrease the size of the neighborhoods in which this risk exists;
          and<a href="#section-5.2-4.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.2-4.3">Other methods for reducing the size of such neighborhoods are
          available to potential victims, such as establishing direct External
          BGP (EBGP) adjacencies with networks from whom the defensive routes
          would otherwise be hidden.<a href="#section-5.2-4.3" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
</section>
</div>
<div id="rtdr">
<section id="section-6">
      <h2 id="name-considerations-for-rtdr-fil">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-considerations-for-rtdr-fil" class="section-name selfRef">Considerations for RTDR Filtering Scenarios</a>
      </h2>
<p id="section-6-1">Considerations related to ROAs and RPKI-ROV <span>[<a href="#RFC6811" class="cite xref">RFC6811</a>]</span> for the case of destination-based RTDR
      (elsewhere referred to as "Remotely Triggered Black
      Hole") filtering are addressed here.  In RTDR filtering, highly specific
      prefixes (greater than /24 in IPv4 and greater than /48 in IPv6, or
      possibly even /32 in IPv4 and /128 in IPv6) are announced in BGP.  These
      announcements are tagged with the well-known BGP community defined by
      <span>[<a href="#RFC7999" class="cite xref">RFC7999</a>]</span>.  For the reasons set out
      above, it is obviously not desirable to use a large
      maxLength value or include any such highly specific prefixes in the ROAs to
      accommodate destination-based RTDR filtering.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">As a result, RPKI-ROV <span>[<a href="#RFC6811" class="cite xref">RFC6811</a>]</span> is a poor fit for the
      validation of RTDR routes.
      Specification of new procedures to address this use case through the use
      of the RPKI is outside the scope of this document.<a href="#section-6-2" class="pilcrow">¶</a></p>
<p id="section-6-3">Therefore:<a href="#section-6-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6-4.1">Operators <span class="bcp14">SHOULD NOT</span> create non-minimal ROAs
        (by either creating additional ROAs or using the maxLength attribute)
        for the purpose of advertising RTDR routes; and<a href="#section-6-4.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-4.2">Operators providing a means for operators of neighboring
        autonomous systems to advertise RTDR routes via BGP <span class="bcp14">MUST NOT</span> make the creation of non-minimal ROAs a pre-requisite for
        its use.<a href="#section-6-4.2" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<div id="ui">
<section id="section-7">
      <h2 id="name-user-interface-design-recom">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-user-interface-design-recom" class="section-name selfRef">User Interface Design Recommendations</a>
      </h2>
<p id="section-7-1">Most operator interaction with the RPKI system when creating or
      modifying ROAs will occur via a user interface that abstracts the
      underlying encoding, signing, and publishing operations.<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">This document recommends that designers and/or providers of such user
      interfaces <span class="bcp14">SHOULD</span> provide warnings to draw the user's
      attention to the risks of creating non-minimal ROAs in general and using
      the maxLength attribute in particular.<a href="#section-7-2" class="pilcrow">¶</a></p>
<p id="section-7-3">Warnings provided by such a system may vary in nature from generic
      warnings based purely on the inclusion of the maxLength attribute to
      customised guidance based on the observable BGP routing policy of the
      operator in question.  The choices made in this respect are expected to
      be dependent on the target user audience of the implementation.<a href="#section-7-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="operational-considerations">
<section id="section-8">
      <h2 id="name-operational-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-operational-considerations" class="section-name selfRef">Operational Considerations</a>
      </h2>
<p id="section-8-1">The recommendations specified in this document (in particular, those
      in <a href="#recommendations" class="auto internal xref">Section 5</a>) involve trade-offs between
      operational agility and security.<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2">Operators adopting the recommended practice of issuing minimal ROAs
      will, by definition, need to make changes to their existing set of issued
      ROAs in order to effect changes to the set of prefixes that are
      originated in BGP.<a href="#section-8-2" class="pilcrow">¶</a></p>
<p id="section-8-3">Even in the case of routing changes that are planned in advance,
      existing procedures may need to be updated to incorporate changes to
      issued ROAs and may require additional time allowed for those changes
      to propagate.<a href="#section-8-3" class="pilcrow">¶</a></p>
<p id="section-8-4">Operators are encouraged to carefully review the issues highlighted
      (especially those in Sections <a href="#nominimal" class="auto internal xref">5.1</a> and <a href="#deaggr" class="auto internal xref">5.2</a>) in light of their specific operational
      requirements. Failure to do so could, in the worst case, result in a
      self-inflicted denial of service.<a href="#section-8-4" class="pilcrow">¶</a></p>
<p id="section-8-5">The recommendations made in <a href="#recommendations" class="auto internal xref">Section 5</a> are
      likely to be more onerous for operators utilising large IP address space
      allocations from which many more-specific advertisements are made in
      BGP. Operators of such networks are encouraged to seek opportunities to
      automate the required procedures in order to minimise manual operational
      burden.<a href="#section-8-5" 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">This document makes recommendations regarding the use of RPKI-ROV
      as defined in <span>[<a href="#RFC6811" class="cite xref">RFC6811</a>]</span> and, as such,
      introduces no additional security considerations beyond those specified
      therein.<a href="#section-9-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="IANA">
<section id="section-10">
      <h2 id="name-iana-considerations">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-10-1">This document has no IANA actions.<a href="#section-10-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-11">
      <h2 id="name-references">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-11.1">
        <h3 id="name-normative-references">
<a href="#section-11.1" class="section-number selfRef">11.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC1918">[RFC1918]</dt>
        <dd>
<span class="refAuthor">Rekhter, Y.</span>, <span class="refAuthor">Moskowitz, B.</span>, <span class="refAuthor">Karrenberg, D.</span>, <span class="refAuthor">de Groot, G. J.</span>, and <span class="refAuthor">E. Lear</span>, <span class="refTitle">"Address Allocation for Private Internets"</span>, <span class="seriesInfo">BCP 5</span>, <span class="seriesInfo">RFC 1918</span>, <span class="seriesInfo">DOI 10.17487/RFC1918</span>, <time datetime="1996-02" class="refDate">February 1996</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1918">https://www.rfc-editor.org/info/rfc1918</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4271">[RFC4271]</dt>
        <dd>
<span class="refAuthor">Rekhter, Y., Ed.</span>, <span class="refAuthor">Li, T., Ed.</span>, and <span class="refAuthor">S. Hares, Ed.</span>, <span class="refTitle">"A Border Gateway Protocol 4 (BGP-4)"</span>, <span class="seriesInfo">RFC 4271</span>, <span class="seriesInfo">DOI 10.17487/RFC4271</span>, <time datetime="2006-01" class="refDate">January 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4271">https://www.rfc-editor.org/info/rfc4271</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6480">[RFC6480]</dt>
        <dd>
<span class="refAuthor">Lepinski, M.</span> and <span class="refAuthor">S. Kent</span>, <span class="refTitle">"An Infrastructure to Support Secure Internet Routing"</span>, <span class="seriesInfo">RFC 6480</span>, <span class="seriesInfo">DOI 10.17487/RFC6480</span>, <time datetime="2012-02" class="refDate">February 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6480">https://www.rfc-editor.org/info/rfc6480</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6482">[RFC6482]</dt>
        <dd>
<span class="refAuthor">Lepinski, M.</span>, <span class="refAuthor">Kent, S.</span>, and <span class="refAuthor">D. Kong</span>, <span class="refTitle">"A Profile for Route Origin Authorizations (ROAs)"</span>, <span class="seriesInfo">RFC 6482</span>, <span class="seriesInfo">DOI 10.17487/RFC6482</span>, <time datetime="2012-02" class="refDate">February 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6482">https://www.rfc-editor.org/info/rfc6482</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6811">[RFC6811]</dt>
        <dd>
<span class="refAuthor">Mohapatra, P.</span>, <span class="refAuthor">Scudder, J.</span>, <span class="refAuthor">Ward, D.</span>, <span class="refAuthor">Bush, R.</span>, and <span class="refAuthor">R. Austein</span>, <span class="refTitle">"BGP Prefix Origin Validation"</span>, <span class="seriesInfo">RFC 6811</span>, <span class="seriesInfo">DOI 10.17487/RFC6811</span>, <time datetime="2013-01" class="refDate">January 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6811">https://www.rfc-editor.org/info/rfc6811</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7115">[RFC7115]</dt>
        <dd>
<span class="refAuthor">Bush, R.</span>, <span class="refTitle">"Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)"</span>, <span class="seriesInfo">BCP 185</span>, <span class="seriesInfo">RFC 7115</span>, <span class="seriesInfo">DOI 10.17487/RFC7115</span>, <time datetime="2014-01" class="refDate">January 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7115">https://www.rfc-editor.org/info/rfc7115</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>
</dl>
</section>
<section id="section-11.2">
        <h3 id="name-informative-references">
<a href="#section-11.2" class="section-number selfRef">11.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="GCHSS">[GCHSS]</dt>
        <dd>
<span class="refAuthor">Gilad, Y.</span>, <span class="refAuthor">Cohen, A.</span>, <span class="refAuthor">Herzberg, A.</span>, <span class="refAuthor">Schapira, M.</span>, and <span class="refAuthor">H. Shulman</span>, <span class="refTitle">"Are We There Yet? On RPKI's Deployment and Security"</span>, <span class="refContent">NDSS 2017</span>, <time datetime="2017-02" class="refDate">February 2017</time>, <span>&lt;<a href="https://eprint.iacr.org/2016/1010.pdf">https://eprint.iacr.org/2016/1010.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="GSG17">[GSG17]</dt>
        <dd>
<span class="refAuthor">Gilad, Y.</span>, <span class="refAuthor">Sagga, O.</span>, and <span class="refAuthor">S. Goldberg</span>, <span class="refTitle">"MaxLength Considered Harmful to the RPKI"</span>, <span class="refContent">CoNEXT '17</span>, <span class="seriesInfo">DOI 10.1145/3143361.3143363</span>, <time datetime="2017-12" class="refDate">December 2017</time>, <span>&lt;<a href="https://eprint.iacr.org/2016/1015.pdf">https://eprint.iacr.org/2016/1015.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="LSG16">[LSG16]</dt>
        <dd>
<span class="refAuthor">Lychev, R.</span>, <span class="refAuthor">Shapira, M.</span>, and <span class="refAuthor">S. Goldberg</span>, <span class="refTitle">"Rethinking security for internet routing"</span>, <span class="refContent">Communications of the ACM</span>, <span class="seriesInfo">DOI 10.1145/2896817</span>, <time datetime="2016-10" class="refDate">October 2016</time>, <span>&lt;<a href="http://cacm.acm.org/magazines/2016/10/207763-rethinking-security-for-internet-routing/">http://cacm.acm.org/magazines/2016/10/207763-rethinking-security-for-internet-routing/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5737">[RFC5737]</dt>
        <dd>
<span class="refAuthor">Arkko, J.</span>, <span class="refAuthor">Cotton, M.</span>, and <span class="refAuthor">L. Vegoda</span>, <span class="refTitle">"IPv4 Address Blocks Reserved for Documentation"</span>, <span class="seriesInfo">RFC 5737</span>, <span class="seriesInfo">DOI 10.17487/RFC5737</span>, <time datetime="2010-01" class="refDate">January 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5737">https://www.rfc-editor.org/info/rfc5737</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6907">[RFC6907]</dt>
        <dd>
<span class="refAuthor">Manderson, T.</span>, <span class="refAuthor">Sriram, K.</span>, and <span class="refAuthor">R. White</span>, <span class="refTitle">"Use Cases and Interpretations of Resource Public Key Infrastructure (RPKI) Objects for Issuers and Relying Parties"</span>, <span class="seriesInfo">RFC 6907</span>, <span class="seriesInfo">DOI 10.17487/RFC6907</span>, <time datetime="2013-03" class="refDate">March 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6907">https://www.rfc-editor.org/info/rfc6907</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7999">[RFC7999]</dt>
        <dd>
<span class="refAuthor">King, T.</span>, <span class="refAuthor">Dietzel, C.</span>, <span class="refAuthor">Snijders, J.</span>, <span class="refAuthor">Doering, G.</span>, and <span class="refAuthor">G. Hankins</span>, <span class="refTitle">"BLACKHOLE Community"</span>, <span class="seriesInfo">RFC 7999</span>, <span class="seriesInfo">DOI 10.17487/RFC7999</span>, <time datetime="2016-10" class="refDate">October 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7999">https://www.rfc-editor.org/info/rfc7999</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8205">[RFC8205]</dt>
      <dd>
<span class="refAuthor">Lepinski, M., Ed.</span> and <span class="refAuthor">K. Sriram, Ed.</span>, <span class="refTitle">"BGPsec Protocol Specification"</span>, <span class="seriesInfo">RFC 8205</span>, <span class="seriesInfo">DOI 10.17487/RFC8205</span>, <time datetime="2017-09" class="refDate">September 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8205">https://www.rfc-editor.org/info/rfc8205</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="Acknowledgments">
<section id="appendix-A">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="appendix-A-1">The authors would like to thank the following people for their review
      and contributions to this document: <span class="contact-name">Omar Sagga</span> and
      <span class="contact-name">Aris Lambrianidis</span>.  Thanks are also due to
      <span class="contact-name">Matthias Waehlisch</span>, <span class="contact-name">Ties de       Kock</span>, <span class="contact-name">Amreesh Phokeer</span>, <span class="contact-name">Éric       Vyncke</span>, <span class="contact-name">Alvaro Retana</span>, <span class="contact-name">John       Scudder</span>, <span class="contact-name">Roman Danyliw</span>, <span class="contact-name">Andrew Alston</span>, and <span class="contact-name">Murray Kucherawy</span>
      for comments and suggestions, to <span class="contact-name">Roni Even</span> for the
      Gen-ART review, to <span class="contact-name">Jean Mahoney</span> for the ART-ART
      review, to <span class="contact-name">Acee Lindem</span> for the Routing Area Directorate
      review, and to <span class="contact-name">Sean Turner</span> for the Security Area
      Directorate review.<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">Yossi Gilad</span></div>
<div dir="auto" class="left"><span class="org">Hebrew University of Jerusalem</span></div>
<div dir="auto" class="left"><span class="extended-address">Rothburg Family Buildings</span></div>
<div dir="auto" class="left"><span class="street-address">Edmond J. Safra Campus</span></div>
<div dir="auto" class="left">
<span class="locality">Jerusalem</span> <span class="postal-code">9190416</span>
</div>
<div dir="auto" class="left"><span class="country-name">Israel</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:yossigi@cs.huji.ac.il" class="email">yossigi@cs.huji.ac.il</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Sharon Goldberg</span></div>
<div dir="auto" class="left"><span class="org">Boston University</span></div>
<div dir="auto" class="left"><span class="street-address">111 Cummington St, MCS135</span></div>
<div dir="auto" class="left">
<span class="locality">Boston</span>, <span class="region">MA</span> <span class="postal-code">02215</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:goldbe@cs.bu.edu" class="email">goldbe@cs.bu.edu</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Kotikalapudi Sriram</span></div>
<div dir="auto" class="left"><span class="org">USA National Institute of Standards and Technology</span></div>
<div dir="auto" class="left"><span class="street-address">100 Bureau Drive</span></div>
<div dir="auto" class="left">
<span class="locality">Gaithersburg</span>, <span class="region">MD</span> <span class="postal-code">20899</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:kotikalapudi.sriram@nist.gov" class="email">kotikalapudi.sriram@nist.gov</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Job Snijders</span></div>
<div dir="auto" class="left"><span class="org">Fastly</span></div>
<div dir="auto" class="left"><span class="locality">Amsterdam</span></div>
<div dir="auto" class="left"><span class="country-name">Netherlands</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:job@fastly.com" class="email">job@fastly.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Ben Maddison</span></div>
<div dir="auto" class="left"><span class="org">Workonline Communications</span></div>
<div dir="auto" class="left"><span class="street-address">114 West St</span></div>
<div dir="auto" class="left"><span class="locality">Johannesburg</span></div>
<div dir="auto" class="left"><span class="postal-code">2196</span></div>
<div dir="auto" class="left"><span class="country-name">South Africa</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:benm@workonline.africa" class="email">benm@workonline.africa</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>