RFC 8897

Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties

📅 published September 2020, from ietf

RFC 8897: Requirements for RPKI Relying Parties 🎀

Title block, the tea ☕

  • RFC number: 8897 ✨
  • Title: Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties
  • Authors: D. Ma (ZDNS) and S. Kent (Independent) 💖
  • Category: Informational 🌸
  • ISSN: 2070-1721
  • Date: September 2020 🗓️
  • Obsoletes / Updates: nothing listed in the header 🙈

Abstract ✨

okay so this doc is a single reference point for the requirements on Relying Party (RP) software in the Resource Public Key Infrastructure (RPKI) 🔐. the requirements are scattered across like a bunch of other RPKI RFCs, so this one gathers them up so implementers can actually see them all 🫶. it's a living doc too, so it'll get updated as those RFCs change 🦋

Status of This Memo ✨

this one is not an Internet Standards Track spec, it's just published for info 📚

it IS a product of the IETF, it represents consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 💅. not everything the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the deets 🧐

info about the current status, errata, and where to send feedback lives at https://www.rfc-editor.org/info/rfc8897 🌈

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. 🔒

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stood on the publication date. read them carefully bestie, they spell out your rights and restrictions 📜. any Code Components pulled out of this doc have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, per the Simplified BSD License ⚠️

Table of Contents 🗂️

1.  Introduction
2.  Fetching and Caching RPKI Repository Objects
  2.1.  TAL Configuration and Processing
  2.2.  Locating RPKI Objects Using Authority and Subject
        Information Extensions
  2.3.  Dealing with Key Rollover
  2.4.  Dealing with Algorithm Transition
  2.5.  Strategies for Efficient Cache Maintenance
3.  Certificate and CRL Processing
  3.1.  Verifying Resource Certificate and Syntax
  3.2.  Certificate Path Validation
  3.3.  CRL Processing
4.  Processing RPKI Repository Signed Objects
  4.1.  Basic Signed Object Syntax Checks
  4.2.  Syntax and Validation for Each Type of Signed Object
    4.2.1.  Manifest
    4.2.2.  ROA
    4.2.3.  Ghostbusters
    4.2.4.  Verifying BGPsec Router Certificate
  4.3.  How to Make Use of Manifest Data
  4.4.  What To Do with Ghostbusters Information
5.  Distributing Validated Cache
6.  Local Control
7.  Security Considerations
8.  IANA Considerations
9.  References
  9.1.  Normative References
  9.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction 🧚

okay so RPKI Relying Party (RP) software is what network operators (and others) use to grab and verify Internet Number Resource (INR) data from the RPKI repository system 💻. once the data is verified, an RP can check which Autonomous Systems (ASes) are allowed to originate routes for IP address prefixes 🗺️. RPKI data also ties public keys to BGP routers and says which AS numbers each router is authorized to represent 🦋

the essential RP requirements for secure Internet routing [RFC6480] are honestly everywhere, spread across a ton of protocol-specific RFCs and Best Current Practice RFCs 🙈. these are the ones:

ngl, spreading the RP requirements over these 13 docs makes it super hard for an implementer to feel sure they've covered everything 😭. good software engineering also might mean splitting the RP system into components with orthogonal functions so they can be distributed, and a taxonomy of the collected RP requirements can help explain what the RP is for 🧩

so this doc lines up a baseline set of requirements for RPs and gives one single reference point for RP software in the RPKI 💅. the requirements are sorted into four groups:

  • Fetching and Caching RPKI Repository Objects
  • Processing Certificates and Certificate Revocation Lists (CRLs)
  • Processing RPKI Repository Signed Objects
  • Distributing Validated Cache of the RPKI Data

this doc will get updated as these RFCs are updated or as new ones show up 🔄

2. Fetching and Caching RPKI Repository Objects 📦

RP software uses synchronization mechanisms that targeted repositories support (for example [rsync] or RRDP [RFC8182]) to download RPKI signed objects from the repository system and update a local cache 💾. these mechanisms only download the objects that were added or replaced with new versions since the RP last checked the repository 🎯. the RP validates the RPKI data and uses it to generate authenticated data saying which ASes can originate routes for address prefixes, and which routers can sign BGP updates on behalf of specified ASes 🔐

2.1. TAL Configuration and Processing 🎀

in the RPKI, each RP picks a set of trust anchors (TAs) 🫶. the IANA and/or the five Regional Internet Registries (RIRs) are the obvious candidates to be default TAs for the RP, since that matches the existing INR allocation hierarchy 🌳

an RP doesn't fetch TAs directly. instead, RP software uses a set of Trust Anchor Locators (TALs) to retrieve each TA and verify that it's authentic 🔍

TAL configuration and processing are specified in Section 3 of [RFC8630] ✨

2.2. Locating RPKI Objects Using Authority and Subject Information Extensions 🗺️

the RPKI repository system is distributed, made up of multiple repository instances. each repository instance holds one or more repository publication points 📍. RP software finds publication points through the Subject Information Access (SIA) and Authority Information Access (AIA) extensions in (validated) certificates 🕵️‍♀️

Section 5 of [RFC6481] explains how RP software locates all RPKI objects using the SIA and AIA extensions. the detailed specs for those extensions in a resource certificate are in Sections 4.8.8 and 4.8.7 of [RFC6487], respectively 📖

2.3. Dealing with Key Rollover 🔁

RP software takes the key rollover period into account when deciding how often to sync with the RPKI repository system ⏰

the RP software requirements for key rollover are described in Section 3 of [RFC6489] and Section 3 of [RFC8634] 💫

2.4. Dealing with Algorithm Transition 🌈

the set of cryptographic algorithms used with the RPKI is expected to change over time 🔄. each RP is expected to know the milestones set for the algorithm transition and what actions are needed at each juncture 🗓️

the RP software requirements for algorithm transition are specified in Section 4 of [RFC6916] 💅

2.5. Strategies for Efficient Cache Maintenance 🧹

each RP is expected to keep a local cache of RPKI objects. the cache needs to be brought up to date and kept consistent with the repository publication point data as often as the repository publication points allow, and as often as the RP's locally selected processing constraints allow ⏱️

the last paragraph of Section 5 of [RFC6481] gives guidance on maintaining a local cache 📝

3. Certificate and CRL Processing 📜

the RPKI uses X.509 certificates and CRLs, but it profiles the standard formats described in [RFC6487] 🎀. the big change to the profile that [RFC5280] set up is the mandatory use of a new extension in RPKI certificates, defined in [RFC3779] 🧩

3.1. Verifying Resource Certificate and Syntax 🔎

certificates in the RPKI are called resource certificates, and they are required to conform to the profile in [RFC6487] 💖. an RP is required to verify that a resource certificate follows the profile set out in Section 4 of [RFC6487]. that means every extension mandated by Section 4.8 of [RFC6487] has to be present, and the value of each extension has to be within the range [RFC6487] specifies. any extension excluded by Section 4.8 of [RFC6487] has to be left out ✅

Section 7.1 of [RFC6487] lays out the procedure RP software follows when verifying the extensions described in [RFC3779] 🛠️

3.2. Certificate Path Validation 🛤️

first things first: the INRs in the issuer's certificate are required to encompass the INRs in the subject's certificate 👑. that's one of the necessary principles of certificate path validation, on top of cryptographic verification (checking the signature on each certificate using the public key of the parent certificate) 🔐

Section 7.2 of [RFC6487] specifies the procedure RP software should follow to do certificate path validation 📋

Certification Authorities (CAs) that want to cut down on operational fragility will move to the new OIDs [RFC8360], which tells RP software to use an alternative RPKI validation algorithm 🦋. an RP is expected to support the amended procedure for handling accidental overclaiming, which Section 4 of [RFC8360] describes 🫶

3.3. CRL Processing 🗒️

the CRL processing requirements for CAs and RPs are described in Section 5 of [RFC6487] 📖. CRLs in the RPKI are tightly constrained: only the AuthorityKeyIdentifier (Section 4.8.3 of [RFC6487]) and CRLNumber (Section 5.2.3 of [RFC5280]) extensions are allowed, and both are required to be present 🔒. no other CRL extensions are allowed, and no CRLEntry extensions are permitted 🚫. RP software is required to verify that these constraints have been met. each CRL in the RPKI has to be verified using the public key from the certificate of the CA that issued it 💅

in the RPKI, RPs are expected to pay extra attention when a CRL isn't consistent with the manifest for the publication point that the CRL is associated with 👀

handling a CRL that isn't consistent with a manifest is a matter of local policy, as described in the fifth paragraph of Section 6.6 of [RFC6486] 🌸

4. Processing RPKI Repository Signed Objects 🎀

4.1. Basic Signed Object Syntax Checks ✨

Okay so, before an RP can use a signed object from the RPKI repository, RP software is required to check the signed-object syntax first. 💅 No skipping this, bestie.

Section 3 of [RFC6488] lists every step RP software is required to run to validate the top-level syntax of a repository signed object. 📋

Heads up though: these checks are necessary but not sufficient 🙈 Extra validation checks must be performed based on the specific type of signed object, as described in Section 4.2.

4.2. Syntax and Validation for Each Type of Signed Object 🎀

4.2.1. Manifest 📜

To figure out whether a manifest is valid, RP software is required to run manifest-specific checks on top of the generic signed-object checks from [RFC6488].

The specific checks for a manifest are in Section 4 of [RFC6486]. If any of them fail, meaning the manifest is invalid, then the manifest gets discarded and RP software acts like no manifest was ever there. 🗑️

4.2.2. ROA 🌍

To validate a Route Origin Authorization (ROA), RP software is required to perform all the checks specified in [RFC6488], plus some extra ROA-specific validation steps. 🔍

The IP Address Delegation extension [RFC3779] in the end-entity (EE) certificate (the one living inside the ROA) must encompass each of the IP address prefix(es) in the ROA. It has to cover all of them, no exceptions. 🫶

More details for ROA validation are specified in Section 4 of [RFC6482].

4.2.3. Ghostbusters 👻

The Ghostbusters Record is optional. A publication point in the RPKI can have zero or more associated Ghostbusters Records, so it's giving flexible. ✨

If a CA has at least one Ghostbusters Record, RP software is required to verify that the record conforms to the syntax of signed objects defined in [RFC6488].

The payload of this signed object is a (severely) profiled vCard. 💀 RP software is required to verify that the payload conforms to the format profiled in [RFC6493].

4.2.4. Verifying BGPsec Router Certificate 🦋

A BGPsec Router Certificate is a resource certificate, so it's required to comply with [RFC6487]. On top of that, the certificate must contain an AS Identifier Delegation extension (Section 4.8.11 of [RFC6487]) and must not contain an IP Address Delegation extension (Section 4.8.10 of [RFC6487]). Not even a little bit of IP stuff, periodt. 🙅‍♀️

The validation procedure for BGPsec Router Certificates is analogous to the one described in Section 7 of [RFC6487], but it uses the constraints defined in Section 3 of [RFC8209]. Same energy, different constraints. 💜

Note that the cryptographic algorithms used by BGPsec routers are found in [RFC8608]. Currently, the algorithms specified in [RFC8608] and [RFC7935] are different, which is a whole mood 😭 BGPsec RP software will need to support the algorithms used to validate BGPsec signatures, plus the algorithms needed to validate signatures on BGPsec certificates, RPKI CA certificates, and RPKI CRLs. That's a lot of algorithms, bestie. 🧚

4.3. How to Make Use of Manifest Data 📦

For a given publication point, RP software ought to perform the tests specified in Section 6.1 of [RFC6486] to determine the state of the manifest at that publication point. 🔎 A manifest gets classified as either valid or invalid, and a valid manifest is either current or stale. Then the RP decides how to use the manifest based on its state, according to local (RP) policy. Your rules, your vibe. 🌸

If there are valid objects in a publication point that aren't present on a manifest, [RFC6486] doesn't mandate any specific RP behavior for those objects. Kinda mysterious, honestly. 🕵️‍♀️

Without a manifest, an RP is expected to accept all valid signed objects present in the publication point (see Section 6.2 of [RFC6486]). 🎉 If a manifest is stale or invalid and the RP has no way to get a more recent valid manifest, the RP is expected to contact the repository manager via Ghostbusters Records, and then make decisions according to local (RP) policy (see Sections 6.3 and 6.4 of [RFC6486]). Reach out, babe. 📞

4.4. What To Do with Ghostbusters Information 👻💌

RP software may run into a stale manifest or CRL, or an expired CA certificate or ROA, at a publication point. When that happens, an RP is expected to use the information from the Ghostbusters Records to contact the maintainer of the publication point where the stale or expired objects were found. 📨

The whole point is to encourage the relevant CA and/or repository manager to update those stale or expired objects. Group chat, but make it infrastructure. 🫶

5. Distributing Validated Cache 🚚

On a periodic basis, BGP speakers within an AS request updated validated origin AS data and router/ASN data from the (local) validated cache of RPKI data. 🔁

The RP can either transfer the validated data straight to the BGP speakers, or transfer it to a cache server that's responsible for provisioning that data to BGP speakers. Both are valid lifestyles. 💖

The protocols designed to deliver validated cache data to a BGP speaker are specified in [RFC6810] and [RFC8210]. ✨

6. Local Control 🎛️

ISPs may want a local view of exceptions to the RPKI data, in the form of local filters and additions. 🧐 For instance, a network operator might want a local override capability to protect routes from adverse actions [RFC8211]. 🛡️

The mechanisms developed to give network operators this capability are called Simplified Local Internet Number Resource Management with the RPKI (SLURM). 🌈 If an ISP wants to implement SLURM, its RP system can follow the instructions specified in [RFC8416]. 👑

7. Security Considerations 🚨

Okay, serious moment, bestie. 🥹 This document does not introduce any new security considerations; it is a resource for implementers. 📚

The RP links the RPKI provisioning side and the routing system, establishing a verified, local view of global RPKI data for BGP speakers. That makes the RP the main character of the whole operation. 👑 The security of the RP is critical for exchanging BGP messages. Like, critical. 😱

Each RP implementation is expected to offer cache backup management to facilitate recovery from outages. 💾 RP software should also support secure transport (e.g., IPsec [RFC4301]) that can protect validated cache delivery in an unsafe environment. 🔐

This document highlights many validation actions applied to RPKI signed objects, which are an essential element of secure operation of RPKI security. Validation is the whole vibe. 💅🔥

8. IANA Considerations 📋

This document has no IANA actions. Nothing to register, nothing to update, we're chilling. 🧘‍♀️

9. References 📚

9.1. Normative References 🦋

9.2. Informative References 📚✨

Okay bestie, here are the bonus reads 🤓💖 These aren't required to implement anything, but they're the background you'll want if you're curious about the bigger picture.

Acknowledgements 🫶

The authors wanna shoutout David Mandelberg, Wei Wang, Tim Bruijnzeels, George Michaelson, and Oleg Muravskiy 🙌 They gave the doc a review, feedback, and editorial help, and it literally wouldn't be this polished without them 💅✨

Authors' Addresses 💌

Di Ma
ZDNS
4 South 4th St. Zhongguancun
Haidian
Beijing, 100190
China

Email: madi@zdns.cn


Stephen Kent
Independent

Email: kent@alum.mit.edu
📦 where this page comes from