Diff: rfc8704xml2.original.xml

	rfc8704xml2.original.xml	rfc8704.xml

	<?xml version="1.0" encoding="US-ASCII"?>	<?xml version='1.0' encoding='utf-8'?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">

	<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.2119.xml">
	<!ENTITY RFC2827 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.2827.xml">
	<!ENTITY RFC3704 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.3704.xml">
	<!ENTITY RFC6811 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.6811.xml">
	<!ENTITY RFC6482 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.6482.xml">
	<!ENTITY RFC4271 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.4271.xml">
	<!ENTITY RFC4036 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.4036.xml">
	<!ENTITY RFC4364 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.4364.xml">
	<!ENTITY RFC7454 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.7454.xml">
	<!ENTITY RFC8174 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
	RFC.8174.xml">
	]>


	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?><?rfc strict="yes" ?>	<rfc number="8704" xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IE
	<?rfc toc="yes"?>	TF"
	<?rfc tocdepth="4"?>	docName="draft-ietf-opsec-urpf-improvements-04" category="bcp"
	<?rfc symrefs="yes"?>	updates="3704" consensus="yes" ipr="trust200902" obsoletes=""
	<?rfc sortrefs="yes" ?>	xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true"
	<?rfc compact="yes" ?>	version="3">
	<?rfc subcompact="no" ?>
	<rfc submissionType="IETF" docName="draft-ietf-opsec-urpf-improvements-04"
	category="bcp" seriesNo="84 (if approved)" updates="3704"
	consensus="yes" ipr="trust200902">


	<!--	<!-- xml2rfc v2v3 conversion 2.31.0 -->
	<rfc category="bcp" updates="3704" docName="draft-ietf-opsec-urpf-improvements-0
	4" ipr="trust200902">


	<front>	<front>
	<title abbrev="Enhanced FP-uRPF">Enhanced Feasible-Path Unicast Reverse Path For	<title abbrev="Enhanced FP-uRPF">Enhanced Feasible-Path Unicast Reverse Path
	warding</title>	Forwarding</title>
		<seriesInfo name="RFC" value="8704" />
		<seriesInfo name="BCP" value="84"/>

	<author fullname="Kotikalapudi Sriram" initials="K." surname="Sriram">	<author fullname="Kotikalapudi Sriram" initials="K." surname="Sriram">
	<organization abbrev="USA NIST">USA National Institute of Standards and Te chnology</organization>	<organization abbrev="USA NIST">USA National Institute of Standards and Te chnology</organization>
	<address>	<address>

	<postal>	<postal>
	<street>100 Bureau Drive</street>	<street>100 Bureau Drive</street>

	<!-- Reorder these if your country does things differently -->
	<city>Gaithersburg</city>	<city>Gaithersburg</city>

	<region></region>	<region>MD</region>
	<code>MD 20899</code>	<code>20899</code>
	<country>USA</country>	<country>United States of America</country>
	</postal>	</postal>
	<email>ksriram@nist.gov</email>	<email>ksriram@nist.gov</email>
	</address>	</address>
	</author>	</author>

		<author fullname="Doug Montgomery" initials="D." surname="Montgomery">
	<author fullname="Doug Montgomery" initials="D." surname="Montgomery">
	<organization abbrev="USA NIST">USA National Institute of Standards and Te chnology</organization>	<organization abbrev="USA NIST">USA National Institute of Standards and Te chnology</organization>
	<address>	<address>

	<postal>	<postal>
	<street>100 Bureau Drive</street>	<street>100 Bureau Drive</street>

	<!-- Reorder these if your country does things differently -->
	<city>Gaithersburg</city>	<city>Gaithersburg</city>

	<region></region>	<region>MD</region>
	<code>MD 20899</code>	<code>20899</code>
	<country>USA</country>	<country>United States of America</country>
	</postal>	</postal>
	<email>dougm@nist.gov</email>	<email>dougm@nist.gov</email>
	</address>	</address>
	</author>	</author>

		<author fullname="Jeffrey Haas" initials="J." surname="Haas">
	<author fullname="Jeffrey Haas" initials="J." surname="Haas">	<organization>Juniper Networks, Inc.</organization>
	<organization>Juniper Networks, Inc.</organization>
	<address>	<address>

	<postal>	<postal>
	<street>1133 Innovation Way</street>	<street>1133 Innovation Way</street>

	<!-- Reorder these if your country does things differently -->
	<city>Sunnyvale</city>	<city>Sunnyvale</city>

	<region></region>	<region>CA</region>
	<code>CA 94089</code>	<code>94089</code>
	<country>USA</country>	<country>United States of America</country>
	</postal>	</postal>
	<email>jhaas@juniper.net</email>	<email>jhaas@juniper.net</email>
	</address>	</address>
	</author>	</author>

		<date month="February" year="2020"/>
	<date year="" />

	<!-- Meta-data Declarations -->

	<area>Operations</area>	<area>Operations</area>
	<workgroup>OPSEC Working Group</workgroup>	<workgroup>OPSEC Working Group</workgroup>


	<keyword>BGP, source address spoofing, source address validation (SAV), Reve	<keyword>BGP, source address spoofing, source address validation (SAV),
	rse Path Forwarding (RPF), unicast RPF (uRPF), DDoS mitigation, BCP 38, BCP 84</	Reverse Path Forwarding (RPF), unicast RPF (uRPF), DDoS mitigation, BCP
	keyword>	38, BCP 84</keyword>

	<abstract>	<abstract>
	<t>	<t>

	This document identifies a need for and proposes improvement of the unicast Reve	This document identifies a need for and proposes improvement of the unicast
	rse Path Forwarding (uRPF) techniques (see RFC 3704) for detection and mitigatio	Reverse Path Forwarding (uRPF) techniques (see RFC 3704) for detection and
	n of source address spoofing (see BCP 38). The strict uRPF is inflexible about d	mitigation of source address spoofing (see BCP 38). Strict uRPF is
	irectionality, the loose uRPF is oblivious to directionality, and the current fe	inflexible about directionality, the loose uRPF is oblivious to
	asible-path uRPF attempts to strike a balance between the two (see RFC 3704). Ho	directionality, and the current feasible-path uRPF attempts to strike a
	wever, as shown in this document, the existing feasible-path uRPF still has shor	balance between the two (see RFC 3704). However, as shown in this document,
	tcomings. This document describes enhanced feasible-path uRPF (EFP-uRPF) techniq	the existing feasible-path uRPF still has shortcomings. This document
	ues, which are more flexible (in a meaningful way) about directionality than the	describes enhanced feasible-path uRPF (EFP-uRPF) techniques that are more flexib
	feasible-path uRPF (RFC 3704). The proposed EFP-uRPF methods aim to significant	le (in a meaningful way) about directionality than the feasible-path uRPF (RFC 3
	ly reduce false positives regarding invalid detection in source address validati	704). The proposed EFP-uRPF methods aim to significantly reduce false positives
	on (SAV). Hence they can potentially alleviate ISPs' concerns about the possibil	regarding invalid detection in source address validation (SAV). Hence, they can
	ity of disrupting service for their customers, and encourage greater deployment	potentially alleviate ISPs' concerns about the possibility of disrupting service
	of uRPF techniques. This document updates RFC 3704.	for their customers and encourage greater deployment of uRPF techniques. This d
	</t>	ocument updates RFC 3704.
		</t>
	</abstract>	</abstract>

	</front>	</front>
		<middle>
	<middle>	<section anchor="intro" numbered="true" toc="default">
	<section anchor="intro" title="Introduction">	<name>Introduction</name>
	<t>	<t>
	Source Address Validation (SAV) refers to the detection and mitigation of source	Source address validation (SAV) refers to the detection and mitigation of source
	address (SA) spoofing <xref target="RFC2827"></xref>. This document identifies	address (SA) spoofing <xref target="RFC2827" format="default"/>. This document
	a need for and proposes improvement of improvement of the unicast Reverse Path F	identifies a need for and proposes improvement of the unicast Reverse Path Forwa
	orwarding (uRPF) techniques <xref target="RFC3704"></xref> for SAV. The strict u	rding (uRPF) techniques <xref target="RFC3704" format="default"/> for SAV. Stric
	RPF is inflexible about directionality (see <xref target="RFC3704"></xref> for d	t uRPF is inflexible about directionality (see <xref target="RFC3704" format="de
	efinitions), the loose uRPF is oblivious to directionality, and the current feas	fault"/> for definitions), the loose uRPF is oblivious to directionality, and th
	ible-path uRPF attempts to strike a balance between the two <xref target="RFC370	e current feasible-path uRPF attempts to strike a balance between the two <xref
	4"></xref>. However, as shown in this document, the existing feasible-path uRPF	target="RFC3704" format="default"/>. However, as shown in this document, the exi
	still has shortcomings. Even with the feasible-path uRPF, ISPs are often apprehe	sting feasible-path uRPF still has shortcomings. Even with the feasible-path uRP
	nsive that they may be dropping customers' data packets with legitimate source a	F, ISPs are often apprehensive that they may be dropping customers' data packets
	ddresses.	with legitimate source addresses.
	</t>	</t>

	<t>	<t>


	This document describes an enhanced feasible-path uRPF (EFP-uRPF) technique, whi	This document describes enhanced feasible-path uRPF (EFP-uRPF)
	ch aims to be more flexible (in a meaningful way) about directionality than the	techniques that aim to be more flexible (in a meaningful way) about
	feasible-path uRPF. It is based on the principle that if BGP updates for multipl	directionality than the feasible-path uRPF. It is based on the
	e prefixes with the same origin AS were received on different interfaces (at bor	principle that if BGP updates for multiple prefixes with the same
	der routers), then incoming data packets with source addresses in any of those p	origin AS were received on different interfaces (at border routers), then incomi
	refixes should be accepted on any of those interfaces (presented in <xref target	ng data packets with source addresses in any of those prefixes should be accepte
	="newtech"></xref>). For some challenging ISP-customer scenarios (see <xref targ	d on any of those interfaces (presented in <xref target="newtech" format="defaul
	et="challenge"></xref>), this document also describes a more relaxed version of	t"/>). For some challenging ISP-customer scenarios (see <xref target="challenge"
	the enhanced feasible-path uRPF technique (presented in <xref target="algB"></xr	format="default"/>), this document also describes a more relaxed version of the
	ef>). Implementation and operations considerations are discussed in <xref target	enhanced feasible-path uRPF technique (presented in <xref target="algB" format=
	="impl"></xref>.	"default"/>). Implementation and operations considerations are discussed in <xre
		f target="impl" format="default"/>.
	</t>	</t>

	<t>	<t>
	Throughout this document, the routes under consideration are assumed to have bee	Throughout this document, the routes under consideration are assumed to have bee
	n vetted based on prefix filtering <xref target="RFC7454"></xref> and possibly o	n vetted based on prefix filtering <xref target="RFC7454" format="default"/> and
	rigin validation <xref target="RFC6811"></xref>.	possibly origin validation <xref target="RFC6811" format="default"/>.
	</t>	</t>

	<t>	<t>
	The EFP-uRPF methods aim to significantly reduce false positives regarding inval	The EFP-uRPF methods aim to significantly reduce false positives regarding inval
	id detection in SAV. They are expected to add greater operational robustness and	id detection in SAV. They are expected to add greater operational robustness and
	efficacy to uRPF, while minimizing ISPs' concerns about accidental service disr	efficacy to uRPF while minimizing ISPs' concerns about accidental service disru
	uption for their customers. It is expected that this will encourage more deploym	ption for their customers. It is expected that this will encourage more deployme
	ent of uRPF to help realize its DDoS prevention benefits network wide.	nt of uRPF to help realize its Denial of Service (DoS) and Distributed DoS (DDoS
		) prevention benefits network wide.
	</t>	</t>

	<section title="Terminology">	<section numbered="true" toc="default">
	<t>	<name>Terminology</name>
	Reverse Path Forwarding (RPF) list: The list of permissible source-address prefi	<t>
	xes for incoming data packets on a given interface.	The Reverse Path Forwarding (RPF) list is the list of permissible source-address
		prefixes for incoming data packets on a given interface.
	</t>	</t>

	<t>	<t>
	Peering relationships considered in this document are provider-to-customer (P2C)	Peering relationships considered in this document are provider-to-customer
	, customer-to-provider (C2P), and peer-to-peer (p2p). Provider here refers to tr	(P2C), customer-to-provider (C2P), and peer-to-peer (P2P). Here,
	ansit provider. The first two are transit relationships. A peer connected via a	"provider" refers to a transit provider. The first two are transit relationships
	p2p link is known as a lateral peer (non-transit).	. A peer connected via a P2P link is known as a lateral peer (non-transit).
	</t>	</t>

	<t>	<t>
	Customer Cone: AS A's customer cone is A plus all the ASes that can be reached f	AS A's customer cone is A plus all the ASes that can be reached from A following
	rom A following only P2C links <xref target="Luckie"></xref>.	only P2C links <xref target="Luckie" format="default"/>.
	</t>	</t>

	<t>	<t>
	A stub AS is an AS that does not have any customers or lateral peers. In this do	A stub AS is an AS that does not have any customers or lateral peers. In this do
	cument, a single-homed stub AS is one that has a single transit provider and a m	cument, a single-homed stub AS is one that has a single transit provider and a m
	ulti-homed stub AS is one that has multiple (two or more) transit providers.	ultihomed stub AS is one that has multiple (two or more) transit providers.
	</t>	</t>

		</section>
		<section numbered="true" toc="default">
		<name>Requirements Language</name>


	</section>	<t>
		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
		RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" 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 title="Requirements Language">	</section>
	<t>
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
	HOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this docu
	ment are to be interpreted as described in BCP 14 <xref target="RFC2119"></xref>
	<xref target="RFC8174"></xref> when, and only when, they appear in all capitals
	, as shown here.
	</t>
	</section>	</section>

		<section anchor="review" numbered="true" toc="default">
	</section>	<name>Review of Existing Source Address Validation Techniques</name>
		<t>
	<section anchor="review" title="Review of Existing Source Address Validation Tec	There are various existing techniques for the mitigation of DoS/DDoS
	hniques">	attacks with spoofed addresses <xref target="RFC2827"
		format="default"/> <xref target="RFC3704" format="default"/>. SAV is performed
	<t>	in network edge devices, such as
	There are various existing techniques for mitigation against DDoS attacks with s	border routers, Cable Modem Termination Systems (CMTS) <xref target="RFC4036"
	poofed addresses <xref target="RFC2827"></xref> <xref target="RFC3704"></xref>.	format="default"/>, and Packet Data Network Gateways (PDN-GW) in mobile
		networks <xref target="Firmin" format="default"/>. Ingress Access Control List
	<!--	(ACL) and uRPF are techniques employed for implementing SAV <xref target="RFC282
	There are also some techniques used for mitigating reflection attacks <xref targ	7" format="default"/> <xref target="RFC3704" format="default"/> <xref target="IS
	et="RRL"></xref> <xref target="TA14-017A"></xref>, which are used to amplify the	OC" format="default"/>.
	impact in DDoS attacks. Employing a combination of these preventive techniques
	(as applicable) in enterprise and ISP border routers, broadband and wireless acc
	ess network, data centers, and DNS/NTP servers provides reasonably effective pro
	tection against DDoS attacks.
	</t>
	<t>

	Source address validation (SAV) is performed in network edge devices such as bor
	der routers, Cable Modem Termination Systems (CMTS) <xref target="RFC4036"></xre
	f>, and Packet Data Network gateways (PDN-GW) in mobile networks <xref target="F
	irmin"></xref>. Ingress Access Control List (ACL) and unicast Reverse Path Forw
	arding (uRPF) are techniques employed for implementing SAV <xref target="RFC2827
	"></xref> <xref target="RFC3704"></xref> <xref target="ISOC"></xref>.
	</t>

	<section anchor="acl" title="SAV using Access Control List">
	<t>
	Ingress/egress Access Control Lists (ACLs) are maintained to list acceptable (or
	alternatively, unacceptable) prefixes for the source addresses in the incoming/
	outgoing Internet Protocol (IP) packets. Any packet with a source address that f
	ails the filtering criteria is dropped. The ACLs for the ingress/egress filters
	need to be maintained to keep them up to date. Updating the ACLs is an operator-
	driven manual process, and hence operationally difficult or infeasible.

	<!-- Hence, this method may be operationally difficult or infeasible in dynamic
	environments such as when a customer network is multihomed, has address space al
	locations from multiple ISPs, or dynamically varies its BGP announcements (i.e.
	routing) for traffic engineering purposes. In such environments, keeping the ACL
	s up to date would be challenging, especially if the rate of change is high. -->
	</t>	</t>

	<t>	<section anchor="acl" numbered="true" toc="default">
	Typically, the egress ACLs in access aggregation devices (e.g., CMTS, PDN-GW) pe	<name>SAV Using Access Control List</name>
	rmit source addresses only from the address spaces (prefixes) that are associate	<t>
	d with the interface on which the customer network is connected. Ingress ACLs ar	Ingress/egress ACLs are maintained to list acceptable
	e typically deployed on border routers, and drop ingress packets when the source	(or alternatively, unacceptable) prefixes for the source addresses in the
	address is spoofed (e.g., belongs to obviously disallowed prefix blocks, IANA s	incoming/outgoing Internet Protocol (IP) packets. Any packet with a source
	pecial-purpose prefixes <xref target="SPAR-v4"></xref><xref target="SPAR-v6"></x	address that fails the filtering criteria is dropped. The ACLs for the
	ref>, provider's own prefixes, etc.).	ingress/egress filters need to be maintained to keep them up to
		date. Updating the ACLs is an operator-driven manual process; hence,
		it is operationally difficult or infeasible. </t>
		<t>
		Typically, the egress ACLs in access aggregation devices (e.g., CMTS, PDN-GW)
		permit source addresses only from the address spaces (prefixes) that are
		associated with the interface on which the customer network is connected. Ingres
		s ACLs are typically deployed on border routers and drop ingress packets when th
		e source address is spoofed (e.g., belongs to obviously disallowed prefix blocks
		, IANA special-purpose prefixes <xref target="SPAR-v4" format="default"/><xref t
		arget="SPAR-v6" format="default"/>, provider's own prefixes, etc.).
	</t>	</t>

	</section>	</section>
		<section anchor="surpf" numbered="true" toc="default">
	<section anchor="surpf" title="SAV using Strict Unicast Reverse Path Forwarding"	<name>SAV Using Strict Unicast Reverse Path Forwarding</name>
	>	<t>
		Note: In the figures (scenarios) in this section and the subsequent sections,
		the following terminology is used:
		</t>
		<ul spacing="normal">
		<li>
		"fails" means drops packets with legitimate
		source addresses.
		</li>
		<li>
		"works (but not desirable)" means passes all packets with
		legitimate source addresses but is oblivious to directionality.
		</li>
		<li>
		"works best" means passes all packets with legitimate source addresses with no
		(or minimal) compromise of directionality.
		</li>
		<li>
		The notation Pi[ASn ASm ...] denotes a BGP update with prefix Pi and an
		AS_PATH as shown in the square brackets.
		</li>
		</ul>
		<t>
		In the strict uRPF method, an ingress packet
		at a border router is accepted only if the Forwarding Information Base (FIB)
		contains a prefix that encompasses the source address and forwarding
		information for that prefix points back to the interface over which the packet
		was received. In other words, the reverse path for routing to the source
		address (if it were used as a destination address) should use the same
		interface over which the packet was received. It is well known that this
		method has limitations when networks are multihomed, routes are not
		symmetrically announced to all transit providers, and there is asymmetric
		routing of data packets. Asymmetric routing occurs (see <xref target="fig1"
		format="default"/>) when a customer AS announces one prefix (P1) to one
		transit provider (ISP-a) and a different prefix (P2) to another transit
		provider (ISP-b) but routes data packets with source addresses in the second
		prefix (P2) to the first transit provider (ISP-a) or vice versa. Then, data
		packets with a source address in prefix P2 that are received at AS2
		directly from AS1
		will get dropped. Further, data packets with a source address in prefix P1 that
		originate from AS1 and traverse via AS3 to AS2 will also get dropped at AS2.


	<t>
	Note: In the figures (scenarios) in this section and the subsequent sections, th
	e following terminology is used: "fails" means drops packets with legitimate sou
	rce addresses; "works (but not desirable)" means passes all packets with legitim
	ate source addresses but is oblivious to directionality; "works best" means pass
	es all packets with legitimate source addresses with no (or minimal) compromise
	of directionality. Further, the notation Pi[ASn ASm ...] denotes a BGP update wi
	th prefix Pi and an AS_PATH as shown in the square brackets.
	</t>	</t>

	<t>
	In the strict unicast Reverse Path Forwarding (uRPF) method, an ingress packet a
	t a border router is accepted only if the Forwarding Information Base (FIB) cont
	ains a prefix that encompasses the source address, and forwarding information fo
	r that prefix points back to the interface over which the packet was received. I
	n other words, the reverse path for routing to the source address (if it were us
	ed as a destination address) should use the same interface over which the packet
	was received. It is well known that this method has limitations when networks a
	re multi-homed, routes are not symmetrically announced to all transit providers,
	and there is asymmetric routing of data packets. Asymmetric routing occurs (see
	<xref target="fig1"></xref>) when a customer AS announces one prefix (P1) to on
	e transit provider (ISP-a) and a different prefix (P2) to another transit provid
	er (ISP-b), but routes data packets with source addresses in the second prefix (
	P2) to the first transit provider (ISP-a) or vice versa. Then data packets with
	source address in prefix P2 that are received directly from AS1 will get dropped
	. Further, data packets with source address in prefix P1 that originate from AS
	1 and traverse via AS3 to AS2 will also get dropped at AS2.


	<figure align="center" anchor="fig1" title="Scenario 1 for illustration of effic	<figure anchor="fig1">
	acy of uRPF schemes.">	<name>Scenario 1 for Illustration of Efficacy of uRPF Schemes</name>
	<artwork align="left"><![CDATA[	<artwork align="left" name="" type="" alt=""><![CDATA[
	+------------+ ---- P1[AS2 AS1] ---> +------------+	+------------+ ---- P1[AS2 AS1] ---> +------------+

	\| AS2(ISP-a) \| <----P2[AS3 AS1] ---- \| AS3(ISP-b)\|	\| AS2(ISP-a) \| <----P2[AS3 AS1] ---- \| AS3(ISP-b) \|
	+------------+ +------------+	+------------+ +------------+
	/\ /\	/\ /\
	\ /	\ /
	\ /	\ /
	\ /	\ /
	P1[AS1]\ /P2[AS1]	P1[AS1]\ /P2[AS1]
	\ /	\ /
	+-----------------------+	+-----------------------+
	\| AS1(customer) \|	\| AS1(customer) \|
	+-----------------------+	+-----------------------+
	P1, P2 (prefixes originated)	P1, P2 (prefixes originated)

	Consider data packets received at AS2	Consider data packets received at AS2

	(1) from AS1 with source address (SA) in P2, or	(1) from AS1 with a source address (SA) in P2, or
	(2) from AS3 that originated from AS1 with SA in P1:	(2) from AS3 that originated from AS1 with a SA in P1:
	* Strict uRPF fails	* Strict uRPF fails
	* Feasible-path uRPF fails	* Feasible-path uRPF fails
	* Loose uRPF works (but not desirable)	* Loose uRPF works (but not desirable)

	* Enhanced Feasible-path uRPF works best	* Enhanced feasible-path uRPF works best
	]]></artwork>	]]></artwork>

	</figure>	</figure>
		</section>
	</t>	<section anchor="fp-urpf" numbered="true" toc="default">
	</section>	<name>SAV Using Feasible-Path Unicast Reverse Path Forwarding</name>
		<t>
	<section anchor="fp-urpf" title="SAV using Feasible-Path Unicast Reverse Path Fo	The feasible-path uRPF technique helps partially overcome the problem
	rwarding">	identified with the strict uRPF in the multihoming case. The feasible-path
		uRPF is similar to the strict uRPF, but in addition to inserting the best-path
		prefix, additional prefixes from alternative announced routes are also
		included in the RPF list. This method relies on either (a) announcements for
		the same prefixes (albeit some may be prepended to effect lower
		preference) propagating to all transit providers performing feasible-path uRPF c
		hecks or
		(b) announcement of an aggregate less-specific prefix to all transit providers
		while announcing more-specific prefixes (covered by the less-specific prefix)
		to different transit providers as needed for traffic engineering.</t>


	<t>	<t>As an
	The feasible-path uRPF technique helps partially overcome the problem identified	example, in the multihoming scenario (see Scenario 2 in <xref target="fig2"
	with the strict uRPF in the multi-homing case. The feasible-path uRPF is simil	format="default"/>), if the customer AS announces routes for both prefixes
	ar to the strict uRPF, but in addition to inserting the best-path prefix, additi	(P1, P2) to both transit providers (with suitable prepends if needed for
	onal prefixes from alternative announced routes are also included in the RPF lis	traffic engineering), then the feasible-path uRPF method works. It should be
	t. This method relies on either (a) announcements for the same prefixes (albeit	mentioned that the feasible-path uRPF works in this scenario only if customer
	some may be prepended to effect lower preference) propagating to all transit pro	routes are preferred at AS2 and AS3 over a shorter non-customer
	viders performing feasible-path uRPF checks, or (b) announcement of an aggregate	route. However, the feasible-path uRPF method has limitations as well. One
	less specific prefix to all transit providers while announcing more specific pr	form of limitation naturally occurs when the recommendation (a) or (b)
	efixes (covered by the less specific prefix) to different transit providers as n	mentioned above regarding propagation of prefixes is not followed.</t>
	eeded for traffic engineering. As an example, in the multi-homing scenario (see	<t>Another
	Scenario 2 in <xref target="fig2"></xref>), if the customer AS announces routes	form of limitation can be described as follows. In Scenario 2 (described here,
	for both prefixes (P1, P2) to both transit providers (with suitable prepends if	illustrated in <xref target="fig2" format="default"/>), it is possible that
	needed for traffic engineering), then the feasible-path uRPF method works. It sh	the second transit provider (ISP-b or AS3) does not propagate the prepended
	ould be mentioned that the feasible-path uRPF works in this scenario only if cus	route for prefix P1 to the first transit provider (ISP-a or AS2). This is
	tomer routes are preferred at AS2 and AS3 over a shorter non-customer route. How	because AS3's decision policy permits giving priority to a shorter route to
	ever, the feasible-path uRPF method has limitations as well. One form of limitat	prefix P1 via a lateral peer (AS2) over a longer route learned directly from
	ion naturally occurs when the recommendation (a) or (b) mentioned above regardin	the customer (AS1). In such a scenario, AS3 would not send any route
	g propagation of prefixes is not followed. Another form of limitation can be des	announcement for prefix P1 to AS2 (over the P2P link). Then, a data packet
	cribed as follows. In Scenario 2 (described here, illustrated in <xref target="f	with a source address in prefix P1 that originates from AS1 and traverses via AS
	ig2"></xref>), it is possible that the second transit provider (ISP-b or AS3) do	3 to AS2 will get dropped at AS2.
	es not propagate the prepended route for prefix P1 to the first transit provider
	(ISP-a or AS2). This is because AS3's decision policy permits giving priority t
	o a shorter route to prefix P1 via a lateral peer (AS2) over a longer route lear
	ned directly from the customer (AS1). In such a scenario, AS3 would not send any
	route announcement for prefix P1 to AS2 (over the p2p link). Then a data packet
	with source address in prefix P1 that originates from AS1 and traverses via AS3
	to AS2 will get dropped at AS2.


	<figure align="center" anchor="fig2" title="Scenario 2 for illustration of effic	</t>
	acy of uRPF schemes.">	<figure anchor="fig2">
	<artwork align="left"><![CDATA[	<name>Scenario 2 for Illustration of Efficacy of uRPF Schemes</name>
	+------------+ routes for P1, P2 +-----------+	<artwork align="left" name="" type="" alt=""><![CDATA[
	\| AS2(ISP-a) \|<-------------------->\| AS3(ISP-b)\|	+------------+ routes for P1, P2 +------------+
	+------------+ (p2p) +-----------+	\| AS2(ISP-a) \|<-------------------->\| AS3(ISP-b) \|
		+------------+ (P2P) +------------+
	/\ /\	/\ /\
	\ /	\ /
	P1[AS1]\ /P2[AS1]	P1[AS1]\ /P2[AS1]
	\ /	\ /
	P2[AS1 AS1 AS1]\ /P1[AS1 AS1 AS1]	P2[AS1 AS1 AS1]\ /P1[AS1 AS1 AS1]
	\ /	\ /
	+-----------------------+	+-----------------------+
	\| AS1(customer) \|	\| AS1(customer) \|
	+-----------------------+	+-----------------------+
	P1, P2 (prefixes originated)	P1, P2 (prefixes originated)

	Consider data packets received at AS2 via AS3	Consider data packets received at AS2 via AS3

	that originated from AS1 and have source address in P1:	that originated from AS1 and have a source address in P1:
	* Feasible-path uRPF works (if customer route to P1	* Feasible-path uRPF works (if the customer route to P1
	is preferred at AS3 over shorter path)	is preferred at AS3 over the shorter path)
	* Feasible-path uRPF fails (if shorter path to P1	* Feasible-path uRPF fails (if the shorter path to P1
	is preferred at AS3 over customer route)	is preferred at AS3 over the customer route)
	* Loose uRPF works (but not desirable)	* Loose uRPF works (but not desirable)

	* Enhanced Feasible-path uRPF works best	* Enhanced feasible-path uRPF works best
	]]></artwork>	]]></artwork>

	</figure>	</figure>
		</section>
	</t>	<section anchor="lurpf" numbered="true" toc="default">
	</section>	<name>SAV Using Loose Unicast Reverse Path Forwarding</name>
	<section anchor="lurpf" title="SAV using Loose Unicast Reverse Path Forwarding">	<t>
		In the loose uRPF method, an ingress packet
	<t>	at the border router is accepted only if the FIB has one or more prefixes that
	In the loose unicast Reverse Path Forwarding (uRPF) method, an ingress packet at	encompass the source address. That is, a packet is dropped if no route exists
	the border router is accepted only if the FIB has one or more prefixes that enc	in the FIB for the source address. Loose uRPF sacrifices directionality. It onl
	ompass the source address. That is, a packet is dropped if no route exists in th	y drops packets if the source address is unreachable in the current FIB (e.g., I
	e FIB for the source address. Loose uRPF sacrifices directionality. <!-- This me	ANA special-purpose prefixes <xref target="SPAR-v4" format="default"/><xref targ
	thod is not effective for prevention of address spoofing since there is little u	et="SPAR-v6" format="default"/>, unallocated, allocated but currently not routed
	nrouted address space in IPv4. --> It only drops packets if the source address i	).
	s unreachable in the current FIB (e.g., IANA special-purpose prefixes <xref targ
	et="SPAR-v4"></xref><xref target="SPAR-v6"></xref>, unallocated, allocated but c
	urrently not routed).
	</t>

	</section>
	<section anchor="vrf" title="SAV using VRF Table">

	<t>
	The Virtual Routing and Forwarding (VRF) technology <xref target="RFC4364"></xre
	f> <xref target="Juniper"></xref> allows a router to maintain multiple routing t
	able instances separate from the global Routing Information Base (RIB). External
	BGP (eBGP) peering sessions send specific routes to be stored in a dedicated VR
	F table. The uRPF process queries the VRF table (instead of the FIB) for source
	address validation. A VRF table can be dedicated per eBGP peer and used for uRPF
	for only that peer, resulting in strict mode operation. <!-- This can also be a
	way of implementing feasible path uRPF if the dedicated VRF table contains all
	announced paths on a given interface. --> For implementing loose uRPF on an inte
	rface, the corresponding VRF table would be global, i.e., contains the same rout
	es as in the FIB.
	</t>	</t>

	</section>	</section>
	</section>	<section anchor="vrf" numbered="true" toc="default">
		<name>SAV Using VRF Table</name>
	<section anchor="newtech" title="SAV using Enhanced Feasible-Path uRPF">	<t>
		The Virtual Routing and Forwarding (VRF) technology <xref target="RFC4364"
	<section anchor="descrip" title="Description of the Method">	format="default"/> <xref target="Juniper" format="default"/> allows a router
		to maintain multiple routing table instances separate from the global Routing
	<t>	Information Base (RIB). External BGP (eBGP) peering sessions send specific
	Enhanced feasible-path uRPF (EFP-uRPF) method adds greater operational robustnes	routes to be stored in a dedicated VRF table. The uRPF process queries the VRF
	s and efficacy to existing uRPF methods discussed in <xref target="review"></xre	table (instead of the FIB) for source address validation. A VRF table can be ded
	f>. That is because it avoids dropping legitimate data packets and avoids compro	icated per eBGP peer and used for uRPF for only that peer, resulting in strict m
	mising directionality. The method is based on the principle that if BGP updates	ode operation. For implementing loose uRPF on an interface, the corresponding V
	for multiple prefixes with the same origin AS were received on different interfa	RF table would be global, i.e., contains the same routes as in the FIB.
	ces (at border routers), then incoming data packets with source addresses in any
	of those prefixes should be accepted on any of those interfaces. The EFP-uRPF m
	ethod can be best explained with an example as follows:
	</t>	</t>

	<t>	</section>
	Let us say, a border router of ISP-A has in its Adj-RIBs-In <xref target="RFC427	</section>
	1"></xref> the set of prefixes {Q1, Q2, Q3} each of which has AS-x as its origin	<section anchor="newtech" numbered="true" toc="default">
	and AS-x is in ISP-A's customer cone. In this set, the border router received t	<name>SAV Using Enhanced Feasible-Path uRPF</name>
	he route for prefix Q1 over a customer facing interface, while it learned the ro	<section anchor="descrip" numbered="true" toc="default">
	utes for prefixes Q2 and Q3 from a lateral peer and an upstream transit provider	<name>Description of the Method</name>
	, respectively. In this example scenario, the enhanced feasible-path uRPF method	<t>
	requires Q1, Q2, and Q3 be included in the RPF list for the customer interface	The enhanced feasible-path uRPF (EFP-uRPF) method adds greater operational robus
	under consideration.	tness and efficacy to existing uRPF methods discussed in <xref target="review" f
		ormat="default"/>. That is because it avoids dropping legitimate data packets an
		d compromising directionality. The method is based on the principle that if BGP
		updates for multiple prefixes with the same origin AS were received on different
		interfaces (at border routers), then incoming data packets with source addresse
		s in any of those prefixes should be accepted on any of those interfaces. The EF
		P-uRPF method can be best explained with an example, as follows:
	</t>	</t>

	<t>	<t>
	Thus, the enhanced feasible-path uRPF (EFP-uRPF) method gathers feasible paths f	Let us say, in its Adj-RIBs-In <xref target="RFC4271" format="default"/>, a bord
	or customer interfaces in a more precise way (as compared to feasible-path uRPF)	er router of ISP-A has the set of prefixes {Q1, Q2, Q3}, each of which has AS-x
	so that all legitimate packets are accepted while the directionality property i	as its origin and AS-x is in ISP-A's customer cone. In this set, the border rout
	s not compromised.	er received the route for prefix Q1 over a customer-facing interface while it le
		arned the routes for prefixes Q2 and Q3 from a lateral peer and an upstream tran
		sit provider, respectively. In this example scenario, the enhanced feasible-path
		uRPF method requires Q1, Q2, and Q3 be included in the RPF list for the custome
		r interface under consideration.
	</t>	</t>

	<t>	<t>
	The above described EFP-uRPF method is recommended to be applied on customer int	Thus, the EFP-uRPF method gathers feasible paths
	erfaces. It can be extended to create the RPF lists for lateral peer interfaces	for customer interfaces in a more precise way (as compared to the feasible-path
	also. That is, the EFP-uRPF method can be applied (and loose uRPF avoided) on la	uRPF) so that all legitimate packets are accepted while the directionality prope
	teral peer interfaces. That will help avoid compromise of directionality for lat	rty is not compromised.
	eral peer interfaces (which is inevitable with loose uRPF; see <xref target="lur
	pf"></xref>).
	</t>	</t>

	<!--	<t>
	In the above example, routes for prefixes Q2 and Q3 were not received on the cus	The above-described EFP-uRPF method is recommended to be applied on customer
	tomer facing interface at the border router, yet data packets with source addres	interfaces. It can also
	ses in Q2 or Q3 are accepted by the router if they come in on the same customer	be extended to create the RPF lists for lateral peer
	interface on which the route for prefix Q1 was received (based on these prefix r	interfaces. That is, the EFP-uRPF method can be applied (and loose uRPF
	outes having the same origin AS).	avoided) on lateral peer interfaces. That will help to avoid compromising direct
	<t>	ionality for lateral peer interfaces (which is inevitable with loose uRPF; see <
	Looking back at Scenarios 1 and 2 (<xref target="fig1"></xref> and <xref target=	xref target="lurpf" format="default"/>).
	"fig2"></xref>), the enhanced feasible-path uRPF (EFP-uRPF) method works better
	than the other uRPF methods. Scenario 3 (<xref target="fig3"></xref>) further il
	lustrates the enhanced feasible-path uRPF method with a more concrete example. I
	n this scenario, the focus is on operation of the feasible-path uRPF at ISP4 (AS
	4). ISP4 learns a route for prefix P1 via a customer-to-provider (C2P) interface
	from customer ISP2 (AS2). This route for P1 has origin AS1. ISP4 also learns a
	route for P2 via another C2P interface from customer ISP3 (AS3). Additionally, A
	S4 learns a route for P3 via a lateral peer-to-peer (p2p) interface from ISP5 (A
	S5). Routes for all three prefixes have the same origin AS (i.e., AS1). Using th
	e enhanced feasible-path uRPF scheme, given the commonality of the origin AS acr
	oss the routes for P1, P2 and P3, AS4 includes all of these prefixes in the RPF
	list for the customer interfaces (from AS2 and AS3).
	</t>	</t>


	<t>	<t>
	<figure align="center" anchor="fig3" title="Scenario 3 for illustration of effic	Looking back at Scenarios 1 and 2 (Figures <xref target="fig1"
	acy of uRPF schemes.">	format="counter"/> and <xref target="fig2" format="counter"/>), the EFP-uRPF met
	<artwork align="left"><![CDATA[	hod works better than the other uRPF
		methods. Scenario 3 (<xref target="fig3" format="default"/>) further
		illustrates the enhanced feasible-path uRPF method with a more concrete
		example. In this scenario, the focus is on operation of the EFP-uRPF
		at ISP4 (AS4). ISP4 learns a route for prefix P1 via a
		C2P interface from customer ISP2 (AS2). This route for P1 has origin
		AS1. ISP4 also learns a route for P2 via another C2P interface from customer
		ISP3 (AS3). Additionally, AS4 learns a route for P3 via a lateral P2P interface
		from ISP5 (AS5). Routes for all three prefixes have the same
		origin AS (i.e., AS1). Using the enhanced feasible-path uRPF scheme and given th
		e
		commonality of the origin AS across the routes for P1, P2, and P3, AS4 includes
		all of these prefixes in the RPF list for the customer interfaces (from AS2
		and AS3).
		</t>
		<figure anchor="fig3">
		<name>Scenario 3 for Illustration of Efficacy of uRPF Schemes</name>
		<artwork align="left" name="" type="" alt=""><![CDATA[
	+----------+ P3[AS5 AS1] +------------+	+----------+ P3[AS5 AS1] +------------+
	\| AS4(ISP4)\|<---------------\| AS5(ISP5) \|	\| AS4(ISP4)\|<---------------\| AS5(ISP5) \|

	+----------+ (p2p) +------------+	+----------+ (P2P) +------------+
	/\ /\ /\	/\ /\ /\
	/ \ /	/ \ /
	P1[AS2 AS1]/ \P2[AS3 AS1] /	P1[AS2 AS1]/ \P2[AS3 AS1] /
	(C2P)/ \(C2P) /	(C2P)/ \(C2P) /
	/ \ /	/ \ /
	+----------+ +----------+ /	+----------+ +----------+ /
	\| AS2(ISP2)\| \| AS3(ISP3)\| /	\| AS2(ISP2)\| \| AS3(ISP3)\| /
	+----------+ +----------+ /	+----------+ +----------+ /
	/\ /\ /	/\ /\ /
	\ / /	\ / /
	P1[AS1]\ /P2[AS1] /P3[AS1]	P1[AS1]\ /P2[AS1] /P3[AS1]
	(C2P)\ /(C2P) /(C2P)	(C2P)\ /(C2P) /(C2P)
	\ / /	\ / /
	+----------------+ /	+----------------+ /
	\| AS1(customer) \|/	\| AS1(customer) \|/
	+----------------+	+----------------+
	P1, P2, P3 (prefixes originated)	P1, P2, P3 (prefixes originated)

	Consider that data packets (sourced from AS1)	Consider that data packets (sourced from AS1)

	may be received at AS4 with source address	may be received at AS4 with a source address
	in P1, P2 or P3 via any of the neighbors (AS2, AS3, AS5):	in P1, P2, or P3 via any of the neighbors (AS2, AS3, AS5):
	* Feasible-path uRPF fails	* Feasible-path uRPF fails
	* Loose uRPF works (but not desirable)	* Loose uRPF works (but not desirable)

	* Enhanced Feasible-path uRPF works best	* Enhanced feasible-path uRPF works best
	]]></artwork>	]]></artwork>

	</figure>	</figure>
	</t>	<section anchor="algA" numbered="true" toc="default">
	<section anchor="algA" title="Algorithm A: Enhanced Feasible-Path uRPF">	<name>Algorithm A: Enhanced Feasible-Path uRPF</name>
	<t>	<t>
	The underlying algorithm in the solution method described above (<xref target="d	The underlying algorithm in the solution method described above (<xref target="d
	escrip"></xref>) can be specified as follows (to be implemented in a transit AS)	escrip" format="default"/>) can be specified as follows (to be implemented in a
	:	transit AS):
	</t>	</t>

	<t><list style="numbers">	<ol spacing="normal" type="1">
	<t>	<li>
	Create the set of unique origin ASes considering only the routes in the Adj-RIBs -In of customer interfaces. Call it Set A = {AS1, AS2, ..., ASn}.	Create the set of unique origin ASes considering only the routes in the Adj-RIBs -In of customer interfaces. Call it Set A = {AS1, AS2, ..., ASn}.

	</t>	</li>
	<t>	<li>
	Considering all routes in Adj-RIBs-In for all interfaces (customer, lateral peer , and transit provider), form the set of unique prefixes that have a common orig in AS1. Call it Set X1.	Considering all routes in Adj-RIBs-In for all interfaces (customer, lateral peer , and transit provider), form the set of unique prefixes that have a common orig in AS1. Call it Set X1.


	<!-- (Note: The routes for these prefixes have potentially been received on diff	</li>
	erent customer/ lateral peer/ provider interfaces. The routes passed prefix filt	<li>
	ering rules that are in effect.) -->	Include Set X1 in the RPF list on all customer interfaces on which one or more o
		f the prefixes in Set X1 were received.
	</t>	</li>
	<t>	<li>
	Include set X1 in Reverse Path Filter (RPF) list on all customer interfaces on w
	hich one or more of the prefixes in set X1 were received.
	</t>
	<t>
	Repeat Steps 2 and 3 for each of the remaining ASes in Set A (i.e., for ASi, whe re i = 2, ..., n).	Repeat Steps 2 and 3 for each of the remaining ASes in Set A (i.e., for ASi, whe re i = 2, ..., n).

		</li>
		</ol>
		<t>
		The above algorithm can also be extended to apply the EFP-uRPF method to
		lateral peer interfaces. However, it is left up to the operator to decide
		whether they should apply the EFP-uRPF or loose uRPF method on lateral peer inte
		rfaces. The loose uRPF method is recommended to be applied on transit provider i
		nterfaces.
	</t>	</t>

	</list></t>	</section>
		</section>
	<t>	<section anchor="recomm" numbered="true" toc="default">
	The above algorithm can be extended to apply EFP-uRPF method to lateral peer int	<name>Operational Recommendations</name>
	erfaces also. However, it is left up to the operator to decide whether they shou	<t>
	ld apply EFP-uRPF or loose uRPF method on lateral peer interfaces. The loose uRP
	F method is recommended to be applied on transit provider interfaces.
	</t>

	</section>
	</section>

	<section anchor="recomm" title="Operational Recommendations">
	<t>
	The following operational recommendations will make the operation of the enhance d feasible-path uRPF robust:	The following operational recommendations will make the operation of the enhance d feasible-path uRPF robust:
	</t>	</t>

		<t>
	<t>	For multihomed stub AS:
	For multi-homed stub AS:
	</t>	</t>

		<ul spacing="normal">
	<t><list style="symbols">	<li>
	<t>	A multihomed stub AS should announce at least one of the prefixes it originates
	A multi-homed stub AS should announce at least one of the prefixes it originates	to each of its transit provider ASes.
	to each of its transit provider ASes.
	(It is understood that a single-homed stub AS would announce all prefixes it ori ginates to its sole transit provider AS.)	(It is understood that a single-homed stub AS would announce all prefixes it ori ginates to its sole transit provider AS.)

	</t>	</li>
	</list></t>	</ul>
		<t>
	<t>
	For non-stub AS:	For non-stub AS:
	</t>	</t>

		<ul spacing="normal">
	<t><list style="symbols">	<li>
	<t>
	A non-stub AS should also announce at least one of the prefixes it originates to each of its transit provider ASes.	A non-stub AS should also announce at least one of the prefixes it originates to each of its transit provider ASes.

	</t>	</li>
	<t>	<li>
	Additionally, from the routes it has learned from customers, a non-stub AS SHOUL	Additionally, from the routes it has learned from customers, a non-stub AS <bcp1
	D announce at least one route per origin AS to each of its transit provider ASes	4>SHOULD</bcp14> announce at least one route per origin AS to each of its transi
	.	t provider ASes.
	</t>	</li>
	</list></t>	</ul>
	<!--
	<t>
	(Note: It is worth noting that in the above recommendations if "at least one" is
	replaced with "all", then even traditional feasible-path uRPF would work effect
	ively. But the latter recommendation ("all") does not seem practical.)
	</t>
	</section>
	<section anchor="challenge" title="A Challenging Scenario">
	<t>
	It should be observed that in the absence of ASes adhering to above recommendati
	ons, the following example scenario may be constructed which poses a challenge f
	or the enhanced feasible-path uRPF (as well as for traditional feasible-path uRP
	F). In the scenario illustrated in <xref target="fig4"></xref>, since routes for
	neither P1 nor P2 are propagated on the AS2-AS4 interface (due to the presence
	of NO_EXPORT Community), the enhanced feasible-path uRPF at AS4 will reject data
	packets received on that interface with source addresses in P1 or P2. (For a li
	ttle more complex example scenario, see slide #10 in <xref target="sriram-urpf">
	</xref>.)
	</t>

	<!--


	But this can be clearly avoided if the above recommendations for stub and non-st	</section>
	ub ASes are followed. In this example, this would mean that the NO_EXPORT is avo	<section anchor="challenge" numbered="true" toc="default">
	ided and instead AS prepending is used (to depref routes) on the AS1-AS2 peering	<name>A Challenging Scenario</name>
	session.	<t>
		It should be observed that in the absence of ASes adhering to above
		recommendations, the following example scenario, which poses
		a challenge for the enhanced feasible-path uRPF (as well as for traditional
		feasible-path uRPF), may be constructed. In the scenario illustrated in <xref ta
		rget="fig4" format="default"/>, since routes for neither P1 nor P2 are propagate
		d on the AS2-AS4 interface (due to the presence of NO_EXPORT Community), the enh
		anced feasible-path uRPF at AS4 will reject data packets received on that interf
		ace with source addresses in P1 or P2. (For a little more complex example scenar
		io, see slide #10 in <xref target="Sriram-URPF" format="default"/>.)
		</t>


	<t>	<figure anchor="fig4">
	<figure align="center" anchor="fig4" title="Illustration of a challenging scenar	<name>Illustration of a Challenging Scenario</name>
	io.">	<artwork align="left" name="" type="" alt=""><![CDATA[
	<artwork align="left"><![CDATA[
	+----------+	+----------+
	\| AS4(ISP4)\|	\| AS4(ISP4)\|
	+----------+	+----------+
	/\ /\	/\ /\
	/ \ P1[AS3 AS1]	/ \ P1[AS3 AS1]
	P1 and P2 not / \ P2[AS3 AS1]	P1 and P2 not / \ P2[AS3 AS1]
	propagated / \ (C2P)	propagated / \ (C2P)
	(C2P) / \	(C2P) / \
	+----------+ +----------+	+----------+ +----------+
	\| AS2(ISP2)\| \| AS3(ISP3)\|	\| AS2(ISP2)\| \| AS3(ISP3)\|

	skipping to change at line 399 ¶	skipping to change at line 468 ¶
	\ / P1[AS1]	\ / P1[AS1]
	P1[AS1] NO_EXPORT \ / P2[AS1]	P1[AS1] NO_EXPORT \ / P2[AS1]
	P2[AS1] NO_EXPORT \ / (C2P)	P2[AS1] NO_EXPORT \ / (C2P)
	(C2P) \ /	(C2P) \ /
	+----------------+	+----------------+
	\| AS1(customer) \|	\| AS1(customer) \|
	+----------------+	+----------------+
	P1, P2 (prefixes originated)	P1, P2 (prefixes originated)

	Consider that data packets (sourced from AS1)	Consider that data packets (sourced from AS1)

	may be received at AS4 with source address	may be received at AS4 with a source address
	in P1 or P2 via AS2:	in P1 or P2 via AS2:
	* Feasible-path uRPF fails	* Feasible-path uRPF fails
	* Loose uRPF works (but not desirable)	* Loose uRPF works (but not desirable)

	* Enhanced Feasible-path uRPF with Algorithm A fails	* Enhanced feasible-path uRPF with Algorithm A fails
	* Enhanced Feasible-path uRPF with Algorithm B works best	* Enhanced feasible-path uRPF with Algorithm B works best
	]]></artwork>	]]></artwork>

	</figure>	</figure>
	</t>	</section>
		<section anchor="algB" numbered="true" toc="default">
	</section>	<name>Algorithm B: Enhanced Feasible-Path uRPF with Additional Flexibili
		ty across Customer Cone</name>
	<section anchor="algB" title="Algorithm B: Enhanced Feasible-Path uRPF with Addi	<t>
	tional Flexibility Across Customer Cone">	Adding further flexibility to the enhanced feasible-path uRPF method can help ad
	<t>	dress the potential limitation identified above using the scenario in <xref targ
	Adding further flexibility to the enhanced feasible-path uRPF method can help ad	et="fig4" format="default"/> (<xref target="challenge" format="default"/>). In t
	dress the potential limitation identified above using the scenario in <xref targ	he following, "route" refers to a route currently existing in the Adj-RIBs-In. I
	et="fig4"></xref> (<xref target="challenge"></xref>). In the following, "route"	ncluding the additional degree of flexibility, the modified algorithm called Alg
	refers to a route currently existing in the Adj-RIB-in. Including the additional	orithm B (implemented in a transit AS) can be described as follows:
	degree of flexibility, the modified algorithm called Algorithm B (implemented i
	n a transit AS) can be described as follows:
	</t>
	<t><list style="numbers">
	<t>
	Create the set of all directly-connected customer interfaces. Call it Set I = {I
	1, I2, ..., Ik}.
	</t>	</t>

	<t>	<ol spacing="normal" type="1">
		<li>
		Create the set of all directly connected customer interfaces. Call it Set I = {I
		1, I2, ..., Ik}.
		</li>
		<li>
	Create the set of all unique prefixes for which routes exist in Adj-RIBs-In for the interfaces in Set I. Call it Set P = {P1, P2, ..., Pm}.	Create the set of all unique prefixes for which routes exist in Adj-RIBs-In for the interfaces in Set I. Call it Set P = {P1, P2, ..., Pm}.

	</t>	</li>
	<t>	<li>
	Create the set of all unique origin ASes seen in the routes that exist in Adj-RI Bs-In for the interfaces in Set I. Call it Set A = {AS1, AS2, ..., ASn}.	Create the set of all unique origin ASes seen in the routes that exist in Adj-RI Bs-In for the interfaces in Set I. Call it Set A = {AS1, AS2, ..., ASn}.

	</t>	</li>
	<t>	<li>
	Create the set of all unique prefixes for which routes exist in Adj-RIBs-In of a ll lateral peer and transit provider interfaces such that each of the routes has its origin AS belonging in Set A. Call it Set Q = {Q1, Q2, ..., Qj}.	Create the set of all unique prefixes for which routes exist in Adj-RIBs-In of a ll lateral peer and transit provider interfaces such that each of the routes has its origin AS belonging in Set A. Call it Set Q = {Q1, Q2, ..., Qj}.

	</t>	</li>
	<t>	<li>
	Then, Set Z = Union(P,Q) is the RPF list that is applied for every customer inte rface in Set I.	Then, Set Z = Union(P,Q) is the RPF list that is applied for every customer inte rface in Set I.

		</li>
		</ol>
		<t>
		When Algorithm B (which is more flexible than Algorithm A) is employed on
		customer interfaces, the type of limitation identified in <xref target="fig4"
		format="default"/> (<xref target="challenge" format="default"/>) is overcome
		and the method works. The directionality property is minimally compromised,
		but the proposed EFP-uRPF method with Algorithm B is still a much better choice
		(for the scenario under consideration) than applying the loose uRPF method, whic
		h is oblivious to directionality.
	</t>	</t>

	</list></t>	<t>
		So, applying the EFP-uRPF method with Algorithm B is recommended on customer int
	<t>	erfaces for the challenging scenarios, such as those described in <xref target="
	When Algorithm B (which is more flexible than Algorithm A) is employed on custom	challenge" format="default"/>.
	er interfaces, the type of limitation identified in <xref target="fig4"></xref>
	(<xref target="challenge"></xref>) is overcome and the method works. The directi
	onality property is minimally compromised, but still the proposed EFP-uRPF metho
	d with Algorithm B is a much better choice (for the scenario under consideration
	) than applying the loose uRPF method which is oblivious to directionality.
	</t>
	<t>
	So, applying EFP-uRPF method with Algorithm B is recommended on customer interfa
	ces for the challenging scenarios such as those described in <xref target="chall
	enge"></xref>.

	<!-- Further, it is recommended that loose uRPF method should be applied on late
	ral peer and transit provider interfaces. -->

	</t>

	<!-- This should eliminate or significantly reduce the possibility of blocking l
	egitimate customer-data packets in uRPF implementations. -->


	<!--
	<t>
	It should be emphasized that, in spite of the flexibilities incorporated into uR
	PF, a multi-homed customer should be always advised to advertise their routes to
	each of its upstream ISPs. When a customer AS is known to be single-homed stub,
	then strict uRPF should be used and would serve well.
	</t>	</t>


	</section>	</section>
		<section anchor="augment" numbered="true" toc="default">
	<section anchor="augment" title="Augmenting RPF Lists with ROA and IRR Data">	<name>Augmenting RPF Lists with ROA and IRR Data</name>
	<t>	<t>
	It is worth emphasizing that an indirect part of the proposal in this document i	It is worth emphasizing that an indirect part of the proposal in this document
	s that RPF filters may be augmented from secondary sources. Hence, the construct	is that RPF filters may be augmented from secondary sources. Hence, the
	ion of RPF lists using a method proposed in this document (Algorithm A or B) can	construction of RPF lists using a method proposed in this document (Algorithm
	be augmented with data from Route Origin Authorization (ROA) <xref target="RFC6	A or B) can be augmented with data from Route Origin Authorization (ROA) <xref
	482"></xref> as well as Internet Routing Registry (IRR) data. Special care shoul	target="RFC6482" format="default"/>, as well as Internet Routing Registry
	d be exercised when using IRR data because it not always accurate or trusted.	(IRR) data. Special care should be exercised when using IRR data because it is
	<!-- Prefixes from registered ROAs and IRR route objects that include ASes in an	not always accurate or trusted. In the EFP-uRPF method with Algorithm A (see <x
	ISP's customer cone SHOULD be used to augment the relevant RPF lists. -->	ref target="algA"
	In the EFP-uRPF method with Algorithm A (see <xref target="algA"></xref>), if a	format="default"/>), if a ROA includes prefix Pi and ASj, then augment
	ROA includes prefix Pi and ASj, then augment with Pi the RPF list of each custom	the RPF list of each customer interface on which at least one route with
	er interface on which at least one route with origin ASj was received. In the EF	origin ASj was received with prefix Pi. In the EFP-uRPF method with Algorithm B,
	P-uRPF method with Algorithm B, if ASj belongs in set A (see Step #3 <xref targe	if ASj
	t="algB"></xref>) and if a ROA includes prefix Pi and ASj, then augment with Pi	belongs in Set A (see Step #3 <xref
	the RPF list Z in Step 5 of Algorithm B. Similar procedures can be followed with	target="algB" format="default"/>) and if a ROA includes prefix Pi and ASj,
	reliable IRR data as well. This will help make the RPF lists more robust about	then augment the RPF list Z in Step 5 of Algorithm B with prefix Pi. Similar pro
	source addresses that may be legitimately used by customers of the ISP.	cedures can be followed with reliable IRR data as well. This will help make the
		RPF lists more robust about source addresses that may be legitimately used by cu
		stomers of the ISP.
	</t>	</t>

	</section>	</section>
		<section anchor="impl" numbered="true" toc="default">
	<section anchor="impl" title="Implementation and Operations Considerations">	<name>Implementation and Operations Considerations</name>
	<section anchor="rpfsize" title="Impact on FIB Memory Size Requirement">	<section anchor="rpfsize" numbered="true" toc="default">
	<t>	<name>Impact on FIB Memory Size Requirement</name>
	The existing RPF checks in edge routers take advantage of existing line card imp	<t>
	lementations to perform the RPF functions. For implementation of the enhanced fe	The existing RPF checks in edge routers take advantage of existing
	asible-path uRPF, the general necessary feature would be to extend the line card	line card implementations to perform the RPF functions. For
	s to take arbitrary RPF lists that are not necessarily the same as the existing	implementation of the enhanced feasible-path uRPF, the general
	FIB contents. In the algorithms (<xref target="algA"></xref> and <xref target="a	necessary feature would be to extend the line cards to take arbitrary
	lgB"></xref>) described here, the RPF lists are constructed by applying a set of	RPF lists that are not necessarily the same as the existing FIB
	rules to all received BGP routes (not just those selected as best path and inst	contents. In the algorithms (Sections <xref target="algA" format="counter"/> and
	alled in the FIB). The concept of uRPF querying an RPF list (instead of the FIB)	<xref target="algB" format="counter"/>) described here, the RPF lists are const
	is similar to uRPF querying a VRF table (see (<xref target="vrf"></xref>).	ructed by applying a set of rules to all received BGP routes (not just those sel
		ected as best path and installed in the FIB). The concept of uRPF querying an RP
		F list (instead of the FIB) is similar to uRPF querying a VRF table (see <xref t
		arget="vrf" format="default"/>).
	</t>	</t>

	<t>	<t>
	The techniques described in this document require that there should be additiona	The techniques described in this document require that there should be additiona
	l memory (i.e., ternary content addressable memory (TCAM)) available to store th	l memory (i.e., ternary content-addressable memory (TCAM)) available to store th
	e RPF lists in line cards. For an ISP's AS, the RPF list size for each line card	e RPF lists in line cards. For an ISP's AS, the RPF list size for each line card
	will roughly equal the total number of originated prefixes from ASes in its cus	will roughly equal the total number of originated prefixes from ASes in its cus
	tomer cone (assuming Algorithm B in <xref target="algB"></xref> is used). (Note:	tomer cone (assuming Algorithm B in <xref target="algB" format="default"/> is us
	EFP-uRPF with Algorithm A (see <xref target="algA"></xref>) requires much less	ed). (Note: EFP-uRPF with Algorithm A (see <xref target="algA" format="default"/
	memory than EFP-uRPF with Algorithm B.)	>) requires much less memory than EFP-uRPF with Algorithm B.)
	</t>	</t>

	<t>	<t>
	The following table shows the measured customer cone sizes in number of prefixes	The following table shows the measured customer cone sizes in number of prefixes
	originated (from all ASes in the customer cone) for various types of ISPs <xref	originated (from all ASes in the customer cone) for various types of ISPs <xref
	target="sriram-ripe63"></xref>:	target="Sriram-RIPE63" format="default"/>:
	</t>	</t>

	<texttable anchor="ccsize" title="Customer cone sizes (# prefixes) for various t
	ypes of ISPs.">

	<ttcol width="50%" align='left'>Type of ISP</ttcol>
	<ttcol width="50%" align='left'>Measured Customer Cone Size in # Prefixe
	s (in turn this is an estimate for RPF list size on the line card)</ttcol>

	<c>Very Large Global ISP #1</c>
	<c>32393</c>


	<c> ------------------------------- </c>	<table anchor="ccsize">
	<c> ------------------------------- </c>	<name>Customer Cone Sizes (# Prefixes) for Various Types of ISPs</name>
		<thead>
	<c>Very Large Global ISP #2</c>	<tr>
	<c>29528</c>	<th>Type of ISP</th>
		<th>Measured Customer Cone Size in # Prefixes (in turn this is an
	<c> ------------------------------- </c>	estimate for RPF list size on the line card)</th>
	<c> ------------------------------- </c>	</tr>
		</thead>
	<c>Large Global ISP</c>	<tbody>
	<c>20038</c>	<tr>
	<c> ------------------------------- </c>	<td>Very Large Global ISP #1</td>
	<c> ------------------------------- </c>	<td>32393</td>
		</tr>
	<c>Mid-size Global ISP</c>	<tr>
	<c>8661</c>	<td>Very Large Global ISP #2</td>
		<td>29528</td>
	<c> ------------------------------- </c>	</tr>
	<c> ------------------------------- </c>	<tr>
		<td>Large Global ISP</td>
	<c>Regional ISP (in Asia) </c>	<td>20038</td>
	<c>1101</c>	</tr>
		<tr>
		<td>Mid-size Global ISP</td>
		<td>8661</td>
		</tr>
		<tr>
		<td>Regional ISP (in Asia)</td>
		<td>1101</td>
		</tr>
		</tbody>
		</table>


	</texttable>	<t>
	<t>	For some super large global ISPs that are at the core of the Internet, the custo
	For some super large global ISPs that are at the core of the Internet, the custo	mer cone size (# prefixes) can be as high as a few hundred thousand <xref target
	mer cone size (# prefixes) can be as high as a few hundred thousand <xref target	="CAIDA" format="default"/>, but uRPF is most effective when deployed at ASes at
	="CAIDA"></xref>. But uRPF is most effective when deployed at ASes at the edges	the edges of the Internet where the customer cone sizes are smaller, as shown i
	of the Internet where the customer cone sizes are smaller as shown in <xref targ	n <xref target="ccsize" format="default"/>.
	et="ccsize"></xref>.
	</t>	</t>

	<t>	<t>
	A very large global ISP's router line card is likely to have a FIB size large en	A very large global ISP's router line card is likely to have a FIB size large en
	ough to accommodate 2 million routes <xref target="Cisco1"></xref>. Similarly, t	ough to accommodate 2 million routes <xref target="Cisco1" format="default"/>. S
	he line cards in routers corresponding to a large global ISP, a mid-size global	imilarly, the line cards in routers corresponding to a large global ISP, a midsi
	ISP, and a regional ISP are likely to have FIB sizes large enough to accommodate	ze global ISP, and a regional ISP are likely to have FIB sizes large enough to a
	about 1 million, 0.5 million, and 100K routes, respectively <xref target="Cisco	ccommodate about 1 million, 0.5 million, and 100k routes, respectively <xref tar
	2"></xref>. Comparing these FIB size numbers with the corresponding RPF list siz	get="Cisco2" format="default"/>. Comparing these FIB size numbers with the corre
	e numbers in <xref target="ccsize"></xref>, it can be surmised that the conserva	sponding RPF list size numbers in <xref target="ccsize" format="default"/>, it c
	tively estimated RPF list size is only a small fraction of the anticipated FIB m	an be surmised that the conservatively estimated RPF list size is only a small f
	emory size under relevant ISP scenarios. What is meant here by relevant ISP scen	raction of the anticipated FIB memory size under relevant ISP scenarios. What is
	arios is that only smaller ISPs (and possibly some mid-size and regional ISPs) a	meant here by relevant ISP scenarios is that only smaller ISPs (and possibly so
	re expected to implement the proposed EFP-uRPF method since it is most effective	me midsize and regional ISPs) are expected to implement the proposed EFP-uRPF me
	closer to the edges of the Internet.	thod since it is most effective closer to the edges of the Internet.
	</t>	</t>

	</section>	</section>
		<section anchor="hyst" numbered="true" toc="default">
	<section anchor="hyst" title="Coping with BGP's Transient Behavior">	<name>Coping with BGP's Transient Behavior</name>
	<t>	<t>
	BGP routing announcements can exhibit transient behavior. Routes may be withdraw	BGP routing announcements can exhibit transient behavior. Routes may be
	n temporarily and then re-announced due to transient conditions such as BGP sess	withdrawn temporarily and then reannounced due to transient conditions, such
	ion reset or link failure-recovery. To cope with this, hysteresis should be intr	as BGP session reset or link failure recovery. To cope with this, hysteresis sho
	oduced in the maintenance of the RPF lists. Deleting entries from the RPF lists	uld be introduced in the maintenance of the RPF lists. Deleting entries from the
	SHOULD be delayed by a pre-determined amount (the value based on operational exp	RPF lists <bcp14>SHOULD</bcp14> be delayed by a predetermined amount (the value
	erience) when responding to route withdrawals. This should help suppress the eff	based on operational experience) when responding to route withdrawals. This sho
	ects due to the transients in BGP.	uld help suppress the effects due to the transients in BGP.
	</t>	</t>

	</section>	</section>
		</section>
	</section>	<section anchor="summ_recomm" numbered="true" toc="default">
		<name>Summary of Recommendations</name>
	<section anchor="summ_recomm" title="Summary of Recommendations">	<t>
	<t>
	Depending on the scenario, an ISP or enterprise AS operator should follow one of the following recommendations concerning uRPF/SAV:	Depending on the scenario, an ISP or enterprise AS operator should follow one of the following recommendations concerning uRPF/SAV:
	</t>	</t>

	<t><list style="numbers">	<ol spacing="normal" type="1">
	<t>	<li>
	For directly connected networks, i.e., subnets directly connected to the AS, the	For directly connected networks, i.e., subnets directly connected to the AS, the
	AS under consideration SHOULD perform ACL-based source address validation (SAV)	AS under consideration <bcp14>SHOULD</bcp14> perform ACL-based SAV.
	.	</li>
		<li>
	<!-- For directly connected networks, i.e., subnets directly connected to the AS	For a directly connected single-homed stub AS (customer), the AS under considera
	and not multi-homed, the AS under consideration SHOULD perform ACL-based source	tion <bcp14>SHOULD</bcp14> perform SAV based on the strict uRPF method.
	address validation (SAV). -->	</li>
		<li>
	</t>	<t>
	<t>
	For a directly connected single-homed stub AS (customer), the AS under considera
	tion SHOULD perform SAV based on the strict uRPF method.
	</t>
	<t>
	For all other scenarios:	For all other scenarios:

	<list style="symbols">
	<t>
	The enhanced feasible-path uRPF (EFP-uRPF) method with Algorithm B (see <xref ta
	rget="algB"></xref>) SHOULD be applied on customer interfaces.
	</t>	</t>

	<t>	<ul spacing="normal">
	Loose uRPF method SHOULD be applied on lateral peer and transit provider interfa	<li>
	ces.	The EFP-uRPF method with Algorithm B (see <xref target="algB" format="default"/>
		) <bcp14>SHOULD</bcp14> be applied on customer interfaces.
		</li>
		<li>
		The loose uRPF method <bcp14>SHOULD</bcp14> be applied on lateral peer and trans
		it provider interfaces.


		</li>
		</ul>
		</li>
		</ol>
		<t>
		It is also recommended that prefixes from registered ROAs and IRR route objects
		that include ASes in an ISP's customer cone <bcp14>SHOULD</bcp14> be used to aug
		ment the pertaining RPF lists (see <xref target="augment" format="default"/> for
		details).
	</t>	</t>

	</list>	<section anchor="discuss" numbered="true" toc="default">
	</t>	<name>Applicability of the EFP-uRPF Method with Algorithm A</name>
	</list>	<t>The EFP-uRPF method with Algorithm A is not mentioned in the above
	</t>	set of recommendations. It is an alternative to EFP-uRPF with Algorithm B and ca
	<t>	n be used in limited circumstances. The EFP-uRPF method with Algorithm A is expe
	It is also recommended that prefixes from registered ROAs and IRR route objects	cted to work fine if an ISP deploying it has only multihomed stub customers. It
	that include ASes in an ISP's customer cone SHOULD be used to augment the pertai	is trivially equivalent to strict uRPF if an ISP deploys it for a single-homed s
	ning RPF lists (see <xref target="augment"></xref> for details).	tub customer. More generally, it is also expected to work fine when there is abs
	</t>	ence of limitations, such as those described in <xref target="challenge" format=
		"default"/>. However, caution is required for use of EFP-uRPF with Algorithm A b
	<section anchor="discuss" title="Applicability of the enhanced feasible-path uRP	ecause even if the limitations are not expected at the time of deployment, the v
	F (EFP-uRPF) method with Algorithm A">	ulnerability to change in conditions exists. It may be difficult for an ISP to k
	<t>	now or track the extent of use of NO_EXPORT (see <xref target="challenge" format
	EFP-uRPF method with Algorithm A is not mentioned in the above set of recommenda	="default"/>) on routes within its customer cone. If an ISP decides to use EFP-u
	tions. It is an alternative to EFP-uRPF with Algorithm B and can be used in limi	RPF with Algorithm A, it should make its direct customers aware of the operation
	ted circumstances. The EFP-uRPF method with Algorithm A is expected to work fine	al recommendations in <xref target="recomm" format="default"/>. This means that
	if an ISP deploying it has only multi-homed stub customers. It is trivially equ	the ISP notifies direct customers that at least one prefix originated by each AS
	ivalent to strict uRPF if an ISP deploys it for a single-homed stub customer. Mo	in the direct customer's customer cone must propagate to the ISP.
	re generally, it is also expected to work fine when there is absence of limitati
	ons such as those described in <xref target="challenge"></xref>. However, cautio
	n is required for use of EFP-uRPF with Algorithm A because even if the limitatio
	ns are not expected at the time of deployment, the vulnerability to change in co
	nditions exists. It may be difficult for an ISP to know or track the extent of u
	se of NO_EXPORT (see <xref target="challenge"></xref>) on routes within its cust
	omer cone. If an ISP decides to use EFP-uRPF with Algorithm A, it should make it
	s direct customers aware of the operational recommendations in <xref target="rec
	omm"></xref>. This means that the ISP notifies direct customers that at least on
	e prefix originated by each AS in the direct customer's customer cone must propa
	gate to the ISP.
	</t>	</t>

	<t>	<t>
	On a lateral peer interface, an ISP may choose to apply the EFP-uRPF method with Algorithm A (with appropriate modification of the algorithm). This is because s tricter forms of uRPF (than the loose uRPF) may be considered applicable by some ISPs on interfaces with lateral peers.	On a lateral peer interface, an ISP may choose to apply the EFP-uRPF method with Algorithm A (with appropriate modification of the algorithm). This is because s tricter forms of uRPF (than the loose uRPF) may be considered applicable by some ISPs on interfaces with lateral peers.
	</t>	</t>

	</section>	</section>
		</section>
	</section>	</section>
		<section anchor="seccon" numbered="true" toc="default">
	</section>	<name>Security Considerations</name>
		<t>
		The security considerations in BCP 38 <xref target="RFC2827"
		format="default"/> and RFC 3704 <xref target="RFC3704" format="default"/> apply
		for this document as well. In addition, if considering using the EFP-uRPF method
		with Algorithm A, an ISP or AS operator should be aware of the applicability co
		nsiderations and potential vulnerabilities discussed in <xref target="discuss" f
		ormat="default"/>.


	<section anchor="seccon" title="Security Considerations">
	<t>
	The security considerations in BCP 38 <xref target="RFC2827"></xref> and BCP 84
	<xref target="RFC3704"></xref> apply for this document as well. In addition, if
	considering using EFP-uRPF method with Algorithm A, an ISP or AS operator should
	be aware of the applicability considerations and potential vulnerabilities disc
	ussed in <xref target="discuss"></xref>.
	<!-- In addition, AS operator should apply the uRPF method that performs best (i
	.e., with zero or low possibility of dropping legitimate data packets) for the t
	ype of peer (customer, transit provider, etc.) in consideration. -->
	</t>	</t>

	<t>	<t>
	In augmenting RPF lists with ROA (and possibly reliable IRR) information (see <x	In augmenting RPF lists with ROA (and possibly reliable IRR) information (see
	ref target="augment"></xref>), a trade-off is made in favor of reducing false po	<xref target="augment" format="default"/>), a trade-off is made in favor of
	sitives (regarding invalid detection in SAV) at the expense of a slight other ri	reducing false positives (regarding invalid detection in SAV) at the expense
	sk. The other risk being a malicious actor at another AS in the neighborhood wit	of another slight risk. The other risk being that a malicious actor at another
	hin the customer cone might take advantage (of the augmented prefix) to some ext	AS in the neighborhood within the customer cone might take advantage (of the
	ent. This risk also exists even with normal announced prefixes (i.e., without RO	augmented prefix) to some extent. This risk also exists even with normal
	A augmentation) for any uRPF method other than the strict. However, the risk is	announced prefixes (i.e., without ROA augmentation) for any uRPF method other
	mitigated if the transit provider of the other AS in question is performing SAV.	than the strict uRPF. However, the risk is mitigated if the transit provider of
		the other AS in question is performing SAV.
	</t>	</t>

	<t>	<t>
	Though not within the scope of this document, security hardening of routers and other supporting systems (e.g., Resource PKI (RPKI) and ROA management systems) against compromise is extremely important. The compromise of those systems can a ffect the operation and performance of the SAV methods described in this documen t.	Though not within the scope of this document, security hardening of routers and other supporting systems (e.g., Resource PKI (RPKI) and ROA management systems) against compromise is extremely important. The compromise of those systems can a ffect the operation and performance of the SAV methods described in this documen t.
	</t>	</t>

	</section>	</section>
		<section numbered="true" toc="default">
	<section title="IANA Considerations">	<name>IANA Considerations</name>
	<t>This document does not request new capabilities or attributes. It does not cr	<t>This document has no IANA actions.
	eate any new IANA registries.
	</t>
	</section>

	<section title=" Acknowledgements">
	<t>The authors would like to thank Sandy Murphy, Alvaro Retana, Job Snijders, Ma
	rco Marzetti, Marco d'Itri, Nick Hilliard, Gert Doering, Fred Baker, Igor Gashin
	sky, Igor Lubashev, Andrei Robachevsky, Barry Greene, Amir Herzberg, Ruediger Vo
	lk, Jared Mauch, Oliver Borchert, Mehmet Adalier, and Joel Jaeggli for comments
	and suggestions. The comments and suggestions received from the IESG reviewers a
	re also much appreciated.
	</t>	</t>

	</section>	</section>

	</middle>
	<back>
	<references title="Normative References">
	&RFC2119;
	&RFC2827;
	&RFC3704;
	&RFC4271;
	&RFC8174;
	</references>

	<references title="Informative References">

	&RFC4036;
	&RFC4364;
	&RFC6811;
	&RFC6482;
	&RFC7454;

	<!--
	<reference anchor="RRL" target="http://www.redbarn.org/dns/ratelimits">
	<front>
	<title>Response Rate Limiting in the Domain Name System</title>
	<author initials="" surname="">
	<organization></organization>
	</author>
	<date month='' year='' />
	</front>
	<seriesInfo name='Redbarn blog' value=''/>
	</reference>

	<reference anchor="Firmin" target="https://www.3gpp.org/technologies/keywords-ac
	ronyms/100-the-evolved-packet-core">
	<front>
	<title>The Evolved Packet Core</title>
	<author initials="F" surname="Firmin">
	<organization></organization>
	</author>
	<date month='' year='' />
	</front>
	<seriesInfo name='3GPP The Mobile Broadband Standard' value=''/>
	</reference>

	<reference anchor="ISOC" target="https://www.internetsociety.org/resources/doc/2
	015/addressing-the-challenge-of-ip-spoofing/">
	<front>
	<title>Addressing the challenge of IP spoofing</title>
	<author initials="P." surname="Vixie (Ed.)">
	<organization></organization>
	</author>
	<date month='September' year='2015' />
	</front>
	<seriesInfo name='ISOC report' value=''/>
	</reference>

	<reference anchor="CAIDA" target="https://spoofer.caida.org/as.php?asn=174">
	<front>
	<title>Information for AS 174 (COGENT-174)</title>
	<author initials="" surname="">
	<organization></organization>
	</author>
	<date month='' year='' />
	</front>
	<seriesInfo name='CAIDA Spoofer Project' value=''/>
	</reference>


	<reference anchor="sriram-ripe63" target="http://www.ietf.org/proceedings/83/sli	</middle>
	des/slides-83-sidr-7.pdf">	<back>
	<front>	<references>
	<title>Estimating CPU Cost of BGPSEC on a Router</title>	<name>References</name>
		<references>
		<name>Normative References</name>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.2119.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.2827.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.3704.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.4271.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8174.xml"/>
		</references>
		<references>
		<name>Informative References</name>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.4036.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.4364.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.6811.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.6482.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7454.xml"/>


	<author initials="K" surname="Sriram">	<reference anchor="Firmin" target="https://www.3gpp.org/technologies/key
	<organization></organization>	words-acronyms/100-the-evolved-packet-core">
	</author>	<front>
	<author initials="R" surname="Bush">	<title>The Evolved Packet Core</title>
	<organization></organization>	<author initials="F" surname="Firmin">
	</author>	<organization/>
	<date year="March 2012" />	</author>
	</front>	</front>
	<seriesInfo name="Presented at RIPE-63;" value="also, at IETF-83 SIDR WG Meeting	</reference>
	" />
	</reference>


	<reference anchor="sriram-urpf" target="https://datatracker.ietf.org/meeting/101	<reference anchor="ISOC" target="https://www.internetsociety.org/resourc
	/materials/slides-101-opsec-draft-sriram-opsec-urpf-improvements-00">	es/doc/2015/addressing-the-challenge-of-ip-spoofing/">
	<front>	<front>
	<title>Enhanced Feasible-Path Unicast Reverse Path Filtering</title>	<title>Addressing the challenge of IP spoofing</title>
		<author>
		<organization>Internet Society</organization>
		</author>
		<date month="September" year="2015"/>
		</front>
		</reference>


	<author initials="K" surname="Sriram et al.">	<reference anchor="CAIDA" target="https://spoofer.caida.org/as.php?asn=1
	<organization></organization>	74">
	</author>	<front>
		<title>Information for AS 174 (COGENT-174)</title>
		<author>
		<organization>CAIDA</organization>
		</author>
		<date month="October" year="2019"/>
		</front>
		</reference>


	<date year="March 2018" />	<reference anchor="Sriram-RIPE63" target="http://www.ietf.org/proceeding
	</front>	s/83/slides/slides-83-sidr-7.pdf">
	<seriesInfo name="Presented at the OPSEC WG Meeting, IETF-101 London" value="" /	<front>
	>	<title>Estimating CPU Cost of BGPSEC on a Router</title>
		<author initials="K" surname="Sriram">
		<organization/>
		</author>
		<author initials="R" surname="Bush">
		<organization/>
		</author>
		<date month="March" year="2012"/>
		</front>
		<refcontent>Presented at RIPE 63 and at the SIDR WG meeting at
		IETF 83</refcontent>
		</reference>


	</reference>	<reference anchor="Sriram-URPF" target="https://datatracker.ietf.org/mee
		ting/101/materials/slides-101-opsec-draft-sriram-opsec-urpf-improvements-00">
		<front>
		<title>Enhanced Feasible-Path Unicast Reverse Path Filtering</title>
		<author initials="K" surname="Sriram">
		<organization/>
		</author>
		<author initials="D" surname="Montgomery">
		<organization/>
		</author>
		<author initials="J" surname="Haas">
		<organization/>
		</author>
		<date month="March" year="2018"/>
		</front>
		<refcontent>Presented at the OPSEC WG meeting at IETF 101</refconten
		t>
		</reference>


	<reference anchor="Cisco1" target="https://www.cisco.com/c/en/us/support/docs/ro	<reference anchor="Cisco1" target="https://www.cisco.com/c/en/us/support
	uters/asr-9000-series-aggregation-services-routers/116999-problem-line-card-00.h	/docs/routers/asr-9000-series-aggregation-services-routers/116999-problem-line-c
	tml">	ard-00.html">
	<front>	<front>
	<title>Internet Routing Table Growth Causes ROUTING-FIB-4-RSRC_LOW Mes	<title>Internet Routing Table Growth Causes
	sage on Trident-Based Line Cards</title>	%ROUTING-FIB-4-RSRC_LOW Message on Trident-Based Line
	<author initials="" surname="">	Cards</title>
	<organization></organization>	<author initials="" surname="">
	</author>	<organization>Cisco</organization>
	<date month='January' year='2014' />	</author>
	</front>	<date month="January" year="2014"/>
	<seriesInfo name="Cisco Trouble-shooting Tech-notes" value=""/>	</front>
	</reference>	</reference>


	<reference anchor="Cisco2" target="https://www.cisco.com/c/en/us/td/docs/switche	<reference anchor="Cisco2" target="https://www.cisco.com/c/en/us/td/docs
	s/datacenter/sw/5_x/nx-os/unicast/configuration/guide/l3_cli_nxos/l3_NewChange.h	/switches/datacenter/sw/5_x/nx-os/unicast/configuration/guide/l3_cli_nxos/l3_New
	tml">	Change.html">
	<front>	<front>
	<title>Cisco Nexus 7000 Series NX-OS Unicast Routing Configuration Gui	<title>Cisco Nexus 7000 Series NX-OS Unicast Routing Configuration G
	de, Release 5.x (Chapter 15: Managing the Unicast RIB and FIB)</title>	uide, Release 5.x (Chapter 15: 'Managing the Unicast RIB and FIB')</title>
	<author initials="" surname="">	<author>
	<organization></organization>	<organization>Cisco</organization>
	</author>	</author>
	<date month='March' year='2018' />	<date month="March" year="2018"/>
	</front>	</front>
	<seriesInfo name="Cisco Configuration Guides" value=""/>	</reference>
	</reference>


	<reference anchor="Juniper" target="https://www.juniper.net/documentation/en_US/	<reference anchor="Juniper" target="https://www.juniper.net/documentatio
	junos/topics/topic-map/l3-vpns-routes-vrf-tables.html#id-understanding-virtual-r	n/en_US/junos/topics/topic-map/l3-vpns-routes-vrf-tables.html#id-understanding-v
	outing-and-forwarding-tables">	irtual-routing-and-forwarding-tables">
	<front>	<front>
	<title>Creating Unique VPN Routes Using VRF Tables</title>	<title>Creating Unique VPN Routes Using VRF Tables</title>
	<author initials="" surname="">	<author>
	<organization></organization>	<organization>Juniper Networks</organization>
	</author>	</author>
	<date month='March' year='2019' />	<date month="May" year="2019"/>
	</front>	</front>
	<seriesInfo name="Juniper Networks TechLibrary" value=""/>	</reference>
	</reference>


	<reference anchor="SPAR-v4" target="https://www.iana.org/assignments/iana-ipv4-s	<reference anchor="SPAR-v4" target="https://www.iana.org/assignments/ian
	pecial-registry/iana-ipv4-special-registry.xhtml">	a-ipv4-special-registry/">
	<front>	<front>
	<title>IANA IPv4 Special-Purpose Address Registry</title>	<title>IANA IPv4 Special-Purpose Address Registry</title>
	<author initials="" surname="">	<author>
	<organization></organization>	<organization>IANA</organization>
	</author>	</author>
	<date month='' year='' />	</front>
	</front>	</reference>
	<seriesInfo name="IANA" value=""/>
	</reference>


	<reference anchor="SPAR-v6" target="https://www.iana.org/assignments/iana-ipv6-s	<reference anchor="SPAR-v6" target="https://www.iana.org/assignments/ian
	pecial-registry/iana-ipv6-special-registry.xhtml">	a-ipv6-special-registry/">
	<front>	<front>
	<title>IANA IPv6 Special-Purpose Address Registry</title>	<title>IANA IPv6 Special-Purpose Address Registry</title>
	<author initials="" surname="">	<author>
	<organization></organization>	<organization>IANA</organization>
	</author>	</author>
	<date month='' year='' />	</front>
	</front>	</reference>
	<seriesInfo name="IANA" value=""/>
	</reference>


	<reference anchor="Luckie" target="http://www.caida.org/~amogh/papers/asrank-I	<reference anchor="Luckie" target="https://dl.acm.org/doi/10.1145/250473
	MC13.pdf">	0.2504735">
	<front>	<front>
	<title>AS Relationships, Customer Cones, and Validation</title>	<title>AS Relationships, customer cones, and validation</title>
	<author initials="M." surname="Luckie">	<seriesInfo name="DOI" value="10.1145/2504730.2504735"/>
	<organization></organization>	<author initials="M." surname="Luckie">
	</author>	<organization/>
	<author initials="B." surname="Huffaker">	</author>
	<organization></organization>	<author initials="B." surname="Huffaker">
	</author>	<organization/>
	<author initials="A." surname="Dhamdhere">	</author>
	<organization></organization>	<author initials="A." surname="Dhamdhere">
	</author>	<organization/>
	<author initials="V." surname="Giotsas">	</author>
	<organization></organization>	<author initials="V." surname="Giotsas">
	</author>	<organization/>
	<author initials="kc" surname="claffy">	</author>
	<organization></organization>	<author initials="kc" surname="claffy">
	</author>	<organization/>
	<date month='October' year='2013' />	</author>
	</front>	<date month="October" year="2013"/>
	<seriesInfo name='In Proceedings of the 2013 ACM Internet	</front>
	Measurement Conference' value='(IMC)' />	<refcontent>In Proceedings of the 2013 Internet Measurement Conferen
	<seriesInfo name="DOI" value="10.1145/2504730.2504735" />	ce</refcontent>
	</reference>	</reference>
		</references>
		</references>


	<!--	<section numbered="false" toc="default">
	<reference anchor="Cisco3" target="https://www.cisco.com/c/dam/en_us/about/secur	<name>Acknowledgements</name>
	ity/intelligence/urpf.pdf">	<t>The authors would like to thank
	<front>	<contact fullname="Sandy Murphy" />,
	<title>Unicast reverse path forwarding enhancements for the Internet s	<contact fullname="Alvaro Retana" />,
	ervice provider</title>	<contact fullname="Job Snijders" />,
	<author initials="" surname="">	<contact fullname="Marco Marzetti" />,
	<organization></organization>	<contact fullname="Marco d'Itri" />,
	</author>	<contact fullname="Nick Hilliard" />,
	<date year='2005' />	<contact fullname="Gert Doering" />,
	</front>	<contact fullname="Fred Baker" />,
	<seriesInfo name="Cisco white paper" value=""/>	<contact fullname="Igor Gashinsky" />,
	</reference>	<contact fullname="Igor Lubashev" />,
		<contact fullname="Andrei Robachevsky" />,
		<contact fullname="Barry Greene" />,
		<contact fullname="Amir Herzberg" />,
		<contact fullname="Ruediger Volk" />,
		<contact fullname="Jared Mauch" />,
		<contact fullname="Oliver Borchert" />,
		<contact fullname="Mehmet Adalier" />, and
		<contact fullname="Joel Jaeggli"/> for comments and suggestions. The comments an
		d suggestions received from the IESG reviewers are also much appreciated.
		</t>
		</section>


	</references>	</back>
	</back>
	</rfc>	</rfc>

End of changes. 113 change blocks.
	918 lines changed or deleted	835 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/