< draft-ietf-sidr-usecases-00.txt		draft-ietf-sidr-usecases-01.txt >
	Secure Inter-Domain Routing T. Manderson		Secure Inter-Domain Routing T. Manderson
	Internet-Draft ICANN		Internet-Draft ICANN
	Intended status: Informational K. Sriram		Intended status: Informational K. Sriram
	Expires: December 23, 2010 NIST		Expires: June 25, 2011 US NIST
	R. White		R. White
	Cisco		Cisco
	June 21, 2010		December 22, 2010
	Use Cases and interpretation of RPKI objects for issuers and relying		Use Cases and interpretation of RPKI objects for issuers and relying
	parties		parties
	draft-ietf-sidr-usecases-00		draft-ietf-sidr-usecases-01
	Abstract		Abstract
	This document provides use cases, directions, and interpretations for		This document provides use cases, directions, and interpretations for
	organizations and relying parties when creating or encountering RPKI		organizations and relying parties when creating or encountering RPKI
	object scenarios in the public RPKI in relation to the Internet		object scenarios in the public RPKI in relation to the Internet
	routing system.		routing system.
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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 23, 2010.		This Internet-Draft will expire on June 25, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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 14 ¶		skipping to change at page 2, line 14 ¶
	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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
	1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5		1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5
	2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.1. General interpretation of RPKI object semantics . . . . . 5		2.1. General interpretation of RPKI object semantics . . . . . 6
	3. Origination Use Cases . . . . . . . . . . . . . . . . . . . . 6		3. Origination Use Cases . . . . . . . . . . . . . . . . . . . . 6
	3.1. Single Announcement . . . . . . . . . . . . . . . . . . . 6		3.1. Single Announcement . . . . . . . . . . . . . . . . . . . 6
	3.2. Aggregate with a More Specific . . . . . . . . . . . . . . 6		3.2. Aggregate with a More Specific . . . . . . . . . . . . . . 6
	3.3. Aggregate with a More Specific from a Different ASN . . . 7		3.3. Aggregate with a More Specific from a Different ASN . . . 7
	3.4. Sub-allocation to a Multi-homed Customer . . . . . . . . . 7		3.4. Sub-allocation to a Multi-homed Customer . . . . . . . . . 7
	3.5. Restriction of a New Allocation . . . . . . . . . . . . . 8		3.5. Restriction of a New Allocation . . . . . . . . . . . . . 8
	3.6. Restriction of New ASN . . . . . . . . . . . . . . . . . . 8		3.6. Restriction of New ASN . . . . . . . . . . . . . . . . . . 8
	3.7. Restriction of a Part of an Allocation . . . . . . . . . . 8		3.7. Restriction of a Part of an Allocation . . . . . . . . . . 9
	3.8. Restriction of Prefix Length . . . . . . . . . . . . . . . 9		3.8. Restriction of Prefix Length . . . . . . . . . . . . . . . 9
	3.9. Restriction of Sub-allocation Prefix Length . . . . . . . 10		3.9. Restriction of Sub-allocation Prefix Length . . . . . . . 10
	3.10. Aggregation and Origination by an Upstream . . . . . . . . 10		3.10. Aggregation and Origination by an Upstream . . . . . . . . 10
	3.11. Rogue Aggregation and Origination by an Upstream . . . . . 11		3.11. Rogue Aggregation and Origination by an Upstream . . . . . 11
	4. Adjacency Use Cases . . . . . . . . . . . . . . . . . . . . . 12		4. Adjacency Use Cases . . . . . . . . . . . . . . . . . . . . . 12
	4.1. Multi-homed . . . . . . . . . . . . . . . . . . . . . . . 12		4.1. Multi-homed . . . . . . . . . . . . . . . . . . . . . . . 12
	4.2. Restricting Peers . . . . . . . . . . . . . . . . . . . . 12		4.2. Restricting Peers . . . . . . . . . . . . . . . . . . . . 13
	5. Partial Deployment Use Cases . . . . . . . . . . . . . . . . . 13		5. Partial Deployment Use Cases . . . . . . . . . . . . . . . . . 13
	5.1. Parent does not do RPKI . . . . . . . . . . . . . . . . . 13		5.1. Parent does not do RPKI . . . . . . . . . . . . . . . . . 13
	5.2. Only Some Children Participate in RPKI . . . . . . . . . . 14		5.2. Only Some Children Participate in RPKI . . . . . . . . . . 14
	5.3. Grandchild Does Not Particpate in RPKI . . . . . . . . . . 14		5.3. Grandchild Does Not Participate in RPKI . . . . . . . . . 14
	6. Transfer Use Cases . . . . . . . . . . . . . . . . . . . . . . 15		6. Transfer Use Cases . . . . . . . . . . . . . . . . . . . . . . 15
	6.1. Transfer of in-use prefix and autonomous system number . . 15		6.1. Transfer of in-use prefix and autonomous system number . . 15
	6.2. Transfer of in-use prefix . . . . . . . . . . . . . . . . 15		6.2. Transfer of in-use prefix . . . . . . . . . . . . . . . . 15
	6.3. Transfer of un-used prefix . . . . . . . . . . . . . . . . 15		6.3. Transfer of un-used prefix . . . . . . . . . . . . . . . . 15
	7. Relying Party Use Cases . . . . . . . . . . . . . . . . . . . 16		7. Relying Party Use Cases . . . . . . . . . . . . . . . . . . . 16
	7.1. ROA Expiry or receipt of a CRL covering a ROA . . . . . . 16		7.1. ROA Expiry or receipt of a CRL covering a ROA . . . . . . 16
	7.1.1. ROA of Parent Prefix is Revoked . . . . . . . . . . . 16		7.1.1. ROA of Parent Prefix is Revoked . . . . . . . . . . . 16
	7.1.2. ROA of Prefix Revoked . . . . . . . . . . . . . . . . 16		7.1.2. ROA of Prefix Revoked . . . . . . . . . . . . . . . . 16
	7.1.3. ROA of Grandparent Prefix Revoked while that of		7.1.3. ROA of Grandparent Prefix Revoked while that of
	Parent Prefix Prevails . . . . . . . . . . . . . . . . 16		Parent Prefix Prevails . . . . . . . . . . . . . . . . 16
	7.1.4. ROA of Prefix Revoked while that of Parent Prefix		7.1.4. ROA of Prefix Revoked while that of Parent Prefix
	Prevails . . . . . . . . . . . . . . . . . . . . . . . 17		Prevails . . . . . . . . . . . . . . . . . . . . . . . 17
	7.1.5. Expiry of ROA of Parent Prefix . . . . . . . . . . . . 17		7.1.5. Expiry of ROA of Parent Prefix . . . . . . . . . . . . 17
	7.1.6. Expiry of ROA of Prefix . . . . . . . . . . . . . . . 17		7.1.6. Expiry of ROA of Prefix . . . . . . . . . . . . . . . 17
	7.1.7. Expiry of ROA of Grandparent Prefix while ROA of		7.1.7. Expiry of ROA of Grandparent Prefix while ROA of
	Parent Prefix Prevails . . . . . . . . . . . . . . . . 17		Parent Prefix Prevails . . . . . . . . . . . . . . . . 17
	7.1.8. Expiry of ROA of Prefix while ROA of Parent Prefix		7.1.8. Expiry of ROA of Prefix while ROA of Parent Prefix
	Prevails . . . . . . . . . . . . . . . . . . . . . . . 18		Prevails . . . . . . . . . . . . . . . . . . . . . . . 18
	7.2. Prefix, Origin Validation use cases . . . . . . . . . . . 18		7.2. Prefix, Origin Validation use cases . . . . . . . . . . . 18
	7.2.1. Covering ROA Prefix, Maxlength Satisfied, and AS		7.2.1. Covering ROA Prefix, maxLength Satisfied, and AS
	Match . . . . . . . . . . . . . . . . . . . . . . . . 18		Match . . . . . . . . . . . . . . . . . . . . . . . . 18
	7.2.2. Covering ROA Prefix, Maxlength Exceeded, and AS		7.2.2. Covering ROA Prefix, maxLength Exceeded, and AS
	Match . . . . . . . . . . . . . . . . . . . . . . . . 18		Match . . . . . . . . . . . . . . . . . . . . . . . . 18
	7.2.3. Covering ROA Prefix, Maxlength Satisfied, and AS		7.2.3. Covering ROA Prefix, maxLength Satisfied, and AS
	Mismatch: . . . . . . . . . . . . . . . . . . . . . . 19		Mismatch: . . . . . . . . . . . . . . . . . . . . . . 19
	7.2.4. Covering ROA Prefix, Maxlength Exceeded, and AS		7.2.4. Covering ROA Prefix, maxLength Exceeded, and AS
	Mismatch . . . . . . . . . . . . . . . . . . . . . . . 19		Mismatch . . . . . . . . . . . . . . . . . . . . . . . 19
	7.2.5. Covering ROA Prefix Not Found . . . . . . . . . . . . 19		7.2.5. Covering ROA Prefix Not Found . . . . . . . . . . . . 19
	7.2.6. Covering ROA Prefix Not Found but ROAs Exist for a		7.2.6. Covering ROA Prefix Not Found but ROAs Exist for a
	Covering Set of More Specifics . . . . . . . . . . . . 19		Covering Set of More Specifics . . . . . . . . . . . . 20
	7.2.7. Update has an AS Set as Origin and ROAs Exist for		7.2.7. AS_SET in Update and Covering ROA Prefix Not Found . . 20
	a Covering Set of More Specifics . . . . . . . . . . . 20		7.2.8. Singleton AS in AS_SET (in the Update), Covering
	7.2.8. Update has AS set, Aggregator AS Absent, and		ROA Prefix, and AS Match . . . . . . . . . . . . . . . 20
	Covering ROA Prefix Not Found . . . . . . . . . . . . 21		7.2.9. Singleton AS in AS_SET (in the Update), Covering
	7.2.9. Update has AS set, Aggregator AS Absent, and
	Covering ROA Prefix . . . . . . . . . . . . . . . . . 21
	7.2.10. Update has AS set, Aggregator AS Present, and
	Covering ROA Prefix Not Found . . . . . . . . . . . . 21
	7.2.11. Update has AS set, Aggregator AS Present, Covering
	ROA Prefix, and AS Mismatch . . . . . . . . . . . . . 21		ROA Prefix, and AS Mismatch . . . . . . . . . . . . . 21
	7.2.12. Update has AS set, Aggregator AS Present, Covering		7.2.10. Multiple ASs in AS_SET (in the Update) and
	ROA Prefix, and AS Match . . . . . . . . . . . . . . . 21		Covering ROA Prefix . . . . . . . . . . . . . . . . . 21
			7.2.11. Update has an AS_SET as Origin and ROAs Exist for
			a Covering Set of More Specifics . . . . . . . . . . . 21
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 22		10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
	11. Normative References . . . . . . . . . . . . . . . . . . . . . 22		11. Normative References . . . . . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	This document provides suggested use cases, directions, and		This document provides suggested use cases, directions, and
	interpretations for organizations and relying parties when creating		interpretations for organizations and relying parties when creating
	skipping to change at page 4, line 21 ¶		skipping to change at page 4, line 21 ¶
	1.1. Terminology		1.1. Terminology
	It is assumed that the reader is familiar with the terms and concepts		It is assumed that the reader is familiar with the terms and concepts
	described in "Internet X.509 Public Key Infrastructure Certificate		described in "Internet X.509 Public Key Infrastructure Certificate
	and Certificate Revocation List (CRL) Profile" [RFC5280], "A Profile		and Certificate Revocation List (CRL) Profile" [RFC5280], "A Profile
	for X.509 PKIX Resource Certificates" [I-D.ietf-sidr-res-certs]		for X.509 PKIX Resource Certificates" [I-D.ietf-sidr-res-certs]
	"X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779], "A		"X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779], "A
	Profile for Route Origin Authorizations (ROAs)"		Profile for Route Origin Authorizations (ROAs)"
	[I-D.ietf-sidr-roa-format], "Validation of Route Origination in BGP		[I-D.ietf-sidr-roa-format], "Validation of Route Origination in BGP
	using the Resource Certificate PKI" [I-D.ietf-sidr-roa-validation],		using the Resource Certificate PKI and ROAs"
			[I-D.ietf-sidr-roa-validation], and BGP Prefix Origin Validation"
			[I-D.pmohapat-sidr-pfx-validate].
	1.2. Definitions		1.2. Definitions
	The following definitions are in use in this document.		The following definitions are in use in this document.
	Autonomous System - A network under a single technical administration		Autonomous System - A network under a single technical administration
	that presents a consistent picture of what destinations are reachable		that presents a consistent picture of what destinations are reachable
	through it.		through it.
	Autonomous System Number (ASN) - An officially registered number		Autonomous System Number (ASN) - An officially registered number
	representing an autonomous system.		representing an autonomous system.
	Prefix - A network address and an integer that specifies the length		Prefix - A network address and an integer that specifies the length
	of a mask to be applied to the address to represent a set of		of a mask to be applied to the address to represent a set of
	numerically adjacent addresses.		numerically adjacent addresses.
	Route - A prefix and a sequence of one or more autonomous system		Route - A prefix and a sequence of one or more autonomous system
	numbers.		numbers.
	Origin AS - The Autonomous System, designated by an ASN, which		Origin AS - The Autonomous System, designated by an ASN, which
	originates a route. Seen as the "First" ASN in a route		originates a route. Seen as the "First" ASN in a route.
	Specific route - A route that has a longer prefix than an aggregate.		Specific route - A route that has a longer prefix than an aggregate.
	Aggregate route - A more general route in the presence of a specific		Aggregate route - A more general route in the presence of a specific
	route.		route.
	Covering Aggregate - A route that covers one or more specific routes.		Covering Aggregate - A route that covers one or more specific routes.
	Multi-homed - An Autonomous System that is connected, and announces		Multi-homed Autonomous System - An Autonomous System that is
	routes, to one or more Autonomous Systems		connected, and announces routes, to two or more Autonomous Systems.
			Multi-homed prefix or subnet - A prefix (i.e., subnet) that is
			originated via two or more Autonomous Systems to which the subnet is
			connected.
	Resource - Internet (IP) addresses or Autonomous System Number.		Resource - Internet (IP) addresses or Autonomous System Number.
	Allocation - The set of resources provided to an entity or		Allocation - The set of resources provided to an entity or
	organization for its use.		organization for its use.
	Sub-allocation - The set of a resources subordinate to an allocation		Sub-allocation - The set of a resources subordinate to an allocation
	assigned to another entity or organization.		assigned to another entity or organization.
	Transit Provider - An Autonomous System that carries traffic that		Transit Provider - An Autonomous System that carries traffic that
	neither originates nor is the destination of that traffic.		neither originates nor is the destination of that traffic.
	Upstream - See "Transit Provider".		Upstream - See "Transit Provider".
	Child - A Sub-allocation that has resulted from an Allocation		Child - A Sub-allocation that has resulted from an Allocation.
	Parent - An allocation from which the subject prefix is a Child		Parent - An allocation from which the subject prefix is a Child.
	Grandchild - A Sub-allocation from or more previous Sub-allocations.		Grandchild - A Sub-allocation from one or more previous Sub-
			allocations.
	Grandparent - The allocation from which the prefix is a Grandchild.		Grandparent - The allocation from which the prefix is a Grandchild.
	Update prefix - The prefix seen in a routing update		Update prefix - The prefix seen in a routing update.
	ROA prefix - The prefix described in a ROA		ROA prefix - The prefix described in a ROA.
	Covering Prefix - The ROA Prefix is an exact match or a less specific		Covering Prefix - The ROA Prefix is an exact match or a less specific
	when compared to the update prefix.		when compared to the update prefix.
	No relevant ROA - No ROA exists that has a covering prefix for the		No relevant ROA - No ROA exists that has a covering prefix for the
	update prefix.		update prefix.
	No other relevant ROA - No other ROA (besides any that is(are)		No other relevant ROA - No other ROA (besides any that is(are)
	already cited) that has a covering prefix for the update prefix		already cited) that has a covering prefix for the update prefix.
	1.3. Requirements Language		1.3. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119.		document are to be interpreted as described in RFC 2119.
	2. Overview		2. Overview
	2.1. General interpretation of RPKI object semantics		2.1. General interpretation of RPKI object semantics
	skipping to change at page 6, line 19 ¶		skipping to change at page 6, line 27 ¶
	stated.		stated.
	While many of the examples provided here illustrate organizations		While many of the examples provided here illustrate organizations
	using their own autonomous system numbers to originate routes, it		using their own autonomous system numbers to originate routes, it
	should be recognised that a prefix holder need not necessarily be the		should be recognised that a prefix holder need not necessarily be the
	holder of the autonomous system number used for the route		holder of the autonomous system number used for the route
	origination.		origination.
	3. Origination Use Cases		3. Origination Use Cases
	This section deals with the various use cases where an orgnaistion		This section deals with the various use cases where an organization
	has Internet resources and will announce routes to the Internet. It		has Internet resources and will announce routes to the Internet. It
	is based on operational observations of the existing routing system.		is based on operational observations of the existing routing system.
	3.1. Single Announcement		3.1. Single Announcement
	An organization (Org A with ASN 64496) has been allocated the prefix		An organization (Org A with ASN 64496) has been allocated the prefix
	192.168.2.0/24. It wishes to announce the /24 prefix from ASN 64496		192.168.2.0/24. It wishes to announce the /24 prefix from ASN 64496
	such that relying parties interpret the route as intended.		such that relying parties interpret the route as intended.
	The desired announcement (and organization) would be:		The desired announcement (and organization) would be:
	skipping to change at page 8, line 29 ¶		skipping to change at page 8, line 37 ¶
	| 10.1.0.0/16 | ANY AS | ANY |		| 10.1.0.0/16 | ANY AS | ANY |
	| 10.1.0.0/20 | ANY AS | ANY |		| 10.1.0.0/20 | ANY AS | ANY |
	| 10.1.17.0/24 | ANY AS | ANY |		| 10.1.17.0/24 | ANY AS | ANY |
	+---------------------------------------------+		+---------------------------------------------+
	The issuing party would create the following RPKI objects: TBC		The issuing party would create the following RPKI objects: TBC
	3.6. Restriction of New ASN		3.6. Restriction of New ASN
	An organization has recently been allocated an additional 4 byte ASN		An organization has recently been allocated an additional 4 byte ASN
	65551. Its network deployment is not yet ready to use this ASN and		65535. Its network deployment is not yet ready to use this ASN and
	wishes to restrict all possible uses of ASN 65551 using RPKI.		wishes to restrict all possible uses of ASN 65535 using RPKI.
	The following announcements would be considered undesirable:		The following announcements would be considered undesirable:
	+---------------------------------------------+		+---------------------------------------------+
	| Prefix | Origin AS |Organization |		| Prefix | Origin AS |Organization |
	+---------------------------------------------+		+---------------------------------------------+
	| ANY | AS65551 | ANY |		| ANY | AS65535 | ANY |
	+---------------------------------------------+		+---------------------------------------------+
	The issuing party would create the following RPKI objects: TBC		The issuing party would create the following RPKI objects: TBC
	3.7. Restriction of a Part of an Allocation		3.7. Restriction of a Part of an Allocation
	An organization (Org A with ASN 64496) has been allocated the prefix		An organization (Org A with ASN 64496) has been allocated the prefix
	10.1.0.0/16. Its network topology permits the announcement of		10.1.0.0/16. Its network topology permits the announcement of
	10.1.0.0/17 and the /16 aggregate. However it wishes to restrict any		10.1.0.0/17 and the /16 aggregate. However it wishes to restrict any
	possible announcement of 10.1.128.0/17 or more specifics of that /17		possible announcement of 10.1.128.0/17 or more specifics of that /17
	skipping to change at page 10, line 9 ¶		skipping to change at page 10, line 20 ¶
	| ... | ANY AS | ANY |		| ... | ANY AS | ANY |
	| 10.1.128.0/24 | ANY AS | ANY |		| 10.1.128.0/24 | ANY AS | ANY |
	+---------------------------------------------+		+---------------------------------------------+
	The issuing party would create the following RPKI objects: TBC		The issuing party would create the following RPKI objects: TBC
	3.9. Restriction of Sub-allocation Prefix Length		3.9. Restriction of Sub-allocation Prefix Length
	An organization (Org A with ASN 64496) has been allocated the prefix		An organization (Org A with ASN 64496) has been allocated the prefix
	10.1.0.0/16, it sub-allocates several /20 prefixes to its multi-homed		10.1.0.0/16, it sub-allocates several /20 prefixes to its multi-homed
	customers Org B with ASN 65551, and Org C with ASN 64499. It wishes		customers Org B with ASN 65535, and Org C with ASN 64499. It wishes
	to restrict those customers from advertising any corresponding routes		to restrict those customers from advertising any corresponding routes
	more specific than a /22.		more specific than a /22.
	The desired announcements would be:		The desired announcements would be:
	+---------------------------------------------+		+---------------------------------------------+
	| Prefix | Origin AS |Organization |		| Prefix | Origin AS |Organization |
	+---------------------------------------------+		+---------------------------------------------+
	| 10.1.0.0/16 | AS64496 | Org A |		| 10.1.0.0/16 | AS64496 | Org A |
	| 10.1.0.0/20 | AS65551 | Org B |		| 10.1.0.0/20 | AS65535 | Org B |
	| 10.1.128.0/20 | AS64499 | Org C |		| 10.1.128.0/20 | AS64499 | Org C |
	| 10.1.4.0/22 | AS65551 | Org B		| 10.1.4.0/22 | AS65535 | Org B
	+---------------------------------------------+		+---------------------------------------------+
	The following example announcements (and organization) would be		The following example announcements (and organization) would be
	considered undesirable:		considered undesirable:
	+---------------------------------------------+		+---------------------------------------------+
	| Prefix | Origin AS |Organization |		| Prefix | Origin AS |Organization |
	+---------------------------------------------+		+---------------------------------------------+
	| 10.1.0.0/24 | AS65551 | Org B |		| 10.1.0.0/24 | AS65535 | Org B |
	| 10.1.128.0/24 | AS64499 | Org C |		| 10.1.128.0/24 | AS64499 | Org C |
	| ..... | ... | ... |		| ..... | ... | ... |
	| 10.1.0.0/23 | ANY AS | ANY |		| 10.1.0.0/23 | ANY AS | ANY |
	+---------------------------------------------+		+---------------------------------------------+
	The issuing party would create the following RPKI objects: TBC		The issuing party would create the following RPKI objects: TBC
	3.10. Aggregation and Origination by an Upstream		3.10. Aggregation and Origination by an Upstream
	Consider four organizations with the following resources which were		Consider four organizations with the following resources, which were
	acquired independently from the transit provider.		acquired independently from any transit provider. .
	+-------------------------------------------------+		+-------------------------------------------------+
	| Organization | ASN | Prefix |		| Organization | ASN | Prefix |
	+-------------------------------------------------+		+-------------------------------------------------+
	| Org A | AS64496 | 10.1.0.0/24 |		| Org A | AS64496 | 10.1.0.0/24 |
	| Org B | AS65551 | 10.1.3.0/24 |		| Org B | AS65535 | 10.1.3.0/24 |
	| Org C | AS64499 | 10.1.1.0/24 |		| Org C | AS64499 | 10.1.1.0/24 |
	| Org D | AS64512 | 10.1.2.0/24 |		| Org D | AS64512 | 10.1.2.0/24 |
	+-------------------------------------------------+		+-------------------------------------------------+
	These organizations share a common upstream provider Transit A (ASN		These organizations share a common upstream provider Transit A (ASN
	64497) that originates an aggregate of these prefixes with the		64497) that originates an aggregate of these prefixes with the
	permission of all four organizations.		permission of all four organizations.
	The desired announcements (and organization) would be:		The desired announcements (and organization) would be:
	+----------------------------------------------+		+----------------------------------------------+
	| Prefix | Origin AS | Organization |		| Prefix | Origin AS | Organization |
	+----------------------------------------------+		+----------------------------------------------+
	| 10.1.0.0/24 | AS64496 | Org A |		| 10.1.0.0/24 | AS64496 | Org A |
	| 10.1.3.0/24 | AS65551 | Org B |		| 10.1.3.0/24 | AS65535 | Org B |
	| 10.1.1.0/24 | AS64499 | Org C |		| 10.1.1.0/24 | AS64499 | Org C |
	| 10.1.2.0/24 | AS64512 | Org D |		| 10.1.2.0/24 | AS64512 | Org D |
	| 10.1.0.0/22 | AS64497 | Transit A |		| 10.1.0.0/22 | AS64497 | Transit A |
	+----------------------------------------------+		+----------------------------------------------+
	The issuing parties would create the following RPKI objects: TBC		The issuing parties would create the following RPKI objects: TBC
	3.11. Rogue Aggregation and Origination by an Upstream		3.11. Rogue Aggregation and Origination by an Upstream
	Consider four organizations with the following resources which were		Consider four organizations with the following resources which were
	acquired independently from any transit provider.		acquired independently from any transit provider.
	+-------------------------------------------------+		+-------------------------------------------------+
	| Organization | ASN | Prefix |		| Organization | ASN | Prefix |
	+-------------------------------------------------+		+-------------------------------------------------+
	| Org A | AS64496 | 10.1.0.0/24 |		| Org A | AS64496 | 10.1.0.0/24 |
	| Org B | AS65551 | 10.1.3.0/24 |		| Org B | AS65535 | 10.1.3.0/24 |
	| Org C | AS64499 | 10.1.1.0/24 |		| Org C | AS64499 | 10.1.1.0/24 |
	| Org D | AS64512 | 10.1.2.0/24 |		| Org D | AS64512 | 10.1.2.0/24 |
	+-------------------------------------------------+		+-------------------------------------------------+
	These organizations share a common upstream provider Transit A (ASN		These organizations share a common upstream provider Transit A (ASN
	64497) that originates an aggregate of these prefixes where possible.		64497) that originates an aggregate of these prefixes where possible.
	In this situation organization B (ASN 65551, 10.1.3.0/24) does not		In this situation organization B (ASN 65535, 10.1.3.0/24) does not
	wish for its prefix to be aggregated by the upstream		wish for its prefix to be aggregated by the upstream
	The desired announcements (and organization) would be:		The desired announcements (and organization) would be:
	+----------------------------------------------+		+----------------------------------------------+
	| Prefix | Origin AS | Organization |		| Prefix | Origin AS | Organization |
	+----------------------------------------------+		+----------------------------------------------+
	| 10.1.0.0/24 | AS64496 | Org A |		| 10.1.0.0/24 | AS64496 | Org A |
	| 10.1.3.0/24 | AS65551 | Org B |		| 10.1.3.0/24 | AS65535 | Org B |
	| 10.1.1.0/24 | AS64499 | Org C |		| 10.1.1.0/24 | AS64499 | Org C |
	| 10.1.2.0/24 | AS64512 | Org D |		| 10.1.2.0/24 | AS64512 | Org D |
	| 10.1.0.0/23 | AS64497 | Transit A |		| 10.1.0.0/23 | AS64497 | Transit A |
	+----------------------------------------------+		+----------------------------------------------+
	The following announcement would be undesirable:		The following announcement would be undesirable:
	+----------------------------------------------+		+----------------------------------------------+
	| Prefix | Origin AS | Organization |		| Prefix | Origin AS | Organization |
	+----------------------------------------------+		+----------------------------------------------+
	| 10.1.0.0/22 | AS64497 | Transit A |		| 10.1.0.0/22 | AS64497 | Transit A |
	+----------------------------------------------+		+----------------------------------------------+
	The issuing parties would create the following RPKI objects: TBC		The issuing parties would create the following RPKI objects: TBC
	4. Adjacency Use Cases		4. Adjacency Use Cases
	Issues regarding validation of adjacency, or path validation, are		Issues regarding validation of adjacency, or path validation, are
	currently out of scope of the SIDR-WG charter. The use cases is this		currently out of scope of the SIDR-WG charter. The use cases in this
	section are listed here as a reminder that the work goes beyond		section are listed here as a reminder that the work goes beyond
	origination and at the stage when origination has been addressed by		origination and at the stage when origination has been addressed by
	the WG, a re-charter to encompass adjacency will allow consideration		the WG, a re-charter to encompass adjacency will allow consideration
	of these use cases.		of these use cases.
	4.1. Multi-homed		4.1. Multi-homed
	An organization (Org A with ASN 64496) has been allocated the prefix		An organization (Org A with ASN 64496) has been allocated the prefix
	10.1.0.0/16. Its upstreams transit providers are Transit A with ASN		10.1.0.0/16. Its upstream transit providers are Transit A with ASN
	65551 and Transit B ASN 64499. The organization announces the /16		65535 and Transit B with ASN 64499. The organization announces the
	aggregate. It permits that ASN 65551 and ASN 64499 may further pass		/16 aggregate. It permits that ASN 65535 and ASN 64499 may further
	on the aggregate route to their peers or upstreams.		pass on the aggregate route to their peers or upstreams.
	The following announcements and paths would be desired:		The following announcements and paths would be desired:
	+---------------------------------------------------------+		+---------------------------------------------------------+
	| Prefix | Origin AS | Path |		| Prefix | Origin AS | Path |
	+---------------------------------------------------------+		+---------------------------------------------------------+
	| 10.1.0.0/16 | AS64496 | AS64499 AS64496 |		| 10.1.0.0/16 | AS64496 | AS64499 AS64496 |
	| 10.1.0.0/16 | AS64496 | AS65551 AS64496 |		| 10.1.0.0/16 | AS64496 | AS65535 AS64496 |
	+---------------------------------------------------------+		+---------------------------------------------------------+
	The issuing parties would create the following RPKI objects: TBC		The issuing parties would create the following RPKI objects: TBC
	4.2. Restricting Peers		4.2. Restricting Peers
	An organization (Org A with ASN 64496) has been allocated the prefix		An organization (Org A with ASN 64496) has been allocated the prefix
	10.1.0.0/16. Its two upstreams are Transit X with ASN 65551 and		10.1.0.0/16. Its two upstreams are Transit X with ASN 65535 and
	Transit Y with ASN 64499. The organization (ASN 64496) peers with a		Transit Y with ASN 64499. The organization (ASN 64496) peers with a
	third AS, Peer Z with ASN 64511. Org A announces the more specific		third AS, Peer Z with ASN 64511. Org A announces the more specific
	10.1.0.0/24 and the /16 aggregate. It wishes that only ASNs 65551		10.1.0.0/24 and the /16 aggregate. It wishes that only ASNs 65535
	and 64499 may announce the aggregate and more specifics to their		and 64499 may announce the aggregate and more specifics to their
	upstreams. ASN 64511, the peer, may not further announce (pass on,		upstreams. ASN 64511, the peer, may not further announce (pass on,
	or leak) any routes for 10.1.0.0/16 and 10.1.0.0/24.		or leak) any routes for 10.1.0.0/16 and 10.1.0.0/24.
	The following announcements and paths would be desired:		The following announcements and paths would be desired:
	+---------------------------------------------------------+		+---------------------------------------------------------+
	| Prefix | Origin AS | Path |		| Prefix | Origin AS | Path |
	+---------------------------------------------------------+		+---------------------------------------------------------+
	| 10.1.0.0/16 | AS64496 | AS64499 AS64496 |		| 10.1.0.0/16 | AS64496 | AS64499 AS64496 |
	| 10.1.0.0/24 | AS64496 | AS64499 AS64496 |		| 10.1.0.0/24 | AS64496 | AS64499 AS64496 |
	| 10.1.0.0/16 | AS64496 | AS65551 AS64496 |		| 10.1.0.0/16 | AS64496 | AS65535 AS64496 |
	| 10.1.0.0/24 | AS64496 | AS65551 AS64496 |		| 10.1.0.0/24 | AS64496 | AS65535 AS64496 |
	| 10.1.0.0/16 | AS64496 | Any_AS AS64499 AS64496 |		| 10.1.0.0/16 | AS64496 | Any_AS AS64499 AS64496 |
	| 10.1.0.0/24 | AS64496 | Any_AS AS64499 AS64496 |		| 10.1.0.0/24 | AS64496 | Any_AS AS64499 AS64496 |
	| 10.1.0.0/16 | AS64496 | Any_AS AS65551 AS64496 |		| 10.1.0.0/16 | AS64496 | Any_AS AS65535 AS64496 |
	| 10.1.0.0/24 | AS64496 | Any_AS AS65551 AS64496 |		| 10.1.0.0/24 | AS64496 | Any_AS AS65535 AS64496 |
	| 10.1.0.0/16 | AS64496 | AS64511 AS64496 |		| 10.1.0.0/16 | AS64496 | AS64511 AS64496 |
	| 10.1.0.0/24 | AS64496 | AS64511 AS64496 |		| 10.1.0.0/24 | AS64496 | AS64511 AS64496 |
	+---------------------------------------------------------+		+---------------------------------------------------------+
	The following announcements and paths would be considered		The following announcements and paths would be considered
	undesirable:		undesirable:
	+---------------------------------------------------------+		+---------------------------------------------------------+
	| Prefix | Origin AS | Path |		| Prefix | Origin AS | Path |
	+---------------------------------------------------------+		+---------------------------------------------------------+
	skipping to change at page 13, line 40 ¶		skipping to change at page 13, line 50 ¶
	| 10.1.0.0/24 | AS64496 | Any_AS AS64511 AS64496 |		| 10.1.0.0/24 | AS64496 | Any_AS AS64511 AS64496 |
	+---------------------------------------------------------+		+---------------------------------------------------------+
	The issuing parties would create the following RPKI objects: TBC		The issuing parties would create the following RPKI objects: TBC
	5. Partial Deployment Use Cases		5. Partial Deployment Use Cases
	5.1. Parent does not do RPKI		5.1. Parent does not do RPKI
	An organization (Org A with ASN 64511) is multi-homed has been		An organization (Org A with ASN 64511) is multi-homed has been
	assigned the prefix 10.1.0.0/20 from its upstream (Transit A with ASN		assigned the prefix 10.1.0.0/20 from its upstream (Transit X with ASN
	64496) Org A wishes to announce the prefix 10.1.0.0/20 from ASN 64511		64496). Org A wishes to announce the prefix 10.1.0.0/20 from ASN
	to its other upstream(s). Org A also wishes to create RPKI		64511 to its other upstream(s). Org A also wishes to create RPKI
	statements about the resource, however Transit A (ASN 64496) which		statements about the resource, however Transit X (ASN 64496) which
	announces the aggregate 10.1.0.0/16 has not yet adopted RPKI.		announces the aggregate 10.1.0.0/16 has not yet adopted RPKI.
	The desired announcements (and organization with RPKI adoption) would		The desired announcements (and organization with RPKI adoption) would
	be:		be:
	+----------------------------------------------------+		+----------------------------------------------------+
	| Prefix | Origin AS |Organization | RPKI |		| Prefix | Origin AS |Organization | RPKI |
	+----------------------------------------------------+		+----------------------------------------------------+
	| 10.1.0.0/20 | AS64511 | Org A | Yes |		| 10.1.0.0/20 | AS64511 | Org A | Yes |
	| 10.1.0.0/16 | AS64496 | Transit A | No |		| 10.1.0.0/16 | AS64496 | Transit X | No |
	+----------------------------------------------------+		+----------------------------------------------------+
	The issuing parties would create the following RPKI objects: TBC		The issuing parties would create the following RPKI objects: TBC
	5.2. Only Some Children Participate in RPKI		5.2. Only Some Children Participate in RPKI
	An organization (Org A with ASN 64496) has been allocated the prefix		An organization (Org A with ASN 64496) has been allocated the prefix
	10.1.0.0/16 and participates in RPKI, it wishes to announce the more		10.1.0.0/16 and participates in RPKI, it wishes to announce the more
	specific prefix 10.1.0.0/20 from ASN 64496. It has further delegated		specific prefix 10.1.0.0/20 from ASN 64496. It has further delegated
	10.1.16.0/20 and 10.1.32.0/20 to customers Org B with ASN 64511 and		10.1.16.0/20 and 10.1.32.0/20 to customers Org B with ASN 64511 and
	and Org C with ASN 65551 (respectively) who are multi-homed. Org B		and Org C with ASN 65535 (respectively) who are multi-homed. Org B
	(ASN 64511) does not participate in RPKI. Org C (ASN 65551)		(ASN 64511) does not participate in RPKI. Org C (ASN 65535)
	participates in RPKI.		participates in RPKI.
	The desired announcements (and organization with RPKI adoption) would		The desired announcements (and organization with RPKI adoption) would
	be:		be:
	+----------------------------------------------------+		+----------------------------------------------------+
	| Prefix | Origin AS |Organization | RPKI |		| Prefix | Origin AS |Organization | RPKI |
	+----------------------------------------------------+		+----------------------------------------------------+
	| 10.1.0.0/16 | AS64496 | Org A | Yes |		| 10.1.0.0/16 | AS64496 | Org A | Yes |
	| 10.1.0.0/20 | AS64496 | Org A | Yes |		| 10.1.0.0/20 | AS64496 | Org A | Yes |
	| 10.1.16.0/20 | AS64511 | Org B | No |		| 10.1.16.0/20 | AS64511 | Org B | No |
	| 10.1.32.0/20 | AS65551 | Org C | YES |		| 10.1.32.0/20 | AS65535 | Org C | YES |
	+----------------------------------------------------+		+----------------------------------------------------+
	The issuing parties would create the following RPKI objects: TBC		The issuing parties would create the following RPKI objects: TBC
	5.3. Grandchild Does Not Particpate in RPKI		5.3. Grandchild Does Not Participate in RPKI
	Consider the previous example with an extension by where Org B, who		Consider the previous example with an extension by where Org B, who
	does not participate in RPKI, further allocates 10.1.17.0/24 to Org X		does not participate in RPKI, further allocates 10.1.17.0/24 to Org X
	with ASN 64512. Org X does not participate in RPKI		with ASN 64512. Org X does not participate in RPKI.
	The desired announcements (and organization with RPKI adoption) would		The desired announcements (and organization with RPKI adoption) would
	be:		be:
	+----------------------------------------------------+		+----------------------------------------------------+
	| Prefix | Origin AS |Organization | RPKI |		| Prefix | Origin AS |Organization | RPKI |
	+----------------------------------------------------+		+----------------------------------------------------+
	| 10.1.0.0/16 | AS64496 | Org A | Yes |		| 10.1.0.0/16 | AS64496 | Org A | Yes |
	| 10.1.0.0/20 | AS64496 | Org A | Yes |		| 10.1.0.0/20 | AS64496 | Org A | Yes |
	| 10.1.16.0/20 | AS64511 | Org B | No |		| 10.1.16.0/20 | AS64511 | Org B | No |
	| 10.1.32.0/20 | AS65551 | Org C | YES |		| 10.1.32.0/20 | AS65535 | Org C | YES |
	| 10.1.17.0/24 | AS64512 | Org X | No |		| 10.1.17.0/24 | AS64512 | Org X | No |
	+----------------------------------------------------+		+----------------------------------------------------+
	The issuing parties would create the following RPKI objects: TBC		The issuing parties would create the following RPKI objects: TBC
	6. Transfer Use Cases		6. Transfer Use Cases
	6.1. Transfer of in-use prefix and autonomous system number		6.1. Transfer of in-use prefix and autonomous system number
	Organization A holds the resource 10.1.0.0/20 and is currently in use		Organization A holds the resource 10.1.0.0/20 and it is currently in
	and originated from AS64496 with valid RPKI objects in place.		use and originated from AS64496 with valid RPKI objects in place.
	Organization B has acquired both the prefix and ASN and desires an		Organization B has acquired both the prefix and ASN and desires an
	RPKI transfer on a particular date and time without adversely		RPKI transfer on a particular date and time without adversely
	affecting the operational use of the resource.		affecting the operational use of the resource.
	The following RPKI objects would be created/revoked: TBC		The following RPKI objects would be created/revoked: TBC
	6.2. Transfer of in-use prefix		6.2. Transfer of in-use prefix
	Organization A holds the resource 10.1.0.0/8 and it is currently in		Organization A holds the resource 10.1.0.0/8 and it is currently in
	use and originated from AS64496 with valid RPKI objects in place.		use and originated from AS64496 with valid RPKI objects in place.
	Organization B has acquired the address and desires an RPKI transfer		Organization B has acquired the address and desires an RPKI transfer
	on a particular date and time. This prefix will be originated by		on a particular date and time. This prefix will be originated by
	AS65551 as a result of this transfer.		AS65535 as a result of this transfer.
	The following RPKI objects would be created/revoked: TBC		The following RPKI objects would be created/revoked: TBC
	6.3. Transfer of un-used prefix		6.3. Transfer of un-used prefix
	Organization A holds the resource 10.1.0.0/8 and AS65551 (with RPKI		Organization A holds the resource 10.1.0.0/8 and AS65535 (with RPKI
	objects). Organization B has acquired an unused portion		objects). Organization B has acquired an unused portion
	(10.1.4.0/24) of the prefix and desires an RPKI transfer on a		(10.1.4.0/24) of the prefix and desires an RPKI transfer on a
	particular date and time. Organsiation B will originate a route		particular date and time. Organization B will originate a route
	10.1.4.0/24 from AS64496		10.1.4.0/24 from AS64496
	The following RPKI objects would be created/revoked: TBC		The following RPKI objects would be created/revoked: TBC
	7. Relying Party Use Cases		7. Relying Party Use Cases
	7.1. ROA Expiry or receipt of a CRL covering a ROA		7.1. ROA Expiry or receipt of a CRL covering a ROA
	In the cases which follow, the terms "expired ROA" or "revoked ROA"		In the cases which follow, the terms "expired ROA" or "revoked ROA"
	are shorthand, and describe the appropriate revocation or expiry of		are shorthand, and describe the appropriate expiry or revocation of
	EE or Resource Certificates that causes a relying party to consider		the EE or Resource Certificates that causes a relying party to
	the corresponding ROA to be viewed as expired or revoked.		consider the corresponding ROA to be viewed as expired or revoked.
	7.1.1. ROA of Parent Prefix is Revoked		7.1.1. ROA of Parent Prefix is Revoked
	A certificate revocation list (CRL) is received which reveals that		A certificate revocation list (CRL) is received which reveals that
	the ROA containing the prefix 10.1.0.0/16; maxLength 24 with ASN64496		the ROA containing the prefix 10.1.0.0/16; maxLength 24 with ASN64496
	is revoked. Further, a prefix route exists in the Internet routing		is revoked. Further, a prefix route exists in the Internet routing
	system for 10.1.4.0/24 originated from ASN64496.		system for 10.1.4.0/24 originated from ASN64496.
	The Relying Party interpretation would be: TBC		The Relying Party interpretation would be: TBC
	skipping to change at page 16, line 51 ¶		skipping to change at page 16, line 51 ¶
	A CRL is received which reveals that the ROA containing the prefix		A CRL is received which reveals that the ROA containing the prefix
	10.1.0.0/16; maxLength 24 with ASN64496 is revoked. Further, a		10.1.0.0/16; maxLength 24 with ASN64496 is revoked. Further, a
	prefix route exists in the Internet routing system for 10.1.4.0/24		prefix route exists in the Internet routing system for 10.1.4.0/24
	originated from ASN64496. Additionally, the current ROA list has a		originated from ASN64496. Additionally, the current ROA list has a
	valid ROA containing the prefix 10.1.0.0/20; maxLength 24 with		valid ROA containing the prefix 10.1.0.0/20; maxLength 24 with
	ASN64496.		ASN64496.
	The Relying Party interpretation would be: TBC		The Relying Party interpretation would be: TBC
	(Clarification: ROA for less specific grandparent prefix 10.1.0.0/16		(Clarification: ROA for less specific grandparent prefix 10.1.0.0/16
	was withdrawn)		was revoked or withdrawn)
	The Relying Party interpretation would be: TBC		The Relying Party interpretation would be: TBC
	7.1.4. ROA of Prefix Revoked while that of Parent Prefix Prevails		7.1.4. ROA of Prefix Revoked while that of Parent Prefix Prevails
	A CRL is received which reveals that the ROA containing the prefix		A CRL is received which reveals that the ROA containing the prefix
	10.1.4.0/24; maxLength 24 with ASN64496 is revoked. Further, a		10.1.4.0/24; maxLength 24 with ASN64496 is revoked. Further, a
	prefix route exists in the Internet routing system for 10.1.4.0/24		prefix route exists in the Internet routing system for 10.1.4.0/24
	originated from ASN64496. Additionally, the current ROA list has a		originated from ASN64496. Additionally, the current ROA list has a
	valid ROA containing the prefix 10.1.0.0/20; maxLength 24 with		valid ROA containing the prefix 10.1.0.0/20; maxLength 24 with
	ASN64496.		ASN64496.
	The Relying Party interpretation would be: TBC		The Relying Party interpretation would be: TBC
	(Clarification: Perhaps the revocation of ROA for prefix 10.1.4.0/24		(Clarification: Perhaps the revocation of ROA for prefix 10.1.4.0/24
	was initiated just to eliminate redundancy)		was initiated just to eliminate redundancy.)
	7.1.5. Expiry of ROA of Parent Prefix		7.1.5. Expiry of ROA of Parent Prefix
	A scan of the ROA list reveals that the ROA containing the prefix		A scan of the ROA list reveals that the ROA containing the prefix
	10.1.0.0/16; maxLength 24 with ASN64496 has expired. Further, a		10.1.0.0/16; maxLength 24 with ASN64496 has expired. Further, a
	prefix route exists in the Internet routing system for 10.1.4.0/24		prefix route exists in the Internet routing system for 10.1.4.0/24
	originated from ASN64496.		originated from ASN64496.
	The Relying Party interpretation would be: TBC		The Relying Party interpretation would be: TBC
	skipping to change at page 18, line 28 ¶		skipping to change at page 18, line 28 ¶
	7.2. Prefix, Origin Validation use cases		7.2. Prefix, Origin Validation use cases
	These use cases try to systematically enumerate the situations a		These use cases try to systematically enumerate the situations a
	relying party may encounter while receiving a BGP update and making		relying party may encounter while receiving a BGP update and making
	use of ROA information to interpret the validity of the prefix-origin		use of ROA information to interpret the validity of the prefix-origin
	information in the update. We enumerate the situations or scenarios		information in the update. We enumerate the situations or scenarios
	but do not make a final recommendation on any RPKI interpretation.		but do not make a final recommendation on any RPKI interpretation.
	For work on development of prefix-origin validation algorithms, see		For work on development of prefix-origin validation algorithms, see
	[I-D.ietf-sidr-roa-validation] and [I-D.pmohapat-sidr-pfx-validate].		[I-D.ietf-sidr-roa-validation] and [I-D.pmohapat-sidr-pfx-validate].
			Also see [I-D.ietf-idr-deprecate-as-sets] for work-in-progress in the
			IDR WG to deprecate AS_SETs in BGP updates (especially in the context
			of RPKI-based validation).
	7.2.1. Covering ROA Prefix, Maxlength Satisfied, and AS Match		7.2.1. Covering ROA Prefix, maxLength Satisfied, and AS Match
	ROA: {10.1.0.0/16, maxlength = 20, AS64496}		ROA: {10.1.0.0/16, maxLength = 20, AS64496}
	Update has {10.1.0.0/17, Origin = AS64496}		Update has {10.1.0.0/17, Origin = AS64496}
	Recommended RPKI prefix-origin validation interpretation: TBC		Recommended RPKI prefix-origin validation interpretation: TBC
	Comment: This is a straight forward prefix-origin validation use		Comment: This is a straight forward prefix-origin validation use
	case; it follows from the primary intention of creation of ROA by a		case; it follows from the primary intention of creation of ROA by a
	resource owner.		resource owner.
	7.2.2. Covering ROA Prefix, Maxlength Exceeded, and AS Match		7.2.2. Covering ROA Prefix, maxLength Exceeded, and AS Match
	ROA: {10.1.0.0/16, maxlength = 20, AS64496}		ROA: {10.1.0.0/16, maxLength = 20, AS64496}
	Update has {10.1.0.0/22, Origin = AS64496}		Update has {10.1.0.0/22, Origin = AS64496}
	No other relevant ROA		No other relevant ROA
	Recommended RPKI prefix-origin validation interpretation: TBC		Recommended RPKI prefix-origin validation interpretation: TBC
			Comment: In this case the maxLength specified in the ROA is exceeded
	Comment: In this case the maxlength specified in the ROA is exceeded
	by the update prefix.		by the update prefix.
	7.2.3. Covering ROA Prefix, Maxlength Satisfied, and AS Mismatch:		7.2.3. Covering ROA Prefix, maxLength Satisfied, and AS Mismatch:
	ROA: {10.1.0.0/16, maxlength = 24, AS64496}		ROA: {10.1.0.0/16, maxLength = 24, AS64496}
	Update has {10.1.88.0/24, Origin = AS65551}		Update has {10.1.88.0/24, Origin = AS65535}
	No other relevant ROA		No other relevant ROA
	Recommended RPKI prefix-origin validation interpretation: TBC		Recommended RPKI prefix-origin validation interpretation: TBC
	Comment: In this case an AS other than the one specified in the ROA		Comment: In this case an AS other than the one specified in the ROA
	is originating an update. This may be a prefix or subprefix hijack		is originating an update. This may be a prefix or subprefix hijack
	situation.		situation.
	7.2.4. Covering ROA Prefix, Maxlength Exceeded, and AS Mismatch		7.2.4. Covering ROA Prefix, maxLength Exceeded, and AS Mismatch
	ROA: {10.1.0.0/16, maxlength = 22, AS64496}		ROA: {10.1.0.0/16, maxLength = 22, AS64496}
	Update has {10.1.88.0/24, Origin = AS65551}		Update has {10.1.88.0/24, Origin = AS65535}
	No other relevant ROA		No other relevant ROA
	Recommended RPKI prefix-origin validation interpretation: TBC		Recommended RPKI prefix-origin validation interpretation: TBC
	Comment: In this case the maxlength specified in the ROA is exceeded		Comment: In this case the maxLength specified in the ROA is exceeded
	by the update prefix, and also an AS other than the one specified in		by the update prefix, and also an AS other than the one specified in
	the ROA is originating the update. This may be a subprefix hijack		the ROA is originating the update. This may be a subprefix hijack
	situation.		situation.
	7.2.5. Covering ROA Prefix Not Found		7.2.5. Covering ROA Prefix Not Found
	Update has {240.1.1.0/24, Origin = AS65551}		Update has {240.1.1.0/24, Origin = AS65535}
	No relevant ROA		No relevant ROA
	Recommended RPKI prefix-origin validation interpretation: TBC		Recommended RPKI prefix-origin validation interpretation: TBC
	Comment: In this case there is no relevant ROA that has a covering		Comment: In this case there is no relevant ROA that has a covering
	prefix for the update prefix. It could be a case of prefix or		prefix for the update prefix. It could be a case of prefix or
	subprefix hijack situation, but this announcement does not contradict		subprefix hijack situation, but this announcement does not contradict
	any existing ROA. During partial deployment, there would be some		any existing ROA. During partial deployment, there would be some
	legitimate prefix-origin announcements for which ROAs may not have		legitimate prefix-origin announcements for which ROAs may not have
	been issued yet.		been issued yet.
	7.2.6. Covering ROA Prefix Not Found but ROAs Exist for a Covering Set		7.2.6. Covering ROA Prefix Not Found but ROAs Exist for a Covering Set
	of More Specifics		of More Specifics
	ROA: {10.1.0.0/18, maxlength = 20, AS64496}		ROA: {10.1.0.0/18, maxLength = 20, AS64496}
	ROA: {10.1.64.0/18, maxlength = 20, AS64496}
	ROA: {10.1.128.0/18, maxlength = 20, AS64496}		ROA: {10.1.64.0/18, maxLength = 20, AS64496}
	ROA: {10.1.192.0/18, maxlength = 20, AS64496}		ROA: {10.1.128.0/18, maxLength = 20, AS64496}
			ROA: {10.1.192.0/18, maxLength = 20, AS64496}
	Update has {10.1.0.0/16, Origin = AS64496}		Update has {10.1.0.0/16, Origin = AS64496}
	No relevant ROA		No relevant ROA
	Recommended RPKI prefix-origin validation interpretation: TBC		Recommended RPKI prefix-origin validation interpretation: TBC
	Comment: In this case the update prefix is an aggregate, and it turns		Comment: In this case the update prefix is an aggregate, and it turns
	out that there exit ROAs for more specifics which, if combined, can		out that there exit ROAs for more specifics which, if combined, can
	help support validation of the announced prefix-origin pair. But it		help support validation of the announced prefix-origin pair. But it
	is very hard in general to breakup an announced prefix into		is very hard in general to breakup an announced prefix into
	constituent more specifics and check for ROA coverage for those more		constituent more specifics and check for ROA coverage for those more
	specifics.		specifics.
	7.2.7. Update has an AS Set as Origin and ROAs Exist for a Covering Set		7.2.7. AS_SET in Update and Covering ROA Prefix Not Found
	of More Specifics
	ROA: {10.1.0.0/18, maxlength = 20, AS64496}
	ROA: {10.1.64.0/18, maxlength = 20, AS64497}
	ROA: {10.1.128.0/18, maxlength = 20, AS64498}
	ROA: {10.1.192.0/18, maxlength = 20, AS64499}
	Update has {10.1.0.0/16, Origin = [AS64496, AS64497, AS64498,		Update has {10.1.0.0/16, Origin = [AS64496, AS64497, AS64498,
	AS64497]}		AS64497]}
	No relevant ROA		No relevant ROA
	Recommended RPKI prefix-origin validation interpretation: TBC		Recommended RPKI prefix-origin validation interpretation: TBC
	Comment: An extremely small percentage (~0.1%) of eBGP updates are		Comment: An extremely small percentage (~0.1%) of eBGP updates are
	seen to have AS set in them as origin; this is known as proxy		seen to have an AS_SET in them as origin; this is known as proxy
	aggregation. In this case the aggregate of the prefixes in the ROAs		aggregation. In this case, update with the AS_SET does not conflict
	is a covering prefix for the update prefix. The ASs in each of the		with any ROA.
	contributing ROAs together form a set that matches the AS set in the
	update. But it is very hard in general to breakup an announced
	prefix into constituent more specifics and check for ROA coverage for
	those more specifics.
	7.2.8. Update has AS set, Aggregator AS Absent, and Covering ROA Prefix		7.2.8. Singleton AS in AS_SET (in the Update), Covering ROA Prefix, and
	Not Found		AS Match
			Update has {10.1.0.0/24, Origin = [AS64496]} (Note: AS_SET with
			singleton AS appears in origin AS position.)
			ROA: {10.1.0.0/22, maxLength = 24, AS64496}
	Recommended RPKI prefix-origin validation interpretation: TBC		Recommended RPKI prefix-origin validation interpretation: TBC
			Comment: In the spirit of [I-D.ietf-idr-deprecate-as-sets], possibly
			any update with an AS_SET in it should not be considered valid (by
			ROA-based validation). But does a scenario as described in the
			example here need be treated differently?
	Comment: Normally an update that has an AS set should contain an		7.2.9. Singleton AS in AS_SET (in the Update), Covering ROA Prefix, and
	Aggregator attribute, but sometimes anomalously the aggregator AS		AS Mismatch
	attribute may be missing. Normally one may expect to find a ROA
	which has a covering prefix and matches the Aggregator AS in the
	update. But in this case, Aggregator AS is absent and also no
	covering ROA prefix is found.
	7.2.9. Update has AS set, Aggregator AS Absent, and Covering ROA Prefix		Update has {10.1.0.0/24, Origin = [AS64496]}
			(Note: AS_SET with singleton AS appears in origin AS position.)
			ROA: {10.1.0.0/22, maxLength = 24, AS65535} No other relevant ROA.
	Recommended RPKI prefix-origin validation interpretation: TBC		Recommended RPKI prefix-origin validation interpretation: TBC
	Comment: In this case, a covering ROA prefix is found but Aggregator		Comment: In this case, update with the AS_SET does conflict with a
	AS is absent. This would appear to be a prefix or subprefix hijack		ROA and there is no other relevant ROA.
	situation.
	7.2.10. Update has AS set, Aggregator AS Present, and Covering ROA		7.2.10. Multiple ASs in AS_SET (in the Update) and Covering ROA Prefix
	Prefix Not Found
			Update has {10.1.0.0/22, Origin = [AS64496, AS64497, AS64498,
			AS64497]}
			ROA: {10.1.0.0/22, maxLength = 24, AS65535} No other relevant ROA.
	Recommended RPKI prefix-origin validation interpretation: TBC		Recommended RPKI prefix-origin validation interpretation: TBC
	Comment: In this case, Aggregator AS is present but a covering ROA		Comment: In this case, update with the AS_SET conflicts with a ROA
	prefix is not found.		and there is no other relevant ROA.
	7.2.11. Update has AS set, Aggregator AS Present, Covering ROA Prefix,		7.2.11. Update has an AS_SET as Origin and ROAs Exist for a Covering
	and AS Mismatch		Set of More Specifics
	Recommended RPKI prefix-origin validation interpretation: TBC		ROA: {10.1.0.0/18, maxLength = 20, AS64496} ROA: {10.1.64.0/18,
			maxLength = 20, AS64497} ROA: {10.1.128.0/18, maxLength = 20,
			AS64498} ROA: {10.1.192.0/18, maxLength = 20, AS64499}
	Comment: In this case, Aggregator AS is present and a covering ROA		Update has {10.1.0.0/16, Origin = [AS64496, AS64497, AS64498,
	prefix is found, but the AS in the ROA does not match the Aggregator		AS64497]}
	AS. This would appear to be a prefix or subprefix hijack situation.
	7.2.12. Update has AS set, Aggregator AS Present, Covering ROA Prefix,		No (directly) relevant ROA
	and AS Match
	Recommended RPKI prefix-origin validation interpretation: TBC		Recommended RPKI prefix-origin validation interpretation: TBC
	Comment: In this case, Aggregator AS is present, a covering ROA		Comment: In this case the aggregate of the prefixes in the ROAs is a
	prefix is found, and also the AS in the ROA matches the Aggregator		covering prefix for the update prefix. The ASs in each of the
	AS.		contributing ROAs together form a set that matches the AS_SET in the
			update. But it is very hard in general to breakup an announced
			prefix into constituent more specifics and check for ROA coverage for
			those more specifics. In any case, it may be noted once again that
			in the spirit of [I-D.ietf-idr-deprecate-as-sets], possibly any
			update with an AS_SET in it should not be considered valid (by ROA-
			based validation).
	8. Acknowledgements		8. Acknowledgements
	The authors are indebted to both Sandy Murphy and Sam Weiler for		The authors are indebted to both Sandy Murphy and Sam Weiler for
	their guidance. Further, the authors would like to thank Curtis		their guidance. Further, the authors would like to thank Curtis
	Villamizar, Steve Kent, and Danny McPherson for their technical		Villamizar, Steve Kent, and Danny McPherson for their technical
	insight and review.		insight and review.
	9. IANA Considerations		9. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	10. Security Considerations		10. Security Considerations
	This memo requires no security considerations		This memo requires no security considerations
	11. Normative References		11. Normative References
			[I-D.ietf-idr-deprecate-as-sets]
			Kumari, W., "Deprecation of BGP AS_SET, AS_CONFED_SET.",
			draft-ietf-idr-deprecate-as-sets-00 (work in progress),
			November 2010.
	[I-D.ietf-sidr-arch]		[I-D.ietf-sidr-arch]
	Lepinski, M. and S. Kent, "An Infrastructure to Support		Lepinski, M. and S. Kent, "An Infrastructure to Support
	Secure Internet Routing", draft-ietf-sidr-arch-09 (work in		Secure Internet Routing", draft-ietf-sidr-arch-11 (work in
	progress), October 2009.		progress), September 2010.
	[I-D.ietf-sidr-res-certs]		[I-D.ietf-sidr-res-certs]
	Huston, G., Michaelson, G., and R. Loomans, "A Profile for		Huston, G., Michaelson, G., and R. Loomans, "A Profile for
	X.509 PKIX Resource Certificates",		X.509 PKIX Resource Certificates",
	draft-ietf-sidr-res-certs-18 (work in progress), May 2010.		draft-ietf-sidr-res-certs-21 (work in progress),
			December 2010.
	[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-06 (work in progress),		draft-ietf-sidr-roa-format-09 (work in progress),
	October 2009.		November 2010.
	[I-D.ietf-sidr-roa-validation]		[I-D.ietf-sidr-roa-validation]
	Huston, G. and G. Michaelson, "Validation of Route		Huston, G. and G. Michaelson, "Validation of Route
	Origination using the Resource Certificate PKI and ROAs",		Origination using the Resource Certificate PKI and ROAs",
	draft-ietf-sidr-roa-validation-06 (work in progress),		draft-ietf-sidr-roa-validation-10 (work in progress),
	May 2010.		November 2010.
	[I-D.pmohapat-sidr-pfx-validate]		[I-D.pmohapat-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-pmohapat-sidr-pfx-validate-07 (work in progress),		draft-pmohapat-sidr-pfx-validate-07 (work in progress),
	April 2010.		April 2010.
	[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP		[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
	Addresses and AS Identifiers", RFC 3779, June 2004.		Addresses and AS Identifiers", RFC 3779, June 2004.
	skipping to change at page 23, line 34 ¶		skipping to change at page 24, line 4 ¶
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, May 2008.		(CRL) Profile", RFC 5280, May 2008.
	Authors' Addresses		Authors' Addresses
	Terry Manderson		Terry Manderson
	ICANN		ICANN
	Email: terry.manderson@icann.org		Email: terry.manderson@icann.org
	Kotikalapudi Sriram		Kotikalapudi Sriram
	NIST		US NIST
	Email: ksriram@nist.gov		Email: ksriram@nist.gov
	Russ White		Russ White
	Cisco		Cisco
	Email: russ@cisco.com		Email: russ@cisco.com
End of changes. 95 change blocks.
	154 lines changed or deleted		172 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/