draft-ietf-sidr-bgpsec-ops-12.txt		draft-ietf-sidr-bgpsec-ops-13.txt
	Network Working Group R. Bush		Network Working Group R. Bush
	Internet-Draft Internet Initiative Japan		Internet-Draft Internet Initiative Japan
	Intended status: Best Current Practice December 6, 2016		Intended status: Best Current Practice January 4, 2017
	Expires: June 9, 2017		Expires: July 8, 2017
	BGPsec Operational Considerations		BGPsec Operational Considerations
	draft-ietf-sidr-bgpsec-ops-12		draft-ietf-sidr-bgpsec-ops-13
	Abstract		Abstract
	Deployment of the BGPsec architecture and protocols has many		Deployment of the BGPsec architecture and protocols has many
	operational considerations. This document attempts to collect and		operational considerations. This document attempts to collect and
	present the most critical and universal. It is expected to evolve as		present the most critical and universal. It is expected to evolve as
	BGPsec is formalized and initially deployed.		BGPsec is formalized and initially deployed.
	Requirements Language		Requirements Language
	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 June 9, 2017.		This Internet-Draft will expire on July 8, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 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
	skipping to change at page 2, line 35 ¶		skipping to change at page 2, line 35 ¶
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	12.1. Normative References . . . . . . . . . . . . . . . . . . 7		12.1. Normative References . . . . . . . . . . . . . . . . . . 7
	12.2. Informative References . . . . . . . . . . . . . . . . . 8		12.2. Informative References . . . . . . . . . . . . . . . . . 8
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	BGPsec, [I-D.ietf-sidr-bgpsec-protocol], is a new protocol with many		BGPsec, [I-D.ietf-sidr-bgpsec-protocol], is a new protocol with many
	operational considerations. It is expected to be deployed		operational considerations. It is expected to be deployed
	incrementally over a number of years. As core BGPsec-capable routers		incrementally over a number of years. As core BGPsec-capable routers
	may require large memory and/or modern CPUs, it is thought that		may require large memory and/or modern CPUs, origin validation based
	origin validation based on the RPKI, [RFC6811], will occur over some		on the Resource Public Key Infrastructure (RPKI), [RFC6811], will
	years and that BGPsec will start to deploy after that.		occur over some years and that BGPsec will start to deploy after
			that.
	BGPsec relies on widespread propagation of the Resource Public Key		BGPsec relies on widespread propagation of the RPKI [RFC6480]. How
	Infrastructure (RPKI) [RFC6480]. How the RPKI is distributed and		the RPKI is distributed and maintained globally and within an
	maintained globally and within an operator's infrastructure may be		operator's infrastructure may be different for BGPsec than for origin
	different for BGPsec than for origin validation.		validation.
	BGPsec needs to be spoken only by an AS's eBGP speaking, AKA border,		BGPsec needs to be spoken only by an AS's eBGP-speaking, AKA border,
	routers, and is designed so that it can be used to protect		routers, and is designed so that it can be used to protect
	announcements which are originated by resource constrained edge		announcements which are originated by resource constrained edge
	routers. This has special operational considerations.		routers. This has special operational considerations.
	Different prefixes may have different timing and replay protection		Different prefixes may have different timing and replay protection
	considerations.		considerations.
	2. Suggested Reading		2. Suggested Reading
	It is assumed that the reader understands BGP, see [RFC4271], BGPsec,		It is assumed that the reader understands BGP, see [RFC4271], BGPsec,
	[I-D.ietf-sidr-bgpsec-overview], the RPKI, see [RFC6480], the RPKI		[I-D.ietf-sidr-bgpsec-overview], the RPKI, see [RFC6480], the RPKI
	Repository Structure, see [RFC6481], and ROAs, see [RFC6482].		Repository Structure, see [RFC6481], and Route Origin Authorizations
			(ROAs), see [RFC6482].
	3. RPKI Distribution and Maintenance		3. RPKI Distribution and Maintenance
	All non-ROA considerations in the section on RPKI Distribution and		All non-ROA considerations in the section on RPKI Distribution and
	Maintenance of [RFC7115] apply.		Maintenance of [RFC7115] apply.
	4. AS/Router Certificates		4. AS/Router Certificates
	As described in [I-D.ietf-sidr-rtr-keying] BGPsec-speaking routers		As described in [I-D.ietf-sidr-rtr-keying] BGPsec-speaking routers
	are either capable of generating their own public/private key-pairs		are either capable of generating their own public/private key-pairs
	and having their certificates signed and published in the RPKI by the		and having their certificates signed and published in the RPKI by the
	RPKI CA system, and/or are given public/private key-pairs by the		RPKI CA system, and/or are given public/private key-pairs by the
	operator.		operator.
	A site/operator MAY use a single certificate/key in all their		A site/operator may use a single certificate/key in all their
	routers, one certificate/key per router, or any granularity in		routers, one certificate/key per router, or any granularity in
	between.		between.
	A large operator, concerned that a compromise of one router's key		A large operator, concerned that a compromise of one router's key
	would make other routers vulnerable, may accept a more complex		would make other routers vulnerable, may deploy a more complex
	certificate/key distribution burden to reduce this exposure.		certificate/key distribution burden to reduce this exposure.
	On the other extreme, an edge site with one or two routers may choose		At the other end of the spectrum, an edge site with one or two
	to use a single certificate/key.		routers may choose to use a single certificate/key.
	In anticipation of possible key compromise, a prudent operator will		In anticipation of possible key compromise, a prudent operator should
	pre-provision each router's 'next' key in the RPKI so there is no		pre-provision each router's 'next' key in the RPKI so there is no
	propagation delay for provisioning the new key.		propagation delay for provisioning the new key.
	5. Within a Network		5. Within a Network
	BGPsec is spoken by edge routers in a network, those which border		BGPsec is spoken by edge routers in a network, those which border
	other networks/ASs.		other networks/ASs.
	In a fully BGPsec enabled AS, Route Reflectors MUST have BGPsec		In a fully BGPsec enabled AS, Route Reflectors MUST have BGPsec
	enabled if and only if there are eBGP speakers in their client cone,		enabled if and only if there are eBGP speakers in their client cone,
	skipping to change at page 4, line 13 ¶		skipping to change at page 4, line 13 ¶
	policy should fit into the AS's existing policy, preferences, etc.		policy should fit into the AS's existing policy, preferences, etc.
	This allows a network to incrementally deploy BGPsec enabled border		This allows a network to incrementally deploy BGPsec enabled border
	routers.		routers.
	eBGP speakers which face more critical peers or up/downstreams would		eBGP speakers which face more critical peers or up/downstreams would
	be candidates for early deployment. Both securing one's own		be candidates for early deployment. Both securing one's own
	announcements and validating received announcements should be		announcements and validating received announcements should be
	considered in partial deployment.		considered in partial deployment.
	The operator should be aware that BGPsec, as any other policy change,		An operator should be aware that BGPsec, as any other policy change,
	can cause traffic shifts in their network. And, as with normal		can cause traffic shifts in their network. And, as with normal
	policy shift practice, a prudent operator has tools and methods to		policy shift practice, a prudent operator has tools and methods to
	predict, measure, modify, etc.		predict, measure, modify, etc.
	On the other hand, an operator wanting to monitor router loading,		On the other hand, an operator wanting to monitor router loading,
	shifts in traffic, etc. might deploy incrementally while watching		shifts in traffic, etc. might deploy incrementally while watching
	those and similar effects.		those and similar effects.
	BGPsec does not sign over communities, so they are not formally		BGPsec does not sign over communities, so they are not formally
	trustable. Additionally, outsourcing verification is not prudent		trustable. Additionally, outsourcing verification is not prudent
	security practice. Therefore an eBGP listener SHOULD NOT strongly		security practice. Therefore an eBGP listener SHOULD NOT strongly
	trust unsigned security signaling, such as communities, received		trust unsigned security signaling, such as communities, received
	across a trust boundary.		across a trust boundary.
	6. Considerations for Edge Sites		6. Considerations for Edge Sites
	An edge site which does not provide transit and trusts its		An edge site which does not provide transit and trusts its
	upstream(s) SHOULD only originate a signed prefix announcement and		upstream(s) may only originate a signed prefix announcement and not
	need not validate received announcements.		validate received announcements.
	Operators might need to use hardware with limited resources. In such		An Operator might need to use hardware with limited resources. In
	cases, BGPsec protocol capability negotiation allows for a resource		such cases, BGPsec protocol capability negotiation allows for a
	constrained edge router to hold only its own signing key(s) and sign		resource constrained edge router to hold only its own signing key(s)
	its announcements, but not receive signed announcements. Therefore,		and sign its announcements, but not receive signed announcements.
	the router would not have to deal with the majority of the RPKI,		Therefore, the router would not have to deal with the majority of the
	potentially saving the need for additional hardware.		RPKI, potentially saving the need for additional hardware.
	As the vast majority (84%) of ASs are stubs, and they announce the		As the vast majority of ASs are stubs, and they announce the majority
	majority of prefixes, this allows for simpler and less expensive		of prefixes, this allows for simpler and less expensive incremental
	incremental deployment. It may also mean that edge sites concerned		deployment. It may also mean that edge sites concerned with routing
	with routing security will be attracted to upstreams which support		security will be attracted to upstreams which support BGPsec.
	BGPsec.
	7. Routing Policy		7. Routing Policy
	Unlike origin validation based on the RPKI, BGPsec marks a received		Unlike origin validation based on the RPKI, BGPsec marks a received
	announcement as Valid or Not Valid, there is no explicit NotFound		announcement as Valid or Not Valid, there is no explicit NotFound
	state. In some sense, an unsigned BGP4 path is the equivalent of		state. In some sense, an unsigned BGP4 path is the equivalent of
	NotFound. How this is used in routing is up to the operator's local		NotFound. How this is used in routing is up to the operator's local
	policy, similar to origin validation as in [RFC6811].		policy, similar to origin validation as in [RFC6811].
	As BGPsec will be rolled out over years and does not allow for		As BGPsec will be rolled out over years and does not allow for
	skipping to change at page 5, line 43 ¶		skipping to change at page 5, line 41 ¶
	metric, which comes after AS-Path in the BGP decision process.		metric, which comes after AS-Path in the BGP decision process.
	Because of possible RPKI version skew, an AS Path which does not		Because of possible RPKI version skew, an AS Path which does not
	validate at router R0 might validate at R1. Therefore, signed paths		validate at router R0 might validate at R1. Therefore, signed paths
	that are Not Valid and yet propagated (because they are chosen as		that are Not Valid and yet propagated (because they are chosen as
	best path) should have their signatures left intact and MUST be		best path) should have their signatures left intact and MUST be
	signed if sent to external BGPsec speakers.		signed if sent to external BGPsec speakers.
	This implies that updates which a speaker judges to be Not Valid MAY		This implies that updates which a speaker judges to be Not Valid MAY
	be propagated to iBGP peers. Therefore, unless local policy ensures		be propagated to iBGP peers. Therefore, unless local policy ensures
	otherwise, a signed path learned via iBGP MAY be Not Valid. If		otherwise, a signed path learned via iBGP may be Not Valid. If
	needed, the validation state should be signaled by normal local		needed, the validation state should be signaled by normal local
	policy mechanisms such as communities or metrics.		policy mechanisms such as communities or metrics.
	On the other hand, local policy on the eBGP edge might preclude iBGP		On the other hand, local policy on the eBGP edge might preclude iBGP
	or eBGP announcement of signed AS Paths which are Not Valid.		or eBGP announcement of signed AS Paths which are Not Valid.
	A BGPsec speaker receiving a path SHOULD perform origin validation		A BGPsec speaker receiving a path SHOULD perform origin validation
	per [RFC6811] and [RFC7115].		per [RFC6811] and [RFC7115].
	A route server is usually 'transparent', i.e. does not insert an AS		A route server is usually 'transparent', i.e. does not insert an AS
	skipping to change at page 7, line 28 ¶		skipping to change at page 7, line 25 ¶
	This document describes operational considerations for the deployment		This document describes operational considerations for the deployment
	of BGPsec. The security considerations for BGPsec are described in		of BGPsec. The security considerations for BGPsec are described in
	[I-D.ietf-sidr-bgpsec-protocol].		[I-D.ietf-sidr-bgpsec-protocol].
	10. IANA Considerations		10. IANA Considerations
	This document has no IANA Considerations.		This document has no IANA Considerations.
	11. Acknowledgments		11. Acknowledgments
	The author wishes to thank the BGPsec design group, Thomas King,		The author wishes to thank Thomas King, Arnold Nipper, and Alvaro
	Arnold Nipper, and Alvaro Retana.		Retana, and the BGPsec design group.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[I-D.ietf-sidr-bgpsec-protocol]		[I-D.ietf-sidr-bgpsec-protocol]
	Lepinski, M., "BGPSEC Protocol Specification", draft-ietf-		Lepinski, M., "BGPSEC Protocol Specification", draft-ietf-
	sidr-bgpsec-protocol-07 (work in progress), February 2013.		sidr-bgpsec-protocol-07 (work in progress), February 2013.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	skipping to change at page 8, line 9 ¶		skipping to change at page 8, line 9 ¶
	[RFC7115] Bush, R., "Origin Validation Operation Based on the		[RFC7115] Bush, R., "Origin Validation Operation Based on the
	Resource Public Key Infrastructure (RPKI)", BCP 185,		Resource Public Key Infrastructure (RPKI)", BCP 185,
	RFC 7115, DOI 10.17487/RFC7115, January 2014,		RFC 7115, DOI 10.17487/RFC7115, January 2014,
	<http://www.rfc-editor.org/info/rfc7115>.		<http://www.rfc-editor.org/info/rfc7115>.
	12.2. Informative References		12.2. Informative References
	[I-D.ietf-sidr-as-migration]		[I-D.ietf-sidr-as-migration]
	George, W. and S. Murphy, "BGPSec Considerations for AS		George, W. and S. Murphy, "BGPSec Considerations for AS
	Migration", draft-ietf-sidr-as-migration-05 (work in		Migration", draft-ietf-sidr-as-migration-06 (work in
	progress), April 2016.		progress), December 2016.
	[I-D.ietf-sidr-bgpsec-overview]		[I-D.ietf-sidr-bgpsec-overview]
	Lepinski, M. and S. Turner, "An Overview of BGPSEC",		Lepinski, M. and S. Turner, "An Overview of BGPSEC",
	draft-ietf-sidr-bgpsec-overview-02 (work in progress), May		draft-ietf-sidr-bgpsec-overview-02 (work in progress), May
	2012.		2012.
	[I-D.ietf-sidr-bgpsec-rollover]		[I-D.ietf-sidr-bgpsec-rollover]
	Gagliano, R., Patel, K., and B. Weis, "BGPSEC router key		Gagliano, R., Patel, K., and B. Weis, "BGPSEC router key
	rollover as an alternative to beaconing", draft-ietf-sidr-		rollover as an alternative to beaconing", draft-ietf-sidr-
	bgpsec-rollover-01 (work in progress), October 2012.		bgpsec-rollover-01 (work in progress), October 2012.
End of changes. 19 change blocks.
	38 lines changed or deleted		39 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/