RPKI Technical Analysis (Part1)

RPKI Technical Analysis (Part1)

以下内容来自 ICANN | Resource Public Key Infrastructure (RPKI) Technical Analysis | OCTO-014 | September 2020

1.Introduction

• A route leak is “the propagation of routing announcement(s) beyond their intended scope” (RFC 790820). The causes of route leaks include route mis-origination, route hijacks, route policy violation, and others
• Number Resources refers to IP addresses and ASNs
• A trust anchor location (TAL) is a description of the location where a RPKI Trust Anchor can be retrieved.

2.RPKI Background

• RIRs allocate or assign them to network operators such as ISPs. There are five RIRs, one per “continental” service region.
• IRR (Internet Routing Registry)
  • The global IRR is actually made of more than 20 independent (and sometimes inconsistent) databases.
  • ISPs publish their routing policies an announcements in one or more of these databases and then use the IRR to build route announcement filters.
  • Allow their ISP to filter out any erroneous prefix coming from the customer.
  • Major issue: open write access policy: there is little to no validation of what goes into some of these databases, an efforts to create an amalgam of all such IRRs inherit the issue of dubious authenticity of individual entries.
  • An additional concern is that objects in the database tend to go stale quickly due to lack of maintenance. These issues render the quality of the IRR data questionable and make its use to automatically build route filters problematic.
• RPKI
  • provide assurance as to which party can speak authoritatively for an IP address block.
  • not guarantee that the data is up-to-date
  • RPKI origin validation has two operational components: route origin attestation and signing, and route origin validation.
• RPKI origin validation signing: Route Origin Authorization
  • These RPKI certificates may be CA certificates when the subject entity is itself a local Internet registry (LIR) that performs number allocations, or they may be End Entity certificates (EE certificates) that are used to certify a key used to generate a digital signature.
  • ROA (Route Origin Authorization): A ROA is a cryptographically verifiable statement that says: “Prefix P (and its subprefixes, up to the specified maximum prefix length) can be announced by the Autonomous System Number A, signed: the holder of the IP address block corresponding to prefix P.”
    • There can be multiple ROAs covering the same prefix.
      • Multihoming, where two (or more) ISPs originate a prefix.
      • An ISP transitions some address space from one ASN to another.
• Resource PKI: Delegated Repository vs. Hosted Model
  • The RIRs developed a hosted model
• RPKI origin validation: Route Origin Validation (ROV)
  • ROV is a process used by routers at ISP BGP peering points to automatically accept or reject BGP route announcements based on a precomputed filter list derived from the Resource PKI and ROAs.
  • Routers performing ROV used in peering do not need to perform the CPU intensive cryptographic functions necessary to validate the ROAs’ digital signatures, the precursor to forming and maintaining route announcement filters.
  • BGP routers rely on external computers running validator software to perform the cryptographic validation and build prefix filters based on validated ROAs, augmented potentially by other local sources of routing policies.
  • To perform this task, the software needs to be constantly synchronized with all ROA repositories across the Internet.
  • Building this list starts with downloading five TALs, one from each of the RIRs. Once the TALs are obtained, the validator software can follow the publication pointers in the chain of certificates and recursively download certificates and signed product ROAs from the various Resource PKI repositories.
  • Local knowledge can be added to the list of synchronized ROAs. (e.g. private IP addresses)
  • Once the list of all valid ROAs is obtained, the next step is the synchronization of the peering routers with validator software.
• Data quality
  • Frivolous Origin ASN: A ROA is signed by the owner of an IP prefix, not by the owner of the AS number. As such it is entirely possible to insert frivolous ROAs into the system, signed by the rightful owner of an address block, but asserting some arbitrary AS number as the authorized origin AS.
  • Different maximum prefix length: Two ROAs have the same prefix but different maximum prefix lengths. The larger ROA will stay in the system until it expires.
  • Stale Data
• Other Usage of Resource PKI
  • Some policy proposals in several RIRs have been adopted, or are under discussion, to use the Resource PKI to validate the data in the IRR and remove bogus entries. For example, see RIPE’s object clean-up proposal. https://www.ripe.net/publications/docs/ripe-731
  • As most legacy addresses are within the ARIN region, many of those legacy blocks cannot be covered by ROAs. While RPKI origin validation adoption is still low, this legacy address issue at ARIN has not been a major problem.

3.From One Root at IANA to Five (or More) Roots

• Five RIR TALs for RPKI Origin Validation
  • This would still generate complexities in the certificate infrastructure when number resources are moved from one RIR to another.
  • Each RIR, by virtue of this new technical capability claims coverage for the entire address space and AS number space.
  • Coordination
  • Conflicts
  • More than five TALs(Trust anchor location)
• AS0: Covering Unallocated Space
  • IP address space squatting. An ISP, wittingly or unwittingly, is convinced to announce unallocated IP address space. This usually gets detected and fixed fairly quickly, but for a period of time, hours or days, that address block is connected.
  • The recommendation was that IANA should issue an AS 0 ROA for all reserved IPv4 and IPv6 resources not intended to be routed.