summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8416.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8416.txt')
-rw-r--r--doc/rfc/rfc8416.txt955
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc8416.txt b/doc/rfc/rfc8416.txt
new file mode 100644
index 0000000..c09f9fd
--- /dev/null
+++ b/doc/rfc/rfc8416.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) D. Ma
+Request for Comments: 8416 ZDNS
+Category: Standards Track D. Mandelberg
+ISSN: 2070-1721 Unaffiliated
+ T. Bruijnzeels
+ NLnet Labs
+ August 2018
+
+
+ Simplified Local Internet Number Resource Management with the RPKI
+ (SLURM)
+
+Abstract
+
+ The Resource Public Key Infrastructure (RPKI) is a global
+ authorization infrastructure that allows the holder of Internet
+ Number Resources (INRs) to make verifiable statements about those
+ resources. Network operators, e.g., Internet Service Providers
+ (ISPs), can use the RPKI to validate BGP route origin assertions.
+ ISPs can also use the RPKI to validate the path of a BGP route.
+ However, ISPs may want to establish a local view of exceptions to the
+ RPKI data in the form of local filters and additions. The mechanisms
+ described in this document provide a simple way to enable INR holders
+ to establish a local, customized view of the RPKI, overriding global
+ RPKI repository data as needed.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc8416.
+
+
+
+
+
+
+
+
+
+
+
+
+Ma, et al. Standards Track [Page 1]
+
+RFC 8416 SLURM August 2018
+
+
+Copyright Notice
+
+ Copyright (c) 2018 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (https://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Terminology ................................................4
+ 2. RP with SLURM ...................................................4
+ 3. SLURM Files and Mechanisms ......................................5
+ 3.1. Use of JSON ................................................5
+ 3.2. SLURM File Overview ........................................5
+ 3.3. Validation Output Filters ..................................6
+ 3.3.1. Validated ROA Prefix Filters ........................6
+ 3.3.2. BGPsec Assertion Filters ............................7
+ 3.4. Locally Added Assertions ...................................9
+ 3.4.1. ROA Prefix Assertions ...............................9
+ 3.4.2. BGPsec Assertions ..................................10
+ 3.5. Example of a SLURM File with Filters and Assertions .......11
+ 4. SLURM File Configuration .......................................13
+ 4.1. SLURM File Atomicity ......................................13
+ 4.2. Multiple SLURM Files ......................................13
+ 5. IANA Considerations ............................................14
+ 6. Security Considerations ........................................14
+ 7. References .....................................................14
+ 7.1. Normative References ......................................14
+ 7.2. Informative References ....................................16
+ Acknowledgments ...................................................17
+ Authors' Addresses ................................................17
+
+
+
+
+
+
+
+
+
+
+
+Ma, et al. Standards Track [Page 2]
+
+RFC 8416 SLURM August 2018
+
+
+1. Introduction
+
+ The Resource Public Key Infrastructure (RPKI) is a global
+ authorization infrastructure that allows the holder of Internet
+ Number Resources (INRs) to make verifiable statements about those
+ resources. For example, the holder of a block of IP(v4 or v6)
+ addresses can issue a Route Origin Authorization (ROA) [RFC6482] to
+ authorize an Autonomous System (AS) to originate routes for that
+ block. Internet Service Providers (ISPs) can then use the RPKI to
+ 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 [RFC8205].)
+
+ However, an RPKI Relying Party (RP) may want to override some of the
+ information expressed via configured Trust Anchors (TAs) and the
+ certificates downloaded from the RPKI repository system. For
+ instance, [RFC6491] recommends the creation of ROAs that would
+ invalidate public routes for reserved and unallocated address space,
+ yet some ISPs might like to use BGP and the RPKI with private address
+ space (see [RFC1918], [RFC4193], and [RFC6598]) or private AS numbers
+ (see [RFC1930] and [RFC6996]). Local use of private address space
+ and/or AS numbers is consistent with the RFCs cited above, but such
+ use cannot be verified by the global RPKI. This motivates creation
+ of mechanisms that enable a network operator to publish, at its
+ discretion, an exception to the RPKI in the form of filters and
+ additions (for its own use and that of its customers). Additionally,
+ a network operator might wish to make use of a local override
+ capability to protect routes from adverse actions [RFC8211], until
+ the results of such actions have been addressed. The mechanisms
+ developed to provide this capability to network operators are hereby
+ called "Simplified Local Internet Number Resource Management with the
+ RPKI (SLURM)".
+
+ SLURM allows an operator to create a local view of the global RPKI by
+ generating sets of assertions. For origin validation [RFC6811], an
+ assertion is a tuple of {IP prefix, prefix length, maximum length,
+ Autonomous System Number (ASN)} as used by the RPKI-Router protocol,
+ version 0 [RFC6810] and version 1 [RFC8210]. For BGPsec [RFC8205],
+ an assertion is a tuple of {ASN, subject key identifier, router
+ public key} as used by version 1 of the RPKI-Router protocol. (For
+ the remainder of this document, these assertions are called "ROA
+ Prefix Assertions" and "BGPsec Assertions", respectively.)
+
+
+
+
+
+
+
+
+
+Ma, et al. Standards Track [Page 3]
+
+RFC 8416 SLURM August 2018
+
+
+1.1. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "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
+
+ SLURM provides a simple way to enable an RP to establish a local,
+ customized view of the RPKI, overriding RPKI repository data if
+ needed. To that end, an RP with SLURM filters out (i.e., removes
+ from consideration for routing decisions) any assertions in the RPKI
+ that are overridden by local ROA Prefix Assertions and BGPsec
+ Assertions.
+
+ In general, the primary output of an RP is the data it sends to
+ routers over the RPKI-Router protocol [RFC8210]. The RPKI-Router
+ protocol enables routers to query an RP for all assertions it knows
+ about (Reset Query) or for an update of only the changes in
+ assertions (Serial Query). The mechanisms specified in this document
+ are to be applied to the result set for a Reset Query and to both the
+ old and new sets that are compared for a Serial Query. RP software
+ may modify other forms of output in comparable ways, but that is
+ outside the scope of this document.
+
+ +--------------+ +---------------------------+ +------------+
+ | | | | | |
+ | Repositories +--->Local cache of RPKI objects+---> Validation |
+ | | | | | |
+ +--------------+ +---------------------------+ +-----+------+
+ |
+ +-------------------------------------------------+
+ |
+ +------v-------+ +------------+ +-----------+ +-------------+
+ | | | | | | | |
+ | SLURM +---> SLURM +--->RPKI-Router+---> BGP Speakers|
+ | Filters | | Assertions | | Protocol | | |
+ +--------------+ +------------+ +-----------+ +-------------+
+
+ Figure 1: SLURM's Position in the RP Stack
+
+
+
+
+
+
+
+
+
+Ma, et al. Standards Track [Page 4]
+
+RFC 8416 SLURM August 2018
+
+
+3. SLURM Files and Mechanisms
+
+3.1. Use of JSON
+
+ SLURM filters and assertions are specified in JSON format [RFC8259].
+ JSON members that are not defined here MUST NOT be used in SLURM
+ files. An RP MUST consider any deviations from the specifications to
+ be errors. Future additions to the specifications in this document
+ MUST use an incremented value for the "slurmVersion" member.
+
+3.2. SLURM File Overview
+
+ A SLURM file consists of a single JSON object containing the
+ following members:
+
+ o A "slurmVersion" member that MUST be set to 1, encoded as a number
+
+ o A "validationOutputFilters" member (Section 3.3), whose value is
+ an object. The object MUST contain exactly two members:
+
+ * A "prefixFilters" member, whose value is described in
+ Section 3.3.1.
+
+ * A "bgpsecFilters" member, whose value is described in
+ Section 3.3.2.
+
+ o A "locallyAddedAssertions" member (Section 3.4), whose value is an
+ object. The object MUST contain exactly two members:
+
+ * A "prefixAssertions" member, whose value is described in
+ Section 3.4.1.
+
+ * A "bgpsecAssertions" member, whose value is described in
+ Section 3.4.2.
+
+ In the envisioned typical use case, an RP uses both Validation Output
+ Filters and Locally Added Assertions. In this case, the resulting
+ assertions MUST be the same as if output filtering were performed
+ before locally adding assertions; that is, Locally Added Assertions
+ MUST NOT be removed by output filtering.
+
+ The following JSON structure with JSON members represents a SLURM
+ file that has no filters or assertions:
+
+
+
+
+
+
+
+
+Ma, et al. Standards Track [Page 5]
+
+RFC 8416 SLURM August 2018
+
+
+ {
+ "slurmVersion": 1,
+ "validationOutputFilters": {
+ "prefixFilters": [],
+ "bgpsecFilters": []
+ },
+ "locallyAddedAssertions": {
+ "prefixAssertions": [],
+ "bgpsecAssertions": []
+ }
+ }
+
+ Figure 2: Empty SLURM File
+
+3.3. Validation Output Filters
+
+3.3.1. Validated ROA Prefix Filters
+
+ The RP can configure zero or more Validated ROA Prefix Filters
+ ("Prefix Filters" for short). Each Prefix Filter can contain either
+ an IPv4 or IPv6 prefix and/or an ASN. 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.
+
+ The above is expressed as a value of the "prefixFilters" member, as
+ an array of zero or more objects. Each object MUST contain either 1)
+ one of the following members or 2) one of each of the following
+ members.
+
+ o A "prefix" member, whose value is a string representing either an
+ IPv4 prefix (see Section 3.1 of [RFC4632]) or an IPv6 prefix (see
+ [RFC5952]).
+
+ o An "asn" member, whose value is a number.
+
+ In addition, each object MAY contain one optional "comment" member,
+ whose value is a string.
+
+ The following example JSON structure represents a "prefixFilters"
+ member with an array of example objects for each use case listed
+ above:
+
+
+
+
+
+
+
+
+
+
+Ma, et al. Standards Track [Page 6]
+
+RFC 8416 SLURM August 2018
+
+
+ "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"
+ }
+ ]
+
+ Figure 3: "prefixFilters" Examples
+
+ Any Validated ROA Payload (VRP) [RFC6811] that matches any configured
+ Prefix Filter MUST be removed from the RP's output.
+
+ A VRP is considered to match with a Prefix Filter if one of the
+ following cases applies:
+
+ 1. If the Prefix Filter only contains an IPv4 or IPv6 prefix, the
+ VRP is considered to match the filter if the VRP prefix is equal
+ to or covered by the Prefix Filter prefix.
+
+ 2. If the Prefix Filter only contains an ASN, the VRP is considered
+ to match the filter if the VRP ASN matches the Prefix Filter ASN.
+
+ 3. If the Prefix Filter contains both an IPv4 or IPv6 prefix and an
+ ASN, the VRP is considered to match if the VRP prefix is equal to
+ or covered by the Prefix Filter prefix and the VRP ASN matches
+ the Prefix Filter ASN.
+
+3.3.2. BGPsec Assertion Filters
+
+ The RP can configure zero or more BGPsec Assertion Filters ("BGPsec
+ Filters" for short). Each BGPsec Filter can contain an ASN and/or
+ the Base64 [RFC4648] encoding of a Router Subject Key Identifier
+ (SKI), 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.
+
+ 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:
+
+
+
+Ma, et al. Standards Track [Page 7]
+
+RFC 8416 SLURM August 2018
+
+
+ o An "asn" member, whose value is a number
+
+ o An "SKI" member, whose value is the Base64 encoding without
+ trailing '=' (Section 5 of [RFC4648]) of the certificate's Subject
+ Key Identifier 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.)
+
+ In addition, each object MAY contain one optional "comment" member,
+ whose value is a string.
+
+ The following example JSON structure represents a "bgpsecFilters"
+ member with an array of example objects for each use case listed
+ 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"
+ }
+ ]
+
+ Figure 4: "bgpsecFilters" Examples
+
+ Any BGPsec Assertion that matches any configured BGPsec Filter MUST
+ 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:
+
+ 1. If the BGPsec Filter only contains an ASN, a BGPsec Assertion is
+ considered to match if the Assertion ASN matches the Filter ASN.
+
+ 2. If the BGPsec Filter only contains an SKI, a BGPsec Assertion is
+ considered to match if the Assertion Router SKI matches the
+ Filter SKI.
+
+ 3. If the BGPsec Filter contains both an ASN and a Router SKI, 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 SKI.
+
+
+
+Ma, et al. Standards Track [Page 8]
+
+RFC 8416 SLURM August 2018
+
+
+3.4. Locally Added Assertions
+
+3.4.1. ROA Prefix Assertions
+
+ Each RP is locally configured with a (possibly empty) array of ROA
+ Prefix Assertions ("Prefix Assertions" for short). Each ROA Prefix
+ Assertion MUST contain an IPv4 or IPv6 prefix and an ASN. It MAY
+ 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 of the RP software.
+
+ The above is expressed as a value of the "prefixAssertions" member,
+ as an array of zero or more objects. Each object MUST contain one of
+ each of the following members:
+
+ o A "prefix" member, whose value is a string representing either an
+ IPv4 prefix (see Section 3.1 of [RFC4632]) or an IPv6 prefix (see
+ [RFC5952]).
+
+ o An "asn" member, whose value is a number.
+
+ In addition, each object MAY contain one of each of the following
+ members:
+
+ o A "maxPrefixLength" member, whose value is a number.
+
+ o A "comment" member, whose value is a string.
+
+ The following example JSON structure represents a "prefixAssertions"
+ member with an array of example objects for each use case listed
+ above:
+
+ "prefixAssertions": [
+ {
+ "asn": 64496,
+ "prefix": "198.51.100.0/24",
+ "comment": "My other important route"
+ },
+ {
+ "asn": 64496,
+ "prefix": "2001:DB8::/32",
+ "maxPrefixLength": 48,
+ "comment": "My other important de-aggregated routes"
+ }
+ ]
+
+ Figure 5: "prefixAssertions" Examples
+
+
+
+
+Ma, et al. Standards Track [Page 9]
+
+RFC 8416 SLURM August 2018
+
+
+ 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 Protocol Data
+ Units (PDUs), excluding duplicates when using the RPKI-Router
+ protocol (see Sections 5.6 and 5.7 of [RFC8210]).
+
+3.4.2. BGPsec Assertions
+
+ Each RP is locally configured with a (possibly empty) array of BGPsec
+ 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.
+
+ The above is expressed as a value of the "bgpsecAssertions" member,
+ as an array of zero or more objects. Each object MUST contain one
+ each of all of the following members:
+
+ o An "asn" member, whose value is a number.
+
+ o An "SKI" member, whose value is the Base64 encoding without
+ trailing '=' (Section 5 of [RFC4648]) of the certificate's Subject
+ Key Identifier 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.)
+
+ o A "routerPublicKey" member, whose value is the Base64 encoding
+ without trailing '=' (Section 5 of [RFC4648]) of the equivalent to
+ the subjectPublicKeyInfo value of the router certificate's public
+ key, 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 example JSON structure represents a "bgpsecAssertions"
+ member with one object as described above:
+
+ "bgpsecAssertions": [
+ {
+ "asn": 64496,
+ "SKI": "<some base64 SKI>",
+ "routerPublicKey": "<some base64 public key>",
+ "comment": "My known key for my important ASN"
+ }
+ ]
+
+ Figure 6: "bgpsecAssertions" Examples
+
+
+
+
+Ma, et al. Standards Track [Page 10]
+
+RFC 8416 SLURM August 2018
+
+
+ Note that a "bgpsecAssertions" member matches the syntax of the
+ Router Key PDU described in Section 5.10 of [RFC8210]. Relying
+ Parties MUST add any "bgpsecAssertions" member thus found to the set
+ of Router Key PDUs, excluding duplicates, when using the RPKI-Router
+ protocol [RFC8210].
+
+3.5. Example of a SLURM File with Filters and Assertions
+
+ The following JSON structure represents an example of a SLURM file
+ that uses all the elements described in the previous sections:
+
+ {
+ "slurmVersion": 1,
+ "validationOutputFilters": {
+ "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"
+ }
+ ],
+ "bgpsecFilters": [
+ {
+ "asn": 64496,
+ "comment": "All keys for ASN"
+ },
+ {
+ "SKI": "Zm9v",
+ "comment": "Key matching Router SKI"
+ },
+ {
+ "asn": 64497,
+ "SKI": "YmFy",
+ "comment": "Key for ASN 64497 matching Router SKI"
+ }
+ ]
+ },
+ "locallyAddedAssertions": {
+ "prefixAssertions": [
+ {
+
+
+
+Ma, et al. Standards Track [Page 11]
+
+RFC 8416 SLURM August 2018
+
+
+ "asn": 64496,
+ "prefix": "198.51.100.0/24",
+ "comment": "My other important route"
+ },
+ {
+ "asn": 64496,
+ "prefix": "2001:DB8::/32",
+ "maxPrefixLength": 48,
+ "comment": "My other important de-aggregated routes"
+ }
+ ],
+ "bgpsecAssertions": [
+ {
+ "asn": 64496,
+ "comment" : "My known key for my important ASN",
+ "SKI": "<some base64 SKI>",
+ "routerPublicKey": "<some base64 public key>"
+ }
+ ]
+ }
+ }
+
+ Figure 7: Example of Full SLURM File
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ma, et al. Standards Track [Page 12]
+
+RFC 8416 SLURM August 2018
+
+
+4. SLURM File Configuration
+
+4.1. SLURM File Atomicity
+
+ To ensure local consistency, the effect of SLURM MUST be atomic.
+ That is, the output of the RP either MUST be the same as if a SLURM
+ file were not used or MUST reflect the entire SLURM configuration.
+ For an example of why this is required, consider the case of two
+ local routes for the same prefix but different origin ASNs. Both
+ routes are configured with Locally Added Assertions. If neither
+ addition occurs, then both routes could be in the NotFound state
+ [RFC6811]. If both additions occur, then both routes would be in the
+ Valid state. However, if one addition occurs and the other does not,
+ then one could be Invalid while the other is Valid.
+
+4.2. Multiple SLURM Files
+
+ An implementation MAY support the concurrent use of multiple SLURM
+ files. In this case, the resulting inputs to Validation Output
+ Filters and Locally Added Assertions are the respective unions of the
+ inputs from each file. The envisioned typical use case for multiple
+ files is when the files have distinct scopes. For instance,
+ operators of two distinct networks may resort to one RP system to
+ frame routing decisions. As such, they probably deliver SLURM files
+ to this RP independently. Before an RP configures SLURM files from
+ different sources, it MUST make sure there is no internal conflict
+ among the INR assertions in these SLURM files. To do so, the RP
+ SHOULD check the entries of each SLURM file with regard to overlaps
+ of the INR assertions and report errors to the sources that created
+ the 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
+ the SLURM files.
+
+ 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
+ report in the following cases:
+
+ 1. There may be conflicting changes to ROA Prefix Assertions if an
+ IP address X and distinct SLURM files Y and Z exist such that X
+ is contained by any prefix in any "prefixAssertions" or
+ "prefixFilters" in file Y and X is contained by any prefix in any
+ "prefixAssertions" or "prefixFilters" in file Z.
+
+ 2. There may be conflicting changes to BGPsec Assertions if an ASN X
+ and distinct SLURM files Y and Z exist such that X is used in any
+ "bgpsecAssertions" or "bgpsecFilters" in file Y and X is used in
+ any "bgpsecAssertions" or "bgpsecFilters" in file Z.
+
+
+
+
+Ma, et al. Standards Track [Page 13]
+
+RFC 8416 SLURM August 2018
+
+
+5. IANA Considerations
+
+ This document has no IANA actions.
+
+6. Security Considerations
+
+ The mechanisms described in this document provide a network operator
+ with additional ways to control use of RPKI data while preserving
+ autonomy in address space and ASN management. These mechanisms are
+ only applied locally; they do not influence how other network
+ operators interpret RPKI data. Nonetheless, care should be taken in
+ how these mechanisms are employed. Note that it also is possible to
+ use SLURM to (locally) manipulate assertions about non-private INRs,
+ e.g., allocated address space that is globally routed. For example,
+ a SLURM file may be used to override RPKI data that a network
+ operator believes has been corrupted by an adverse action. Network
+ operators who elect to use SLURM in this fashion should use extreme
+ caution.
+
+ 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
+ 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
+ can undermine the security offered to that RP by the RPKI. A SLURM
+ file could declare as invalid ROAs that would otherwise be valid, and
+ vice versa. As a result, an RP MUST carefully consider the security
+ implications of the SLURM file being used, especially if the file is
+ provided by a third party.
+
+ Additionally, each RP using SLURM MUST ensure the authenticity and
+ integrity of any SLURM file that it uses. Initially, the SLURM file
+ may be preconfigured out of band, but if the RP updates its SLURM
+ file over the network, it MUST verify the authenticity and integrity
+ of the updated SLURM file. The mechanism to update the SLURM file to
+ guarantee authenticity and integrity is out of the scope of this
+ document.
+
+7. References
+
+7.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+
+
+
+
+
+Ma, et al. Standards Track [Page 14]
+
+RFC 8416 SLURM August 2018
+
+
+ [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
+ Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
+ <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
+ X.509 PKIX Resource Certificates", RFC 6487,
+ DOI 10.17487/RFC6487, February 2012,
+ <https://www.rfc-editor.org/info/rfc6487>.
+
+ [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
+ Austein, "BGP Prefix Origin Validation", RFC 6811,
+ DOI 10.17487/RFC6811, January 2013,
+ <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
+ Specification", RFC 8205, DOI 10.17487/RFC8205, September
+ 2017, <https://www.rfc-editor.org/info/rfc8205>.
+
+ [RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key
+ Formats, and Signature Formats", RFC 8208,
+ DOI 10.17487/RFC8208, September 2017,
+ <https://www.rfc-editor.org/info/rfc8208>.
+
+ [RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for
+ BGPsec Router Certificates, Certificate Revocation Lists,
+ and Certification Requests", RFC 8209,
+ DOI 10.17487/RFC8209, September 2017,
+ <https://www.rfc-editor.org/info/rfc8209>.
+
+ [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
+ Interchange Format", STD 90, RFC 8259,
+ DOI 10.17487/RFC8259, December 2017,
+ <https://www.rfc-editor.org/info/rfc8259>.
+
+
+
+
+Ma, et al. Standards Track [Page 15]
+
+RFC 8416 SLURM August 2018
+
+
+7.2. Informative References
+
+ [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
+ and E. Lear, "Address Allocation for Private Internets",
+ BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
+ <https://www.rfc-editor.org/info/rfc1918>.
+
+ [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation,
+ selection, and registration of an Autonomous System (AS)",
+ BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996,
+ <https://www.rfc-editor.org/info/rfc1930>.
+
+ [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
+ Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
+ <https://www.rfc-editor.org/info/rfc4193>.
+
+ [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
+ Origin Authorizations (ROAs)", RFC 6482,
+ DOI 10.17487/RFC6482, February 2012,
+ <https://www.rfc-editor.org/info/rfc6482>.
+
+ [RFC6491] Manderson, T., Vegoda, L., and S. Kent, "Resource Public
+ Key Infrastructure (RPKI) Objects Issued by IANA",
+ RFC 6491, DOI 10.17487/RFC6491, February 2012,
+ <https://www.rfc-editor.org/info/rfc6491>.
+
+ [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
+ M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
+ Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April
+ 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
+ Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, July
+ 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>.
+
+
+
+
+
+
+
+Ma, et al. Standards Track [Page 16]
+
+RFC 8416 SLURM August 2018
+
+
+ [RFC8211] Kent, S. and D. Ma, "Adverse Actions by a Certification
+ Authority (CA) or Repository Manager in the Resource
+ Public Key Infrastructure (RPKI)", RFC 8211,
+ DOI 10.17487/RFC8211, September 2017,
+ <https://www.rfc-editor.org/info/rfc8211>.
+
+Acknowledgments
+
+ The authors would like to thank Stephen Kent for his guidance and
+ detailed reviews of this document. The authors would also like to
+ thank Richard Hansen for his careful reviews and Hui Zou and Chunlin
+ An for their editorial assistance.
+
+Authors' Addresses
+
+ Di Ma
+ ZDNS
+ 4 South 4th St. Zhongguancun
+ Haidian, Beijing 100190
+ China
+
+ Email: madi@zdns.cn
+
+
+ David Mandelberg
+ Unaffiliated
+
+ Email: david@mandelberg.org
+ URI: https://david.mandelberg.org
+
+
+ Tim Bruijnzeels
+ NLnet Labs
+ Science Park 400
+ Amsterdam 1098 XH
+ The Netherlands
+
+ Email: tim@nlnetlabs.nl
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ma, et al. Standards Track [Page 17]
+