Simplified Local Internet Number Resource Management with the RPKI (SLURM)
Extracted elements (24)
JSON was chosen as the format for SLURM files (RFC 8259) because it provides a simple, well-understood, human-readable structure for expressing filters and assertions; undefined JSON members MUST NOT be used so that future extensions require a version increment.
Multiple SLURM files are supported to accommodate the use case where operators of two distinct networks share a single RP system and deliver SLURM files independently, requiring conflict detection before merging.
SLURM applies only locally and does not influence how other network operators interpret RPKI data, preserving the operator's autonomy in address space and ASN management without affecting the global RPKI.
SLURM was created because ISPs may need to use BGP and the RPKI with private address space or private AS numbers that cannot be verified by the global RPKI, and to allow operators to protect routes from adverse actions against the RPKI until those actions are remedied.
The 'bgpsecAssertions' member matches the syntax of the Router Key PDU described in Section 5.10 of RFC 8210, enabling direct integration with the RPKI-Router protocol.
The SLURM mechanisms must be applied to the result set for a Reset Query and to both the old and new assertion sets compared for a Serial Query in the RPKI-Router protocol (RFC 8210).
Any BGPsec Assertion that matches any configured BGPsec Filter MUST be removed from the RP's output. Match is based on ASN-only, SKI-only, or both ASN and SKI.
Any Validated ROA Payload (VRP) that matches any configured Prefix Filter MUST be removed from the RP's output.
Before configuring SLURM files from different sources, an RP MUST verify there is no internal conflict among INR assertions. If overlapping prefixes or ASNs are found across SLURM files, the RP MUST NOT use them and SHOULD issue a warning; the whole set of files MUST be rejected.
JSON members not defined in the SLURM specification MUST NOT be used in SLURM files, and an RP MUST treat any deviations from the specifications as errors.
Relying Parties MUST add any 'bgpsecAssertions' entries to the set of Router Key PDUs, excluding duplicates, when using the RPKI-Router protocol. The bgpsecAssertions syntax matches the Router Key PDU described in Section 5.10 of RFC 8210.
The effect of SLURM MUST be atomic: the RP output MUST either be entirely as if no SLURM file were used, or MUST reflect the entire SLURM configuration. Partial application of SLURM (e.g., one of two locally asserted routes for the same prefix) could result in inconsistent route validity states.
The RP MUST add all locally configured Prefix Assertions to the VRP set found through RPKI validation and MUST send the complete set of PDUs, excluding duplicates, via the RPKI-Router protocol.
The 'slurmVersion' member MUST be set to 1, encoded as a number; future additions to the specification MUST use an incremented value for this member.
When both Validation Output Filters and Locally Added Assertions are used, 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.
When using multiple SLURM files, the resulting inputs to Validation Output Filters and Locally Added Assertions are the respective unions of the inputs from each file.
A BGPsec Assertion Filter ('BGPsec Filter') is a JSON object that MUST contain an 'asn' member (number) and/or an 'SKI' member (Base64-encoded Subject Key Identifier without trailing '='), with an optional 'comment' string.
A BGPsec Assertion is a JSON object that MUST contain an 'asn' member (number), an 'SKI' member (Base64 without trailing '=' of the Subject Key Identifier), and a 'routerPublicKey' member (Base64 without trailing '=' of the full ASN.1 DER-encoded subjectPublicKeyInfo).
A ROA Prefix Assertion is a JSON object that MUST contain a 'prefix' member (IPv4 or IPv6 string) and an 'asn' member (number), and MAY contain a 'maxPrefixLength' member (number) and a 'comment' string. This tuple describes a VRP as per RFC 6811.
A SLURM file is a single JSON object with three top-level members: 'slurmVersion' (number, MUST be 1), 'validationOutputFilters' (containing 'prefixFilters' and 'bgpsecFilters' arrays), and 'locallyAddedAssertions' (containing 'prefixAssertions' and 'bgpsecAssertions' arrays).
A Validated ROA Prefix Filter ('Prefix Filter') is a JSON object that MUST contain either a 'prefix' member (IPv4 or IPv6 prefix string) and/or an 'asn' member (number), with an optional 'comment' string. Three match cases are defined: prefix-only (covers VRP prefix), ASN-only, or both prefix and ASN.
An RP using a SLURM file trusts the assertions made in that file. Errors in the SLURM file can undermine the security offered by the RPKI; it could declare valid ROAs as invalid and vice versa. An RP MUST carefully consider the security implications, especially when the file is provided by a third party.
Each RP using SLURM MUST ensure the authenticity and integrity of any SLURM file it uses. If the RP updates its SLURM file over the network, it MUST verify the authenticity and integrity of the updated file; the specific mechanism to do so is out of scope for this document.
SLURM can be used to locally manipulate assertions about non-private INRs such as globally routed address space, for example to override RPKI data believed to be corrupted by adverse actions. Network operators who elect to use SLURM in this fashion should use extreme caution.