draft-ietf-grow-bgp-reject-00.txt		draft-ietf-grow-bgp-reject-01.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: June 30, 2016 December 28, 2015		Expires: November 11, 2016 May 10, 2016
	By default reject propagation when no policy is associated with a BGP		By default reject propagation when no policy is associated with a BGP
	peering session.		peering session.
	draft-ietf-grow-bgp-reject-00		draft-ietf-grow-bgp-reject-01
	Abstract		Abstract
	This document defines the default behaviour of a BGP speaker when no		This document defines the default behaviour of a BGP speaker when no
	explicit policy is associated with a BGP peering session.		explicit policy is associated with a BGP peering session.
	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.
	skipping to change at page 1, line 32 ¶		skipping to change at page 1, line 32 ¶
	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 June 30, 2016.		This Internet-Draft will expire on November 11, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 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
	skipping to change at page 2, line 22 ¶		skipping to change at page 2, line 22 ¶
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 3		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 3
	7.1. Normative References . . . . . . . . . . . . . . . . . . 3		7.1. Normative References . . . . . . . . . . . . . . . . . . 3
	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 guidace to BGP implementors for the default behaviors		need to provide guidance to BGP implementors for the default
	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		[I-D.ietf-idr-route-leak-detection-mitigation] are part of the
	problem, but software defects and operator misconfigurations are just		problem, but software defects and operator misconfigurations are just
	a few of the attacks on internet stability we aim to address.		a few of the attacks on internet stability we aim to address.
	Usually BGP speakers accept all routes from a configured peer or		Usually BGP speakers accept all routes from a configured peer or
	neighbor. This practice dates back to the early days of internet		neighbor. This practice dates back to the early days of internet
	protocols in being very permissive in offering routing information to		protocols in being very permissive in offering routing information to
	allow all networks to reach each other. With the core of the		allow all networks to reach each other. With the core of the
	internet becoming more densely interconnected the risk of a		internet becoming more densely interconnected the risk of a
	misbehaving edge device or BGP speaking customer poses signficiant		misbehaving edge device or BGP speaking customer poses signficiant
	risks to the reachability of critical services.		risks to the reachability of critical services.
	This proposal intends to solve this situation with the requiring the		This proposal intends to solve this situation by requiring the
	explicity configuration of BGP policy for any non-iBGP speaking		explicit configuration of BGP policy for any non-iBGP speaking
	session such as customers, peers or confederation boundaries. When		session such as customers, peers or confederation boundaries. When
	this solution is implemented, devices will no longer pass routes		this solution is implemented, devices will no longer pass routes
	without explicit policy.		without explicit policy.
	2. Requirements Language		2. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	3. Solution Requirements		3. Solution Requirements
	The following requirements apply to the solution described in this		The following requirements apply to the solution described in this
	document:		document:
	o Software MUST mark any routes from an eBGP peer as 'invalid' in		o Software MUST mark any routes from an eBGP peer as 'invalid' in
	the Adj-RIB-In, if no explicit policy was configured.		the Adj-RIB-In, if no explicit 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 without an
	operator configuring a policy		operator configuring a policy.
	o Software MUST NOT require a configuration directive to operate in		o Software MUST NOT require a configuration directive to operate in
	this mode.		this mode.
	o Software MUST provide protection from internal failures preventing		o Software MUST provide protection from internal failures preventing
	the advertisement and acceptance of routes		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		4. Acknowledgements
	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 and support: Shane Amante, Christopher Morrow, Robert
	Raszuk.		Raszuk, Greg Skinner.
	5. Security Considerations		5. Security Considerations
	This document addresses the basic security posture of a BGP speaking		This document addresses the basic security posture of a BGP speaking
	device within a network. Operators have a need for implementors to		device within a network. Operators have a need for implementors to
	address the problem through a behavior change to mitigate against		address the problem through a behavior change to mitigate against
	possible attacks from a permissive security posture. Attacks and		possible attacks from a permissive security posture. Attacks and
	inadvertent advertisements cause business impact necessitating this		inadvertent advertisements cause business impact necessitating this
	default behavior.		default behavior.
	skipping to change at page 4, line 11 ¶		skipping to change at page 4, line 11 ¶
	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]		[I-D.ietf-idr-route-leak-detection-mitigation]
	Sriram, K., Montgomery, D., Dickson, B., Patel, K., and A.		Sriram, K., Montgomery, D., Dickson, B., Patel, K., and A.
	Robachevsky, "Methods for Detection and Mitigation of BGP		Robachevsky, "Methods for Detection and Mitigation of BGP
	Route Leaks", draft-ietf-idr-route-leak-detection-		Route Leaks", draft-ietf-idr-route-leak-detection-
	mitigation-01 (work in progress), October 2015.		mitigation-02 (work in progress), March 2016.
	Authors' Addresses		Authors' Addresses
	Jared Mauch		Jared Mauch
	NTT Communications, Inc.		NTT Communications, Inc.
	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, Inc.
	Amsterdam		Theodorus Majofskistraat 100
			Amsterdam 1065 SZ
	NL		NL
	Email: job@ntt.net		Email: job@ntt.net
End of changes. 11 change blocks.
	13 lines changed or deleted		14 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/