draft-ietf-sidr-bgpsec-ops-11.txt		draft-ietf-sidr-bgpsec-ops-12.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 2, 2016		Intended status: Best Current Practice December 6, 2016
	Expires: June 5, 2017		Expires: June 9, 2017
	BGPsec Operational Considerations		BGPsec Operational Considerations
	draft-ietf-sidr-bgpsec-ops-11		draft-ietf-sidr-bgpsec-ops-12
	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 5, 2017.		This Internet-Draft will expire on June 9, 2017.
	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 6, line 26 ¶		skipping to change at page 6, line 26 ¶
	uses pCount of zero to not increase the effective AS hop count,		uses pCount of zero to not increase the effective AS hop count,
	thereby retaining the intent of 'transparency'.		thereby retaining the intent of 'transparency'.
	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, or is otherwise validly using pCount=0 (e,g, see		server, or is otherwise validly using pCount=0 (e,g, see
	[I-D.ietf-sidr-as-migration]), and the router provides a knob to		[I-D.ietf-sidr-as-migration]), and the router provides a knob to
	disallow a received pCount (of zero, that knob SHOULD be applied.		disallow a received pCount (of zero, that knob SHOULD be applied.
	Routers should disallow pCount 0 by default.		Routers should disallow pCount 0 by default.
	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 exporting to a non-member removes all intra-
	sign updates sent to another Member-AS of the same Confederation.		confederation Secure_Path segments. Therefore signing within the
			confederation will not cause external confusion even if non-unique
			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]
	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
End of changes. 4 change blocks.
	6 lines changed or deleted		8 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/