Re: Genart telechat review of draft-ietf-grow-bgp-reject-07

["Hankins, Greg (Nokia - US)" <greg.hankins@xxxxxxxxx>]

On Fri, May 19, 2017 at 11:19:34AM -0700, Dale Worley wrote:
>This paragraph is a good introduction, but it isn't very cohesive.  I
>suggest revising the third sentence to something like:
>
>   This document updates [RFC4271] so that routes are neither imported
>   nor exported unless specifically enabled by configuration, thus
>   reducing the consequences of these problems, and so improving the
>   default level of Internet routing security.

Hi Dale, this paragraphs seems wordy now, so I would suggested splitting
sentences as follows:

This document updates [RFC4271] so that routes are neither imported nor
exported unless specifically enabled by configuration.  The solution
reduces the consequences of these problems, and improves the default level
of Internet routing security.

>You probably want to s/a compliant BGP implementation/compliant BGP
>implementations/, unless you are describing the process for an
>individual operator, not for all operators collectively.

As Job said, this was a transition consideration for BGP implementers.

How about this change for clarity:
- old: It is anticipated that transitioning to a compliant BGP implementation
will require a process thay may take several years.
- new: Transitioning to a compliant BGP implementation may require a software
development and release process that can take implementers several years.

I attached a new -07 -> -08 htmldiff that incorporates my edits and
Job's edits.

Greg

--
Greg Hankins <ghankins@xxxxxxxxxxxxxx>

Title: Diff: draft-ietf-grow-bgp-reject-07.txt - draft-ietf-grow-bgp-reject-08.txt

	draft-ietf-grow-bgp-reject-07.txt		draft-ietf-grow-bgp-reject-08.txt
	Global Routing Operations J. Mauch		Global Routing Operations J. Mauch
	Internet-Draft Akamai		Internet-Draft Akamai
	Updates: 4271 (if approved) J. Snijders		Updates: 4271 (if approved) J. Snijders
	Intended status: Standards Track NTT		Intended status: Standards Track NTT
	Expires: November 9, 2017 G. Hankins		Expires: November 23, 2017 G. Hankins
	Nokia		Nokia
	May 8, 2017		May 22, 2017
	Default EBGP Route Propagation Behavior Without Policies		Default EBGP Route Propagation Behavior Without Policies
	draft-ietf-grow-bgp-reject-07		draft-ietf-grow-bgp-reject-08
	Abstract		Abstract
	This document updates RFC4271 by defining the default behavior of a		This document updates RFC4271 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		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	skipping to change at page 1, line 41		skipping to change at page 1, line 41
	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 9, 2017.		This Internet-Draft will expire on November 23, 2017.
	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
	skipping to change at page 2, line 25		skipping to change at page 2, line 25
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Changes to RFC4271 . . . . . . . . . . . . . . . . . . . . . 3		3. Changes to RFC4271 . . . . . . . . . . . . . . . . . . . . . 3
	4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4		4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 4		5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
	7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 4		7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 4
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
	8.1. Normative References . . . . . . . . . . . . . . . . . . 5		8.1. Normative References . . . . . . . . . . . . . . . . . . 5
	8.2. Informative References . . . . . . . . . . . . . . . . . 5		8.2. Informative References . . . . . . . . . . . . . . . . . 5
	Appendix A. Transition Considerations . . . . . . . . . . . . . 5		Appendix A. Transition Considerations . . . . . . . . . . . . . 5
	A.1. N+1 N+2 Release Strategy . . . . . . . . . . . . . . . . 5		A.1. "N+1 N+2" Release Strategy . . . . . . . . . . . . . . . 5
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
	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 contribute too.
	This document updates [RFC4271] in order to improve the default level		This document updates [RFC4271] so that routes are neither imported
	of Internet routing security.		nor exported unless specifically enabled by configuration. The
			solution reduces the consequences of these 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 behaviour 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 configured to do otherwise.		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) which 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		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		3. Changes to RFC4271
	This section describes the Updates to [RFC4271] that define the		This section updates [RFC4271] to specify the default behavior of a
	default behavior of a BGP speaker when there are no Import or Export		BGP speaker when there are no Import or Export Policies associated
	Policies associated with a particular EBGP session. A BGP speaker		with a particular EBGP session. A BGP speaker MAY provide a
	MAY provide a configuration option to deviate from the following		configuration option to deviate from the following updated behaviors.
	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 ending in "route aggregation and route		after the fifth paragraph, which ends in "route aggregation and route
	information reduction":		information reduction":
	Routes contained in an Adj-RIB-In associated with an EBGP peer		Routes contained in an Adj-RIB-In associated with an EBGP peer
	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 ending in "by means of an		Dissemination) after the third paragraph, which ends in "by means of
	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. Acknowledgments
	The authors would like to thank the following people for their		The authors would like to thank the following people for their
	comments, support and review: Shane Amante, Christopher Morrow,		comments, support and review: Shane Amante, Christopher Morrow,
	Robert Raszuk, Greg Skinner, Adam Chappell, Sriram Kotikalapudi,		Robert Raszuk, Greg Skinner, Adam Chappell, Sriram Kotikalapudi,
	Brian Dickson, Jeffrey Haas, John Heasley, Ignas Bagdonas, Donald		Brian Dickson, Jeffrey Haas, John Heasley, Ignas Bagdonas, Donald
	Smith, Dale Worley, Alvaro Retana, and John Scudder.		Smith, Dale Worley, Alvaro Retana, John Scudder, and Dale Worley.
	5. Security Considerations		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 rerouting 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
	skipping to change at page 5, line 34		skipping to change at page 5, line 34
	[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		Appendix A. Transition Considerations
	This appendix is non-normative.		This appendix is non-normative.
	It is anticipated that transitioning to a compliant BGP		Transitioning to a compliant BGP implementation may require a
	implementation will require a process thay may take several years.		software development and release process that can take implementers
			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
	An implementer could leverage an approach described as "the N+1 and		An implementer could leverage an approach described as the "N+1 and
	N+2 release strategy". In release N+1, the implementer introduces a		N+2" release strategy. In release N+1, the implementer introduces a
	new default configuration parameter to indicate that the BGP speaker		new default configuration parameter to indicate that the BGP speaker
	is operating in "ebgp insecure-mode". In addition to the		is operating in "ebgp insecure-mode". In addition to the
	introduction of the new parameter, an implementer could begin to		introduction of the new parameter, an implementer could begin to
	display informational warnings to the operator that certain parts of		display informational warnings to the operator that certain parts of
	the configuration are incomplete. In release N+1, operators of the		the configuration are incomplete. In release N+1, operators of the
	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.
End of changes. 16 change blocks.
	24 lines changed or deleted		26 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/