draft-ietf-idr-bgp-open-policy-07.txt		draft-ietf-idr-bgp-open-policy-08.txt
	Network Working Group A. Azimov		Network Working Group A. Azimov
	Internet-Draft E. Bogomazov		Internet-Draft E. Bogomazov
	Intended status: Standards Track Qrator Labs		Intended status: Standards Track Qrator Labs
	Expires: July 12, 2020 R. Bush		Expires: September 10, 2020 R. Bush
	Internet Initiative Japan & Arrcus		Internet Initiative Japan & Arrcus
	K. Patel		K. Patel
	Arrcus, Inc.		Arrcus, Inc.
	K. Sriram		K. Sriram
	US NIST		US NIST
	January 9, 2020		March 9, 2020
	Route Leak Prevention using Roles in Update and Open messages		Route Leak Prevention using Roles in Update and Open messages
	draft-ietf-idr-bgp-open-policy-07		draft-ietf-idr-bgp-open-policy-08
	Abstract		Abstract
	Route leaks are the propagation of BGP prefixes which violate		Route leaks are the propagation of BGP prefixes which violate
	assumptions of BGP topology relationships; e.g. passing a route		assumptions of BGP topology relationships; e.g. passing a route
	learned from one peer to another peer or to a transit provider,		learned from one peer to another peer or to a transit provider,
	passing a route learned from one transit provider to another transit		passing a route learned from one transit provider to another transit
	provider or to a peer. Today, approaches to leak prevention rely on		provider or to a peer. Today, approaches to leak prevention rely on
	marking routes by operator configuration, with no check that the		marking routes by operator configuration, with no check that the
	configuration corresponds to that of the BGP neighbor, or enforcement		configuration corresponds to that of the BGP neighbor, or enforcement
	skipping to change at page 2, line 12 ¶		skipping to change at page 2, line 12 ¶
	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 July 12, 2020.		This Internet-Draft will expire on September 10, 2020.
	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 38 ¶		skipping to change at page 2, line 38 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Peering Relationships . . . . . . . . . . . . . . . . . . . . 3		2. Peering Relationships . . . . . . . . . . . . . . . . . . . . 3
	3. BGP Role . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. BGP Role . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. BGP Role Capability . . . . . . . . . . . . . . . . . . . . . 4		4. BGP Role Capability . . . . . . . . . . . . . . . . . . . . . 4
	5. Role correctness . . . . . . . . . . . . . . . . . . . . . . 5		5. Role correctness . . . . . . . . . . . . . . . . . . . . . . 5
	5.1. Strict mode . . . . . . . . . . . . . . . . . . . . . . . 6		5.1. Strict mode . . . . . . . . . . . . . . . . . . . . . . . 6
	6. BGP Only to Customer (OTC) Attribute . . . . . . . . . . . . 6		6. BGP Only to Customer (OTC) Attribute . . . . . . . . . . . . 6
	7. Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . 6		7. Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . 7
	8. Additional Considerations . . . . . . . . . . . . . . . . . . 7		8. Additional Considerations . . . . . . . . . . . . . . . . . . 7
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 8		10. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	12.1. Normative References . . . . . . . . . . . . . . . . . . 8		12.1. Normative References . . . . . . . . . . . . . . . . . . 8
	12.2. Informative References . . . . . . . . . . . . . . . . . 9		12.2. Informative References . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	BGP route leak occurs when a route is learned from a transit provider		A BGP route leak occurs when a route is learned from a transit
	or peer and then announced to another provider or peer. See		provider or peer and then announced to another provider or peer. See
	[RFC7908]. These are usually the result of misconfigured or absent		[RFC7908]. These are usually the result of misconfigured or absent
	BGP route filtering or lack of coordination between two BGP speakers.		BGP route filtering or lack of coordination between two BGP speakers.
	The mechanism proposed in		The mechanism proposed in
	[I-D.ietf-grow-route-leak-detection-mitigation] uses large-		[I-D.ietf-grow-route-leak-detection-mitigation] uses large-
	communities to perform detection and mitigation of route leaks.		communities to perform detection and mitigation of route leaks.
	While signaling using communities is easy to implement and deploy		While signaling using communities is easy to implement and deploy
	quickly, it normally relies on operator-maintained policy		quickly, it normally relies on operator-maintained policy
	configuration, which is often vulnerable to misconfiguration. There		configuration, which is often vulnerable to misconfiguration and even
	is also the vulnerability that the community signal may be stripped,		attack [Streibelt]. There is also the vulnerability that the
	accidentally or maliciously.		community signal may be stripped, accidentally or maliciously.
	This document provides configuration automation using 'BGP roles',		This document provides configuration automation using 'BGP roles',
	which are negotiated using a new BGP Capability Code in OPEN message		which are negotiated using a new BGP Capability Code in OPEN message
	(see Section 4 in [RFC5492]). Either or both BGP speakers MAY be		(see Section 4 in [RFC5492]). Either or both BGP speakers MAY be
	configured to require that this capability be agreed for the BGP OPEN		configured to require that this capability be agreed for the BGP OPEN
	to succeed.		to succeed.
	A new BGP Path Attribute is specified that SHOULD be automatically		A new BGP Path Attribute is specified that SHOULD be automatically
	configured using BGP roles. This attribute prevents networks from		configured using BGP roles. This attribute prevents networks from
	creating leaks, and detects leaks created by third parties.		creating leaks, and detects leaks created by third parties.
	skipping to change at page 4, line 16 ¶		skipping to change at page 4, line 16 ¶
	its customers. A peer MUST NOT send to a peer prefixes learned		its customers. A peer MUST NOT send to a peer prefixes learned
	from other peers, from its providers, or from RS(s).		from other peers, from its providers, or from RS(s).
	Of course, any BGP speaker may apply policy to reduce what is		Of course, any BGP speaker may apply policy to reduce what is
	announced, and a recipient may apply policy to reduce the set of		announced, and a recipient may apply policy to reduce the set of
	routes they accept. Violation of the above rules may result in route		routes they accept. Violation of the above rules may result in route
	leaks and MUST not be allowed. Automatic enforcement of these rules		leaks and MUST not be allowed. Automatic enforcement of these rules
	should significantly reduce route leaks that may otherwise occur due		should significantly reduce route leaks that may otherwise occur due
	to manual configuration mistakes. While enforcing the above rules		to manual configuration mistakes. While enforcing the above rules
	will address most BGP peering scenarios, their configuration is not		will address most BGP peering scenarios, their configuration is not
	part of BGP itself; therefore, additionally requiring configuration		part of BGP itself; therefore,configuration of ingress and egress
	of ingress and egress prefix filters is still strongly advised.		prefix filters is still strongly advised.
	3. BGP Role		3. BGP Role
	BGP Role is new configuration option that SHOULD be configured on		BGP Role is new configuration option that SHOULD be configured on
	each BGP session. It reflects the real-world agreement between two		each BGP session. It reflects the real-world agreement between two
	BGP speakers about their relationship.		BGP speakers about their relationship.
	Allowed Role values for eBGP sessions are:		Allowed Role values for eBGP sessions are:
	o Provider - sender is a transit provider to neighbor;		o Provider - sender is a transit provider to neighbor;
	skipping to change at page 5, line 47 ¶		skipping to change at page 5, line 47 ¶
	| Customer | Provider |		| Customer | Provider |
	| RS | RS-Client |		| RS | RS-Client |
	| RS-Client | RS |		| RS-Client | RS |
	| Peer | Peer |		| Peer | Peer |
	+-------------+---------------+		+-------------+---------------+
	Table 2: Allowed Role Capabilities		Table 2: Allowed Role Capabilities
	If the observed Role pair is not in the above table, then the		If the observed Role pair is not in the above table, then the
	receiving speaker MUST send a Role Mismatch Notification (code 2,		receiving speaker MUST send a Role Mismatch Notification (code 2,
	subcode <TBD2>).		subcode <TBD2>) and reset the BGP session.
	5.1. Strict mode		5.1. Strict mode
	A new BGP configuration option "strict mode" is defined with values		A new BGP configuration option "strict mode" is defined with values
	of true or false. If set to true, then the speaker MUST refuse to		of true or false. If set to true, then the speaker MUST refuse to
	establish a BGP session with a neighbor which does not announce the		establish a BGP session with a neighbor which does not announce the
	BGP Role capability in the OPEN message. If a speaker rejects a		BGP Role capability in the OPEN message. If a speaker rejects a
	connection, it MUST send a Connection Rejected Notification [RFC4486]		connection, it MUST send a Connection Rejected Notification [RFC4486]
	(Notification with error code 6, subcode 5). By default, strict mode		(Notification with error code 6, subcode 5). By default, strict mode
	SHOULD be set to false for backward compatibility with BGP speakers		SHOULD be set to false for backward compatibility with BGP speakers
	that do not yet support this mechanism.		that do not yet support this mechanism.
	6. BGP Only to Customer (OTC) Attribute		6. BGP Only to Customer (OTC) Attribute
	Newly defined here, the Only to Customer (OTC) is an optional,		Newly defined here, the Only to Customer (OTC) is an optional, 4 byte
	transitive BGP Path attribute with the Type Code <TBD3>. The OTC		long, transitive BGP Path attribute with the Type Code <TBD3>. The
	attribute is four bytes long and its value equals an AS number. The		purpose of this attribute is to guarantee that once route is sent to
			customer, peer or RS-client it will go only to customers. The
	semantics and usage of the OTC attribute are made clear by the		semantics and usage of the OTC attribute are made clear by the
	ingress and egress policies described below.		ingress and egress policies described below.
	The following ingress policy applies to the OTC attribute:		The following ingress policy applies to the OTC attribute:
	1. If a route with OTC attribute is received from a Customer or RS-		1. If a route with OTC attribute is received from a Customer or RS-
	client, then it is a route leak and MUST be rejected.		client, then it is a route leak and MUST be rejected.
	2. If a route with OTC attribute is received from a Peer and its		2. If a route with OTC attribute is received from a Peer and its
	value is not equal to the neighbor's ASN, then it is a route leak		value is not equal to the neighbor's ASN, then it is a route leak
	skipping to change at page 6, line 42 ¶		skipping to change at page 6, line 43 ¶
	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 value equal		attribute is not present, then it MUST be added with value equal
	to the neighbor's AS number.		to the neighbor's AS number.
	The egress policy MUST be:		The egress policy MUST be:
	1. A route with the OTC attribute set MUST NOT be sent to providers,		1. A route with the OTC attribute set MUST NOT be sent to providers,
	peers, or RS(s).		peers, or RS(s).
	2. If route is sent to a customer or peer, or an RS clien and the		2. If route is sent to a customer or peer, or an RS-Client and the
	OTC attribute is not present, then it MUST be added with value		OTC attribute is not present, then it MUST be added with value
	equal to AS number of the sender.		equal to AS number of the sender.
	Once the OTC attribute has been set, it MUST be preserved unchanged.		Once the OTC attribute has been set, it MUST be preserved unchanged.
	7. Enforcement		7. Enforcement
	Having the relationship unequivocally agreed between the two peers in		Having the relationship unequivocally agreed between the two peers in
	BGP OPEN is critical; BGP implementations MUST enforce the		BGP OPEN is critical; BGP implementations MUST enforce the
	relationship/role establishment rules (see Section 5) in order to		relationship/role establishment rules (see Section 5) in order to
	skipping to change at page 7, line 28 ¶		skipping to change at page 7, line 33 ¶
	There are peering relationships that are 'complex', i.e., both		There are peering relationships that are 'complex', i.e., both
	parties are intentionally sending prefixes received from each other		parties are intentionally sending prefixes received from each other
	to their non-transit peers and/or transit providers. If multiple BGP		to their non-transit peers and/or transit providers. If multiple BGP
	peerings can segregate the 'complex' parts of the relationship, the		peerings can segregate the 'complex' parts of the relationship, the
	complex peering roles can be segregated into different normal BGP		complex peering roles can be segregated into different normal BGP
	sessions, and BGP Roles MUST be used on each of the resulting normal		sessions, and BGP Roles MUST be used on each of the resulting normal
	(non-complex) BGP sessions.		(non-complex) BGP sessions.
	No Roles SHOULD be configured on a 'complex' BGP session (assuming it		No Roles SHOULD be configured on a 'complex' BGP session (assuming it
	is not segregated) and in that case, OTC MUST be set by configuration		is not segregated) and in that case, OTC MUST be set by configuration
	on a per-prefix basis. However, there can be no measures to check		on a per-prefix basis. However, there are no built-in measures to
	correctness of OTC use if BGP Role is not configured.		check correctness of OTC use if BGP Role is not configured.
	As the BGP Role reflects the peering relationship between neighbors,		As the BGP Role reflects the peering relationship between neighbors,
	it might have other uses beyond the route leaks solution discussed so		it might have other uses beyond the route leaks solution discussed so
	far. For example, BGP Role might affect route priority, or be used		far. For example, BGP Role might affect route priority, or be used
	to distinguish borders of a network if a network consists of multiple		to distinguish borders of a network if a network consists of multiple
	ASs. Though such uses may be worthwhile, they are not the goal of		ASs. Though such uses may be worthwhile, they are not the goal of
	this document. Note that such uses would require local policy		this document. Note that such uses would require local policy
	control.		control.
	As BGP role configuration results in automatic creation of inbound/		As BGP role configuration results in automatic creation of inbound/
	skipping to change at page 8, line 25 ¶		skipping to change at page 8, line 30 ¶
	option, named "Only to Customer (OTC)" with an assigned value <TBD3>		option, named "Only to Customer (OTC)" with an assigned value <TBD3>
	[To be removed upon publication: http://www.iana.org/assignments/bgp-		[To be removed upon publication: http://www.iana.org/assignments/bgp-
	parameters/bgp-parameters.xhtml#bgp-parameters-2] [RFC4271]. The		parameters/bgp-parameters.xhtml#bgp-parameters-2] [RFC4271]. The
	length of this attribute is four bytes.		length of this attribute is four bytes.
	10. Security Considerations		10. Security Considerations
	This document proposes a mechanism for prevention of route leaks that		This document proposes a mechanism for prevention of route leaks that
	are the result of BGP policy mis-configuration.		are the result of BGP policy mis-configuration.
	Deliberate sending of a known conflicting BGP Role could be used to
	sabotage a BGP connection. This is easily detectable.
	A misconfiguration in OTC setup may affect prefix propagation. But		A misconfiguration in OTC setup may affect prefix propagation. But
	the automation that is provided by BGP roles should make such		the automation that is provided by BGP roles should make such
	misconfiguration unlikely.		misconfiguration unlikely.
	11. Acknowledgments		11. Acknowledgments
	The authors wish to thank Douglas Montgomery, Brian Dickson, Andrei		The authors wish to thank Douglas Montgomery, Brian Dickson, Andrei
	Robachevsky, and Daniel Ginsburg for their contributions to a variant		Robachevsky, and Daniel Ginsburg for their contributions to a variant
	of this work.		of this work.
	skipping to change at page 9, line 46 ¶		skipping to change at page 10, line 5 ¶
	[RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E.,		[RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E.,
	and B. Dickson, "Problem Definition and Classification of		and B. Dickson, "Problem Definition and Classification of
	BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June		BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June
	2016, <https://www.rfc-editor.org/info/rfc7908>.		2016, <https://www.rfc-editor.org/info/rfc7908>.
	[RFC8212] Mauch, J., Snijders, J., and G. Hankins, "Default External		[RFC8212] Mauch, J., Snijders, J., and G. Hankins, "Default External
	BGP (EBGP) Route Propagation Behavior without Policies",		BGP (EBGP) Route Propagation Behavior without Policies",
	RFC 8212, DOI 10.17487/RFC8212, July 2017,		RFC 8212, DOI 10.17487/RFC8212, July 2017,
	<https://www.rfc-editor.org/info/rfc8212>.		<https://www.rfc-editor.org/info/rfc8212>.
			[Streibelt]
			Streibelt, F., Lichtblau, F., Beverly, R., Feldmann, A.,
			Cristel, C., Smaragdakis, G., and R. Bush, "BGP
			Communities: Even more Worms in the Routing Can",
			<https://people.mpi-inf.mpg.de/~fstreibelt/preprint/
			communities-imc2018.pdf>.
	Authors' Addresses		Authors' Addresses
	Alexander Azimov		Alexander Azimov
	Qrator Labs		Qrator Labs
	Email: a.e.azimov@gmail.com		Email: a.e.azimov@gmail.com
	Eugene Bogomazov		Eugene Bogomazov
	Qrator Labs		Qrator Labs
	Email: eb@qrator.net		Email: eb@qrator.net
	Randy Bush		Randy Bush
	Internet Initiative Japan & Arrcus		Internet Initiative Japan & Arrcus
	Email: randy@psg.com		Email: randy@psg.com
End of changes. 16 change blocks.
	23 lines changed or deleted		29 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/