< draft-ietf-sidr-slurm-07.txt		draft-ietf-sidr-slurm-08.txt >
	SIDR D. Ma		SIDR D. Ma
	Internet-Draft ZDNS		Internet-Draft ZDNS
	Intended status: Standards Track D. Mandelberg		Intended status: Standards Track D. Mandelberg
	Expires: September 23, 2018 Unaffiliated		Expires: October 28, 2018 Unaffiliated
	T. Bruijnzeels		T. Bruijnzeels
	RIPE NCC		RIPE NCC
	March 22, 2018		April 26, 2018
	Simplified Local internet nUmber Resource Management with the RPKI		Simplified Local internet nUmber Resource Management with the RPKI
	draft-ietf-sidr-slurm-07		(SLURM)
			draft-ietf-sidr-slurm-08
	Abstract		Abstract
	The Resource Public Key Infrastructure (RPKI) is a global		The Resource Public Key Infrastructure (RPKI) is a global
	authorization infrastructure that allows the holder of Internet		authorization infrastructure that allows the holder of Internet
	Number Resources (INRs) to make verifiable statements about those		Number Resources (INRs) to make verifiable statements about those
	resources. Network operators, e.g., Internet Service Providers		resources. Network operators, e.g., Internet Service Providers
	(ISPs), can use the RPKI to validate BGP route origination		(ISPs), can use the RPKI to validate BGP route origin assertions.
	assertions. ISPs can also be able to use the RPKI to validate the		ISPs can also use the RPKI to validate the path of a BGP route.
	path of a BGP route. However, ISPs may want to establish a local		However, ISPs may want to establish a local view of exceptions to the
	view of the RPKI to control its own network while making use of RPKI		RPKI data in the form of local filters and additions. The mechanisms
	data. The mechanisms described in this document provide a simple way		described in this document provide a simple way to enable INR holders
	to enable INR holders to establish a local, customized view of the		to establish a local, customized view of the RPKI, overriding global
	RPKI, overriding global RPKI repository data as needed.		RPKI repository data as needed.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 September 23, 2018.		This Internet-Draft will expire on October 28, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. RP with SLURM . . . . . . . . . . . . . . . . . . . . . . . . 3		2. RP with SLURM . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. SLURM File and Mechanisms . . . . . . . . . . . . . . . . . . 4		3. SLURM File and Mechanisms . . . . . . . . . . . . . . . . . . 4
	3.1. Use of JSON . . . . . . . . . . . . . . . . . . . . . . . 4		3.1. Use of JSON . . . . . . . . . . . . . . . . . . . . . . . 4
	3.2. SLURM File Overview . . . . . . . . . . . . . . . . . . . 4		3.2. SLURM File Overview . . . . . . . . . . . . . . . . . . . 5
	3.3. SLURM Target . . . . . . . . . . . . . . . . . . . . . . 5		3.3. Validation Output Filters . . . . . . . . . . . . . . . . 6
	3.4. Validation Output Filters . . . . . . . . . . . . . . . . 7		3.3.1. Validated ROA Prefix Filters . . . . . . . . . . . . 6
	3.4.1. Validated ROA Prefix Filters . . . . . . . . . . . . 7		3.3.2. BGPsec Assertion Filters . . . . . . . . . . . . . . 7
	3.4.2. BGPsec Assertion Filters . . . . . . . . . . . . . . 8		3.4. Locally Added Assertions . . . . . . . . . . . . . . . . 9
	3.5. Locally Added Assertions . . . . . . . . . . . . . . . . 9		3.4.1. ROA Prefix Assertions . . . . . . . . . . . . . . . . 9
	3.5.1. ROA Prefix Assertions . . . . . . . . . . . . . . . . 9		3.4.2. BGPsec Assertions . . . . . . . . . . . . . . . . . . 10
	3.5.2. BGPsec Assertions . . . . . . . . . . . . . . . . . . 10		3.5. Example of a SLURM File with Filters and Assertions . . . 11
	3.6. Example of a SLURM File with Filters and Assertions . . . 11		4. SLURM File Configuration . . . . . . . . . . . . . . . . . . 13
	4. SLURM File Configuration . . . . . . . . . . . . . . . . . . 12		4.1. SLURM File Atomicity . . . . . . . . . . . . . . . . . . 13
	4.1. SLURM File Atomicity . . . . . . . . . . . . . . . . . . 12
	4.2. Multiple SLURM Files . . . . . . . . . . . . . . . . . . 13		4.2. Multiple SLURM Files . . . . . . . . . . . . . . . . . . 13
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 14		6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
	8.1. Informative References . . . . . . . . . . . . . . . . . 14		8.1. Informative References . . . . . . . . . . . . . . . . . 15
	8.2. Normative References . . . . . . . . . . . . . . . . . . 15		8.2. Normative References . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	The Resource Public Key Infrastructure (RPKI) is a global		The Resource Public Key Infrastructure (RPKI) is a global
	authorization infrastructure that allows the holder of Internet		authorization infrastructure that allows the holder of Internet
	Number Resources (INRs) to make verifiable statements about those		Number Resources (INRs) to make verifiable statements about those
	resources. For example, the holder of a block of IP(v4 or v6)		resources. For example, the holder of a block of IP(v4 or v6)
	addresses can issue a Route Origination Authorization (ROA) [RFC6482]		addresses can issue a Route Origin Authorization (ROA) [RFC6482] to
	to authorize an Autonomous System (AS) to originate routes for that		authorize an Autonomous System (AS) to originate routes for that
	block. Internet Service Providers (ISPs) can then use the RPKI to		block. Internet Service Providers (ISPs) can then use the RPKI to
	validate BGP routes. (Validation of the origin of a route is		validate BGP routes. (Validation of the origin of a route is
	described in [RFC6811], and validation of the path of a route is		described in [RFC6811], and validation of the path of a route is
	described in [RFC8205].)		described in [RFC8205].)
	However, an "RPKI relying party" (RP) may want to override some of		However, an "RPKI relying party" (RP) may want to override some of
	the information expressed via putative Trust Anchor(TA) and the		the information expressed via configured Trust Anchors (TAs) and the
	certificates downloaded from the RPKI repository system. For		certificates downloaded from the RPKI repository system. For
	instances, [RFC6491] recommends the creation of ROAs that would		instances, [RFC6491] recommends the creation of ROAs that would
	invalidate public routes for reserved and unallocated address space,		invalidate public routes for reserved and unallocated address space,
	yet some ISPs might like to use BGP and the RPKI with private address		yet some ISPs might like to use BGP and the RPKI with private address
	space ([RFC1918], [RFC4193], [RFC6598]) or private AS numbers		space ([RFC1918], [RFC4193], [RFC6598]) or private AS numbers
	([RFC1930], [RFC6996]). Local use of private address space and/or AS		([RFC1930], [RFC6996]). Local use of private address space and/or AS
	numbers is consistent with the RFCs cited above, but such use cannot		numbers is consistent with the RFCs cited above, but such use cannot
	be verified by the global RPKI. This motivates creation of		be verified by the global RPKI. This motivates creation of
	mechanisms that enable a network operator to publish a variant of		mechanisms that enable a network operator to publish exception to the
	RPKI hierarchy (for its own use and that of its customers) at its		RPKI in the form of filters and additions (for its own use and that
	discretion. Additionally, a network operator might wish to make use		of its customers) at its discretion. Additionally, a network
	of a local override capability to protect routes from adverse actions		operator might wish to make use of a local override capability to
	[RFC8211], until the results of such actions have been addressed.		protect routes from adverse actions [RFC8211], until the results of
	The mechanisms developed to provide this capability to network		such actions have been addressed. The mechanisms developed to
	operators are hereby called Simplified Local internet nUmber Resource		provide this capability to network operators are hereby called
	Management with the RPKI (SLURM).		Simplified Local internet nUmber Resource Management with the RPKI
			(SLURM).
	SLURM allows an operator to create a local view of the global RPKI by		SLURM allows an operator to create a local view of the global RPKI by
	generating sets of assertions. For Origin Validation [RFC6811], an		generating sets of assertions. For Origin Validation [RFC6811], an
	assertion is a tuple of {IP prefix, prefix length, maximum length, AS		assertion is a tuple of {IP prefix, prefix length, maximum length, AS
	number} as used by rpki-rtr version 0 [RFC6810] and version 1		number (ASN)} as used by rpki-rtr (the RPKI to Router Protocol)
	[RFC8210]. For BGPsec [RFC8205], an assertion is a tuple of {AS		version 0 [RFC6810] and rpki-rtr version 1 [RFC8210]. For BGPsec
	number, subject key identifier, router public key} as used by rpki-		[RFC8205], an assertion is a tuple of {ASN, subject key identifier,
	rtr version 1. (For the remainder of this document, these assertions		router public key} as used by rpki-rtr version 1. (For the remainder
	are called Origin Validation assertions and BGPsec assertions,		of this document, these assertions are called ROA Prefix Assertions
	respectively.)		and BGPsec Assertions, respectively.)
	1.1. Terminology		1.1. Terminology
	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", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in [RFC2119].		"OPTIONAL" in this document are to be interpreted as described in BCP
			14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	2. RP with SLURM		2. RP with SLURM
	SLURM provides a simple way to enable an RP to establish a local,		SLURM provides a simple way to enable an RP to establish a local,
	customized view of the RPKI, by overriding RPKI repository data if		customized view of the RPKI, by overriding RPKI repository data if
	needed. To that end, an RP with SLURM filters out (removes from		needed. To that end, an RP with SLURM filters out (removes from
	consideration for routing decisions) any assertions in the RPKI that		consideration for routing decisions) any assertions in the RPKI that
	are overridden by local Origin Validation assertions and BGPsec		are overridden by local ROA Prefix Assertions and BGPsec Assertions.
	assertions.
	In general, the primary output of an RP is the data it sends to		In general, the primary output of an RP is the data it sends to
	routers over the rpki-rtr protocol. The rpki-rtr protocol enables		routers over the rpki-rtr protocol [RFC8210]. The rpki-rtr protocol
	routers to query an RP for all assertions it knows about (Reset		enables routers to query an RP for all assertions it knows about
	Query) or for an update of only the changes in assertions (Serial		(Reset Query) or for an update of only the changes in assertions
	Query). The mechanisms specified in this document are to be applied		(Serial Query). The mechanisms specified in this document are to be
	to the result set for a Reset Query, and to both the old and new sets		applied to the result set for a Reset Query, and to both the old and
	that are compared for a Serial Query. RP software may modify other		new sets that are compared for a Serial Query. RP software may
	forms of output in comparable ways, but that is outside the scope of		modify other forms of output in comparable ways, but that is outside
	this document.		the scope of this document.
	+--------------+ +---------------------------+ +------------+		+--------------+ +---------------------------+ +------------+
	| | | | | |		| | | | | |
	| Repositories +--->Local cache of RPKI objects+---> Validation |		| Repositories +--->Local cache of RPKI objects+---> Validation |
	| | | | | |		| | | | | |
	+--------------+ +---------------------------+ +-----+------+		+--------------+ +---------------------------+ +-----+------+
	|		|
	+-------------------------------------------------+		+-------------------------------------------------+
	|		|
	+------v-------+ +------------+ +----------+ +-------------+		+------v-------+ +------------+ +----------+ +-------------+
	skipping to change at page 4, line 35 ¶		skipping to change at page 4, line 43 ¶
	| SLURM +---> SLURM +---> rpki-rtr +---> BGP Speakers|		| SLURM +---> SLURM +---> rpki-rtr +---> BGP Speakers|
	| Filters | | Assertions | | | | |		| Filters | | Assertions | | | | |
	+--------------+ +------------+ +----------+ +-------------+		+--------------+ +------------+ +----------+ +-------------+
	Figure 1: SLURM's Position in the RP Stack		Figure 1: SLURM's Position in the RP Stack
	3. SLURM File and Mechanisms		3. SLURM File and Mechanisms
	3.1. Use of JSON		3.1. Use of JSON
	This document describes responses in the JSON [RFC8259] format. JSON		SLURM filters and assertions are specified in JSON [RFC8259] format.
	members that are not defined here MUST NOT be used in SLURM Files.		JSON members that are not defined here MUST NOT be used in SLURM
	An RP MUST consider any deviations from the specification an error.		Files. An RP MUST consider any deviations from the specification
	Future additions to the specifications in this document MUST use an		errors. Future additions to the specifications in this document MUST
	incremented value for the "slurmVersion" member.		use an incremented value for the "slurmVersion" member.
	3.2. SLURM File Overview		3.2. SLURM File Overview
	A SLURM file consists of:		A SLURM file consists of a single JSON object containing the
			following members:
	o A SLURM Version indication that MUST be 1
	o A slurmTarget element (Section 3.3) consisting of:
	* Zero or more target elements. In this version of SLURM, there		o A "slurmVersion" member that MUST be set to 1, encoded as a number
	are two types of values for the target: ASN or Fully Qualified
	Domain Name(FQDN). If more than one target line is present,
	all targets MUST be acceptable to the RP.
	o Validation Output Filters (Section 3.4), consisting of:		o A "validationOutputFilters" member (Section 3.3), whose value is
			an object. The object MUST contain exactly two members:
	* An array of zero or more Prefix Filters, described in		* A "prefixFilters" member, whose value is described in
	Section 3.4.1		Section 3.3.1.
	* An array of zero or more BGPsec Filters, described in		* A "bgpsecFilters" member, whose value is described in
	Section 3.4.2		Section 3.3.2.
	o Locally Added Assertions (Section 3.5), consisting of:		o A "locallyAddedAssertions" member (Section 3.4), whose value is an
			object. The object MUST contain exactly two members:
	* An array of zero or more Prefix Assertions, described in		* A "prefixAssertions" member, whose value is described in
	Section 3.5.1		Section 3.4.1.
	* An array of zero or more BGPsec Assertions, described in		* A "bgpsecAssertions" member, whose value is described in
	Section 3.5.2		Section 3.4.2.
	In the envisioned typical use case, an RP uses both Validation Output		In the envisioned typical use case, an RP uses both Validation Output
	Filters and Locally Added Assertions. In this case, the resulting		Filters and Locally Added Assertions. In this case, the resulting
	assertions MUST be the same as if output filtering were performed		assertions MUST be the same as if output filtering were performed
	before locally adding assertions. I.e., locally added assertions		before locally adding assertions. i.e. locally added assertions
	MUST NOT be removed by output filtering.		MUST NOT be removed by output filtering.
	The following JSON structure with JSON members represents a SLURM		The following JSON structure with JSON members represents a SLURM
	file that has no filters or assertions:		file that has no filters or assertions:
	{		{
	"slurmVersion": 1,		"slurmVersion": 1,
	"slurmTarget": [],
	"validationOutputFilters": {		"validationOutputFilters": {
	"prefixFilters": [],		"prefixFilters": [],
	"bgpsecFilters": []		"bgpsecFilters": []
	},		},
	"locallyAddedAssertions": {		"locallyAddedAssertions": {
	"prefixAssertions": [],		"prefixAssertions": [],
	"bgpsecAssertions": []		"bgpsecAssertions": []
	}		}
	}		}
	Empty SLURM File		Empty SLURM File
	3.3. SLURM Target		3.3. Validation Output Filters
	A SLURM file MUST specify a "slurmTarget" element that identifies the
	environment in which the SLURM file is intended to be used. The
	"slurmTarget" element MAY have an empty array as its value, which
	means "applies to all". The meaning of the "slurmTarget" element, if
	present, is determined by the user. If a "slurmTarget" element is
	present, an RP SHOULD verify that the target is an acceptable value,
	and reject this SLURM file if the "slurmTarget" element is not
	acceptable. Each "slurmTarget" element contains merely one "asn" or
	one "hostname". An explanatory "comment" MAY be included in each
	"slurmTarget" element so that it can be shown to users of the RP
	software.
	For instance, a large ISP may want some of its ASes to establish a		3.3.1. Validated ROA Prefix Filters
	local view of RPKI while the others not. Accordingly, this ISP needs
	to make its RPs aware of this distinction for different BGP speakers
	by adding ASN(s) to SLURM file target. Such a target value is an ASN
	expressed in number.
	"slurmTarget": [		The RP can configure zero or more Validated ROA Prefix Filters
	{		(Prefix Filters in short). Each Prefix Filter can contain either an
	"asn": 65536,		IPv4 or IPv6 prefix and/or an ASN. It is RECOMMENDED that an
	"comment": "This file is intended for BGP speakers in AS 65536"		explanatory comment is included with each Prefix Filter, so that it
	}		can be shown to users of the RP software.
	]
	slurmTarget example 1		The above is expressed as a value of the "prefixFilters" member, as
			an array of zero or more objects. Each object MUST contain one of
			either, or one each of both following members:
	Also, for instance, an organization may share one trusted third-party		o A "prefix" member, whose value is string representing either an
	SLURM file source. For the local control, or in the case of		IPv4 prefix (Section 3.1 of [RFC4632]) or an IPv6 prefix
	Emergency Response Team Coordination, the SLURM file source may		([RFC5952]).
	generate a SLURM file that is to be applied to only one specific RP.
	This file can take advantage of the "target" element to restrict the
	ASes that will accept and use the file. Accordingly, the SLURM file
	source needs to indicate which RP(s) should make use of the file by
	adding the domain name(s) of the RP(s) to the SLURM file target.
	Such a target value is a server name expressed in FQDN.
	"slurmTarget": [		o An "asn" member, whose value is a number.
	{
	"hostname": "rpki.example.com",
	"comment": "This file is intended for RP server rpki.example.com"
	}
	]
	slurmTarget example 2		In addition, each object MAY contain one optional "comment" member,
			whose value is a string.
	3.4. Validation Output Filters		The following example JSON structure represents a "prefixFilters"
			member with an array of example objects for each use case listed
			above:
	3.4.1. Validated ROA Prefix Filters		"prefixFilters": [
			{
			"prefix": "192.0.2.0/24",
			"comment": "All VRPs encompassed by prefix"
			},
			{
			"asn": 64496,
			"comment": "All VRPs matching ASN"
			},
			{
			"prefix": "198.51.100.0/24",
			"asn": 64497,
			"comment": "All VRPs encompassed by prefix, matching ASN"
			}
			]
	The RP can configure zero or more Validated ROA Prefix Filters		prefixFilters examples
	(Prefix Filters in short). Each Prefix Filter can contain either an
	IPv4 or IPv6 prefix and/or an AS number. It is RECOMMENDED that an
	explanatory comment is included with each Prefix Filter, so that it
	can be shown to users of the RP software.
	Any Validated ROA Prefix (VRP, [RFC6811]) that matches any configured		Any Validated ROA Prefix (VRP, [RFC6811]) that matches any configured
	Prefix Filter MUST be removed from the RP's output.		Prefix Filter MUST be removed from the RP's output.
	A Validated ROA Prefix is considered to match with a Prefix Filter if		A VRP is considered to match with a Prefix Filter if one of the
	one of the following cases applies:		following cases applies:
	1. If the Prefix Filter contains an IPv4 or IPv6 Prefix only, the		1. If the Prefix Filter contains an IPv4 or IPv6 Prefix only, the
	VRP is considered to match the filter if the VRP Prefix is equal		VRP is considered to match the filter if the VRP prefix is equal
	to or subsumed by the Prefix Filter.		to or covered by the Prefix Filter prefix.
	2. If Prefix Filter contains an AS number only, the VRP is		2. If Prefix Filter contains an ASN only, the VRP is considered to
	considered to match the filter if the VRP ASN matches the Prefix		match the filter if the VRP ASN matches the Prefix Filter ASN.
	Filter ASN.
	3. If Prefix Filter contains both an IPv4 or IPv6 prefix AND an AS		3. If Prefix Filter contains both an IPv4 or IPv6 prefix and an ASN,
	Number, the VRP is considered to match if the VRP Prefix is equal		the VRP is considered to match if the VRP prefix is equal to or
	to or subsumed by the Prefix Filter AND the VRP ASN matches the		covered by the Prefix Filter prefix and the VRP ASN matches the
	Prefix Filter ASN.		Prefix Filter ASN.
	The following JSON structure represents an array of "prefixFilters"		3.3.2. BGPsec Assertion Filters
	with an element for each use case listed above:
	"prefixFilters": [		The RP can configure zero or more BGPsec Assertion Filters (BGPsec
	{		Filters in short). Each BGPsec Filter can contain an ASN and/or the
	"prefix": "192.0.2.0/24",		Base64 [RFC4648] encoding of a Router Subject Key Identifier (SKI),
	"comment": "All VRPs encompassed by prefix"		as described in [RFC8209] and [RFC6487]. It is RECOMMENDED that an
	},		explanatory comment is also included with each BGPSec Filter, so that
	{		it can be shown to users of the RP software.
	"asn": 64496,
	"comment": "All VRPs matching ASN"
	},
	{
	"prefix": "198.51.100.0/24",
	"asn": 64497,
	"comment": "All VRPs encompassed by prefix, matching ASN"
	}
	]
	prefixFilters examples		The above is expressed as a value of the "bgpsecFilters" member, as
			an array of zero or more objects. Each object MUST contain one of
			either, or one each of both following members:
	3.4.2. BGPsec Assertion Filters		o An "asn" member, whose value is a number
	The RP can configure zero or more BGPsec Assertion Filters (BGPsec		o An "SKI" member, whose value is the Base64 encoding without
	Filters in short). Each BGPsec Filter can contain an AS number and/		trailing '=' (Section 5 of [RFC4648]) of the certificate's Subject
	or a Router SKI.		Public Key as described in Section 4.8.2. of [RFC6487] (This is
			the value of the ASN.1 OCTET STRING without the ASN.1 tag or
			length fields.)
	The Router SKI is the Base64 [RFC4648] encoding of a router		In addition, each object MAY contain one optional "comment" member,
	certificate's Subject Key Identifier, as described in [RFC8209] and		whose value is a string.
	[RFC6487]. This is the value of the ASN.1 OCTET STRING without the
	ASN.1 tag or length fields.
	Furthermore it is RECOMMENDED that an explanatory comment is included		The following example JSON structure represents a "bgpsecFilters"
	with each BGPsec Filter, so that it can be shown to users of the RP		member with an array of example objects for each use case listed
	software.		above:
			"bgpsecFilters": [
			{
			"asn": 64496,
			"comment": "All keys for ASN"
			},
			{
			"SKI": "<Base 64 of some SKI>",
			"comment": "Key matching Router SKI"
			},
			{
			"asn": 64497,
			"SKI": "<Base 64 of some SKI>",
			"comment": "Key for ASN 64497 matching Router SKI"
			}
			]
			bgpsecFilters examples
	Any BGPsec Assertion that matches any configured BGPsec Filter MUST		Any BGPsec Assertion that matches any configured BGPsec Filter MUST
	be removed from the RP's output.		be removed from the RP's output. A BGPsec Assertion is considered to
			match with a BGPsec Filter if one of the following cases applies:
	A BGPsec Assertion is considered to match with a BGPsec Filter if one		1. If the BGPsec Filter contains an ASN only, a BGPsec Assertion is
	of the following cases applies:		considered to match if the Assertion ASN matches the Filter ASN.
	1. If the BGPsec Filter contains an AS number only, a BGPsec		2. If the BGPsec Filter contains an SKI only, a BGPsec Assertion is
	Assertion is considered to match if the Assertion ASN matches the		considered to match if the Assertion Router SKI matches the
	Filter ASN.		Filter SKI.
	2. If the BGPsec Filter contains a Router SKI only, a BGPsec		3. If the BGPsec Filter contains both an ASN and a Router SKI, then
	Assertion is considered to match if the Assertion Router SKI		a BGPsec Assertion is considered to match if both the Assertion
	matches the Filter Router SKI.		ASN matches the Filter ASN and the Assertion Router SKI matches
			the Filter Router SKI.
	3. If the BGPsec Filter contains both an AS number AND a Router SKI,		3.4. Locally Added Assertions
	then a BGPsec Assertion is considered to match if both the
	Assertion ASN matches the Filter ASN and the Assertion Router SKI
	matches the Filter Router SKI.
	The following JSON structure represents an array of "bgpsecFilters"		3.4.1. ROA Prefix Assertions
	with an element for each use case listed above:
	"bgpsecFilters": [		Each RP is locally configured with a (possibly empty) array of ROA
	{		Prefix Assertions (Prefix Assertion in short). Each ROA Prefix
	"asn": 64496,		Assertion MUST contain an IPv4 or IPv6 prefix and an ASN. It MAY
	"comment": "All keys for ASN"		include a value for the maximum length. It is RECOMMENDED that an
	},		explanatory comment is also included with each, so that it can be
	{		shown to users ofthe RP software.
	"routerSKI": "<Base 64 of some SKI>",
	"comment": "Key matching Router SKI"
	},
	{
	"asn": 64497,
	"routerSKI": "<Base 64 of some SKI>",
	"comment": "Key for ASN 64497 matching Router SKI"
	}
	]
	bgpsecFilters examples		The above is expressed as a value of the "prefixAssertions" member,
			as an array of zero or more objects. Each object MUST contain one
			each of both following members:
	3.5. Locally Added Assertions		o A "prefix" member, whose value is string representing either an
			IPv4 prefix (Section 3.1 of [RFC4632]) or an IPv6 prefix
			([RFC5952]).
	3.5.1. ROA Prefix Assertions		o An "asn" member, whose value is a number.
	Each RP is locally configured with a (possibly empty) array of ROA		In addition, each object MAY contain one of each of the following
	Prefix Assertions. This array is added to the RP's output.		members:
	Each ROA Prefix Assertion MUST contain an IPv4 or IPv6 prefix, an AS		o A "maxPrefixLength" member, whose value is a number.
	number, optionally a MaxLength and optionally a comment that can be
	shown to users of the RP software.
	The following JSON structure represents an array of		o A "comment" member, whose value is a string.
	"prefixAssertions" with an element for each use case listed above:
			The following example JSON structure represents a "prefixAssertions"
			member with an array of example objects for each use case listed
			above:
	"prefixAssertions": [		"prefixAssertions": [
	{		{
	"asn": 64496,		"asn": 64496,
	"prefix": "198.51.100.0/24",		"prefix": "198.51.100.0/24",
	"comment": "My other important route"		"comment": "My other important route"
	},		},
	{		{
	"asn": 64496,		"asn": 64496,
	"prefix": "2001:DB8::/32",		"prefix": "2001:DB8::/32",
	"maxPrefixLength": 48,		"maxPrefixLength": 48,
	"comment": "My other important de-aggregated routes"		"comment": "My other important de-aggregated routes"
	}		}
	]		]
	prefixAssertions examples		prefixAssertions examples
	3.5.2. BGPsec Assertions		Note that the combination of the prefix, ASN and optional maximum
			length describes a VRP as described in [RFC6811]. The RP MUST add
			all Prefix Assertions found this way to the VRP found through RPKI
			validation, and ensure that it sends the complete set of PDUs,
			excluding duplicates when using the rpki-rtr protocol, see
			Section 5.6 and 5.7 of [RFC8210].
	Each RP is locally configured with a (possibly empty) array of BGPsec		3.4.2. BGPsec Assertions
	Assertions. This array is added to the RP's output.
	Each BGPsec Assertion MUST contain an AS number, a Router SKI, the		Each RP is locally configured with a (possibly empty) array of BGPsec
	Router Public Key, and optionally a comment that can be shown to		Assertions. Each BGPsec Assertion MUST contain an AS number, a
			Router SKI, and the Router Public Key. It is RECOMMENDED that an
			explanatory comment is also included, so that it can be shown to
	users of the RP software.		users of the RP software.
	The Router SKI is the Base64 [RFC4648] encoding of a router		The above is expressed as a value of the "bgpsecAssertions" member,
	certificate's Subject Key Identifier, as described in [RFC8209] and		as an array of zero or more objects. Each object MUST contain one
	[RFC6487]. This is the value of the ASN.1 OCTET STRING without the		each of all of the following members:
	ASN.1 tag or length fields.
	The Router Public Key is the Base64 [RFC4648] encoding of a router		An "asn" member, whose value is a number.
	public key's subjectPublicKeyInfo value, as described in [RFC8208].
	This is the full ASN.1 DER encoding of the subjectPublicKeyInfo,		An "SKI" member, whose value is the Base64 encoding without
	including the ASN.1 tag and length values of the subjectPublicKeyInfo		trailing '=' (Section 5 of RFC4648 ) of the router's public key
	SEQUENCE.		equivalent to a certificate's Subject Public Key as described in
			Section 4.8.2. of [RFC6487]. This is the value of the ASN.1 OCTET
			STRING without the ASN.1 tag or length fields.
			A "routerPublicKey" member, whose value is is the Base64 encoding
			without trailing '=' (Section 5 of [RFC4648]) of the equivalent to
			a router certificate's public key's subjectPublicKeyInfo value, as
			described in [RFC8208]. This is the full ASN.1 DER encoding of
			the subjectPublicKeyInfo, including the ASN.1 tag and length
			values of the subjectPublicKeyInfo SEQUENCE.
	The following JSON structure represents an array of		The following JSON structure represents an array of
	"bgpsecAssertions" with one element as described above:		"bgpsecAssertions" with one element as described above:
	"bgpsecAssertions": [		"bgpsecAssertions": [
	{		{
	"asn": 64496,		"asn": 64496,
	"comment" : "My known key for my important ASN",
	"SKI": "<some base64 SKI>",		"SKI": "<some base64 SKI>",
	"publicKey": "<some base64 public key>"		"publicKey": "<some base64 public key>",
			"comment": "My known key for my important ASN"
	}		}
	]		]
	prefixAssertions examples		bgpsecAssertions examples
	3.6. Example of a SLURM File with Filters and Assertions		Note that a bgpsecAssertion matches the syntax of the Router Key PDU
			described in section 5.10 of [RFC8210]. Relying Parties MUST add any
			bgpsecAssertion thus found to the set of Router PDUs, excluding
			duplicates, when using the RPKI-RTR protocol [RFC8210].
			3.5. Example of a SLURM File with Filters and Assertions
	The following JSON structure represents an example of a SLURM file		The following JSON structure represents an example of a SLURM file
	that uses all the elements described in the previous sections:		that uses all the elements described in the previous sections:
	{		{
	"slurmVersion": 1,		"slurmVersion": 1,
	"slurmTarget":[
	{
	"asn":65536
	},
	{
	"hostname":"rpki.example.com"
	}
	],
	"validationOutputFilters": {		"validationOutputFilters": {
	"prefixFilters": [		"prefixFilters": [
	{		{
	"prefix": "192.0.2.0/24",		"prefix": "192.0.2.0/24",
	"comment": "All VRPs encompassed by prefix"		"comment": "All VRPs encompassed by prefix"
	},		},
	{		{
	"asn": 64496,		"asn": 64496,
	"comment": "All VRPs matching ASN"		"comment": "All VRPs matching ASN"
	},		},
	skipping to change at page 12, line 4 ¶		skipping to change at page 12, line 8 ¶
	{		{
	"prefix": "198.51.100.0/24",		"prefix": "198.51.100.0/24",
	"asn": 64497,		"asn": 64497,
	"comment": "All VRPs encompassed by prefix, matching ASN"		"comment": "All VRPs encompassed by prefix, matching ASN"
	}		}
	],		],
	"bgpsecFilters": [		"bgpsecFilters": [
	{		{
	"asn": 64496,		"asn": 64496,
	"comment": "All keys for ASN"		"comment": "All keys for ASN"
	},		},
	{		{
	"routerSKI": "Zm9v",		"SKI": "Zm9v",
	"comment": "Key matching Router SKI"		"comment": "Key matching Router SKI"
	},		},
	{		{
	"asn": 64497,		"asn": 64497,
	"routerSKI": "YmFy",		"SKI": "YmFy",
	"comment": "Key for ASN 64497 matching Router SKI"		"comment": "Key for ASN 64497 matching Router SKI"
	}		}
	]		]
	},		},
	"locallyAddedAssertions": {		"locallyAddedAssertions": {
	"prefixAssertions": [		"prefixAssertions": [
	{		{
	"asn": 64496,		"asn": 64496,
	"prefix": "198.51.100.0/24",		"prefix": "198.51.100.0/24",
	"comment": "My other important route"		"comment": "My other important route"
	skipping to change at page 12, line 42 ¶		skipping to change at page 12, line 45 ¶
	{		{
	"asn": 64496,		"asn": 64496,
	"comment" : "My known key for my important ASN",		"comment" : "My known key for my important ASN",
	"SKI": "<some base64 SKI>",		"SKI": "<some base64 SKI>",
	"publicKey": "<some base64 public key>"		"publicKey": "<some base64 public key>"
	}		}
	]		]
	}		}
	}		}
	Full SLURM File		Example of Full SLURM File
	4. SLURM File Configuration		4. SLURM File Configuration
	4.1. SLURM File Atomicity		4.1. SLURM File Atomicity
	To ensure local consistency, the effect of SLURM MUST be atomic.		To ensure local consistency, the effect of SLURM MUST be atomic.
	That is, the output of the RP must be either the same as if SLURM		That is, the output of the RP MUST be either the same as if SLURM
	file were not used, or it must reflect the entire SLURM		file were not used, or it MUST reflect the entire SLURM
	configuration. For an example of why this is required, consider the		configuration. For an example of why this is required, consider the
	case of two local routes for the same prefix but different origin AS		case of two local routes for the same prefix but different origin
	numbers. Both routes are configured with Locally Added Assertions.		ASNs. Both routes are configured with Locally Added Assertions. If
	If neither addition occurs, then both routes could be in the unknown		neither addition occurs, then both routes could be in the unknown
	state [RFC6811]. If both additions occur then both routes would be		state [RFC6811]. If both additions occur then both routes would be
	in the valid state. However, if one addition occurs and the other		in the valid state. However, if one addition occurs and the other
	does not, then one could be invalid while the other is valid.		does not, then one could be invalid while the other is valid.
	4.2. Multiple SLURM Files		4.2. Multiple SLURM Files
	An implementation MAY support the concurrent use of multiple SLURM		An implementation MAY support the concurrent use of multiple SLURM
	files. In this case, the resulting inputs to Validation Output		files. In this case, the resulting inputs to Validation Output
	Filters and Locally Added Assertions are the respective unions of the		Filters and Locally Added Assertions are the respective unions of the
	inputs from each file. The envisioned typical use case for multiple		inputs from each file. The envisioned typical use case for multiple
	files is when the files have distinct scopes. For instance,		files is when the files have distinct scopes. For instance,
	operators of two distinct networks may resort to one RP system to		operators of two distinct networks may resort to one RP system to
	frame routing decisions. As such, they probably deliver SLURM files		frame routing decisions. As such, they probably deliver SLURM files
	to this RP respectively. Before an RP configures SLURM files from		to this RP respectively. Before an RP configures SLURM files from
	different sources it MUST make sure there is no internal conflict		different sources it MUST make sure there is no internal conflict
	among the INR assertions in these SLURM files. To do so, the RP MUST		among the INR assertions in these SLURM files. To do so, the RP
	check the entries of SLURM file with regard to overlaps of the INR		SHOULD check the entries of SLURM file with regard to overlaps of the
	assertions and report errors to the sources that created these SLURM		INR assertions and report errors to the sources that created these
	files in question.		SLURM files in question. The RP gets multiple SLURM files as a set,
			and the whole set MUST be rejected in case of any overlaps among
			SLURM files.
	If a problem is detected with the INR assertions in these SLURM		If a problem is detected with the INR assertions in these SLURM
	files, the RP MUST NOT use them, and SHOULD issue a warning as error		files, the RP MUST NOT use them, and SHOULD issue a warning as error
	report in the following cases:		report in the following cases:
	1. There may be conflicting changes to Origin Validation		1. There may be conflicting changes to ROA Prefix Assertions if
	assertions if there exists an IP address X and distinct SLURM		there exists an IP address X and distinct SLURM files Y, Z
	files Y, Z such that X is contained by any prefix in any		such that X is contained by any prefix in any
	<prefixAssertions> or <prefixFilters> in file Y and X is		<prefixAssertions> or <prefixFilters> in file Y and X is
	contained by any prefix in any <prefixAssertions> or		contained by any prefix in any <prefixAssertions> or
	<prefixFilters> in file Z.		<prefixFilters> in file Z.
	2. There may be conflicting changes to BGPsec assertions if there		2. There may be conflicting changes to BGPsec Assertions if there
	exists an AS number X and distinct SLURM files Y, Z such that		exists an ASN X and distinct SLURM files Y, Z such that X is
	X is used in any <bgpsecAssertions> or <bgpsecFilters> in file		used in any <bgpsecAssertions> or <bgpsecFilters> in file Y
	Y and X is used in any <bgpsecAssertions> or <bgpsecFilters>		and X is used in any <bgpsecAssertions> or <bgpsecFilters> in
	in file Z.		file Z.
	5. IANA Considerations		5. IANA Considerations
	None		None
	6. Security Considerations		6. Security Considerations
	The mechanisms described in this document provide a network operator		The mechanisms described in this document provide a network operator
	with additional ways to control use of RPKI data while preserving		with additional ways to control use of RPKI data while preserving
	autonomy in address space and ASN management. These mechanisms are		autonomy in address space and ASN management. These mechanisms are
	skipping to change at page 14, line 26 ¶		skipping to change at page 14, line 33 ¶
	operator believes has been corrupted by an adverse action. Network		operator believes has been corrupted by an adverse action. Network
	operators who elect to use SLURM in this fashion should use extreme		operators who elect to use SLURM in this fashion should use extreme
	caution.		caution.
	The goal of the mechanisms described in this document is to enable an		The goal of the mechanisms described in this document is to enable an
	RP to create its own view of the RPKI, which is intrinsically a		RP to create its own view of the RPKI, which is intrinsically a
	security function. An RP using a SLURM file is trusting the		security function. An RP using a SLURM file is trusting the
	assertions made in that file. Errors in the SLURM file used by an RP		assertions made in that file. Errors in the SLURM file used by an RP
	can undermine the security offered by the RPKI, to that RP. It could		can undermine the security offered by the RPKI, to that RP. It could
	declare as invalid ROAs that would otherwise be valid, and vice		declare as invalid ROAs that would otherwise be valid, and vice
	versa. As a result, an RP must carefully consider the security		versa. As a result, an RP MUST carefully consider the security
	implications of the SLURM file being used, especially if the file is		implications of the SLURM file being used, especially if the file is
	provided by a third party.		provided by a third party.
	Additionally, each RP using SLURM MUST ensure the authenticity and		Additionally, each RP using SLURM MUST ensure the authenticity and
	integrity of any SLURM file that it uses. Initially, the SLURM file		integrity of any SLURM file that it uses. Initially, the SLURM file
	may be pre-configured out of band, but if the RP updates its SLURM		may be pre-configured out of band, but if the RP updates its SLURM
	file over the network, it MUST verify the authenticity and integrity		file over the network, it MUST verify the authenticity and integrity
	of the updated SLURM file. Yet the mechanism to update SLURM file to		of the updated SLURM file. Yet the mechanism to update SLURM file to
	guarantee authenticity and integrity is out of the scope of this		guarantee authenticity and integrity is out of the scope of this
	document.		document.
	7. Acknowledgments		7. Acknowledgments
	The authors would like to thank Stephen Kent for his guidance and		The authors would like to thank Stephen Kent for his guidance and
	detailed reviews of this document. Thanks go to Wei Wang for the		detailed reviews of this document. Thanks go to to Richard Hansen
	idea behind the target command, to Richard Hansen for his careful		for his careful reviews, to Hui Zou and Chunlin An for their
	reviews, to Hui Zou and Chunlin An for their editorial assistance.		editorial assistance.
	8. References		8. References
	8.1. Informative References		8.1. Informative References
	[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,		[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
	and E. Lear, "Address Allocation for Private Internets",		and E. Lear, "Address Allocation for Private Internets",
	BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,		BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
	<https://www.rfc-editor.org/info/rfc1918>.		<https://www.rfc-editor.org/info/rfc1918>.
	skipping to change at page 15, line 29 ¶		skipping to change at page 15, line 38 ¶
	[RFC6491] Manderson, T., Vegoda, L., and S. Kent, "Resource Public		[RFC6491] Manderson, T., Vegoda, L., and S. Kent, "Resource Public
	Key Infrastructure (RPKI) Objects Issued by IANA",		Key Infrastructure (RPKI) Objects Issued by IANA",
	RFC 6491, DOI 10.17487/RFC6491, February 2012,		RFC 6491, DOI 10.17487/RFC6491, February 2012,
	<https://www.rfc-editor.org/info/rfc6491>.		<https://www.rfc-editor.org/info/rfc6491>.
	[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and		[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
	M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address		M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
	Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April		Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April
	2012, <https://www.rfc-editor.org/info/rfc6598>.		2012, <https://www.rfc-editor.org/info/rfc6598>.
			[RFC6810] Bush, R. and R. Austein, "The Resource Public Key
			Infrastructure (RPKI) to Router Protocol", RFC 6810,
			DOI 10.17487/RFC6810, January 2013,
			<https://www.rfc-editor.org/info/rfc6810>.
	[RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for		[RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for
	Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, July		Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, July
	2013, <https://www.rfc-editor.org/info/rfc6996>.		2013, <https://www.rfc-editor.org/info/rfc6996>.
			[RFC8210] Bush, R. and R. Austein, "The Resource Public Key
			Infrastructure (RPKI) to Router Protocol, Version 1",
			RFC 8210, DOI 10.17487/RFC8210, September 2017,
			<https://www.rfc-editor.org/info/rfc8210>.
	[RFC8211] Kent, S. and D. Ma, "Adverse Actions by a Certification		[RFC8211] Kent, S. and D. Ma, "Adverse Actions by a Certification
	Authority (CA) or Repository Manager in the Resource		Authority (CA) or Repository Manager in the Resource
	Public Key Infrastructure (RPKI)", RFC 8211,		Public Key Infrastructure (RPKI)", RFC 8211,
	DOI 10.17487/RFC8211, September 2017,		DOI 10.17487/RFC8211, September 2017,
	<https://www.rfc-editor.org/info/rfc8211>.		<https://www.rfc-editor.org/info/rfc8211>.
	8.2. Normative References		8.2. Normative References
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
			[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
			(CIDR): The Internet Address Assignment and Aggregation
			Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
			2006, <https://www.rfc-editor.org/info/rfc4632>.
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data		[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,		Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
	<https://www.rfc-editor.org/info/rfc4648>.		<https://www.rfc-editor.org/info/rfc4648>.
			[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
			Address Text Representation", RFC 5952,
			DOI 10.17487/RFC5952, August 2010,
			<https://www.rfc-editor.org/info/rfc5952>.
	[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for		[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
	X.509 PKIX Resource Certificates", RFC 6487,		X.509 PKIX Resource Certificates", RFC 6487,
	DOI 10.17487/RFC6487, February 2012,		DOI 10.17487/RFC6487, February 2012,
	<https://www.rfc-editor.org/info/rfc6487>.		<https://www.rfc-editor.org/info/rfc6487>.
	[RFC6810] Bush, R. and R. Austein, "The Resource Public Key
	Infrastructure (RPKI) to Router Protocol", RFC 6810,
	DOI 10.17487/RFC6810, January 2013,
	<https://www.rfc-editor.org/info/rfc6810>.
	[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.		[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
	Austein, "BGP Prefix Origin Validation", RFC 6811,		Austein, "BGP Prefix Origin Validation", RFC 6811,
	DOI 10.17487/RFC6811, January 2013,		DOI 10.17487/RFC6811, January 2013,
	<https://www.rfc-editor.org/info/rfc6811>.		<https://www.rfc-editor.org/info/rfc6811>.
			[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol		[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
	Specification", RFC 8205, DOI 10.17487/RFC8205, September		Specification", RFC 8205, DOI 10.17487/RFC8205, September
	2017, <https://www.rfc-editor.org/info/rfc8205>.		2017, <https://www.rfc-editor.org/info/rfc8205>.
	[RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key		[RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key
	Formats, and Signature Formats", RFC 8208,		Formats, and Signature Formats", RFC 8208,
	DOI 10.17487/RFC8208, September 2017,		DOI 10.17487/RFC8208, September 2017,
	<https://www.rfc-editor.org/info/rfc8208>.		<https://www.rfc-editor.org/info/rfc8208>.
	[RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for		[RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for
	BGPsec Router Certificates, Certificate Revocation Lists,		BGPsec Router Certificates, Certificate Revocation Lists,
	and Certification Requests", RFC 8209,		and Certification Requests", RFC 8209,
	DOI 10.17487/RFC8209, September 2017,		DOI 10.17487/RFC8209, September 2017,
	<https://www.rfc-editor.org/info/rfc8209>.		<https://www.rfc-editor.org/info/rfc8209>.
	[RFC8210] Bush, R. and R. Austein, "The Resource Public Key
	Infrastructure (RPKI) to Router Protocol, Version 1",
	RFC 8210, DOI 10.17487/RFC8210, September 2017,
	<https://www.rfc-editor.org/info/rfc8210>.
	[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data		[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
	Interchange Format", STD 90, RFC 8259,		Interchange Format", STD 90, RFC 8259,
	DOI 10.17487/RFC8259, December 2017,		DOI 10.17487/RFC8259, December 2017,
	<https://www.rfc-editor.org/info/rfc8259>.		<https://www.rfc-editor.org/info/rfc8259>.
	Authors' Addresses		Authors' Addresses
	Di Ma		Di Ma
	ZDNS		ZDNS
	4 South 4th St. Zhongguancun		4 South 4th St. Zhongguancun
	Haidian, Beijing 100190		Haidian, Beijing 100190
	China		China
	Email: madi@zdns.cn		Email: madi@zdns.cn
	David Mandelberg		David Mandelberg
	Unaffiliated		Unaffiliated
End of changes. 90 change blocks.
	272 lines changed or deleted		286 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/