< draft-ietf-idr-deprecate-as-set-confed-set-02.txt		draft-ietf-idr-deprecate-as-set-confed-set-03.txt >
	Network Working Group W. Kumari		Network Working Group W. Kumari
	Internet-Draft Google, Inc.		Internet-Draft Google, Inc.
	Obsoletes: 6472 (if approved) K. Sriram		Obsoletes: 6472 (if approved) K. Sriram
	Updates: 4271 5065 (if approved) L. Hannachi		Updates: 4271 5065 (if approved) L. Hannachi
	Intended status: Standards Track USA NIST		Intended status: Standards Track USA NIST
	Expires: May 6, 2020 November 3, 2019		Expires: September 10, 2020 J. Haas
			Juniper Networks, Inc.
			March 9, 2020
	Deprecation of AS_SET and AS_CONFED_SET in BGP		Deprecation of AS_SET and AS_CONFED_SET in BGP
	draft-ietf-idr-deprecate-as-set-confed-set-02		draft-ietf-idr-deprecate-as-set-confed-set-03
	Abstract		Abstract
	BCP 172 (i.e., RFC 6472) recommends not using AS_SET and		BCP 172 (i.e., RFC 6472) recommends not using AS_SET and
	AS_CONFED_SET in the Border Gateway Protocol. This document advances		AS_CONFED_SET in the Border Gateway Protocol. This document advances
	this recommendation to a standards requirement in BGP; it proscribes		this recommendation to a standards requirement in BGP; it proscribes
	the use of the AS_SET and AS_CONFED_SET types of path segments in the		the use of the AS_SET and AS_CONFED_SET types of path segments in the
	AS_PATH. This is done to simplify the design and implementation of		AS_PATH. This is done to simplify the design and implementation of
	BGP and to make the semantics of the originator of a route clearer.		BGP and to make the semantics of the originator of a route clearer.
	This will also simplify the design, implementation, and deployment of		This will also simplify the design, implementation, and deployment of
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 43 ¶
	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 May 6, 2020.		This Internet-Draft will expire on September 10, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
	3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3		3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Updates to Existing RFCs . . . . . . . . . . . . . . . . . . 4		4. Updates to Existing RFCs . . . . . . . . . . . . . . . . . . 4
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 4		5. Operational Considerations . . . . . . . . . . . . . . . . . 4
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
	8.1. Normative References . . . . . . . . . . . . . . . . . . 5		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
	8.2. Informative References . . . . . . . . . . . . . . . . . 5		9.1. Normative References . . . . . . . . . . . . . . . . . . 5
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6		9.2. Informative References . . . . . . . . . . . . . . . . . 6
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	BCP 172 [RFC6472] makes a recommendation for not using AS_SET (see		BCP 172 [RFC6472] makes a recommendation for not using AS_SET (see
	[RFC4271]) and AS_CONFED_SET (see [RFC5065]) in the Border Gateway		[RFC4271]) and AS_CONFED_SET (see [RFC5065]) in the Border Gateway
	Protocol (BGP). This document advances the BCP recommendation to a		Protocol (BGP). This document advances the BCP recommendation to a
	standards requirement in BGP; it proscribes the use of the AS_SET and		standards requirement in BGP; it proscribes the use of the AS_SET and
	AS_CONFED_SET types of path segments in the AS_PATH.		AS_CONFED_SET types of path segments in the AS_PATH.
	The AS_SET path segment in the AS_PATH attribute (Sections 4.3 and		The AS_SET path segment in the AS_PATH attribute (Sections 4.3 and
	5.1.2 of [RFC4271]) is created by a router that is performing route		5.1.2 of [RFC4271]) is created by a router that is performing route
	aggregation and contains an unordered set of Autonomous Systems		aggregation and contains an unordered set of Autonomous Systems
	(ASes) that the update has traversed. The AS_CONFED_SET path segment		(ASes) that contributing prefixes in the aggregate have traversed.
	(see [RFC5065]) in the AS_PATH attribute is created by a router that		The AS_CONFED_SET path segment (see [RFC5065]) in the AS_PATH
	is performing route aggregation and contains an unordered set of		attribute is created by a router that is performing route aggregation
	Member AS Numbers in the local confederation that the update has		and contains an unordered set of Member AS Numbers in the local
	traversed. It is very similar to AS_SETs but is used within a		confederation that contributing prefixes in the aggregate have
			traversed. It is very similar to an AS_SET but is used within a
	confederation.		confederation.
	By performing aggregation, a router is combining multiple existing		By performing aggregation, a router is combining multiple existing
	routes into a single new route. The aggregation together with the		routes into a single new route. The aggregation together with the
	use of AS_SET blurs the semantics of origin AS for the prefix being		use of AS_SET blurs the semantics of origin AS for the prefix being
	announced. Therefore, the aggregation with AS_SET (or AS_CONFED_SET)		announced. Therefore, the aggregation with AS_SET (or AS_CONFED_SET)
	can cause operational issues, such as not being able to authenticate		can cause operational issues, such as not being able to authenticate
	a route origin for the aggregate prefix in new BGP security		a route origin for the aggregate prefix in new BGP security
	technologies such as those that take advantage of X.509 extensions		technologies such as those that take advantage of X.509 extensions
	for IP addresses and AS identifiers [RFC3779] [RFC6480] [RFC6811]		for IP addresses and AS identifiers [RFC3779] [RFC6480] [RFC6811]
	skipping to change at page 3, line 4 ¶		skipping to change at page 3, line 8 ¶
	confederation.		confederation.
	By performing aggregation, a router is combining multiple existing		By performing aggregation, a router is combining multiple existing
	routes into a single new route. The aggregation together with the		routes into a single new route. The aggregation together with the
	use of AS_SET blurs the semantics of origin AS for the prefix being		use of AS_SET blurs the semantics of origin AS for the prefix being
	announced. Therefore, the aggregation with AS_SET (or AS_CONFED_SET)		announced. Therefore, the aggregation with AS_SET (or AS_CONFED_SET)
	can cause operational issues, such as not being able to authenticate		can cause operational issues, such as not being able to authenticate
	a route origin for the aggregate prefix in new BGP security		a route origin for the aggregate prefix in new BGP security
	technologies such as those that take advantage of X.509 extensions		technologies such as those that take advantage of X.509 extensions
	for IP addresses and AS identifiers [RFC3779] [RFC6480] [RFC6811]		for IP addresses and AS identifiers [RFC3779] [RFC6480] [RFC6811]
	[RFC8205]. This in turn could result in reachability problems for		[RFC8205]. This in turn could result in reachability problems for
	the aggregated prefix and its components (i.e., more-specific		the aggregated prefix and its components (i.e., more specific
	prefixes). The aggregation as described above could also create		prefixes).
	traffic engineering issues, because the precise path information for
	the component prefixes are not preserved.
	From analysis of past Internet routing data, it is apparent that		From analysis of past Internet routing data, it is apparent that
	aggregation that involves AS_SETs is very seldom used in practice on		aggregation that involves AS_SETs is very seldom used in practice on
	the public Internet [Analysis] and when it is used, it is often used		the public Internet [Analysis] and when it is used, it is often used
	incorrectly -- only a single AS in the AS_SET are by far the most		incorrectly -- only a single AS in the AS_SET are by far the most
	common cases. Also, very often the same AS appears in the		common cases. Also, very often the same AS appears in the
	AS_SEQUENCE and the AS_SET in the BGP update. The occurrence of		AS_SEQUENCE and the AS_SET in the BGP update. The occurrence of
	reserved AS numbers ([IANA-SP-ASN]) is also somewhat frequent.		reserved AS numbers ([IANA-SP-ASN]) is also somewhat frequent.
	Because the aggregation involving AS_SETs is very rarely used, the		Because the aggregation involving AS_SETs is very rarely used, the
	reduction in table size provided by this is extremely small, and any		reduction in table size provided by this is extremely small, and any
	skipping to change at page 4, line 5 ¶		skipping to change at page 4, line 9 ¶
	to do so on a per peer basis. The operator should understand the		to do so on a per peer basis. The operator should understand the
	full implications of choosing this option. There is no knob		full implications of choosing this option. There is no knob
	concerning locally generated BGP UPDATE messages, i.e., as stated		concerning locally generated BGP UPDATE messages, i.e., as stated
	before a conformant BGP speaker must not locally generate BGP UPDATE		before a conformant BGP speaker must not locally generate BGP UPDATE
	messages with AS_SET or AS_CONFED_SET.		messages with AS_SET or AS_CONFED_SET.
	Network operators MUST NOT locally generate any new announcements		Network operators MUST NOT locally generate any new announcements
	containing AS_SET or AS_CONFED_SET. If they have announced routes		containing AS_SET or AS_CONFED_SET. If they have announced routes
	with AS_SET or AS_CONFED_SET in them, then they SHOULD withdraw those		with AS_SET or AS_CONFED_SET in them, then they SHOULD withdraw those
	routes and re-announce routes for the aggregate or component prefixes		routes and re-announce routes for the aggregate or component prefixes
	(i.e., the more-specific routes subsumed by the previously aggregated		(i.e., the more specific routes subsumed by the previously aggregated
	route) without AS_SET or AS_CONFED_SET in the updates.		route) without AS_SET or AS_CONFED_SET in the updates.
	It is worth noting that new BGP security technologies (such as those		It is worth noting that new BGP security technologies (such as those
	that take advantage of X.509 extensions for IP addresses and AS		that take advantage of X.509 extensions for IP addresses and AS
	identifiers [RFC3779] [RFC6480] [RFC6811] [RFC8205]) might not		identifiers [RFC3779] [RFC6480] [RFC6811] [RFC8205]) might not
	support routes with AS_SET or AS_CONFED_SET in them, and may treat		support routes with AS_SET or AS_CONFED_SET in them, and may treat
	routes containing them as infeasible even before the updated BGP in		routes containing them as infeasible even before the updated BGP in
	this document is implemented.		this document is implemented.
	4. Updates to Existing RFCs		4. Updates to Existing RFCs
	skipping to change at page 4, line 38 ¶		skipping to change at page 4, line 42 ¶
	BGP speakers SHOULD NOT send BGP UPDATE messages containing		BGP speakers SHOULD NOT send BGP UPDATE messages containing
	AS_CONFED_SET. Upon receipt of such messages, conformant BGP		AS_CONFED_SET. Upon receipt of such messages, conformant BGP
	speakers SHOULD use the "Treat-as-withdraw" error handling behavior		speakers SHOULD use the "Treat-as-withdraw" error handling behavior
	as per [RFC7606].		as per [RFC7606].
	Wherever mentions of AS_SET or AS_CONFED_SET occur in [RFC4271] and		Wherever mentions of AS_SET or AS_CONFED_SET occur in [RFC4271] and
	[RFC5065], appropriate modification or elimination of the text must		[RFC5065], appropriate modification or elimination of the text must
	be made in future RFCs that would replace these RFCs, consistent with		be made in future RFCs that would replace these RFCs, consistent with
	the deprecation of AS_SET and AS_CONFED_SET.		the deprecation of AS_SET and AS_CONFED_SET.
	5. Security Considerations		5. Operational Considerations
			When aggregating prefixes, network operators MUST use brief
			aggregation. In brief aggregation, the AGGREGATOR attribute is
			included but the AS_SET or AS_CONFED_SET attribute is not included.
			When doing the above, operators MUST form the aggregate at the border
			in the outbound BGP policy and omit any prefixes from the AS that the
			aggregate is being advertised to. In other words, an aggregate
			prefix MUST NOT be announced to the contributing ASes. Instead, more
			specific prefixes (from the aggregate) MUST be announced to each
			contributing AS, excluding any that were learned from the
			contributing AS in consideration. For illustration, if p1/24 (from
			AS1), p2/24 (from AS2), p3/24 (from AS3) and p4/24 (from AS4) are
			aggregated to p/22, then p/22 will not be announced to AS1, AS2, AS3,
			or AS4. Instead, as further illustration, p1/24, p2/24 and p4/24 are
			announced to AS3. Or, possibly q/23 (aggregate of p1/24 and p2/24)
			and p4/24 are announced to AS3.
			Operators MUST install egress filters to block data packets when the
			destination address belongs to an internal prefix. Similarly, any
			known single-homed customer prefix MUST also be included in the
			egress filters except on the interface for that customer. This
			mitigates looping in the data plane when connection to such an
			internal or customer prefix is lost. This mechanism effectively
			compensates for the lack of the additional loop detection capability
			accorded by AS_SETs (if they were allowed).
			6. Security Considerations
	This document obsoletes the use of aggregation techniques that create		This document obsoletes the use of aggregation techniques that create
	AS_SETs or AS_CONFED_SETs. Obsoleting these path segment types from		AS_SETs or AS_CONFED_SETs. Obsoleting these path segment types from
	BGP and removal of the related code from implementations would		BGP and removal of the related code from implementations would
	potentially decrease the attack surface for BGP. Deployments of new		potentially decrease the attack surface for BGP. Deployments of new
	BGP security technologies [RFC6480] [RFC6811] [RFC8205] benefit		BGP security technologies [RFC6480] [RFC6811] [RFC8205] benefit
	greatly if AS_SET and AS_CONFED_SET are not used in BGP.		greatly if AS_SET and AS_CONFED_SET are not used in BGP.
	6. IANA Considerations		7. IANA Considerations
	This document requires no IANA actions.		This document requires no IANA actions.
	7. Acknowledgements		8. Acknowledgements
	The authors would like to thank Jeffery Haas, John Heasley, Job		The authors would like to thank John Heasley, Job Snijders, Jared
	Snijders, Jared Mauch, Jakob Heitz, Keyur Patel, Douglas Montgomery,		Mauch, Jakob Heitz, Keyur Patel, Douglas Montgomery, Randy Bush,
	Randy Bush, Susan Hares, John Scudder, Curtis Villamizar, Danny		Susan Hares, John Scudder, Curtis Villamizar, Danny McPherson, Chris
	McPherson, Chris Morrow, Tom Petch, Ilya Varlashkin, Enke Chen, Tony		Morrow, Tom Petch, Ilya Varlashkin, Enke Chen, Tony Li, Florian
	Li, Florian Weimer, John Leslie, Paul Jakma, Rob Austein, Russ		Weimer, John Leslie, Paul Jakma, Rob Austein, Russ Housley, Sandra
	Housley, Sandra Murphy, Steve Bellovin, Steve Kent, Steve Padgett,		Murphy, Steve Bellovin, Steve Kent, Steve Padgett, Alfred Hoenes, and
	Alfred Hoenes, and Alvaro Retana for comments and suggestions.		Alvaro Retana for comments and suggestions.
	8. References		9. References
	8.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>.
	[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A		[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
	Border Gateway Protocol 4 (BGP-4)", RFC 4271,		Border Gateway Protocol 4 (BGP-4)", RFC 4271,
	DOI 10.17487/RFC4271, January 2006,		DOI 10.17487/RFC4271, January 2006,
	<https://www.rfc-editor.org/info/rfc4271>.		<https://www.rfc-editor.org/info/rfc4271>.
	[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous		[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous
	System Confederations for BGP", RFC 5065,		System Confederations for BGP", RFC 5065,
	DOI 10.17487/RFC5065, August 2007,		DOI 10.17487/RFC5065, August 2007,
	<https://www.rfc-editor.org/info/rfc5065>.		<https://www.rfc-editor.org/info/rfc5065>.
	8.2. Informative References		9.2. Informative References
	[Analysis]		[Analysis]
	Hannachi, L. and K. Sriram, "Detailed analysis of AS_SETs		Hannachi, L. and K. Sriram, "Detailed analysis of AS_SETs
	in BGP updates", NIST Robust Inter-domain Routing Project		in BGP updates", NIST Robust Inter-domain Routing Project
	Website , October 2019,		Website , October 2019,
	<https://www.nist.gov/sites/default/files/		<https://www.nist.gov/sites/default/files/
	documents/2019/10/23/detailed-as_set-analysis.txt>.		documents/2019/10/23/detailed-as_set-analysis.txt>.
	[IANA-SP-ASN]		[IANA-SP-ASN]
	"Special-Purpose Autonomous System (AS) Numbers",		"Special-Purpose Autonomous System (AS) Numbers",
	skipping to change at page 7, line 4 ¶		skipping to change at page 7, line 32 ¶
	Email: warren@kumari.net		Email: warren@kumari.net
	Kotikalapudi Sriram		Kotikalapudi Sriram
	USA NIST		USA NIST
	100 Bureau Drive		100 Bureau Drive
	Gaithersburg, MD 20899		Gaithersburg, MD 20899
	US		US
	Phone: +1 301 975 3973		Phone: +1 301 975 3973
	Email: sriram.ietf@gmail.com		Email: sriram.ietf@gmail.com
	Lilia Hannachi		Lilia Hannachi
	USA NIST		USA NIST
	100 Bureau Drive		100 Bureau Drive
	Gaithersburg, MD 20899		Gaithersburg, MD 20899
	US		US
	Phone: +1 301 975 3259		Phone: +1 301 975 3259
	Email: lilia.hannachi@nist.gov		Email: lilia.hannachi@nist.gov
			Jeffrey Haas
			Juniper Networks, Inc.
			1133 Innovation Way
			Sunnyvale, CA 94089
			United States of America
			Email: jhaas@juniper.net
End of changes. 18 change blocks.
	35 lines changed or deleted		65 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/