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.