draft-ietf-sidr-bgpsec-ops-13.txt		draft-ietf-sidr-bgpsec-ops-14.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 January 4, 2017		Intended status: Best Current Practice January 5, 2017
	Expires: July 8, 2017		Expires: July 9, 2017
	BGPsec Operational Considerations		BGPsec Operational Considerations
	draft-ietf-sidr-bgpsec-ops-13		draft-ietf-sidr-bgpsec-ops-14
	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 July 8, 2017.		This Internet-Draft will expire on July 9, 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 37 ¶		skipping to change at page 2, line 37 ¶
	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, origin validation based		may require large memory and/or modern CPUs, origin validation based
	on the Resource Public Key Infrastructure (RPKI), [RFC6811], will		on the Resource Public Key Infrastructure (RPKI), [RFC6811], will
	occur over some years and that BGPsec will start to deploy after		occur over some years and BGPsec will start to deploy after that. As
	that.		with most operational practices, this document will likely evolve.
	BGPsec relies on widespread propagation of the RPKI [RFC6480]. How		BGPsec relies on widespread propagation of the RPKI [RFC6480]. How
	the RPKI is distributed and maintained globally and within an		the RPKI is distributed and maintained globally and within an
	operator's infrastructure may be different for BGPsec than for origin		operator's infrastructure may be 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, see Section 6.
	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-protocol], the RPKI, see [RFC6480], the RPKI
	Repository Structure, see [RFC6481], and Route Origin Authorizations		Repository Structure, see [RFC6481], and Route Origin Authorizations
	(ROAs), see [RFC6482].		(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
	skipping to change at page 3, line 45 ¶		skipping to change at page 3, line 45 ¶
	In anticipation of possible key compromise, a prudent operator should		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 an AS where edge routers speak BGPsec and therefore inject BGPsec
	enabled if and only if there are eBGP speakers in their client cone,		paths into the iBGP, Route Reflectors MUST have BGPsec enabled if and
	i.e. an RR client or the transitive closure of a client's customers'		only if there are eBGP speakers in their client cone, i.e. an RR
	customers' customers' etc.		client or the transitive closure of a client's customers.
	A BGPsec capable router MAY use the data it receives to influence		A BGPsec capable router MAY use the data it receives to influence
	local policy within its network, see Section 7. In deployment this		local policy within its network, see Section 7. In deployment this
	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
	skipping to change at page 5, line 29 ¶		skipping to change at page 5, line 29 ¶
	10.0.666.0/24 from neighbor I. If local policy on the router is not		10.0.666.0/24 from neighbor I. If local policy on the router is not
	configured to discard the Not Valid announcement from I, then longest		configured to discard the Not Valid announcement from I, then longest
	match forwarding will send packets to neighbor I no matter the value		match forwarding will send packets to neighbor I no matter the value
	of local preference.		of local preference.
	Validation of signed paths is usually deployed at the eBGP edge.		Validation of signed paths is usually deployed at the eBGP edge.
	Local policy on the eBGP edge MAY convey the validation state of a		Local policy on the eBGP edge MAY convey the validation state of a
	BGP signed path through normal local policy mechanisms, e.g. setting		BGP signed path through normal local policy mechanisms, e.g. setting
	a BGP community for internal use, or modifying a metric value such as		a BGP community for internal use, or modifying a metric value such as
	local-preference or MED. Some may choose to use the large Local-Pref		local-preference or multi-exit discriminator (MED). Some may choose
	hammer. Others may choose to let AS-Path rule and set their internal		to use the large Local-Pref hammer. Others may choose to let AS-Path
	metric, which comes after AS-Path in the BGP decision process.		rule and set their internal metric, which comes after AS-Path in the
			BGP decision process.
	Because of possible RPKI version skew, an AS Path which does not		As the mildly stochastic timing of RPKI propagation may cause version
	validate at router R0 might validate at R1. Therefore, signed paths		skew across routers, an AS Path which does not validate at router R0
	that are Not Valid and yet propagated (because they are chosen as		might validate at R1. Therefore, signed paths that are Not Valid and
	best path) should have their signatures left intact and MUST be		yet propagated (because they are chosen as best path) should have
	signed if sent to external BGPsec speakers.		their signatures left intact and MUST be 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.
	skipping to change at page 6, line 35 ¶		skipping to change at page 6, line 38 ¶
	confederation will not cause external confusion even if non-unique		confederation will not cause external confusion even if non-unique
	private ASs are used.		private ASs are used.
	8. Notes		8. Notes
	For protection from attacks replaying BGP data on the order of a day		For protection from attacks replaying BGP data on the order of a day
	or longer old, re-keying routers with new keys (previously)		or longer old, re-keying routers with new keys (previously)
	provisioned in the RPKI is sufficient. For one approach, see		provisioned in the RPKI is sufficient. For one approach, see
	[I-D.ietf-sidr-bgpsec-rollover]		[I-D.ietf-sidr-bgpsec-rollover]
			A router that once negotiated (and/or sent) BGPsec should not be
			expected to always do so.
	Like the DNS, the global RPKI presents only a loosely consistent		Like the DNS, the global RPKI presents only a loosely consistent
	view, depending on timing, updating, fetching, etc. Thus, one cache		view, depending on timing, updating, fetching, etc. Thus, one cache
	or router may have different data about a particular prefix or router		or router may have different data about a particular prefix or router
	than another cache or router. There is no 'fix' for this, it is the		than another cache or router. There is no 'fix' for this, it is the
	nature of distributed data with distributed caches.		nature of distributed data with distributed caches.
	Operators who manage certificates SHOULD have RPKI GhostBuster		Operators who manage certificates SHOULD have RPKI GhostBuster
	Records (see [RFC6493]), signed indirectly by End Entity		Records (see [RFC6493]), signed indirectly by End Entity
	certificates, for those certificates on which others' routing depends		certificates, for those certificates on which others' routing depends
	for certificate and/or ROA validation.		for certificate and/or ROA validation.
	skipping to change at page 8, line 12 ¶		skipping to change at page 8, line 17 ¶
	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-06 (work in		Migration", draft-ietf-sidr-as-migration-06 (work in
	progress), December 2016.		progress), December 2016.
	[I-D.ietf-sidr-bgpsec-overview]
	Lepinski, M. and S. Turner, "An Overview of BGPSEC",
	draft-ietf-sidr-bgpsec-overview-02 (work in progress), May
	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.
	[I-D.ietf-sidr-rtr-keying]		[I-D.ietf-sidr-rtr-keying]
	Turner, S., Patel, K., and R. Bush, "Router Keying for		Turner, S., Patel, K., and R. Bush, "Router Keying for
	BGPsec", draft-ietf-sidr-rtr-keying-01 (work in progress),		BGPsec", draft-ietf-sidr-rtr-keying-01 (work in progress),
	February 2013.		February 2013.
End of changes. 11 change blocks.
	25 lines changed or deleted		25 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/