draft-ietf-grow-bgp-reject-01.txt		draft-ietf-grow-bgp-reject-02.txt
	Global Routing Operations J. Mauch		Global Routing Operations J. Mauch
	Internet-Draft J. Snijders		Internet-Draft J. Snijders
	Intended status: Standards Track NTT		Intended status: Standards Track NTT
	Expires: November 11, 2016 May 10, 2016		Expires: May 4, 2017 G. Hankins
			Nokia
			October 31, 2016
	By default reject propagation when no policy is associated with a BGP		Default IPv4 and IPv6 Unicast EBGP Route Propagation Behavior Without
	peering session.		Policies
	draft-ietf-grow-bgp-reject-01		draft-ietf-grow-bgp-reject-02
	Abstract		Abstract
	This document defines the default behaviour of a BGP speaker when no		This document defines the default behavior of a BGP speaker when
	explicit policy is associated with a BGP peering session.		there is no import or export policy associated with a BGP session for
			the IPv4 or IPv6 Unicast Address Family.
			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 Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 November 11, 2016.		This Internet-Draft will expire on May 4, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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. Requirements Language . . . . . . . . . . . . . . . . . . . . 2		2. Solution Requirements . . . . . . . . . . . . . . . . . . . . 3
	3. Solution Requirements . . . . . . . . . . . . . . . . . . . . 2		3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3		4. Security Considerations . . . . . . . . . . . . . . . . . . . 3
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 3		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3		6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 3		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
	7.1. Normative References . . . . . . . . . . . . . . . . . . 3		7.1. Normative References . . . . . . . . . . . . . . . . . . 4
	7.2. Informative References . . . . . . . . . . . . . . . . . 4		7.2. Informative References . . . . . . . . . . . . . . . . . 4
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4
	1. Introduction		1. Introduction
	BGP [RFC4271] speakers have many default settings which need to be		BGP [RFC4271] speakers have many default settings which need to be
	revisited as part of improving the routing ecosystem. There is a		revisited as part of improving the routing ecosystem. There is a
	need to provide guidance to BGP implementors for the default		need to provide guidance to BGP implementers for the default
	behaviors of a well functioning internet ecosystem. Routing leaks		behaviors of a well functioning Internet ecosystem. Routing leaks
	[I-D.ietf-idr-route-leak-detection-mitigation] are part of the		[RFC7908] are part of the problem, but software defects and operator
	problem, but software defects and operator misconfigurations are just		misconfigurations are just a few of the attacks on Internet stability
	a few of the attacks on internet stability we aim to address.		we aim to address.
	Usually BGP speakers accept all routes from a configured peer or
	neighbor. This practice dates back to the early days of internet
	protocols in being very permissive in offering routing information to
	allow all networks to reach each other. With the core of the
	internet becoming more densely interconnected the risk of a
	misbehaving edge device or BGP speaking customer poses signficiant
	risks to the reachability of critical services.
	This proposal intends to solve this situation by requiring the
	explicit configuration of BGP policy for any non-iBGP speaking
	session such as customers, peers or confederation boundaries. When
	this solution is implemented, devices will no longer pass routes
	without explicit policy.
	2. Requirements Language		Many BGP speakers send and accept all routes from a peer by default.
			This practice dates back to the early days of the Internet, where
			operators were permissive in offering routing information to allow
			all networks to reach each other. As the Internet has become more
			densely interconnected, the risk of a misbehaving BGP speaker poses
			significant risks to Internet routing.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		This specification intends to improve this situation by requiring the
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		explicit configuration of a BGP import and export policy for any EBGP
	document are to be interpreted as described in RFC 2119 [RFC2119].		speaking session such as customers, peers, or confederation
			boundaries in a base router or VPN instances. When this solution is
			implemented, BGP speakers do not accept or send routes without
			policies configured on EBGP sessions.
	3. Solution Requirements		2. Solution Requirements
	The following requirements apply to the solution described in this		The following requirements for the IPv4 and IPv6 Unicast Address
	document:		Family apply to the solution described in this document:
	o Software MUST mark any routes from an eBGP peer as 'invalid' in		o Software MUST consider any routes from an EBGP peer invalid, if no
	the Adj-RIB-In, if no explicit policy was configured.		import policy was configured.
	o Software MUST NOT advertise any routes to an eBGP peer without an		o Software MUST NOT advertise any routes to an EBGP peer, if no
	operator configuring a policy.		export policy was configured.
	o Software MUST NOT require a configuration directive to operate in		o Software SHOULD provide protection from internal failures
	this mode.		preventing the advertisement and acceptance of routes.
	o Software MUST provide protection from internal failures preventing		o Software MUST operate in this mode by default.
	the advertisement and acceptance of routes.
	o Software MAY provide a configuration option to disable this		o Software MAY provide a configuration option to disable this
	security capability.		security capability.
	4. Acknowledgements		3. Acknowledgments
	The authors would like to thank the following people for their		The authors would like to thank the following people for their
	comments and support: Shane Amante, Christopher Morrow, Robert		comments, support and review: Shane Amante, Christopher Morrow,
	Raszuk, Greg Skinner.		Robert Raszuk, Greg Skinner, Adam Chappell, Sriram Kotikalapudi, and
			Brian Dickson.
	5. Security Considerations		4. Security Considerations
	This document addresses the basic security posture of a BGP speaking		This document addresses the basic security behavior of how a BGP
	device within a network. Operators have a need for implementors to		speaker propagates routes in a default configuration without
	address the problem through a behavior change to mitigate against		policies. Operators have a need for implementers to address the
	possible attacks from a permissive security posture. Attacks and		problem through a behavior change to mitigate against possible
	inadvertent advertisements cause business impact necessitating this		attacks from a permissive security behavior. Attacks and inadvertent
	default behavior.		advertisements cause business impact that can be mitigated by a
			secure default behavior.
	6. IANA Considerations		5. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
			6. 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
	7. References		7. References
	7.1. Normative References		7.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>.
	7.2. Informative References		7.2. Informative References
	[I-D.ietf-idr-route-leak-detection-mitigation]		[RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E.,
	Sriram, K., Montgomery, D., Dickson, B., Patel, K., and A.		and B. Dickson, "Problem Definition and Classification of
	Robachevsky, "Methods for Detection and Mitigation of BGP		BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June
	Route Leaks", draft-ietf-idr-route-leak-detection-		2016, <http://www.rfc-editor.org/info/rfc7908>.
	mitigation-02 (work in progress), March 2016.
	Authors' Addresses		Authors' Addresses
	Jared Mauch		Jared Mauch
	NTT Communications, Inc.		NTT Communications
	8285 Reese Lane		8285 Reese Lane
	Ann Arbor Michigan 48103		Ann Arbor Michigan 48103
	US		US
	Email: jmauch@us.ntt.net		Email: jmauch@us.ntt.net
	Job Snijders		Job Snijders
	NTT Communications, Inc.		NTT Communications
	Theodorus Majofskistraat 100		Theodorus Majofskistraat 100
	Amsterdam 1065 SZ		Amsterdam 1065 SZ
	NL		NL
	Email: job@ntt.net		Email: job@ntt.net
			Greg Hankins
			Nokia
			777 E. Middlefield Road
			Mountain View, CA 94043
			USA
			Email: greg.hankins@nokia.com
End of changes. 25 change blocks.
	67 lines changed or deleted		84 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/