< draft-ietf-grow-as-path-prepending-00.txt		draft-ietf-grow-as-path-prepending-01.txt >
	Network Working Group M. McBride		Network Working Group M. McBride
	Internet-Draft Futurewei		Internet-Draft Futurewei
	Intended status: Best Current Practice D. Madory		Intended status: Best Current Practice D. Madory
	Expires: March 12, 2021 Oracle		Expires: May 3, 2021 Oracle
	J. Tantsura		J. Tantsura
	Apstra		Apstra
	R. Raszuk		R. Raszuk
	Bloomberg LP		Bloomberg LP
	H. Li		H. Li
	HPE		HPE
	September 8, 2020		October 30, 2020
	AS Path Prepending		AS Path Prepending
	draft-ietf-grow-as-path-prepending-00		draft-ietf-grow-as-path-prepending-01
	Abstract		Abstract
	AS Path Prepending provides a tool to manipulate the BGP AS_Path		AS Path Prepending provides a tool to manipulate the BGP AS_Path
	attribute through prepending multiple entries of an AS. AS Path		attribute through prepending multiple entries of an AS. AS Path
	Prepending is used to deprioritize a route or alternate path. By		Prepending is used to deprioritize a route or alternate path. By
	prepending the local ASN multiple times, ASs can make advertised AS		prepending the local ASN multiple times, ASs can make advertised AS
	paths appear artificially longer. Excessive AS Path Prepending has		paths appear artificially longer. Excessive AS Path Prepending has
	caused routing issues in the internet. This document provides		caused routing issues in the internet. This document provides
	guidance,to the internet community, with how best to utilize AS Path		guidance,to the internet community, with how best to utilize AS Path
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 44 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on March 12, 2021.		This Internet-Draft will expire on May 3, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 34 ¶		skipping to change at page 2, line 34 ¶
	2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Excessive Prepending . . . . . . . . . . . . . . . . . . 4		3.1. Excessive Prepending . . . . . . . . . . . . . . . . . . 4
	3.2. Prepending during a routing leak . . . . . . . . . . . . 5		3.2. Prepending during a routing leak . . . . . . . . . . . . 5
	3.3. Prepending to All . . . . . . . . . . . . . . . . . . . . 6		3.3. Prepending to All . . . . . . . . . . . . . . . . . . . . 6
	3.4. Memory . . . . . . . . . . . . . . . . . . . . . . . . . 6		3.4. Memory . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.5. Errant announcement . . . . . . . . . . . . . . . . . . . 7		3.5. Errant announcement . . . . . . . . . . . . . . . . . . . 7
	4. Alternatives to AS Path Prepend . . . . . . . . . . . . . . . 7		4. Alternatives to AS Path Prepend . . . . . . . . . . . . . . . 7
	5. Best Practices . . . . . . . . . . . . . . . . . . . . . . . 7		5. Best Practices . . . . . . . . . . . . . . . . . . . . . . . 7
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 8		7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9		8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	9.1. Normative References . . . . . . . . . . . . . . . . . . 9		9.1. Normative References . . . . . . . . . . . . . . . . . . 9
	9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9		9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	The Border Gateway Protocol (BGP) [RFC4271] specifies the AS_PATH		The Border Gateway Protocol (BGP) [RFC4271] specifies the AS_PATH
	attribute which enumerates ASs a route update has traversed. If the		attribute which enumerates ASs a route update has traversed. If the
	UPDATE message is propagated over an external link, then the local AS		UPDATE message is propagated over an external link, then the local AS
	number is prepended to the AS_PATH attribute, and the NEXT_HOP		number is prepended to the AS_PATH attribute, and the NEXT_HOP
	attribute is updated with an IP address of the router that should be		attribute is updated with an IP address of the router that should be
	used as a next hop to the network. If the UPDATE message is		used as a next hop to the network. If the UPDATE message is
	propagated over an internal link, then the AS_PATH attribute and the		propagated over an internal link, then the AS_PATH attribute and the
	skipping to change at page 3, line 39 ¶		skipping to change at page 3, line 39 ¶
	different ASBRs		different ASBRs
	o Preferring one ASBR over another ASBR in the same site		o Preferring one ASBR over another ASBR in the same site
	o Utilize one path exclusively and another path solely as a backup		o Utilize one path exclusively and another path solely as a backup
	o Signal to indicate that one path may have a different amount of		o Signal to indicate that one path may have a different amount of
	capacity than another where the lower capacity link still takes		capacity than another where the lower capacity link still takes
	traffic		traffic
			o An ISP doesn't accept traffic engineering using BGP communities.
			Prepending is the only option.
	The following illustration, from Geoff Hustons Path Prepending in BGP		The following illustration, from Geoff Hustons Path Prepending in BGP
	[1], shows how AS Prepending is typically used:		[1], shows how AS Prepending is typically used:
	+---+ +---+		+---+ +---+
	+---| D |----| F |		+---| D |----| F |
	| +---+ +---+		| +---+ +---+
	+---+ +---+ |		+---+ +---+ |
	| A |---| B | |		| A |---| B | |
	+---+ +---+ |		+---+ +---+ |
	| +---+ +---+		| +---+ +---+
	skipping to change at page 4, line 27 ¶		skipping to change at page 4, line 27 ¶
	two instances of its own AS number when advertising its routes to C,		two instances of its own AS number when advertising its routes to C,
	then B will now see a different situation, where the AS Path via D		then B will now see a different situation, where the AS Path via D
	represents the shorter path. Through the use of selective prepending		represents the shorter path. Through the use of selective prepending
	E is able to alter the routing decision of B, even though B is not an		E is able to alter the routing decision of B, even though B is not an
	adjacent neighbour of E. The result is that traffic from A and B		adjacent neighbour of E. The result is that traffic from A and B
	will be passed via D and F to reach E, rather than via C. In this		will be passed via D and F to reach E, rather than via C. In this
	way prepending implements action at a distance where the routing		way prepending implements action at a distance where the routing
	decisions made by non-adjacent ASs can be influenced by selective AS		decisions made by non-adjacent ASs can be influenced by selective AS
	Path prepending.		Path prepending.
	In August 2020 a large ISP had a network outage that affected their		To illustrate, in August 2020 a large ISP had a network outage that
	customers and other ISPs. One major problem was that the ISP wasn't		affected their customers and other ISPs. One major problem was that
	withdrawing BGP routes, the stale routes were continuing to be		the ISP wasn't withdrawing BGP routes, the stale routes were
	announced as legitimate by the down ISP. This caused blackholing of		continuing to be announced as legitimate by the down ISP. This
	traffic even when customers had backup ISPs. What could customers do		caused blackholing of traffic even when customers had backup ISPs.
	in this situation? They could change local preference to help send		What could customers do in this situation? They could change local
	traffic to the backup ISP. They could send more specifics to the		preference to help send traffic to the backup ISP. They could send
	backup ISP. They could also use AS Path Prepend by prepending the		more specifics to the backup ISP. They could also pre-provision the
	same amount to both primary and backup ISPs before failure.		use of AS Path Prepend to prepend the same AS amount to both primary
	Customers could then, during a failure, remove one prepend to the		and backup ISPs before failure. Customers could then, during a
	backup ISP to make it more preferred over the down ISP. This is one,		failure, remove one prepend to the backup ISP to make it more
	of several, scenarios where using AS Path Prepend can be beneficial.		preferred over the down ISP. This is one, of several, scenarios
			where using AS Path Prepend can be beneficial.
	3. Problems		3. Problems
	Since it is so commonly used, what is the problem with the excessive		Since it is so commonly used, what is the problem with the excessive
	use of AS Path Prepending? Here are a few examples:		use of AS Path Prepending? Here are a few examples:
	3.1. Excessive Prepending		3.1. Excessive Prepending
	The risk of excessive use of AS Path Prepending can be illustrated		The risk of excessive use of AS Path Prepending can be illustrated
	with real-world examples that have been anonymized using documention		with real-world examples that have been anonymized using documention
	skipping to change at page 7, line 34 ¶		skipping to change at page 7, line 36 ¶
	There are various options to provide path preference without needing		There are various options to provide path preference without needing
	to use AS Path Prepend:		to use AS Path Prepend:
	o Use predefined communities that are mapped to a particular		o Use predefined communities that are mapped to a particular
	behavior when propagated.		behavior when propagated.
	o Announce more specific routes on the preferred path.		o Announce more specific routes on the preferred path.
	o The BGP Origin Code is an attribute that is used for path		o The BGP Origin Code is an attribute that is used for path
	selection. The three origin codes are IGP, EGP and Incomplete.		selection and can be used as a high order tie-breaker. The three
	We could advertise paths with IGP or EGP origin over the preferred		origin codes are IGP, EGP and INCOMPLETE. When AS Paths are of
	path while the other ASBRs (which would otherwise prepend N times)		equivalent length, users could advertise paths, with IGP or EGP
	advertises with an INCOMPLETE origin code.		origin, over the preferred path while the other ASBRs (which would
			otherwise need to prepend N times) advertises with an INCOMPLETE
			origin code.
	5. Best Practices		5. Best Practices
	Many of the best practices, or lack thereof, can be illustrated from		Many of the best practices, or lack thereof, can be illustrated from
	the preceeding examples. Here's a summary of the best current		the preceeding examples. Here's a summary of the best current
	practices of using AS Path Prepending:		practices when using AS Path Prepending:
	o Network operators should ensure prepending is absolutely		o Network operators should ensure prepending is absolutely necessary
	necessary. Many of your networks have excessive prepending		as many networks have excessive prepending
	o There is no need to prepend more than 5 ASs. The following		o There is no need to prepend more than 5 ASs. The following
	diagram shows that, according to Excessive AS Path Prepending [3],		diagram shows that, according to Excessive AS Path Prepending [3],
	90% of AS path lengths are 5 ASNs or fewer in length.		90% of AS path lengths are 5 ASNs or fewer in length.
	+------------------------------------+		+------------------------------------+
	90| |		90| |
	| X |		| X |
	80| X X |		80| X X |
	| X X |		| X X |
	skipping to change at page 8, line 36 ¶		skipping to change at page 8, line 40 ¶
	AS Path Length in IPv4		AS Path Length in IPv4
	X Axis = unique AS Paths in millions		X Axis = unique AS Paths in millions
	o Don't prepend ASNs that you don't own.		o Don't prepend ASNs that you don't own.
	o Prepending-to-all is a self-inflicted and needless risk that		o Prepending-to-all is a self-inflicted and needless risk that
	serves little purpose. Those excessively prepending their routes		serves little purpose. Those excessively prepending their routes
	should consider this risk and adjust their routing configuration.		should consider this risk and adjust their routing configuration.
	o It is not typical to see more than 20 ASs in a AS_PATH in the		o The Internet is typically around 5 ASs deep with the largest
	Internet today even with the use of AS_Path prepend. The Internet		AS_PATH being 16-20 ASNs. Some have added 100 or more AS Path
	is typically around 5 ASs deep with the largest AS_PATH being		Prepends and operators should therefore consider limiting the
	16-20 ASNs. Some have added 100 or more AS Path Prepends and		maximum AS-path length being accepted through aggressive filter
	operators should therefore consider limiting the maximum AS-path		policies.
	length being accepted
	6. IANA Considerations		6. IANA Considerations
	7. Security Considerations		7. Security Considerations
	There are no security issues introduced by this draft.		Long prepending may make a network more vulernable to route hijacking
			which will exist whenever there is a well connected peer that is
			willing to forge their AS_PATH or allows announcements with a
			fabricated AS path.
	8. Acknowledgement		8. Acknowledgement
	The authors would like to thank Greg Skinner, Randy Bush, Dave		The authors would like to thank Greg Skinner, Randy Bush, Dave
	Farmer, Nick Hilliard, Martijn Schmidt, Jakob Heitz, Michael Still		Farmer, Nick Hilliard, Martijn Schmidt, Jakob Heitz, Michael Still,
	and Geoff Huston for contributing to this document.		Geoff Huston and Jeffrey Haas for contributing to this document.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
End of changes. 15 change blocks.
	35 lines changed or deleted		42 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/