draft-ietf-sidr-bgpsec-ops-00.txt		draft-ietf-sidr-bgpsec-ops-01.txt
	Network Working Group R. Bush		Network Working Group R. Bush
	Internet-Draft Internet Initiative Japan		Internet-Draft Internet Initiative Japan
	Intended status: BCP June 28, 2011		Intended status: BCP October 19, 2011
	Expires: December 30, 2011		Expires: April 21, 2012
	BGPsec Operational Considerations		BGPsec Operational Considerations
	draft-ietf-sidr-bgpsec-ops-00		draft-ietf-sidr-bgpsec-ops-01
	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 them. It is expected to evolve as BGPsec is formalized and		present them. It is expected to evolve as BGPsec is formalized and
	initially deployed.		initially deployed.
	Requirements Language		Requirements Language
	skipping to change at page 1, line 39		skipping to change at page 1, line 39
	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 30, 2011.		This Internet-Draft will expire on April 21, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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 4, line 20		skipping to change at page 4, line 20
	For redundancy, a router SHOULD peer with more than one cache at the		For redundancy, a router SHOULD peer with more than one cache at the
	same time. Peering with two or more, at least one local and others		same time. Peering with two or more, at least one local and others
	remote, is recommended.		remote, is recommended.
	If an operator trusts upstreams to carry their traffic, they SHOULD		If an operator trusts upstreams to carry their traffic, they SHOULD
	also trust the RPKI data those upstreams cache, and SHOULD peer with		also trust the RPKI data those upstreams cache, and SHOULD peer with
	those caches. Note that this places an obligation on those upstreams		those caches. Note that this places an obligation on those upstreams
	to maintain fresh and reliable caches.		to maintain fresh and reliable caches.
	A transit provider or a network with peers SHOULD validate NLRI in		A transit provider or a network with peers SHOULD validate NLRI in
	announcements made by upstreams, downstreams, and peers. They still		announcements made by upstreams, downstreams, and peers. To minimize
	SHOULD trust the caches provided by their upstreams.		impact on the global RPKI, they SHOULD fetch from and then revalidate
			data from caches provided by their upstreams.
	An environment where private address space is announced in eBGP the		An environment where private address space is announced in eBGP the
	operator MAY have private RPKI objects which cover these private		operator MAY have private RPKI objects which cover these private
	spaces. This will require a trust anchor created and owned by that		spaces. This will require a trust anchor created and owned by that
	environment, see [I-D.ietf-sidr-ltamgmt].		environment, see [I-D.ietf-sidr-ltamgmt].
	4. AS/Router Certificates		4. AS/Router Certificates
	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
	skipping to change at page 7, line 25		skipping to change at page 7, line 25
	otherwise, a signed path learned via iBGP MAY be invalid. If needed,		otherwise, a signed path learned via iBGP MAY be invalid. If needed,
	the validation state SHOULD be signaled by normal local policy		the validation state SHOULD be signaled by normal local policy
	mechanisms such as communities or metrics.		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 invalid.
	If a BGPsec speaker receives an unsigned path, it SHOULD perform		If a BGPsec speaker receives an unsigned path, it SHOULD perform
	origin validation per [I-D.ietf-sidr-pfx-validate].		origin validation per [I-D.ietf-sidr-pfx-validate].
			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
			(prepend count, zero for transparent route servers) of zero, that
			knob SHOULD be applied.
	9. Notes		9. Notes
	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 than		or router may have different data about a particular prefix than
	another cache or router. There is no 'fix' for this, it is the		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 [I-D.ietf-sidr-ghostbusters]), signed indirectly by End		Records (see [I-D.ietf-sidr-ghostbusters]), signed indirectly by End
	skipping to change at page 8, line 30		skipping to change at page 8, line 33
	13.1. Normative References		13.1. Normative References
	[I-D.ietf-sidr-bgpsec-protocol]		[I-D.ietf-sidr-bgpsec-protocol]
	Lepinski, M., "BGPSEC Protocol Specification",		Lepinski, M., "BGPSEC Protocol Specification",
	draft-ietf-sidr-bgpsec-protocol-00 (work in progress),		draft-ietf-sidr-bgpsec-protocol-00 (work in progress),
	June 2011.		June 2011.
	[I-D.ietf-sidr-ghostbusters]		[I-D.ietf-sidr-ghostbusters]
	Bush, R., "The RPKI Ghostbusters Record",		Bush, R., "The RPKI Ghostbusters Record",
	draft-ietf-sidr-ghostbusters-03 (work in progress),		draft-ietf-sidr-ghostbusters-15 (work in progress),
	March 2011.		October 2011.
	[I-D.ietf-sidr-roa-format]		[I-D.ietf-sidr-roa-format]
	Lepinski, M., Kent, S., and D. Kong, "A Profile for Route		Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
	Origin Authorizations (ROAs)",		Origin Authorizations (ROAs)",
	draft-ietf-sidr-roa-format-12 (work in progress),		draft-ietf-sidr-roa-format-12 (work in progress),
	May 2011.		May 2011.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	skipping to change at page 9, line 11		skipping to change at page 9, line 15
	progress), May 2011.		progress), May 2011.
	[I-D.ietf-sidr-ltamgmt]		[I-D.ietf-sidr-ltamgmt]
	Reynolds, M. and S. Kent, "Local Trust Anchor Management		Reynolds, M. and S. Kent, "Local Trust Anchor Management
	for the Resource Public Key Infrastructure",		for the Resource Public Key Infrastructure",
	draft-ietf-sidr-ltamgmt-02 (work in progress), June 2011.		draft-ietf-sidr-ltamgmt-02 (work in progress), June 2011.
	[I-D.ietf-sidr-pfx-validate]		[I-D.ietf-sidr-pfx-validate]
	Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.		Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
	Austein, "BGP Prefix Origin Validation",		Austein, "BGP Prefix Origin Validation",
	draft-ietf-sidr-pfx-validate-01 (work in progress),		draft-ietf-sidr-pfx-validate-02 (work in progress),
	February 2011.		July 2011.
	[I-D.ietf-sidr-repos-struct]		[I-D.ietf-sidr-repos-struct]
	Huston, G., Loomans, R., and G. Michaelson, "A Profile for		Huston, G., Loomans, R., and G. Michaelson, "A Profile for
	Resource Certificate Repository Structure",		Resource Certificate Repository Structure",
	draft-ietf-sidr-repos-struct-08 (work in progress),		draft-ietf-sidr-repos-struct-09 (work in progress),
	June 2011.		July 2011.
	[I-D.lepinski-bgpsec-overview]		[I-D.lepinski-bgpsec-overview]
	Lepinski, M. and S. Turner, "An Overview of BGPSEC",		Lepinski, M. and S. Turner, "An Overview of BGPSEC",
	draft-lepinski-bgpsec-overview-00 (work in progress),		draft-lepinski-bgpsec-overview-00 (work in progress),
	March 2011.		March 2011.
	[I-D.ymbk-rfd-usable]		[I-D.ymbk-rfd-usable]
	Pelsser, C., Bush, R., Patel, K., Mohapatra, P., and O.		Pelsser, C., Bush, R., Patel, K., Mohapatra, P., and O.
	Maennel, "Making Route Flap Damping Usable",		Maennel, "Making Route Flap Damping Usable",
	draft-ymbk-rfd-usable-00 (work in progress), March 2011.		draft-ymbk-rfd-usable-01 (work in progress), June 2011.
	[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway		[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
	Protocol 4 (BGP-4)", RFC 4271, January 2006.		Protocol 4 (BGP-4)", RFC 4271, January 2006.
	[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network		[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
	Time Protocol Version 4: Protocol and Algorithms		Time Protocol Version 4: Protocol and Algorithms
	Specification", RFC 5905, June 2010.		Specification", RFC 5905, June 2010.
	Author's Address		Author's Address
End of changes. 9 change blocks.
	13 lines changed or deleted		19 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/