draft-ietf-grow-bgp-reject-08.txt		rfc8212.txt
	Global Routing Operations J. Mauch		Internet Engineering Task Force (IETF) J. Mauch
	Internet-Draft Akamai		Request for Comments: 8212 Akamai
	Updates: 4271 (if approved) J. Snijders		Updates: 4271 J. Snijders
	Intended status: Standards Track NTT		Category: Standards Track NTT
	Expires: November 25, 2017 G. Hankins		ISSN: 2070-1721 G. Hankins
	Nokia		Nokia
	May 24, 2017		July 2017
	Default EBGP Route Propagation Behavior Without Policies		Default External BGP (EBGP) Route Propagation Behavior without Policies
	draft-ietf-grow-bgp-reject-08
	Abstract		Abstract
	This document updates RFC4271 by defining the default behavior of a		This document updates RFC 4271 by defining the default behavior of a
	BGP speaker when there is no Import or Export Policy associated with		BGP speaker when there is no Import or Export Policy associated with
	an External BGP session.		an External BGP session.
	Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on November 25, 2017.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			http://www.rfc-editor.org/info/rfc8212.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Changes to RFC4271 . . . . . . . . . . . . . . . . . . . . . 3		2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4		3. Changes to RFC 4271 . . . . . . . . . . . . . . . . . . . . . 3
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 4		4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
	7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 4		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5		6.1. Normative References . . . . . . . . . . . . . . . . . . 4
	8.1. Normative References . . . . . . . . . . . . . . . . . . 5		6.2. Informative References . . . . . . . . . . . . . . . . . 5
	8.2. Informative References . . . . . . . . . . . . . . . . . 5		Appendix A. Transition Considerations for BGP Implementers . . . 6
	Appendix A. Transition Considerations for BGP Implementers . . . 5		A.1. "N+1 N+2" Release Strategy . . . . . . . . . . . . . . . 6
	A.1. "N+1 N+2" Release Strategy . . . . . . . . . . . . . . . 5		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6		Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 7
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	BGP routing security issues need to be addressed in order to make the		BGP routing security issues need to be addressed in order to make the
	Internet more stable. Route leaks [RFC7908] are part of the problem,		Internet more stable. Route leaks [RFC7908] are part of the problem,
	but software defects or operator misconfiguration can contribute too.		but software defects or operator misconfiguration can also
	This document updates [RFC4271] so that routes are neither imported		contribute. This document updates [RFC4271] so that routes are
	nor exported unless specifically enabled by configuration. This		neither imported nor exported unless specifically enabled by
	change reduces the consequences of these problems, and improves the		configuration. This change reduces the consequences of these
	default level of Internet routing security.		problems and improves the default level of Internet routing security.
	Many deployed BGP speakers send and accept any and all route		Many deployed BGP speakers send and accept any and all route
	announcements between their BGP neighbors by default. This practice		announcements between their BGP neighbors by default. This practice
	dates back to the early days of the Internet, where operators were		dates back to the early days of the Internet, where operators were
	permissive in sending routing information to allow all networks to		permissive in sending routing information to allow all networks to
	reach each other. As the Internet has become more densely		reach each other. As the Internet has become more densely
	interconnected, the risk of a misbehaving BGP speaker poses		interconnected, the risk of a misbehaving BGP speaker poses
	significant risks to Internet routing.		significant risks to Internet routing.
	This specification intends to improve this situation by requiring the		This specification intends to improve this situation by requiring the
	explicit configuration of both BGP Import and Export Policies for any		explicit configuration of both BGP Import and Export Policies for any
	External BGP (EBGP) session such as customers, peers, or		External BGP (EBGP) session such as customers, peers, or
	confederation boundaries for all enabled address families. Through		confederation boundaries for all enabled address families. Through
	codification of the aforementioned requirement, operators will		codification of the aforementioned requirement, operators will
	benefit from consistent behaviour across different BGP		benefit from consistent behavior across different BGP
	implementations.		implementations.
	BGP speakers following this specification do not use or send routes		BGP speakers following this specification do not use or send routes
	on EBGP sessions, unless specifically configured to do so.		on EBGP sessions, unless specifically configured to do so.
	2. Terminology		2. Terminology
	[RFC4271] describes a Policy Information Base (PIB) which contains		[RFC4271] describes a Policy Information Base (PIB) that contains
	local policies that can be applied to the information in the Routing		local policies that can be applied to the information in the Routing
	Information Base (RIB). This document distinguishes the type of a		Information Base (RIB). This document distinguishes the type of a
	policy based on its application.		policy based on its application.
	Import Policy: a local policy to be applied to the information		Import Policy: a local policy to be applied to the information
	contained in the Adj-RIBs-In. As described in Section 3.2 [RFC4271],		contained in the Adj-RIBs-In. As described in Section 3.2 [RFC4271],
	the Adj-RIBs-In contain information learned from other BGP speakers,		the Adj-RIBs-In contain information learned from other BGP speakers,
	and the application of the Import Policy results in the routes that		and the application of the Import Policy results in the routes that
	will be considered in the Decision Process by the local BGP speaker.		will be considered in the Decision Process by the local BGP speaker.
	Export Policy: a local policy to be applied in selecting the		Export Policy: a local policy to be applied in selecting the
	information contained in the Adj-RIBs-Out. As described in		information contained in the Adj-RIBs-Out. As described in
	Section 3.2 [RFC4271], the Adj-RIBs-Out contain information that has		Section 3.2 [RFC4271], the Adj-RIBs-Out contain information that has
	been selected for advertisement to other BGP speakers.		been selected for advertisement to other BGP speakers.
	3. Changes to RFC4271		2.1. Requirements Language
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
			"OPTIONAL" in this document are to be interpreted as described in
			BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
			3. Changes to RFC 4271
	This section updates [RFC4271] to specify the default behavior of a		This section updates [RFC4271] to specify the default behavior of a
	BGP speaker when there are no Import or Export Policies associated		BGP speaker when there are no Import or Export Policies associated
	with a particular EBGP session. A BGP speaker MAY provide a		with a particular EBGP session. A BGP speaker MAY provide a
	configuration option to deviate from the following updated behaviors.		configuration option to deviate from the following updated behaviors.
	The following paragraph is added to Section 9.1 (Decision Process)		The following paragraph is added to Section 9.1 (Decision Process)
	after the fifth paragraph, which ends in "route aggregation and route		after the fifth paragraph, which ends in "route aggregation and route
	information reduction":		information reduction":
	skipping to change at page 4, line 5 ¶		skipping to change at page 4, line 5 ¶
	SHALL NOT be considered eligible in the Decision Process if no		SHALL NOT be considered eligible in the Decision Process if no
	explicit Import Policy has been applied.		explicit Import Policy has been applied.
	The following paragraph is added to Section 9.1.3 (Phase 3: Route		The following paragraph is added to Section 9.1.3 (Phase 3: Route
	Dissemination) after the third paragraph, which ends in "by means of		Dissemination) after the third paragraph, which ends in "by means of
	an UPDATE message (see 9.2).":		an UPDATE message (see 9.2).":
	Routes SHALL NOT be added to an Adj-RIB-Out associated with an		Routes SHALL NOT be added to an Adj-RIB-Out associated with an
	EBGP peer if no explicit Export Policy has been applied.		EBGP peer if no explicit Export Policy has been applied.
	4. Acknowledgments		4. Security Considerations
	The authors would like to thank the following people for their
	comments, support and review: Shane Amante, Christopher Morrow,
	Robert Raszuk, Greg Skinner, Adam Chappell, Sriram Kotikalapudi,
	Brian Dickson, Jeffrey Haas, John Heasley, Ignas Bagdonas, Donald
	Smith, Dale Worley, Alvaro Retana, John Scudder, and Dale Worley.
	5. Security Considerations
	Permissive default routing policies can result in inadvertent effects		Permissive default routing policies can result in inadvertent effects
	such as route leaks [RFC7908], in general resulting in routing of		such as route leaks [RFC7908], in general resulting in routing of
	traffic through an unexpected path. While it is possible for an		traffic through an unexpected path. While it is possible for an
	operator to use monitoring to detect unexpected flows, there is no		operator to use monitoring to detect unexpected flows, there is no
	general framework that can be applied. These policies also have the		general framework that can be applied. These policies also have the
	potential to expose software defects or misconfiguration that could		potential to expose software defects or misconfiguration that could
	have unforeseen technical and business impacting effects.		have unforeseen technical and business impacting effects.
	The update to [RFC4271] specified in this document is intended to		The update to [RFC4271] specified in this document is intended to
	eliminate those inadvertent effects. Operators must explicitly		eliminate those inadvertent effects. Operators must explicitly
	configure Import and Export Policies to achieve their expected goals.		configure Import and Export Policies to achieve their expected goals.
	There is of course no protection against a malicious or incorrect		There is of course no protection against a malicious or incorrect
	explicit configuration.		explicit configuration.
	The security considerations described in [RFC4271] and the		The security considerations described in [RFC4271] and the
	vulnerability analysis discussed in [RFC4272] also apply to this		vulnerability analysis discussed in [RFC4272] also apply to this
	document.		document.
	6. IANA Considerations		5. IANA Considerations
	This document has no actions for IANA.
	7. Contributors
	The following people contributed to successful deployment of solution
	described in this document:
	Jakob Heitz
	Cisco
	Email: jheitz@cisco.com
	Ondrej Filip
	CZ.NIC
	Email: ondrej.filip@nic.cz		This document does not require any IANA actions.
	8. References		6. References
	8.1. Normative References		6.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,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://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,
	<http://www.rfc-editor.org/info/rfc4271>.		<http://www.rfc-editor.org/info/rfc4271>.
	8.2. Informative References		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <http://www.rfc-editor.org/info/rfc8174>.
			6.2. Informative References
	[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",		[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
	RFC 4272, DOI 10.17487/RFC4272, January 2006,		RFC 4272, DOI 10.17487/RFC4272, January 2006,
	<http://www.rfc-editor.org/info/rfc4272>.		<http://www.rfc-editor.org/info/rfc4272>.
	[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, <http://www.rfc-editor.org/info/rfc7908>.		2016, <http://www.rfc-editor.org/info/rfc7908>.
	Appendix A. Transition Considerations for BGP Implementers		Appendix A. Transition Considerations for BGP Implementers
	This appendix is non-normative.		This appendix is not normative.
	For an implementer, transitioning to a compliant BGP implementation		For an implementer, transitioning to a compliant BGP implementation
	may require a process that can take several years.		may require a process that can take several years.
	It is understood and acknowledged that operators who are taking		It is understood and acknowledged that operators who are taking
	advantage of an undefined behavior will always be surprised by		advantage of an undefined behavior will always be surprised by
	changes to said behavior.		changes to said behavior.
	A.1. "N+1 N+2" Release Strategy		A.1. "N+1 N+2" Release Strategy
	skipping to change at page 6, line 12 ¶		skipping to change at page 6, line 35 ¶
	BGP implementation become aware that a configurable default exists in		BGP implementation become aware that a configurable default exists in
	the implementation, and can prepare accordingly. In release N+2 or		the implementation, and can prepare accordingly. In release N+2 or
	later, the inverse of the previous default configuration parameter		later, the inverse of the previous default configuration parameter
	that was introduced in release N+1 becomes the new default.		that was introduced in release N+1 becomes the new default.
	As a result, any new installation of release N+2 will adhere to this		As a result, any new installation of release N+2 will adhere to this
	document. Installations upgraded from version release N+1 will		document. Installations upgraded from version release N+1 will
	adhere to the previous insecure behavior, if no modification was made		adhere to the previous insecure behavior, if no modification was made
	to the "ebgp insecure-mode" configuration parameter.		to the "ebgp insecure-mode" configuration parameter.
			Acknowledgments
			The authors would like to thank the following people for their
			comments, support and review: Shane Amante, Christopher Morrow,
			Robert Raszuk, Greg Skinner, Adam Chappell, Sriram Kotikalapudi,
			Brian Dickson, Jeffrey Haas, John Heasley, Ignas Bagdonas, Donald
			Smith, Alvaro Retana, John Scudder, and Dale Worley.
			Contributors
			The following people contributed to successful deployment of the
			solution described in this document:
			Jakob Heitz
			Cisco
			Email: jheitz@cisco.com
			Ondrej Filip
			CZ.NIC
			Email: ondrej.filip@nic.cz
	Authors' Addresses		Authors' Addresses
	Jared Mauch		Jared Mauch
	Akamai Technologies		Akamai Technologies
	8285 Reese Lane		8285 Reese Lane
	Ann Arbor Michigan 48103		Ann Arbor Michigan 48103
	US		United States of America
	Email: jared@akamai.com		Email: jared@akamai.com
	Job Snijders		Job Snijders
	NTT Communications		NTT Communications
	Theodorus Majofskistraat 100		Theodorus Majofskistraat 100
	Amsterdam 1065 SZ		Amsterdam 1065 SZ
	NL		The Netherlands
	Email: job@ntt.net		Email: job@ntt.net
	Greg Hankins		Greg Hankins
	Nokia		Nokia
	777 E. Middlefield Road		777 E. Middlefield Road
	Mountain View, CA 94043		Mountain View, CA 94043
	USA		United States of America
	Email: greg.hankins@nokia.com		Email: greg.hankins@nokia.com
End of changes. 24 change blocks.
	79 lines changed or deleted		82 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/