draft-ietf-sidr-bgpsec-ops-09.txt		draft-ietf-sidr-bgpsec-ops-10.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 June 16, 2016		Intended status: Best Current Practice June 23, 2016
	Expires: December 18, 2016		Expires: December 25, 2016
	BGPsec Operational Considerations		BGPsec Operational Considerations
	draft-ietf-sidr-bgpsec-ops-09		draft-ietf-sidr-bgpsec-ops-10
	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 December 18, 2016.		This Internet-Draft will expire on December 25, 2016.
	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
	skipping to change at page 2, line 20 ¶		skipping to change at page 2, line 20 ¶
	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. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 3		2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 3
	3. RPKI Distribution and Maintenance . . . . . . . . . . . . . . 3		3. RPKI Distribution and Maintenance . . . . . . . . . . . . . . 3
	4. AS/Router Certificates . . . . . . . . . . . . . . . . . . . 3		4. AS/Router Certificates . . . . . . . . . . . . . . . . . . . 3
	5. Within a Network . . . . . . . . . . . . . . . . . . . . . . 3		5. Within a Network . . . . . . . . . . . . . . . . . . . . . . 3
	6. Considerations for Edge Sites . . . . . . . . . . . . . . . . 4		6. Considerations for Edge Sites . . . . . . . . . . . . . . . . 4
	7. Routing Policy . . . . . . . . . . . . . . . . . . . . . . . 5		7. Routing Policy . . . . . . . . . . . . . . . . . . . . . . . 4
	8. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		8. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 7		9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
	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 . . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	BGPsec, [I-D.ietf-sidr-bgpsec-overview], is a new protocol with many		BGPsec, [I-D.ietf-sidr-bgpsec-overview], 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, it is thought that
	origin validation based on the RPKI, [RFC6811], will occur over the		origin validation based on the RPKI, [RFC6811], will occur over the
	next two to three years and that BGPsec will start to deploy well		next two to three years and that BGPsec will start to deploy well
	after that.		after that.
	BGPsec relies on widespread propagation of the Resource Public Key		BGPsec relies on widespread propagation of the Resource Public Key
	Infrastructure (RPKI) [RFC6480]. How the RPKI is distributed and		Infrastructure (RPKI) [RFC6480]. How the RPKI is distributed and
	maintained globally and within an operator's infrastructure may be		maintained globally and within an operator's infrastructure may be
	different for BGPsec than for origin validation.		different for BGPsec than for origin validation.
	BGPsec need 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 small edge routers. This has		announcements which are originated by resource constrained edge
	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, [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 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 47 ¶		skipping to change at page 3, line 47 ¶
	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,
	i.e. an RR client or the transitive closure of their customers'		i.e. an RR client or the transitive closure of their customers'
	customers' customers' ....		customers' customers' etc.
	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 4, line 32 ¶		skipping to change at page 4, line 32 ¶
	As they are not formally verifiable, an eBGP listener SHOULD NOT		As they are not formally verifiable, an eBGP listener SHOULD NOT
	strongly trust unsigned security markings such as communities		strongly trust unsigned security markings such as communities
	received across a trust boundary.		received 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) SHOULD only originate a signed prefix announcement and
	need not validate received announcements.		need not validate received announcements.
	BGPsec protocol capability negotiation provides for a speaker signing
	the data it sends without being able to accept signed data. Thus a
	smallish edge router may hold only its own signing key(s), sign its
	announcements, but not receive signed announcements and therefore not
	need to deal with the majority of the RPKI. Thus such routers CPU,
	RAM, and crypto needs are trivial and additional hardware should not
	be needed.
	Operators might need to use hardware with limited resources. In such		Operators might need to use hardware with limited resources. In such
	cases, BGPsec protocol capability negotiation allows for a resource		cases, BGPsec protocol capability negotiation allows for a resource
	constrained edge router to hold only its own signing key(s) and sign		constrained edge router to hold only its own signing key(s) and sign
	its announcements, but not receive signed announcements. Therefore,		its announcements, but not receive signed announcements. Therefore,
	the router would not have to deal with the majority of the RPKI,		the router would not have to deal with the majority of the RPKI,
	potentially saving the need for additional hardware.		potentially saving the need for additional hardware.
	As the vast majority (84%) of ASs are stubs, and they announce the		As the vast majority (84%) of ASs are stubs, and they announce the
	majority of prefixes, this allows for simpler and less expensive		majority of prefixes, this allows for simpler and less expensive
	incremental deployment. It may also mean that edge sites concerned		incremental deployment. It may also mean that edge sites concerned
	with routing security will be attracted to upstreams which support		with routing 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 Invalid, 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. See [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
	intermediate non-signing edge routers, coverage will be spotty for a		intermediate non-signing edge routers, coverage will be spotty for a
	long time. Hence a normal operator's policy SHOULD NOT be overly		long time. Hence a normal operator's policy SHOULD NOT be overly
	strict, perhaps preferring Valid paths and giving very low		strict, perhaps preferring Valid paths and giving very low
	preference, but still using, Invalid paths.		preference, but still using, Not Valid paths.
	Operators should be aware that accepting Invalid announcements, no		Operators should be aware that accepting Not Valid announcements, no
	matter how de-preffed, will often be the equivalent of treating them		matter the local preference, will often be the equivalent of treating
	as fully Valid. Consider having a Valid announcement from neighbor V		them as fully Valid. Local preference affects only routes to the
	for prefix 10.0.0.0/16 and an Invalid announcement for 10.0.666.0/24		same set of destinations. Consider having a Valid announcement from
	from neighbor I. If local policy on the router is not configured to		neighbor V for prefix 10.0.0.0/16 and an Not Valid announcement for
	discard the Invalid announcement from I, then longest match		10.0.666.0/24 from neighbor I. If local policy on the router is not
	forwarding will send packets to neighbor I no matter the value of		configured to discard the Not Valid announcement from I, then longest
	local preference.		match forwarding will send packets to neighbor I no matter the value
			of local preference.
	A BGPsec speaker validates signed paths 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 MED. Some may choose to use the large Local-Pref
	hammer. Others may choose to let AS-Path rule and set their internal		hammer. Others may choose to let AS-Path rule and set their internal
	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 Invalid and yet propagated (because they are chosen as best		that are Not Valid and yet propagated (because they are chosen as
	path) SHOULD have their signatures kept intact and MUST be signed if		best path) SHOULD have their signatures kept intact and MUST be
	sent to external BGPsec speakers.		signed if sent to external BGPsec speakers.
	This implies that updates which a speaker judges to be Invalid MAY be		This implies that updates which a speaker judges to be Not Valid MAY
	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 Invalid. If needed,		otherwise, a signed path learned via iBGP MAY be Not Valid. If
	the validation state should be signaled by normal local policy		needed, the validation state should be signaled by normal local
	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 Invalid.		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', most importantly not		A route server is usually 'transparent'. To operate transparently in
	inserting its own AS into the AS_Path, to not lengthen the AS hop		an environment in which the route server connects BGPsec-enabled
	count and thereby reduce the likelihood of best path selection. See		peers, the route server MUST run BGPsec as well. A BGPsec-aware
	2.2.2 of [I-D.ietf-idr-ix-bgp-route-server]. A BGPsec-aware route		route server needs to validate the incoming BGPsec_Path, and to
	server needs to validate the incoming BGPSEC_Path, and to forward		forward updates which can be validated by clients which know the
	updates which can be validated by clients which know the route		route server's AS. This implies that the route server creates
	server's AS. The route server uses pCount of zero to not increase		signatures per client including its own AS in the BGPsec_Path and the
	the effective AS hop count.		target ASes, see 2.2.2 of [I-D.ietf-idr-ix-bgp-route-server]. The
			route server uses pCount of zero to not increase the effective AS hop
			count.
	If it is known that a BGPsec neighbor is not a transparent route		If it is known that a BGPsec neighbor is not a transparent route
	server, and the router provides a knob to disallow a received pCount		server, and the router provides a knob to disallow a received pCount
	(prepend count, zero for transparent route servers) of zero, that		(prepend count, zero for transparent route servers) of zero, that
	knob SHOULD be applied. Routers should default to this knob		knob SHOULD be applied. Routers should disallow pCount 0 by default.
	disallowing pCount 0.
	To prevent exposure of the internals of BGP Confederations [RFC5065],		To prevent exposure of the internals of BGP Confederations [RFC5065],
	a BGPsec speaker which is a Member-AS of a Confederation MUST NOT		a BGPsec speaker which is a Member-AS of a Confederation MUST NOT
	sign updates sent to another Member-AS of the same Confederation.		sign updates sent to another Member-AS of the same Confederation.
	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
	skipping to change at page 7, line 10 ¶		skipping to change at page 6, line 50 ¶
	As a router must evaluate certificates and ROAs which are time		As a router must evaluate certificates and ROAs which are time
	dependent, routers' clocks MUST be correct to a tolerance of		dependent, routers' clocks MUST be correct to a tolerance of
	approximately an hour.		approximately an hour.
	If a router has reason to believe its clock is seriously incorrect,		If a router has reason to believe its clock is seriously incorrect,
	e.g. it has a time earlier than 2011, it SHOULD NOT attempt to		e.g. it has a time earlier than 2011, it SHOULD NOT attempt to
	validate incoming updates. It SHOULD defer validation until it		validate incoming updates. It SHOULD defer validation until it
	believes it is within reasonable time tolerance.		believes it is within reasonable time tolerance.
	Servers should provide time service, such as [RFC5905], to client		Operators should deploy servers that provide time service, such as
	routers.		[RFC5905], to client routers.
	9. Security Considerations		9. Security Considerations
	The major security considerations for the BGPsec protocol are		The major security considerations for the BGPsec protocol are
	described in [I-D.ietf-sidr-bgpsec-protocol].		described in [I-D.ietf-sidr-bgpsec-protocol].
	10. IANA Considerations		10. IANA Considerations
	This document has no IANA Considerations.		This document has no IANA Considerations.
End of changes. 21 change blocks.
	52 lines changed or deleted		46 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/