draft-ietf-idr-bgp-open-policy-18.txt		draft-ietf-idr-bgp-open-policy-19.txt
	Network Working Group A. Azimov		Network Working Group A. Azimov
	Internet-Draft Qrator Labs & Yandex		Internet-Draft Qrator Labs & Yandex
	Intended status: Standards Track E. Bogomazov		Intended status: Standards Track E. Bogomazov
	Expires: June 7, 2022 Qrator Labs		Expires: July 11, 2022 Qrator Labs
	R. Bush		R. Bush
	Internet Initiative Japan & Arrcus, Inc.		Internet Initiative Japan & Arrcus, Inc.
	K. Patel		K. Patel
	Arrcus		Arrcus
	K. Sriram		K. Sriram
	USA NIST		USA NIST
	December 4, 2021		January 7, 2022
	Route Leak Prevention and Detection using Roles in UPDATE and OPEN		Route Leak Prevention and Detection using Roles in UPDATE and OPEN
	Messages		Messages
	draft-ietf-idr-bgp-open-policy-18		draft-ietf-idr-bgp-open-policy-19
	Abstract		Abstract
	Route leaks are the propagation of BGP prefixes that violate		Route leaks are the propagation of BGP prefixes that violate
	assumptions of BGP topology relationships, e.g., announcing a route		assumptions of BGP topology relationships, e.g., announcing a route
	learned from one transit provider to another transit provider or a		learned from one transit provider to another transit provider or a
	lateral (i.e., non-transit) peer or announcing a route learned from		lateral (i.e., non-transit) peer or announcing a route learned from
	one lateral peer to another lateral peer or a transit provider.		one lateral peer to another lateral peer or a transit provider.
	These are usually the result of misconfigured or absent BGP route		These are usually the result of misconfigured or absent BGP route
	filtering or lack of coordination between autonomous systems (ASes).		filtering or lack of coordination between autonomous systems (ASes).
	skipping to change at page 2, line 20 ¶		skipping to change at page 2, line 20 ¶
	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 June 7, 2022.		This Internet-Draft will expire on July 11, 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 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 . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Peering Relationships . . . . . . . . . . . . . . . . . . . . 4		2. Peering Relationships . . . . . . . . . . . . . . . . . . . . 4
	3. BGP Role . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. BGP Role . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. BGP Role Capability . . . . . . . . . . . . . . . . . . . 5		3.1. BGP Role Capability . . . . . . . . . . . . . . . . . . . 5
	3.2. Role Correctness . . . . . . . . . . . . . . . . . . . . 6		3.2. Role Correctness . . . . . . . . . . . . . . . . . . . . 6
	4. BGP Only to Customer (OTC) Attribute . . . . . . . . . . . . 7		4. BGP Only to Customer (OTC) Attribute . . . . . . . . . . . . 7
	5. Additional Considerations . . . . . . . . . . . . . . . . . . 8		5. Additional Considerations . . . . . . . . . . . . . . . . . . 9
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 10		7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	8.1. Normative References . . . . . . . . . . . . . . . . . . 11		8.1. Normative References . . . . . . . . . . . . . . . . . . 11
	8.2. Informative References . . . . . . . . . . . . . . . . . 11		8.2. Informative References . . . . . . . . . . . . . . . . . 12
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12
	Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12		Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	Route leaks are the propagation of BGP prefixes that violate		Route leaks are the propagation of BGP prefixes that violate
	assumptions of BGP topology relationships, e.g., announcing a route		assumptions of BGP topology relationships, e.g., announcing a route
	learned from one transit provider to another transit provider or a		learned from one transit provider to another transit provider or a
	lateral (i.e., non-transit) peer or announcing a route learned from		lateral (i.e., non-transit) peer or announcing a route learned from
	skipping to change at page 4, line 35 ¶		skipping to change at page 4, line 35 ¶
	Route Server (RS): MAY propagate any available route to a Route		Route Server (RS): MAY propagate any available route to a Route
	Server Client (RS-Client).		Server Client (RS-Client).
	RS-Client: MAY propagate any route learned from a Customer, or		RS-Client: MAY propagate any route learned from a Customer, or
	locally originated, to an RS. All other routes MUST NOT be		locally originated, to an RS. All other routes MUST NOT be
	propagated.		propagated.
	Peer: MAY propagate any route learned from a Customer, or locally		Peer: MAY propagate any route learned from a Customer, or locally
	originated, to a Peer. All other routes MUST NOT be propagated.		originated, to a Peer. All other routes MUST NOT be propagated.
			If the local AS has one of the above Roles (in the order shown), then
			the corresponding peering relationship with the remote AS is
			Provider-to-Customer, Customer-to-Provider, RS-to-RS-Client, RS-
			Client-to-RS, or Peer-to-Peer (i.e., lateral peers), respectively.
			These are called normal peering relationships.
			If the local AS has more than one peering role with the remote AS
			such peering relation is called Complex. An example is when the
			peering relationship is Provider-to-Customer for some prefixes while
			it is Peer-to-Peer for other prefixes [Gao].
	A BGP speaker may apply policy to reduce what is announced, and a		A BGP speaker may apply policy to reduce what is announced, and a
	recipient may apply policy to reduce the set of routes they accept.		recipient may apply policy to reduce the set of routes they accept.
	Violation of the above rules may result in route leaks. Automatic		Violation of the above rules may result in route leaks. Automatic
	enforcement of these rules should significantly reduce route leaks		enforcement of these rules should significantly reduce route leaks
	that may otherwise occur due to manual configuration mistakes.		that may otherwise occur due to manual configuration mistakes.
	As specified in Section 4, the Only to Customer (OTC) Attribute is		As specified in Section 4, the Only to Customer (OTC) Attribute is
	used to identify all the routes in the AS that have been received		used to identify all the routes in the AS that have been received
	from a Peer, Provider, or RS.		from a Peer, Provider, or RS.
	3. BGP Role		3. BGP Role
	The BGP Role characterizes the relationship between the eBGP speakers		The BGP Role characterizes the relationship between the eBGP speakers
	forming a session. One of the Roles described below SHOULD be		forming a session. One of the Roles described below SHOULD be
	configured at the local AS for each eBGP session (see definitions in		configured at the local AS for each eBGP session (see definitions in
	Section 1.1) based on the local AS's knowledge of its Role. The only		Section 1.1) based on the local AS's knowledge of its Role. The only
	exception is when the eBGP connection is 'complex' (see Section 5).		exception is when the eBGP connection is Complex (see Section 5).
	BGP Roles are mutually confirmed using the BGP Role Capability		BGP Roles are mutually confirmed using the BGP Role Capability
	(described in Section 3.1) on each eBGP session.		(described in Section 3.1) on each eBGP session.
	Allowed Roles for eBGP sessions are:		Allowed Roles for eBGP sessions are:
	o Provider - the local AS is a transit Provider of the remote AS;		o Provider - the local AS is a transit Provider of the remote AS;
	o Customer - the local AS is a transit Customer of the remote AS;		o Customer - the local AS is a transit Customer of the remote AS;
	o RS - the local AS is a Route Server (usually at an Internet		o RS - the local AS is a Route Server (usually at an Internet
	skipping to change at page 6, line 15 ¶		skipping to change at page 6, line 32 ¶
	3.2. Role Correctness		3.2. Role Correctness
	Section 3.1 described how BGP Role encodes the relationship on each		Section 3.1 described how BGP Role encodes the relationship on each
	eBGP session between autonomous systems (ASes).		eBGP session between autonomous systems (ASes).
	The mere receipt of BGP Role Capability does not automatically		The mere receipt of BGP Role Capability does not automatically
	guarantee the Role agreement between two eBGP neighbors. If the BGP		guarantee the Role agreement between two eBGP neighbors. If the BGP
	Role Capability is advertised, and one is also received from the		Role Capability is advertised, and one is also received from the
	peer, the roles MUST correspond to the relationships in Table 2. If		peer, the roles MUST correspond to the relationships in Table 2. If
	the roles do not correspond, the BGP speaker MUST reject the		the roles do not correspond, the BGP speaker MUST reject the
	connection using the Role Mismatch Notification (code 2, subcode 8).		connection using the Role Mismatch Notification (code 2, subcode
			TBD).
	+---------------+----------------+		+---------------+----------------+
	| Local AS Role | Remote AS Role |		| Local AS Role | Remote AS Role |
	+---------------+----------------+		+---------------+----------------+
	| Provider | Customer |		| Provider | Customer |
	| Customer | Provider |		| Customer | Provider |
	| RS | RS-Client |		| RS | RS-Client |
	| RS-Client | RS |		| RS-Client | RS |
	| Peer | Peer |		| Peer | Peer |
	+---------------+----------------+		+---------------+----------------+
	skipping to change at page 6, line 39 ¶		skipping to change at page 7, line 9 ¶
	For backward compatibility, if the BGP Role Capability is sent but		For backward compatibility, if the BGP Role Capability is sent but
	one is not received, the BGP Speaker SHOULD ignore the absence of the		one is not received, the BGP Speaker SHOULD ignore the absence of the
	BGP Role Capability and proceed with session establishment. The		BGP Role Capability and proceed with session establishment. The
	locally configured BGP Role is used for the procedures described in		locally configured BGP Role is used for the procedures described in
	Section 4.		Section 4.
	An operator may choose to apply a "strict mode" in which the receipt		An operator may choose to apply a "strict mode" in which the receipt
	of a BGP Role Capability from the remote AS is required. When		of a BGP Role Capability from the remote AS is required. When
	operating in the "strict mode", if the BGP Role Capability is sent,		operating in the "strict mode", if the BGP Role Capability is sent,
	but one is not received, then the connection is rejected using the		but one is not received, then the connection is rejected using the
	Role Mismatch Notification (code 2, subcode 8). See comments in		Role Mismatch Notification (code 2, subcode TBD). See comments in
	Section 7.		Section 7.
	If an eBGP speaker receives multiple but identical BGP Role		If an eBGP speaker receives multiple but identical BGP Role
	Capabilities with the same value in each, then the speaker must		Capabilities with the same value in each, then the speaker must
	consider it to be a single BGP Role Capability and proceed [RFC5492].		consider it to be a single BGP Role Capability and proceed [RFC5492].
	If multiple BGP Role Capabilities are received and not all of them		If multiple BGP Role Capabilities are received and not all of them
	have the same value, then the BGP speaker MUST reject the connection		have the same value, then the BGP speaker MUST reject the connection
	using the Role Mismatch Notification (code 2, subcode 8).		using the Role Mismatch Notification (code 2, subcode TBD).
	The BGP Role value for the local AS is used in the route leak		The BGP Role value for the local AS (in conjunction with the OTC
			Attribute in the received UPDATE message) is used in the route leak
	prevention and detection procedures described in Section 4.		prevention and detection procedures described in Section 4.
	4. BGP Only to Customer (OTC) Attribute		4. BGP Only to Customer (OTC) Attribute
	The Only to Customer (OTC) Attribute is an optional transitive path		The Only to Customer (OTC) Attribute is an optional transitive path
	attribute with Attribute Type Code 35 and a length of 4 octets. The		attribute of the UPDATE message with Attribute Type Code 35 and a
	purpose of this attribute is to guarantee that once a route is sent		length of 4 octets. The purpose of this attribute is to guarantee
	to a Customer, Peer, or RS-Client, it will subsequently go only to		that once a route is sent to a Customer, Peer, or RS-Client, it will
	Customers. The attribute value is an AS number (ASN) determined by		subsequently go only to Customers. The attribute value is an AS
	the policy described below.		number (ASN) determined by the policy described below.
	The following ingress policy applies to the processing of the OTC		The following ingress policy applies to the processing of the OTC
	Attribute:		Attribute:
	1. If a route with the OTC Attribute is received from a Customer or		1. If a route with the OTC Attribute is received from a Customer or
	RS-Client, then it is a route leak and MUST be considered		RS-Client, then it is a route leak and MUST be considered
	ineligible (see Section 1.1).		ineligible (see Section 1.1).
	2. If a route with the OTC Attribute is received from a Peer and at		2. If a route with the OTC Attribute is received from a Peer and the
	least one of the OTC Attributes has a value that is not equal to		Attribute has a value that is not equal to the remote (i.e.,
	the remote (i.e., Peer's) AS number, then it is a route leak and		Peer's) AS number, then it is a route leak and MUST be considered
	MUST be considered ineligible.		ineligible.
	3. If a route is received from a Provider, Peer, or RS, and the OTC		3. If a route is received from a Provider, Peer, or RS, and the OTC
	Attribute is not present, then it MUST be added with a value		Attribute is not present, then it MUST be added with a value
	equal to the AS number of the remote AS.		equal to the AS number of the remote AS.
	The following egress policy applies to the processing of the OTC		The following egress policy applies to the processing of the OTC
	Attribute:		Attribute:
	1. If a route is to be advertised to a Customer, Peer, or RS-Client		1. If a route is to be advertised to a Customer, Peer, or RS-Client
	(when the sender is an RS), and the OTC Attribute is not present,		(when the sender is an RS), and the OTC Attribute is not present,
	skipping to change at page 8, line 30 ¶		skipping to change at page 8, line 47 ¶
	The procedures specified in this document in scenarios that use		The procedures specified in this document in scenarios that use
	private AS numbers behind an Internet-facing ASN (e.g., a data center		private AS numbers behind an Internet-facing ASN (e.g., a data center
	network [RFC7938] or stub customer) may be used, but any details are		network [RFC7938] or stub customer) may be used, but any details are
	outside the scope of this document. On egress from the Internet-		outside the scope of this document. On egress from the Internet-
	facing AS, the OTC Attribute MUST NOT contain a value other than the		facing AS, the OTC Attribute MUST NOT contain a value other than the
	Internet-facing ASN.		Internet-facing ASN.
	Once the OTC Attribute has been set, it MUST be preserved unchanged		Once the OTC Attribute has been set, it MUST be preserved unchanged
	(this also applies to an AS Confederation).		(this also applies to an AS Confederation).
	Correct implementation of the procedures specified in this document
	is not expected to result in the presence of multiple OTC Attributes
	in an UPDATE. However, if an eBGP speaker receives multiple OTC
	Attributes with a route, then the only difference in the processing
	is in Step 2 of the ingress policy.
	The described ingress and egress policies are applicable only for		The described ingress and egress policies are applicable only for
	unicast IPv4 and IPv6 address families and MUST NOT be applied to		unicast IPv4 and IPv6 address families and MUST NOT be applied to
	other address families by default. The operator MUST NOT have the		other address families by default. The operator MUST NOT have the
	ability to modify the policies defined in this section.		ability to modify the policies defined in this section.
	5. Additional Considerations		5. Additional Considerations
	There are peering relationships that are 'complex', i.e., both		Roles MUST NOT be configured on an eBGP session with a Complex
	parties intentionally advertise prefixes received from each other to		peering relationship. If multiple eBGP sessions can segregate the
	their Peers and/or transit Providers. If multiple eBGP sessions can		Complex peering relationship into eBGP sessions with normal peering
	segregate the 'complex' parts of the relationship, then the complex		relationships, BGP Roles SHOULD be used on each of the resulting eBGP
	peering roles can be segregated into different normal eBGP sessions,		sessions.
	and BGP Roles MUST be used on each of the resulting normal (non-
	complex) eBGP sessions.
	No Roles SHOULD be configured on a 'complex' eBGP session (assuming		An operator may want to achieve an equivalent outcome by configuring
	it is not segregated). An operator may want to achieve an equivalent		policies on a per-prefix basis to follow the definitions of peering
	outcome by configuring policies on a per-prefix basis to follow the		relations as described in Section 2. However, in this case, there
	definitions of peering relations as described in Section 2. However,		are no built-in measures to check the correctness of the per-prefix
	in this case, there are no built-in measures to check the correctness		peering configuration.
	of the per-prefix peering configuration.
	The incorrect setting of BGP Roles and/or OTC Attributes may affect		The incorrect setting of BGP Roles and/or OTC Attributes may affect
	prefix propagation. Further, this document does not specify any		prefix propagation. Further, this document does not specify any
	special handling of incorrect AS numbers in the OTC Attribute.		special handling of incorrect AS numbers in the OTC Attribute.
	6. IANA Considerations		6. IANA Considerations
	IANA has registered a new BGP Capability (Section 3.1) in the		IANA has registered a new BGP Capability (Section 3.1) in the
	"Capability Codes" registry's "IETF Review" range [RFC5492]. The		"Capability Codes" registry's "IETF Review" range [RFC5492]. The
	description for the new capability is "BGP Role". IANA has assigned		description for the new capability is "BGP Role". IANA has assigned
	skipping to change at page 9, line 48 ¶		skipping to change at page 10, line 7 ¶
	| 2 | RS-Client | This document |		| 2 | RS-Client | This document |
	| 3 | Customer | This document |		| 3 | Customer | This document |
	| 4 | Peer (i.e., Lateral Peer) | This document |		| 4 | Peer (i.e., Lateral Peer) | This document |
	| 5-255 | To be assigned by IETF Review |		| 5-255 | To be assigned by IETF Review |
	+-------+--------------------------------+---------------+		+-------+--------------------------------+---------------+
	Table 3: IANA Registry for BGP Role		Table 3: IANA Registry for BGP Role
	IANA has registered a new OPEN Message Error subcode named the "Role		IANA has registered a new OPEN Message Error subcode named the "Role
	Mismatch" (see Section 3.2) in the OPEN Message Error subcodes		Mismatch" (see Section 3.2) in the OPEN Message Error subcodes
	registry. IANA has assigned the value 8 [to be removed upon		registry. IANA has assigned the value TBD [to be removed upon
	publication: https://www.iana.org/assignments/bgp-parameters/bgp-		publication: https://www.iana.org/assignments/bgp-parameters/bgp-
	parameters.xhtml#bgp-parameters-6]. This document is the reference		parameters.xhtml#bgp-parameters-6]. This document is the reference
	for the new subcode.		for the new subcode.
	IANA has also registered a new path attribute named "Only to Customer		IANA has also registered a new path attribute named "Only to Customer
	(OTC)" (see Section 4) in the "BGP Path Attributes" registry. IANA		(OTC)" (see Section 4) in the "BGP Path Attributes" registry. IANA
	has assigned code value 35 [To be removed upon publication:		has assigned code value 35 [To be removed upon publication:
	http://www.iana.org/assignments/bgp-parameters/bgp-		http://www.iana.org/assignments/bgp-parameters/bgp-
	parameters.xhtml#bgp-parameters-2]. This document is the reference		parameters.xhtml#bgp-parameters-2]. This document is the reference
	for the new attribute.		for the new attribute.
End of changes. 20 change blocks.
	43 lines changed or deleted		46 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/