]> BBN Technologies

10 Moulton St. Camridge MA 02138 US david@mandelberg.org

Secure Inter-Domain Routing 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. Internet Service Providers (ISPs) can use the RPKI to validate BGP route origination assertions. Some ISPs locally use BGP with private address space or private AS numbers (see RFC6890). These local BGP routes cannot be verified by the global RPKI, and SHOULD be considered invalid based on the global RPKI (see RFC6491). The mechanisms described below provide ISPs with a way to make local assertions about private (reserved) INRs while using the RPKI's assertions about all other INRs.

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 Origination Authorization (ROA) 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. However, some ISPs locally use BGP with private address space (, , ) or private AS numbers (, ). These local BGP routes cannot be verified by the global RPKI, and SHOULD be considered invalid when using the RPKI. For example, recommends the creation of ROAs that would invalidate routes for reserved and unallocated address space. This document specifies two new mechanisms to enable ISPs to make local assertions about private INRs while using the RPKI's assertions about all other INRs. Both mechanisms are specified in terms of abstract sets of assertions. For Origin Validation , an assertion is a tuple of {IP prefix, prefix length, maximum length, AS number} as used by rpki-rtr. Output Filtering, described in , filters out any assertions by the RPKI about locally reserved INRs. Locally Adding Assertions, described in , adds local assertions about locally reserved INRs. Note that both of these mechanisms can later be extended to cover any assertions made by the RPKI for use in BGPSEC. In general, the primary output of an RPKI relying party is the data it sends to routers over the rpki-rtr protocol. The rpki-rtr protocol enables routers to query a relying party for all Origin Validation assertions it knows about (Reset Query) or for an update of only the changes in Origin Validation 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. Relying party software MAY modify other forms of output in comparable ways, but that is outside the scope of this document. This document is intended to supersede while focusing only on local management of private INRs. Another draft focuses on the other aspects of local management.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

To prevent the global RPKI from affecting routes with locally reserved INRs, a relying party is locally configured with a list of IP prefixes and/or AS numbers that are used locally, and taken from the reserved INR spaces. Any Origin Validation assertions where the IP prefix is equal to or subsumed by a locally reserved IP prefix, are removed from the relying party's output. Any Origin Validation assertions where the IP prefix contains a locally reserved IP prefix are removed and the relying party software SHOULD issue a warning.

Each relying party is locally configured with a (possibly empty) list of Origin Validation assertions. This list is added to the relying party's output.

Relying party software SHOULD support the following configuration format for Validation Output Filtering and Locally Adding Assertions. The format is defined using the Augmented Backus-Naur Form (ABNF) notation and core rules from and the rules <IPv4address> and <IPv6address> from Appendix A of . Each <del> command specifies an INR to use for Validation Output Filtering. Each <add> command specifies an assertion to use for Locally Adding Assertions. See for an example SLURM file.

SLURMFile = header *line header = %x53.4c.55.52.4d SP "1.0" CRLF ; "SLURM 1.0" line = *WSP [comment] CRLF / *WSP command [ 1*WSP [comment] ] CRLF comment = "#" *(VCHAR / WSP) command = add / del add = %x61.64.64 1*WSP IPprefixMaxLen 1*WSP ASnum del = %x64.65.6c 1*WSP inr inr = IPprefix / ASnum IPprefix = IPv4prefix / IPv6prefix IPprefixMaxLen = IPv4prefixMaxLen / IPv6prefixMaxLen IPv4prefix = IPv4address "/" 1*2DIGIT IPv6prefix = IPv6address "/" 1*3DIGIT ; In the following two rules, if the maximum length component is ; missing, it is treated as equal to the prefix length. IPv4prefixMaxLen = IPv4prefix ["-" 1*2DIGIT] IPv6prefixMaxLen = IPv6prefix ["-" 1*3DIGIT] ASnum = 1*DIGIT

In the typical use case, a relying party uses both output filtering and locally added assertions. In this case, the resulting assertions MUST be the same as if output filtering were performed before locally adding assertions. I.e., locally added assertions MUST NOT be removed by output filtering. If a relying party chooses to use both SLURM and Suspenders, the SLURM mechanisms MUST be performed on the output of Suspenders.

TBD

The mechanisms described in this document provide an ISP additional control over its own network. Care should be taken in how that control is used.

The author would like to thank Stephen Kent for his guidance and detailed reviews of this document.

&rfc1918; &rfc1930; &rfc4193; &rfc6482; &rfc6483; &rfc6491; &rfc6598; &rfc6810; &rfc6890; &rfc6996; &I-D.ietf-sidr-bgpsec-protocol; &I-D.ietf-sidr-ltamgmt; &I-D.kent-sidr-suspenders; &rfc2119; &rfc3986; &rfc5234;

SLURM 1.0 # Reserve 192.0.2.0/24 and 2001:DB8::/32 for local use. del 192.0.2.0/24 del 2001:DB8::/32 # Allow either 65536 or 65537 to originate routes to 192.0.2.0/24. add 192.0.2.0/24 65536 add 192.0.2.0/24 65537 add 2001:DB8::/48-52 65536 # 65536 originates 2001:DB8::/48 and # sub-prefixes down to length 52. add 2001:DB8:0:42::/64 65537 # However, 65537 originates # 2001:DB8:0:42::/64. add 2001:DB8:1::/48 65537 # 65537 also originates 2001:DB8:1::/48