rfc9319xml2.original.xml   rfc9319.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<rfc category="bcp"
seriesNo="185"
docName="draft-ietf-sidrops-rpkimaxlen-15"
submissionType="IETF"
ipr="trust200902"
consensus="true">
<front>
<title abbrev="RPKI maxLength">The Use of maxLength in the RPKI</title>
<author fullname="Yossi Gilad" initials="Y." surname="Gilad">
<organization>Hebrew University of Jerusalem</organization>
<address>
<postal>
<street>Rothburg Family Buildings, Edmond J. Safra Campus</s
treet>
<city>Jerusalem</city>
<region></region>
<code>9190416</code>
<country>Israel</country>
</postal>
<email>yossigi@cs.huji.ac.il</email>
</address>
</author>
<author fullname="Sharon Goldberg" initials="S." surname="Goldberg">
<organization>Boston University</organization>
<address>
<postal>
<street>111 Cummington St, MCS135</street>
<city>Boston</city>
<region>MA</region>
<code>02215</code>
<country>USA</country>
</postal>
<email>goldbe@cs.bu.edu</email>
</address>
</author>
<author fullname="Kotikalapudi Sriram" initials="K." surname="Sriram">
<organization abbrev="USA NIST">USA National Institute of Standards
and Technology</organization>
<address>
<postal>
<street>100 Bureau Drive</street>
<city>Gaithersburg</city>
<region>MD</region>
<code>20899</code>
<country>USA</country>
</postal>
<email>kotikalapudi.sriram@nist.gov</email>
</address>
</author>
<author fullname="Job Snijders" initials="J." surname="Snijders">
<organization>Fastly</organization>
<address>
<postal>
<street/>
<code/>
<city>Amsterdam</city>
<country>Netherlands</country>
</postal>
<email>job@fastly.com</email>
</address>
</author>
<author fullname="Ben Maddison" initials="B." surname="Maddison">
<organization>Workonline Communications</organization>
<address>
<postal>
<street>114 West St</street>
<city>Johannesburg</city>
<code>2196</code>
<country>South Africa</country>
</postal>
<email>benm@workonline.africa</email>
</address>
</author>
<date />
<workgroup>Internet Engineering Task Force (IETF)</workgroup>
<keyword>Secure Internet routing</keyword>
<keyword>Resource public key infrastructure</keyword>
<abstract>
<t>
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 ma
xLength attribute
in ROAs except in some specific cases. The recommendations compl
ement and extend
those in RFC 7115. The document also discusses the creation of R
OAs for facilitating
the use of Distributed Denial of Service (DDoS) mitigation servi
ces. Considerations
related to ROAs and origin validation in the context of destinat
ion-based Remotely
Triggered Discard Route (RTDR) (elsewhere referred to as "Remote
ly Triggered
Black Hole") filtering are also highlighted.
</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<t>
The RPKI <xref target="RFC6480"/> uses Route Origin Authorizatio
ns (ROAs) to create
a cryptographically verifiable mapping from an IP prefix to a se
t 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 <xref tar
get="RFC6482"/>.
The ROA is cryptographically signed by the party that holds a ce
rtificate for the
set of IP prefixes.
</t>
<t>
The ROA format also supports a maxLength attribute. According to
<xref target="RFC6482"/>, "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 aut
horizes an AS to
originate a set of IP prefixes.
</t>
<t>
However, measurements of RPKI deployments have found that the us
e of the maxLength in
ROAs tends to lead to security problems.
In particular, measurements taken in June 2017 showed that of th
e prefixes
specified in ROAs that use the maxLength attribute, 84% were vul
nerable to a
forged-origin sub-prefix hijack <xref target="HARMFUL" />.
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, and can
be launched
against any IP prefix/sub-prefix that has a ROA. Consider a pref
ix/sub-prefix that
has a ROA but is unused, i.e., not announced in BGP by a legitim
ate AS. A forged
origin hijack involving such a prefix/sub-prefix can propagate w
idely throughout the
Internet. On the other hand, if the prefix/sub-prefix were annou
nced 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 legitima
te announcement. Of
course, forged-origin hijacks are harmful in both cases but the
extent of harm is
greater for unannounced prefixes. See <xref target="hijack"/> fo
r detailed
discussion.
</t>
<t>
For this reason, this document recommends that, whenever possibl
e, operators SHOULD
use "minimal ROAs" that authorize only those IP prefixes that ar
e actually
originated in BGP, and no other prefixes. Further, it recommends
ways to reduce the
forged-origin attack surface by prudently limiting the address s
pace that is
included in Route Origin Authorizations (ROAs). One recommendati
on is to avoid
using the maxLength attribute in ROAs except in some specific ca
ses. The
recommendations complement and extend those in <xref target="RFC
7115"/>. The
document also discusses the creation of ROAs for facilitating th
e use of Distributed
Denial of Service (DDoS) mitigation services. Considerations rel
ated to ROAs and
origin validation in the context of destination-based Remotely T
riggered Discard
Route (RTDR) (elsewhere referred to as "Remotely Triggered Black
Hole") filtering
are also highlighted.
</t>
<t>
One ideal place to implement the ROA related recommendations is
in the user
interfaces for configuring ROAs. Recommendations for implementor
s of such user
interfaces are provided in <xref target="ui"/>
</t>
<t>
Best current practices described in this document require no cha
nges to the RPKI
specification and will not increase the number of signed ROAs in
the RPKI because
ROAs already support lists of IP prefixes <xref target="RFC6482"
/>.
</t>
<section title="Requirements">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHAL
L NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "
OPTIONAL" in this
document are to be interpreted as described in BCP 14 <xref
target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in
all capitals, as
shown here.
</t>
</section>
<section title=" Documentation Prefixes">
<t>
The documentation prefixes recommended in <xref target="RFC5
737"/> are
insufficient for use as example prefixes in this document. T
herefore, this
document uses <xref target="RFC1918" /> address space for co
nstructing example
prefixes.
</t>
<t>
Note that although the examples in this document are present
ed using IPv4
prefixes, all the analysis thereof and the recommendations m
ade are
equally valid for the equivalent IPv6 cases.
</t>
</section>
</section>
<section title="Suggested Reading">
<t>
It is assumed that the reader understands BGP <xref target="RFC4
271"/>, RPKI
<xref target="RFC6480"/>, Route Origin Authorizations (ROAs)
<xref target="RFC6482"/>, RPKI-based Prefix Validation <xref tar
get="RFC6811"/>,
and BGPsec <xref target="RFC8205"/>.
</t>
</section>
<section title="Forged-Origin Sub-prefix Hijack" anchor="hijack">
<t>
A detailed description and discussion of forged-origin sub-prefi
x hijacks are
presented here, especially considering the case when the sub-pre
fix is not announced
in BGP.
The forged-origin sub-prefix hijack is relevant to a scenario in
which:
<list>
<t>
(1) the RPKI <xref target="RFC6480"/> is deployed, and
</t>
<t>
(2) routers use RPKI origin validation to drop invalid r
outes
<xref target="RFC6811" />, but
</t>
<t>
(3) BGPsec <xref target="RFC8205"/> (or any similar meth
od to validate the
truthfulness of the BGP AS_PATH attribute) is not de
ployed.
</t>
</list>
Note that this set of assumptions accurately describes a substan
tial and growing
number of large Internet networks at the time of writing.
</t>
<t>
The forged-origin sub-prefix hijack <xref target="RFC7115" />
<xref target="GCHSS" /> is described here using a running exampl
e.
</t>
<t>
Consider the IP prefix 192.168.0.0/16 which is allocated to an o
rganization 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.
</t>
<t>
Suppose, however, the organization issues and publishes a ROA in
cluding a maxLength
value of 24:
<list>
<t>
ROA:(192.168.0.0/16-24, AS 64496)
</t>
</list>
We refer to the above as a "loose ROA" since it authorizes AS 64
496 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.
</t>
<t>
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 RO
A" (for instance,
192.168.0.0/24), are vulnerable to the following forged-origin s
ub-prefix hijack
<xref target="RFC7115"/> <xref target="GCHSS" />:
<list>
<t>
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
falsely claiming 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.
</t>
<t>
The hijacker's BGP announcement is valid according to th
e 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.
</t>
<t>
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/2
4.
Longest-prefix-match routing ensures that the hijacker's
route to the
sub-prefix 192.168.0.0/24 is always preferred over the l
egitimate route to
192.168.0.0/16 originated by AS 64496.
</t>
</list>
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 hija
cker.
</t>
<t>
The forged-origin sub-prefix hijack would have failed if a "mini
mal ROA" described
below was used instead of the "loose ROA".
In this example, a "minimal ROA" would be:
<list>
<t>
ROA:(192.168.0.0/16, 192.168.225.0/24, AS 64496)
</t>
</list>
This ROA is "minimal" because it includes only those IP prefixes
that AS 64496
originates in BGP, but no other IP prefixes <xref target="RFC690
7" />.
</t>
<t>
The "minimal ROA" renders AS 64511's BGP announcement invalid be
cause:
<list>
<t>
(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
</t>
<t>
(2) there is no ROA "matching" the attacker's announceme
nt (there is no ROA
for AS 64511 and IP prefix 192.168.0.0/24) <xref tar
get="RFC6811" />.
</t>
</list>
If routers ignore invalid BGP announcements, the minimal ROA abo
ve ensures that the
sub-prefix hijack will fail.
</t>
<t> <!DOCTYPE rfc [
Thus, if a "minimal ROA" had been used, the attacker would be fo <!ENTITY nbsp "&#160;">
rced to launch a <!ENTITY zwsp "&#8203;">
forged-origin prefix hijack in order to attract traffic, as foll <!ENTITY nbhy "&#8209;">
ows: <!ENTITY wj "&#8288;">
<list> ]>
<t>
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.
</t>
</list>
</t>
<t>
This forged-origin prefix hijack is significantly less damaging
than the
forged-origin sub-prefix hijack:
<list>
<t>
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.
</t>
<t>
Moreover, the path originated by AS 64511 is one hop lon
ger than the path
originated by the legitimate origin AS 64496.
</t>
</list>
As discussed in <xref target="LSG16"/>, this means that the hija
cker 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.
</t>
<t>
In summary, a forged-origin sub-prefix hijack has the same impac
t as a regular
sub-prefix hijack, despite the increased AS_PATH length of the i
llegitimate route.
A forged-origin sub-prefix hijack is also more damaging than the
forged-origin
prefix hijack.
</t>
</section>
<section title="Measurements of the RPKI">
<t>
Network measurements taken in June 2017 showed that 12% of the I
P prefixes
authorized in ROAs have a maxLength longer than their prefix len
gth.
Of these, the vast majority (84%) were non-minimal, as they incl
uded sub-prefixes
that are not announced in BGP by the legitimate AS, and were thu
s vulnerable to
forged-origin sub-prefix hijacks.
See <xref target="GSG17"/> for details.
</t>
<t>
These measurements suggest that operators commonly misconfigure
the maxLength
attribute, and unwittingly open themselves up to forged-origin s
ub-prefix hijacks.
That is, they are exposing a much larger attack surface for forg
ed-origin hijacks
than necessary.
</t>
</section>
<section title="Recommendations about Minimal ROAs and maxLength" anchor
="recommendations">
<t>
Operators SHOULD 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 <xref target="hijack"/> for an example.)
</t>
<t>
In general, operators SHOULD avoid using the maxLength attribute
in their ROAs,
since its inclusion will usually make the ROA non-minimal.
</t>
<t>
One such exception may be when all more specific prefixes permit
ted by the
maxLength are actually announced by the AS in the ROA.
Another exception is where: (a) the maxLength is substantially l
arger compared to
the specified prefix length in the ROA, and (b) a large number o
f more specific
prefixes in that range are announced by the AS in the ROA. In pr
actice, this case
should occur rarely (if at all). Operator discretion is necessar
y in this case.
</t>
<t>
This practice requires no changes to the RPKI specification and
need not increase
the number of signed ROAs in the RPKI because ROAs already suppo
rt lists of IP
prefixes <xref target="RFC6482"/>.
See also <xref target="GSG17"/> for further discussion of why th
is practice will
have minimal impact on the performance of the RPKI ecosystem.
</t>
<t>
Operators implementing these recommendations and that have exist
ing ROAs published
in the RPKI system MUST perform a review of such objects, especi
ally where they
make use of the maxLength attribute, to ensure that the set of i
ncluded prefixes is
"minimal" with respect to the current BGP origination and routin
g policies.
Published ROAs MUST be replaced as necessary.
Such an exercise MUST be repeated whenever the operator makes ch
anges to either
policy.
</t>
<section title="Facilitating Ad Hoc Routing Changes and DDoS Mitigat
ion" anchor="nominimal">
<t>
Operational requirements may require that a route for an IP
prefix be
originated on an ad hoc basis, with little or no prior warni
ng.
An example of such a situation arises when an operator wishe
s to make use of
DDoS mitigation services that use BGP to redirect traffic vi
a a "scrubbing
center".
</t>
<t>
In order to ensure that such ad hoc routing changes are effe
ctive, 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.
</t>
<t>
Ideally, it would not be necessary to pre-create the ROA whi
ch 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 circumstanc
es.
For time-critical interventions such as responding to a DDoS
attack, this is
unlikely to be the case.
</t>
<t>
Thus, the ROA in question will usually need to be created we
ll 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 i
n BGP.
</t>
<t>
In this case, the ROA SHOULD include only:
<list>
<t>
(1) the set of IP prefixes that are always
originated in BGP, and
</t>
<t>
(2) the set of IP prefixes that are sometimes, but n
ot always,
originated in BGP.
</t>
</list>
The ROA SHOULD NOT include any IP prefixes that the operator
knows will not be
originated in BGP.
In general, the ROA SHOULD NOT make use of the maxLength att
ribute unless doing
so has no impact on the set of included prefixes.
</t>
<t>
The running example is now extended to illustrate one situat
ion where it is not
possible to issue a minimal ROA.
</t>
<t>
Consider the following scenario prior to the deployment of R
PKI.
Suppose AS 64496 announced 192.168.0.0/16 and has a contract
with a Distributed
Denial of Service (DDoS) mitigation service provider that ho
lds AS 64500.
Further, assume that the DDoS mitigation service contract ap
plies 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 traf
fic 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 servi
ce provider AS
64500 originates a /22 prefix that is longer than AS 64496's
/16 prefix, and so
all the traffic (destined to addresses in 192.168.0.0/22) th
at normally goes to
AS 64496 goes to AS 64500 instead.
In some deployments, the origination of the /22 route is per
formed by AS 64496
and announced only to AS 64500, which then announces transit
for that prefix.
This variation does not change the properties considered her
e.
</t>
<t>
First, suppose the RPKI only had the minimal ROA for AS 6449
6, as described
in <xref target="hijack"/>.
But 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 <xref target="RFC6811" />.
</t>
<t> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
Therefore, the RPKI should have two ROAs: one for AS 64496 a bcp" consensus="true" docName="draft-ietf-sidrops-rpkimaxlen-15" number="9319" i
nd one for AS pr="trust200902" tocInclude="true" symRefs="true" sortRefs="true" updates="" obs
64500. oletes="" xml:lang="en" version="3">
<list>
<t>
ROA:(192.168.0.0/16, 192.168.225.0/24, AS 64496)
</t>
<t>
ROA:(192.168.0.0/22, AS 64500)
</t>
</list>
Neither ROA uses the maxLength attribute.
But the second ROA is not "minimal" because it contains a /2
2 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.
</t>
<t> <!-- xml2rfc v2v3 conversion 3.14.0 -->
Notice, however, that this scheme does not come without risk
s.
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 pre
fix 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 nei
ghbor of AS 64500
and falsely claiming that AS 64500 originates 192.168.0.0/22
.)
</t>
<t> <front>
In some situations, the DDoS mitigation service at AS 64500 <title abbrev="RPKI maxLength">The Use of maxLength in the Resource Public K
might want to limit ey Infrastructure (RPKI)</title>
the amount of DDoS traffic that it attracts and scrubs. <seriesInfo name="RFC" value="9319"/>
Suppose that a DDoS attack only targets IP addresses in 192. <seriesInfo name="BCP" value="185"/>
168.0.0/24. <author fullname="Yossi Gilad" initials="Y." surname="Gilad">
Then, the DDoS mitigation service at AS 64500 only wants to <organization>Hebrew University of Jerusalem</organization>
attract the traffic <address>
designated for the /24 prefix that is under attack, but not <postal>
the entire /22 <extaddr>Rothburg Family Buildings</extaddr>
prefix. <street>Edmond J. Safra Campus</street>
To allow for this, the RPKI should have two ROAs: one for AS <city>Jerusalem</city>
64496 and one for <region/>
AS 64500. <code>9190416</code>
<list> <country>Israel</country>
<t> </postal>
ROA:(192.168.0.0/16, 192.168.225.0/24, AS 64496) <email>yossigi@cs.huji.ac.il</email>
</t> </address>
<t> </author>
ROA:(192.168.0.0/22-24, AS 64500) <author fullname="Sharon Goldberg" initials="S." surname="Goldberg">
</t> <organization>Boston University</organization>
</list> <address>
</t> <postal>
<t> <street>111 Cummington St, MCS135</street>
The second ROA uses the maxLength attribute because it is de <city>Boston</city>
signed to <region>MA</region>
explicitly enable AS 64500 to originate any /24 sub-prefix o <code>02215</code>
f 192.168.0.0/22. <country>United States of America</country>
</t> </postal>
<t> <email>goldbe@cs.bu.edu</email>
As before, the second ROA is not "minimal" because it contai </address>
ns prefixes that </author>
are not originated by anyone in BGP during normal operations <author fullname="Kotikalapudi Sriram" initials="K." surname="Sriram">
. <organization abbrev="USA NIST">USA National Institute of Standards and Te
As before, all IP addresses in 192.168.0.0/22 are vulnerable chnology</organization>
to a forged-origin <address>
sub-prefix hijack during normal operations, when the /22 pre <postal>
fix is not <street>100 Bureau Drive</street>
originated. <city>Gaithersburg</city>
</t> <region>MD</region>
<t> <code>20899</code>
The use of maxLength in this second ROA also comes with addi <country>United States of America</country>
tional risk. </postal>
While it permits the DDoS mitigation service at AS 64500 to <email>kotikalapudi.sriram@nist.gov</email>
originate prefix </address>
192.168.0.0/24 during a DDoS attack in that space, it also m </author>
akes the other <author fullname="Job Snijders" initials="J." surname="Snijders">
/24 prefixes covered by the /22 prefix (i.e., 192.168.1.0/24 <organization>Fastly</organization>
, 192.168.2.0/24, <address>
192.168.3.0/24) vulnerable to forged-origin sub-prefix attac <postal>
ks. <street/>
</t> <code/>
</section> <city>Amsterdam</city>
<country>Netherlands</country>
</postal>
<email>job@fastly.com</email>
</address>
</author>
<author fullname="Ben Maddison" initials="B." surname="Maddison">
<organization>Workonline Communications</organization>
<address>
<postal>
<street>114 West St</street>
<city>Johannesburg</city>
<code>2196</code>
<country>South Africa</country>
</postal>
<email>benm@workonline.africa</email>
</address>
</author>
<date year="2022" month="October" />
<area>ops</area>
<workgroup>sidrops</workgroup>
<keyword>Secure Internet routing</keyword>
<keyword>Resource public key infrastructure</keyword>
<abstract>
<t>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 c
ontext of
destination-based Remotely Triggered Discard Route (RTDR) (elsewhere
referred to as "Remotely Triggered Black Hole") filtering are also
highlighted.
</t>
</abstract>
</front>
<middle>
<section anchor="intro">
<name>Introduction</name>
<section title="Defensive De-aggregation In Response To Prefix Hijac <t>The Resource Public Key Infrastructure (RPKI) <xref
ks" anchor="deaggr"> target="RFC6480"/> uses Route Origin Authorizations (ROAs) to create a
<t> cryptographically verifiable mapping from an IP prefix to a set of
In responding to certain classes of prefix hijack, in partic Autonomous Systems (ASes) that are authorized to originate that prefix.
ular, the Each ROA contains a set of IP prefixes and the AS number of one of the
forged-origin sub-prefix hijack described above, it may be d ASes authorized to originate all the IP prefixes in the set <xref
esirable for the target="RFC6482"/>. The ROA is cryptographically signed by the party
victim to perform "defensive de-aggregation", i.e. to begin that holds a certificate for the set of IP prefixes.
originating </t>
more-specific prefixes in order to compete with the hijack r <t>The ROA format also supports a maxLength attribute. According to
outes for selection <xref target="RFC6482"/>, "When
as the best path in networks that are not performing RPKI-ba present, the maxLength specifies the maximum length of the IP address
sed route origin prefix that the AS is authorized to advertise." Thus, rather than
validation (ROV) <xref target="RFC6811"/>. requiring the ROA to list each prefix that the AS is authorized to
</t> originate, the maxLength attribute provides a shorthand that authorizes
<t> an AS to originate a set of IP prefixes.
In some topologies, where at least one AS on every path betw </t>
een the victim
and hijacker filters ROV invalid prefixes, it may be the cas
e 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 t
his response.
</t>
<t>
Nevertheless, this document recommends that where possible,
network operators
publish minimal ROAs even in the face of this risk. This is
because:
<list style="symbols">
<t>
Minimal ROAs offer the best possible protection agai
nst the immediate
impact of such an attack, rendering the need for suc
h a response less
likely;
</t>
<t>
Increasing ROV adoption by network operators will, o
ver time, decrease
the size of the neighborhoods in which this risk exi
sts; and
</t>
<t>
Other methods for reducing the size of such neighbor
hoods are available
to potential victims, such as establishing direct EB
GP adjacencies with
networks from whom the defensive routes would otherw
ise be hidden.
</t>
</list>
</t>
</section>
</section> <t>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 <xref
target="GSG17"/>. 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 <xref target="hijack"/>
for detailed discussion.
</t>
<t>For this reason, this document recommends that, whenever possible,
operators <bcp14>SHOULD</bcp14> 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 <xref target="RFC7115"/>. 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.
</t>
<t>Please note that the term "RPKI-based Route Origin Validation" and
the corresponding acronym "RPKI-ROV" that are used in this document mean t
he
same as the term "Prefix Origin Validation" used in <xref target="RFC6811"
/>.
</t>
<t>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 <xref target="ui"/>.
</t>
<section title="Considerations for RTDR Filtering Scenarios" anchor="rtdr"> <t>The practices described in this document require no changes
<t> to the RPKI specifications and will not increase the number of signed
Considerations related to ROAs and origin validation <xref target="R ROAs in the RPKI because ROAs already support lists of IP prefixes <xref
FC6811"/> for the target="RFC6482"/>.
case of destination-based Remotely Triggered Discard Route (RTDR) (e </t>
lsewhere referred <section>
to as "Remotely Triggered Black Hole") filtering are addressed here. <name>Requirements</name>
In RTDR filtering, highly specific prefixes (greater than /24 in IPv <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
4 and greater than "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
/48 in IPv6; possibly even /32 (IPv4) and /128 (IPv6)) are announced NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
in BGP. "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
These announcements are tagged with the Well-known BGP Community def "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
ined by are to be interpreted as described in BCP&nbsp;14 <xref
<xref target="RFC7999"/>. target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
It is obviously not desirable to use a large maxLength or include an appear in all capitals, as shown here.
y such highly
specific prefixes in the ROAs to accommodate destination-based RTDR
filtering, for the
reasons set out above.
</t> </t>
</section>
<section>
<name>Documentation Prefixes</name>
<t> <t>The documentation prefixes recommended in <xref target="RFC5737"/> ar
As a result, RPKI-based route origin validation <xref target="RFC681 e
1"/> is a poor fit insufficient for use as example prefixes in this document. Therefore,
for the validation of RTDR routes. this document uses the address space defined in <xref target="RFC1918"/>
Specification of new procedures to address this use case through the for
use of the RPKI is constructing example prefixes.
outside the scope of this document.
</t> </t>
<t>Note that although the examples in this document are presented
<t> using IPv4 prefixes, all the analysis thereof and the recommendations
Therefore: made are equally valid for the equivalent IPv6 cases.
<list style="symbols">
<t>
Operators SHOULD NOT create non-minimal ROAs (either by crea
ting additional
ROAs, or through the use of maxLength) for the purpose of ad
vertising RTDR
routes; and
</t>
<t>
Operators providing a means for operators of neighboring aut
onomous systems to
advertise RTDR routes via BGP MUST NOT make the creation of
non-minimal ROAs
a pre-requisite for its use.
</t>
</list>
</t> </t>
</section>
</section>
<section>
<name>Suggested Reading</name>
<t>It is assumed that the reader understands BGP <xref
target="RFC4271"/>, RPKI <xref target="RFC6480"/>, ROAs <xref
target="RFC6482"/>, RPKI-ROV <xref
target="RFC6811"/>, and BGPsec <xref target="RFC8205"/>.
</t>
</section>
<section anchor="hijack">
<name>Forged-Origin Sub-Prefix Hijack</name>
<t>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:
</t>
<ol type="(%d)" spacing="normal">
<li>the RPKI <xref target="RFC6480"/> is deployed, and</li>
<li>routers use RPKI-ROV to drop invalid
routes <xref target="RFC6811"/>, but </li>
<li>BGPsec <xref target="RFC8205"/> (or any similar method
to validate the truthfulness of the BGP AS_PATH attribute) is not
deployed.</li></ol>
<t>Note that this set of assumptions accurately describes a substantial
and growing number of large Internet networks at the time of writing.
</t>
<t>The forged-origin sub-prefix hijack <xref target="RFC7115"/>
<xref target="GCHSS"/> is described here using a running example.
</t>
<t>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.
</t>
<t>Suppose, however, the organization issues and publishes a ROA
including a maxLength value of 24:
</t>
<t indent="3">ROA:(192.168.0.0/16-24, AS 64496)</t>
<t>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.
</t>
<t>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 <xref target="RFC7115"/> <xref
target="GCHSS"/>:
</t>
<t indent="3">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.</t>
<t indent="3">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.</t>
<t indent="3">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.</t>
<t>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.
</t>
<t>The forged-origin sub-prefix hijack would have failed if a minimal
ROA as described in <xref target="recommendations"/> was used instead of t
he loose ROA. In this
example, a minimal ROA would be:
</t>
<t indent="3">ROA:(192.168.0.0/16, 192.168.225.0/24, AS 64496)</t>
<t>This ROA is "minimal" because it includes only those IP prefixes that A
S 64496 originates in BGP, but no other IP prefixes <xref target="RFC6907"/>.
</t>
<t>The minimal ROA renders AS 64511's BGP announcement invalid because:
</t>
<ol type="(%d)" spacing="normal">
<li>this ROA "covers" the attacker's announcement (since
192.168.0.0/24 is a sub-prefix of 192.168.0.0/16), and</li>
<li>there is no ROA "matching" the attacker's announcement (there is
no ROA for AS 64511 and IP prefix 192.168.0.0/24) <xref
target="RFC6811"/>.</li>
</ol>
<t>If routers ignore invalid BGP announcements, the minimal ROA above
ensures that the sub-prefix hijack will fail.
</t>
<t>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:
</t>
<t indent="3">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.</t>
<t>This forged-origin prefix hijack is significantly less damaging than
the forged-origin sub-prefix hijack:
</t>
<t indent="3">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.</t>
<t indent="3">Moreover, the path originated by AS 64511 is one hop
longer than the path originated by the legitimate origin AS 64496.</t>
<t>As discussed in <xref target="LSG16"/>, 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.
</t>
<t>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.
</t>
</section> </section>
<section>
<name>Measurements of the RPKI</name>
<section title="User Interface Design Recommendations" anchor="ui"> <t>Network measurements taken in June 2017 showed that 12% of the IP
<t> prefixes authorized in ROAs have a maxLength value longer than their prefi
Most operator interaction with the RPKI system when creating or modi x
fying ROAs will length. Of these, the vast majority (84%) were non-minimal, as they
occur via a user interface that abstracts the underlying encoding, s included sub-prefixes that are not announced in BGP by the legitimate
igning and AS and were thus vulnerable to forged-origin sub-prefix hijacks. See
publishing operations. <xref target="GSG17"/> for details.
</t>
<t>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.
</t>
</section>
<section anchor="recommendations">
<name>Recommendations about Minimal ROAs and maxLength</name>
<t>Operators <bcp14>SHOULD</bcp14> 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 <xref
target="hijack"/> for an example.
</t>
<t>In general, operators <bcp14>SHOULD</bcp14> avoid using the maxLength
attribute in their ROAs, since its inclusion will usually make the ROA
non-minimal.
</t>
<t>One such exception may be when all more specific prefixes permitted
by the maxLength value are actually announced by the AS in the ROA. Anoth
er
exception is where: (a) the maxLength value is substantially larger compar
ed
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.</t>
<t>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 <xref target="RFC6482"/>. See <xref
target="GSG17"/> for further discussion of why this practice will have
minimal impact on the performance of the RPKI ecosystem.
</t>
<t>Operators that implement these recommendations and have existing
ROAs published in the RPKI system <bcp14>MUST</bcp14> 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 <bcp14>MUST</bcp14> be replaced as necessary. Such an exercise
<bcp14>MUST</bcp14> be repeated whenever the operator makes changes to
either policy.
</t>
<section anchor="nominimal">
<name>Facilitating Ad Hoc Routing Changes and DDoS Mitigation</name>
<t>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".
</t> </t>
<t> <t>In order to ensure that such ad hoc routing changes are effective,
This document recommends that designers and/or providers of such use a ROA validating the new route should exist. However, a difficulty
r interfaces SHOULD arises due to the fact that newly created objects in the RPKI are made
provide warnings to draw the user's attention to the risks of creati visible to relying parties considerably more slowly than routing
ng non-minimal updates in BGP.
ROAs in general, and use of the maxLength attribute in particular.
</t> </t>
<t> <t>Ideally, it would not be necessary to pre-create the ROA, which
Warnings provided by such a system may vary in nature from generic w validates the ad hoc route, and instead create it "on the fly" as
arnings based required. However, this is practical only if the latency imposed by
purely on the inclusion of the maxLength attribute, to customised gu the propagation of RPKI data is guaranteed to be within acceptable
idance based on the limits in the circumstances. For time-critical interventions such as
observable BGP routing policy of the operator in question. responding to a DDoS attack, this is unlikely to be the case.
The choices made in this respect are expected to be dependent on the
target user
audience of the implementation.
</t> </t>
</section> <t>Thus, the ROA in question will usually need to be created well in
advance of the routing intervention, but such a ROA will be
<section title="Operational Considerations" anchor="operational-consideratio non-minimal, since it includes an IP prefix that is sometimes (but not
ns"> always) originated in BGP.
<t>
The recommendations specified in this document, in particular, those
in
<xref target="recommendations"/>, involve trade-offs between operati
onal agility and
security.
</t> </t>
<t> <t>In this case, the ROA <bcp14>SHOULD</bcp14> only include:
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 t
o effect changes to
the set of prefixes which are originated in BGP.
</t> </t>
<t> <ol type="(%d)" spacing="normal">
Even in the case of routing changes that are planned in advance, exi <li>the set of IP prefixes that are always originated in BGP,
sting procedures and</li>
may need to be updated to incorporate changes to issued ROAs, and ma <li>the set of IP prefixes that are sometimes, but not always,
y require originated in BGP.</li>
additional time allowed for those changes to propagate. </ol>
<t>The ROA <bcp14>SHOULD NOT</bcp14> include any IP prefixes that the
operator knows will not be originated in BGP. In general, the ROA
<bcp14>SHOULD NOT</bcp14> make use of the maxLength attribute unless
doing so has no impact on the set of included prefixes.
</t> </t>
<t> <t>The running example is now extended to illustrate one situation
Operators are encouraged to carefully review the issues highlighted where it is not possible to issue a minimal ROA.
(especially those
in <xref target="nominimal"/> and <xref target="deaggr"/>) in light
of their specific
operational requirements. Failure to do so could, in the worst case,
result in a
self-inflicted denial of service.
</t> </t>
<t> <t>Consider the following scenario prior to the deployment of RPKI.
The recommendations made in section 5 are likely to be more onerous Suppose AS 64496 announced 192.168.0.0/16 and has a contract with a
for operators DDoS mitigation service provider that
utilising large IP address space allocations from which many more-sp holds AS 64500. Further, assume that the DDoS mitigation service
ecific contract applies to all IP addresses covered by 192.168.0.0/22. When
advertisements are made in BGP. Operators of such networks are encou a DDoS attack is detected and reported by AS 64496, AS 64500
raged to seek immediately originates 192.168.0.0/22, thus attracting all the DDoS
opportunities to automate the required procedures in order to minimi traffic to itself. The traffic is scrubbed at AS 64500 and then sent
se manual back to AS 64496 over a backhaul link. Notice that, during a DDoS
operational burden. 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.
</t> </t>
</section> <t>First, suppose the RPKI only had the minimal ROA for AS 64496, as
described in <xref target="hijack"/>. However, if there is no ROA
<section title="Security Considerations" anchor="security-considerations"> authorizing AS 64500 to announce the /22 prefix, then the DDoS
<t> mitigation (and traffic scrubbing) scheme would not work. That is, if
This document makes recommendations regarding the use of RPKI-based AS 64500 originates the /22 prefix in BGP during DDoS attacks, the
origin validation announcement would be invalid <xref target="RFC6811"/>.
as defined in <xref target="RFC6811"/>, and as such introduces no ad
ditional security
considerations beyond those specified therein.
</t> </t>
</section> <t>Therefore, the RPKI should have two ROAs: one for AS 64496 and one
for AS 64500.
<section anchor="IANA" title="IANA Considerations">
<t>
This document includes no request to IANA.
</t> </t>
</section> <t indent="3">ROA:(192.168.0.0/16, 192.168.225.0/24, AS 64496)</t>
<t indent="3">ROA:(192.168.0.0/22, AS 64500)</t>
<section anchor="Acknowledgments" title="Acknowledgments"> <t>Neither ROA uses the maxLength attribute, but the second ROA is
<t> not "minimal" because it contains a /22 prefix that is not originated
The authors would like to thank the following people for their revie by anyone in BGP during normal operations. The /22 prefix is only
w and originated by AS 64500 as part of its DDoS mitigation service during a
contributions to this document: DDoS attack.
Omar Sagga </t>
and <t>Notice, however, that this scheme does not come without risks.
Aris Lambrianidis. Namely, all IP addresses in 192.168.0.0/22 are vulnerable to a
Thanks are also due to forged-origin sub-prefix hijack during normal operations when the /22
Matthias Waehlisch, prefix is not originated. (The hijacker AS 64511 would send the BGP
Ties de Kock, announcement "192.168.0.0/22: AS 64511, AS 64500", falsely claiming
Amreesh Phokeer, that AS 64511 is a neighbor of AS 64500 and falsely claiming that AS
Éric Vyncke, 64500 originates 192.168.0.0/22.)
Alvaro Retana, </t>
John Scudder, <t>In some situations, the DDoS mitigation service at AS 64500 might
Roman Danyliw, want to limit the amount of DDoS traffic that it attracts and scrubs.
Andrew Alston, Suppose that a DDoS attack only targets IP addresses in
and 192.168.0.0/24. Then, the DDoS mitigation service at AS 64500 only
Murray Kucherawy wants to attract the traffic designated for the /24 prefix that is
for comments and suggestions, under attack, but not the entire /22 prefix. To allow for this, the
to Roni Even for the Gen-ART review, RPKI should have two ROAs: one for AS 64496 and one for AS 64500.
to Jean Mahoney for the ART-ART review, </t>
to Acee Lindem for the Routing Directorate review, <t indent="3">ROA:(192.168.0.0/16, 192.168.225.0/24, AS 64496)</t>
and <t indent="3">ROA:(192.168.0.0/22-24, AS 64500)</t>
to Sean Turner for the Security Area Directorate review. <t>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.
</t>
<t>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.
</t>
<t>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.
</t>
</section>
<section anchor="deaggr">
<name>Defensive De-aggregation in Response to Prefix Hijacks</name>
<t>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 <xref
target="RFC6811"/>.
</t>
<t>In topologies where at least one AS on every path between the
victim and hijacker filters RPKI-ROV invalid prefixes, it may be the cas
e
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.
</t>
<t>Nevertheless, this document recommends that, where possible, network
operators publish minimal ROAs even in the face of this risk. This is
because:
</t> </t>
<ul spacing="normal">
<li>Minimal ROAs offer the best possible protection against the
immediate impact of such an attack, rendering the need for such a
response less likely;</li>
<li>Increasing RPKI-ROV adoption by network operators will, over time,
decrease the size of the neighborhoods in which this risk exists;
and</li>
<li>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.</li>
</ul>
</section>
</section> </section>
<section anchor="rtdr">
<name>Considerations for RTDR Filtering Scenarios</name>
<t>Considerations related to ROAs and RPKI-ROV <xref
target="RFC6811"/> 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
<xref target="RFC7999"/>. 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 t
o
accommodate destination-based RTDR filtering.
</t>
</middle> <t>As a result, RPKI-ROV <xref target="RFC6811"/> is a poor fit for the
validation of RTDR routes.
<back> Specification of new procedures to address this use case through the use
of the RPKI is outside the scope of this document.
<references title="Normative References"> </t>
<?rfc include="reference.RFC.1918.xml"?> <t>Therefore:
<?rfc include="reference.RFC.2119.xml"?> </t>
<?rfc include="reference.RFC.4271.xml"?> <ul spacing="normal">
<?rfc include="reference.RFC.6480.xml"?> <li>Operators <bcp14>SHOULD NOT</bcp14> create non-minimal ROAs
<?rfc include="reference.RFC.6482.xml"?> (by either creating additional ROAs or using the maxLength attribute)
<?rfc include="reference.RFC.6811.xml"?> for the purpose of advertising RTDR routes; and</li>
<?rfc include="reference.RFC.7115.xml"?> <li>Operators providing a means for operators of neighboring
<?rfc include="reference.RFC.8174.xml"?> autonomous systems to advertise RTDR routes via BGP <bcp14>MUST
NOT</bcp14> make the creation of non-minimal ROAs a pre-requisite for
</references> its use.</li>
</ul>
<references title="Informative References"> </section>
<section anchor="ui">
<name>User Interface Design Recommendations</name>
<t>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.
</t>
<t>This document recommends that designers and/or providers of such user
interfaces <bcp14>SHOULD</bcp14> 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.
</t>
<t>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.
</t>
</section>
<section anchor="operational-considerations">
<name>Operational Considerations</name>
<t>The recommendations specified in this document (in particular, those
in <xref target="recommendations"/>) involve trade-offs between
operational agility and security.
</t>
<t>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.
</t>
<t>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.
</t>
<t>Operators are encouraged to carefully review the issues highlighted
(especially those in Sections <xref target="nominimal" format="counter"/>
and <xref
target="deaggr" format="counter"/>) in light of their specific operational
requirements. Failure to do so could, in the worst case, result in a
self-inflicted denial of service.
</t>
<t>The recommendations made in <xref target="recommendations"/> 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.
</t>
</section>
<section anchor="security-considerations">
<name>Security Considerations</name>
<t>This document makes recommendations regarding the use of RPKI-ROV
as defined in <xref target="RFC6811"/> and, as such,
introduces no additional security considerations beyond those specified
therein.
</t>
</section>
<section anchor="IANA">
<name>IANA Considerations</name>
<t>This document has no IANA actions.
</t>
</section>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
918.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
271.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
480.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
482.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
811.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
115.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
</references>
<references>
<name>Informative References</name>
<reference anchor="GSG17" target="https://eprint.iacr.org/2016/1015.pdf" > <reference anchor="GSG17" target="https://eprint.iacr.org/2016/1015.pdf" >
<front> <front>
<title>Maxlength Considered Harmful to the RPKI</title> <title>MaxLength Considered Harmful to the RPKI</title>
<author initials="Y." surname="Gilad"><organization /></author> <author initials="Y." surname="Gilad">
<author initials="O." surname="Sagga"><organization /></author> <organization/>
<author initials="S." surname="Goldberg"><organization /></autho </author>
r> <author initials="O." surname="Sagga">
<date year="2017" month="December" /> <organization/>
</front> </author>
<seriesInfo name="in" value="ACM CoNEXT 2017" /> <author initials="S." surname="Goldberg">
<organization/>
</author>
<date year="2017" month="December"/>
</front>
<refcontent>CoNEXT '17</refcontent>
<seriesInfo name="DOI" value="10.1145/3143361.3143363"/>
</reference> </reference>
<reference anchor="LSG16" target="http://cacm.acm.org/magazines/2016/10/ 207763-rethinking-security-for-internet-routing/"> <reference anchor="LSG16" target="http://cacm.acm.org/magazines/2016/10/ 207763-rethinking-security-for-internet-routing/">
<front> <front>
<title>Rethinking Security for Internet Routing</title> <title>Rethinking security for internet routing</title>
<author initials="R." surname="Lychev"><organization /></author> <author initials="R." surname="Lychev">
<author initials="M." surname="Shapira"><organization /></author <organization/>
> </author>
<author initials="S." surname="Goldberg"><organization /></autho <author initials="M." surname="Shapira">
r> <organization/>
<date year="2016" month="October" /> </author>
</front> <author initials="S." surname="Goldberg">
<seriesInfo name="in" value="Communications of the ACM" /> <organization/>
</author>
<date year="2016" month="October"/>
</front>
<refcontent>Communications of the ACM</refcontent>
<seriesInfo name="DOI" value="10.1145/2896817"/>
</reference> </reference>
<reference anchor="GCHSS" target="https://eprint.iacr.org/2016/1010.pdf" > <reference anchor="GCHSS" target="https://eprint.iacr.org/2016/1010.pdf" >
<front> <front>
<title>Are We There Yet? On RPKI&#39;s Deployment and Security</ <title>Are We There Yet? On RPKI's Deployment and Security</title>
title> <author initials="Y." surname="Gilad">
<author initials="Y." surname="Gilad"><organization /></author> <organization/>
<author initials="A." surname="Cohen"><organization /></author> </author>
<author initials="A." surname="Herzberg"><organization /></autho <author initials="A." surname="Cohen">
r> <organization/>
<author initials="M." surname="Schapira"><organization /></autho </author>
r> <author initials="A." surname="Herzberg">
<author initials="H." surname="Shulman"><organization /></author <organization/>
> </author>
<date year="2017" month="February" /> <author initials="M." surname="Schapira">
</front> <organization/>
<seriesInfo name="in" value="NDSS 2017" /> </author>
</reference> <author initials="H." surname="Shulman">
<organization/>
<reference anchor="HARMFUL" target="https://eprint.iacr.org/2016/1015.pd </author>
f"> <date year="2017" month="February"/>
<!-- https://dl.acm.org/citation.cfm?doid=3143361.3143363 --> </front>
<front> <refcontent>NDSS 2017</refcontent>
<title>MaxLength Considered Harmful to the RPKI</title>
<author initials="Y." surname="Gilad"><organization /></author>
<author initials="O." surname="Sagga"><organization /></author>
<author initials="S." surname="Goldberg"><organization /></autho
r>
<date year="2017" />
</front>
<!-- <seriesInfo name="in" value="NDSS 2017" /> -->
</reference> </reference>
<?rfc include="reference.RFC.5737.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<?rfc include="reference.RFC.6907.xml"?> 737.xml"/>
<?rfc include="reference.RFC.7999.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<?rfc include="reference.RFC.8205.xml"?> 907.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
999.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
205.xml"/>
</references>
</references> </references>
<section anchor="Acknowledgments" numbered="false">
<name>Acknowledgments</name>
<t>The authors would like to thank the following people for their review
and contributions to this document: <contact fullname="Omar Sagga"/> and
<contact fullname="Aris Lambrianidis"/>. Thanks are also due to
<contact fullname="Matthias Waehlisch"/>, <contact fullname="Ties de
Kock"/>, <contact fullname="Amreesh Phokeer"/>, <contact fullname="Éric
Vyncke"/>, <contact fullname="Alvaro Retana"/>, <contact fullname="John
Scudder"/>, <contact fullname="Roman Danyliw"/>, <contact
fullname="Andrew Alston"/>, and <contact fullname="Murray Kucherawy"/>
for comments and suggestions, to <contact fullname="Roni Even"/> for the
Gen-ART review, to <contact fullname="Jean Mahoney"/> for the ART-ART
review, to <contact fullname="Acee Lindem"/> for the Routing Area Director
ate
review, and to <contact fullname="Sean Turner"/> for the Security Area
Directorate review.
</t>
</section>
</back>
</back>
</rfc> </rfc>
<!-- vim: et ts=4 sts=4 sw=4 colorcolumn=100 spell :
 End of changes. 35 change blocks. 
1035 lines changed or deleted 692 lines changed or added

This html diff was produced by rfcdiff 1.48.