RFC 8211

Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI)

📅 published September 2017, from ietf

Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI) 🎀

okay so bestie, this is RFC 8211 and it's giving "the RPKI's worst-case scenarios, but make it an analysis" 🔍💅

Here's the title block, the important bits first 🫶:

RFC number: 8211
Authors: S. Kent (BBN Technologies) and D. Ma (ZDNS)
Category: Informational 🦋 (not a Standards Track thing, just published for info)
ISSN: 2070-1721
Date: September 2017
Obsoletes / Updates: Neither is mentioned in the original title block, so there's nothing to report there 🙈

The whole vibe of this doc is "who can mess with your INRs, and how bad is it?" 😭 It's about adverse actions (fancy term for anything that shrinks the Internet Number Resources an INR holder has, and that the holder doesn't want) done by a Certification Authority (CA) or an independent repository manager in the RPKI. The authors look at it from the affected holder's side, and they say upfront that it's not comprehensive, just an orderly way to think through all the ways errors or attacks on a CA or repository manager can wreck RPKI data and the routing decisions built on top of it 🌸

Abstract ✨

Okay so the abstract is basically the TL;DR. This document analyzes actions by or against a CA or an independent repository manager in the RPKI that can adversely affect the INRs tied to that CA or its subordinate CAs 💖 The analysis comes from the affected INR holder's perspective, and it's based on looking at the data items in the RPKI repository, which a CA (or independent repository manager) controls and Relying Parties (RPs) fetch 🧚

It doesn't claim to cover everything. It's more like a structured way to think about how mistakes by, or attacks on, a CA or repository manager can mess with the RPKI and the routing decisions that rely on RPKI data 🍓

Status of This Memo ✨

Okay, the fine print, but it matters 💅

This document is not an Internet Standards Track spec. It's published for informational purposes 🦋

It's a product of the Internet Engineering Task Force (IETF) and got approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 for that 🧐

Want the current status, any errata, or a way to send feedback? Head to https://www.rfc-editor.org/info/rfc8211 🔗

Copyright Notice ⭐

This document 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 those carefully, because they spell out your rights and restrictions for this doc 📜

One more thing: any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🫶

Table of Contents 🗺️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Analysis of RPKI Repository Objects . . . . . . . . . . . . .   4
  2.1.  CA Certificates . . . . . . . . . . . . . . . . . . . . .   6
  2.2.  Manifest  . . . . . . . . . . . . . . . . . . . . . . . .   9
  2.3.  Certificate Revocation List . . . . . . . . . . . . . . .  12
  2.4.  ROA . . . . . . . . . . . . . . . . . . . . . . . . . . .  15
  2.5.  Ghostbusters Record . . . . . . . . . . . . . . . . . . .  17
  2.6.  Router Certificates . . . . . . . . . . . . . . . . . . .  18
3.  Analysis of Actions Relative to Scenarios . . . . . . . . . .  19
  3.1.  Scenario A  . . . . . . . . . . . . . . . . . . . . . . .  21
  3.2.  Scenario B  . . . . . . . . . . . . . . . . . . . . . . .  21
  3.3.  Scenario C  . . . . . . . . . . . . . . . . . . . . . . .  21
  3.4.  Scenario D  . . . . . . . . . . . . . . . . . . . . . . .  22
4.  Security Considerations . . . . . . . . . . . . . . . . . . .  22
5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
  6.1.  Normative References  . . . . . . . . . . . . . . . . . .  23
  6.2.  Informative References  . . . . . . . . . . . . . . . . .  25
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  26
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  26

1. Introduction 🌈

1.1. Setting the Scene 💅

Okay so here's the core definition 😭 In this doc, any change to the Resource Public Key Infrastructure (RPKI) [RFC6480] that shrinks the set of Internet Number Resources (INRs) an INR holder has, and that goes against what the holder wants, is called "adverse" 🦋 The analysis is always from the affected INR holder's point of view 💖

An adverse change can come from an attack on a CA [RFC7132], a mistake by a CA, or a mistake by or attack on a repository operator. Here's the plot twist: the CA that handed out the affected INRs might be following established policy, so a change can be contractually justified even if the holder sees it as adverse 🙈 The doc looks at what adverse actions do within the RPKI for INRs, no matter what caused them 🧚

Now the competing-objects part 👑 A new Route Origin Authorization (ROA) or router certificate that "competes" with an existing one can be adverse too. A newer ROA competes with an older ROA if it points to a different Autonomous System Number (ASN), has the same or a more specific prefix, and was issued by a different CA. A newer router certificate competes with an older one if it has the same ASN, a different public key, and was issued by a different CA 🎀 Transferring resources or switching upstream providers can cause competing ROAs or router certificates in some situations, so not every competition is an adverse action. Iykyk 🫶

Causes of adverse changes are all over the place 🍓 A CA can slip up while managing the RPKI objects it signs, or it can get attacked. If an attacker uses that CA's private key to sign RPKI objects, it's basically the same as the CA making a mistake 💀 A CA or repository operator can also be hit with legal measures that force them to make adverse changes to RPKI data 📜 Honestly, these can be hard to tell apart from mistakes or attacks, except for how long it takes to fix them 😭 (Presumably the CA will fix a detected mistake or attack, so the effects look similar. If a CA was legally forced into an adverse change, the fix probably won't be quick.)

Last bit of the intro: this document analyzes the different types of actions by a CA (or an independent repository operator) that can adversely affect the INRs tied to that CA, plus the INRs of subordinate CAs ✨ The analysis is based on looking at the data items in the RPKI repository, which a CA (or independent repository operator) controls and RPs fetch 🌸

That's part 1 of 7, bestie. Stay tuned for the next part 💖

2. Analysis of RPKI Repository Objects ✨

okay bestie, this section is where we get into the RPKI repository itself 📦🦋 It lists out every kind of object that lives in there and then looks at how messing with each one could mess up Route Origin Authorizations (ROAs) and router certificate validation 😭 Quick heads up: each error gets an identifier so later sections can point back to it, and the list of adverse actions here is not necessarily the full story, so lowkey keep that in mind 🙈

The RPKI repository [RFC6481] holds a bunch of digitally signed objects that Relying Parties (RPs) fetch and process 💅 Until BGPsec [RFC8205] is deployed, the main job of the RPKI is letting an RP validate ROAs [RFC6482] 🌸 A ROA binds address space to an ASN, and it can be used to check BGP announcements against the route origin [RFC6483] 🔥 The ROAs are the most important objects for origin validation. Every other RPKI object is basically there to help validate ROAs in a way that matches the INR allocation system 🧚 So if an error changes a ROA, or changes an RPKI object needed to validate a ROA, RPs can end up with a different conclusion (than what was intended) about whether the bindings in that ROA are valid 😭💀

When BGPsec is deployed, router certificates [RFC8209] get added to repository publication points 🎀 These are end entity (EE) certificates used to verify signatures on BGP update data and to enable path validation [RFC8205] ✨ Router certificates matter just as much for path validation as ROAs do for origin validation, so no skipping them 👑

The objects in the RPKI repository come in two flavors 🌈 There are conventional PKI objects (certificates and Certificate Revocation Lists (CRLs)) and RPKI-specific signed objects. The RPKI-specific ones use a common encapsulation format [RFC6488] built on the Cryptographic Message Syntax (CMS) [RFC5652] 💖 A syntax error in this common format will make an RP reject the object (for example, a ROA or manifest) as invalid 🙈

Adverse actions come in several forms, and here they are 💅

Deletion (D) 🗑️ is removing an object from a publication point without the permission of the INR holder.
Suppression (S) 🙈 is not deleting an object, or not publishing an object, as the INR holder intended. It also covers keeping an older version of an object in a publication point when a newer version is ready to be published.
Corruption (C) 💀 is modifying a signed object without needing the private key used to sign it. So a corrupted object won't carry a valid signature, and it implicitly replaces the legit version.
Modification (M) 🎀 is publishing a syntactically valid, verifiable version of an object that differs from the (existing) version the INR holder authorized. Implicitly, the legit version gets deleted and replaced by the modified one.
Revocation (R) 🦋 is revoking a certificate (EE or CA) by putting its Serial Number on the appropriate CRL, without the INR holder's authorization.
Injection (I) 🧚 is introducing an instance of a signed object into a publication point (without the INR holder's authorization). It assumes RPs will see that signature as valid 😭

The first three actions (deletion, suppression, and corruption) can be pulled off by any entity that manages the affected INR holder's publication point 🌸 An entity that can play man-in-the-middle between an RP and a repository can also do these to that RP 👀

The latter three (modification, revocation, and injection) nominally require access to the INR holder's private key 🔐

All six of these can also be done by a parent CA 💅 A parent CA could reissue the INR holder's CA certificate with a different public key, one that matches a private key the parent CA has access to. Then the CA could generate new signed objects using the private key tied to the reissued certificate, and publish them wherever it likes 🫶

Most of these actions can be done alone or mixed together 🌈 For example, a ROA could be revoked and deleted, or revoked and replaced with a modified ROA 💜 Where it matters, the analysis will separate individual actions, or combos of them, that give RPs different outcomes. Remember, the whole point is the impact on ROAs and router certificates, from the RP's processing point of view ✨

The next sections look at how each of these actions affects the objects in the RPKI repository system 🦋 Each action gets handled in order (deletion, suppression, corruption, modification, revocation, and injection) for each object, so it's easy to see how every action was considered for every object 💖 (For the Ghostbusters Record [RFC6493], we condensed the discussion of the actions because the impact is the same in each case 💅)

2.1. CA Certificates ✨

Okay so every INR holder is represented by one or more CA certificates 🎀. An INR holder can have multiple CA certs if it holds resources acquired from different sources 💅. And every INR holder has more than one CA certificate during key rollover [RFC6489] and algorithm rollover [RFC6916] 🔄, so having two certs at once is literally normal, bestie.

If a publication point is not a "leaf" in the RPKI hierarchy (aka it has stuff underneath it 🌳), then it will contain one or more CA certificates, each one representing a subordinate CA 👑. Each subordinate CA certificate has a Subject Information Access (SIA) pointer to the publication point where the signed objects for that CA can be found [RFC6487] 🗺️.

A CA certificate is a complex data structure, so errors in it can hit RPs in different ways depending on exactly what data is wrong 🙈.

Adverse actions against a CA certificate can cause the following errors:

A-1.1 Deletion 🗑️

A-1.1.1 Deleting a CA certificate means an RP can't locate signed objects generated by that CA, except the ones it already cached 😭. So the RP wouldn't know about changed or new (issued after the cached data) INR bindings asserted in subordinate ROAs, and it couldn't validate new or changed router certificates. If the missed objects were meant to replace ROAs or router certificates before they expire, then once those expire, RPs may stop seeing them as valid. The result? Valid routes might get marked as NotFound or Invalid 💀.

A-1.2 Suppression 🤐

A-1.2.1 If publication of a CA certificate is suppressed, the impact depends on what changed in the suppressed certificate. If the SIA value changed, it's the same as A-1.1 or A-1.4.3. If the [RFC3779] extensions changed, it's the same as A-1.4.1. If the Authority Information Access (AIA) extension changed, it's the same as A-1.4.4. Suppressing a renewed or re-issued certificate may cause an old certificate to expire and get rejected by RPs ⏳.

A-1.3 Corruption 🧨

A-1.3.1 Corruption of a CA certificate will cause it to be rejected by RPs. This may then make subordinate signed objects invalid 🚫. An RP that has cached the subtree under the affected CA certificate may keep viewing it as valid until the objects expire. But changed or new objects might not get retrieved, depending on the details of the RP software's design. So this action may be equivalent to suppressing changes to the affected subtree 🫥.

A-1.4 Modification ✏️

A-1.4.1 If a CA certificate is modified but still conforms to the RPKI certificate profile [RFC7935], it will be accepted by RPs ✅. If an [RFC3779] extension in this certificate gets changed to exclude INRs that were previously present, then subordinate signed objects will become invalid if they rely on the excised INRs. If those objects are CA certificates, their subordinate signed objects will be treated as invalid. If the objects are ROAs, RPs will ignore the binding expressed by the affected ROAs. If the objects are router certificates, BGPsec_PATH attributes [RFC8205] verifiable under these certificates will be considered invalid 🙃.

A-1.4.2 If the SIA extension of a CA certificate is modified to refer to another publication point, this will cause an RP to look somewhere else for subordinate objects 🗺️. This could stop RPs from acquiring the objects the INR holder intended to be retrieved: manifests, ROAs, router certificates, Ghostbuster Records, or any subordinate CA certificates associated with that CA. If the objects at this new location have invalid signatures or appear corrupted, they may be rejected. In that case, cached versions of the objects may still be viewed as valid by an RP until they expire. But if the objects at the new location have valid signatures and pass path validation checks, they will replace the cached objects, effectively replacing the INR holder's objects 😱.

A-1.4.3 If the AIA extension in a CA certificate is modified, it would point to a different CA certificate, not the parent CA certificate 🔀. This extension is only used for path discovery, not path validation. Path discovery in the RPKI is usually done top-down, starting with trust anchors (TAs) and recursively descending the RPKI hierarchy. So there may be no impact on clients' ability to acquire and validate certificates if the AIA is modified 🤷‍♀️.

A-1.4.4 If the Subject Public Key Info (and Subject Key Identifier extension) in a CA certificate is modified to contain a public key matching a private key held by the parent, the parent could sign objects as children of the affected CA certificate 👀. With that capability, the parent could replace the INR holder, issuing new signed objects that RPs would accept (as long as they don't violate the path validation criteria). This would let the parent carry out modification, revocation, and injection actions against all the objects under the affected CA certificate, including subordinate CA certificates. 🚨 (Note that key rollover also yields a new CA certificate. However, the new certificate will coexist with the old one for a while, which may help tell this legitimate activity apart from an adverse action 💜.)

A-1.5 Revocation 🚫

A-1.5.1 If a CA certificate is revoked, an RP will treat all subordinate signed objects as invalid, both immediate and transitive 💔. The effects are essentially the same as those described in A-3.4.2.

A-1.6 Injection 💉

A-1.6.1 If a CA certificate is injected, the impact depends on the data in the injected certificate 🧐. Changes will generally be equivalent to the modification actions described in A-1.4.

2.2. Manifest ✨

Every repository publication point comes with its own manifest [RFC6486] 📜. The RPKI uses manifests so RPs can spot when (more recent) publication point objects have been suppressed or swapped out, whether by accident or by an attack 🕵️‍♀️. A manifest lists every other signed object at the publication point by filename. It also includes a hash for each file, so an RP can check whether the file it's looking at matches what the INR holder put on the manifest 🔍.

A manifest is an RPKI signed object, so it gets validated the way [RFC6488] says 🎀. If someone tampers with a manifest and any of those checks fail, the manifest is considered invalid 🙅‍♀️. Suppressing the manifest itself (which shows up as a stale manifest) can also keep an RP from noticing that other signed objects at the publication point were suppressed 😭. Here's the tea: if a manifest's EE certificate expires right when the manifest is supposed to get replaced, a publication delay turns the manifest from merely stale into invalid 💀. That is a very serious outcome and should be avoided. One way is to set the manifest EE certificate's notAfter value to the same value as the CA certificate it was issued under 🫶. If a signed object at a publication point can be validated using the rules for that object type, an RP may accept it, even if there's no matching entry for it on the manifest ✨. Still, it appears that most RP software ignores publication point data that doesn't match manifest entries (at the time this document was written) 🙈.

Corrupting, suppressing, modifying, or deleting a manifest might not affect how RPs process other publication point objects, as specified in [RFC6486] 🦋. But like we just said, lots of RP implementations ignore objects that show up at a publication point without being listed in a valid manifest 👀. So these actions against a manifest can totally impact RP processing:

A-2.1 Deletion

A-2.1.1 A manifest may get deleted from the indicated publication point 🗑️. When that happens, an RP may choose to fall back on the previous manifest (if one is around) and may ignore any new or changed objects at the publication point 😬. Honestly, the fallout is the same as suppressing those objects, because RPs won't recognize the new stuff since it's not in the old manifest 💅. For example, a new ROA could get ignored (A-1.2). A newly issued CA certificate might get ignored (A-1.1). A subordinate CA certificate that was revoked might still look valid to RPs (A-4.1). A new or changed router certificate might be ignored (A-6.2), and so would a revised Ghostbusters Record (A-4.1) 👻.

A-2.2 Suppression

A-2.2.1 Publication of a newer manifest may be suppressed 🙃. Suppressing a newer manifest will probably make an RP rely on a cached manifest (if one is available) 🧊. The older manifest won't list newly added objects, so an RP might ignore those objects, which is basically the same as deleting them (A-1.1, A-3.1, A-4.1, A-5.1, and A-6.1) 💔.

A-2.3 Corruption

A-2.3.1 A manifest may get corrupted 🌪️. A corrupted manifest will be rejected by RPs ❌. That might push RPs to rely on a previous manifest, with the same impact as A-2.2 🔁. If an RP doesn't revert to a cached manifest, things get really bad 😱. All publication point objects will probably be seen as invalid, including subordinate tree objects. That's the same as revoking or deleting a whole subtree (see A-4.4.2) 🌳💀.

A-2.4 Modification

A-2.4.1 A manifest may be modified to remove one or more objects ✂️. Since RPs see the modified manifest as valid, any objects that got removed may be ignored by RPs 🫥. That's equivalent to deleting those objects from the repository. How bad it is depends on which objects are (effectively) removed, but the impact is always equivalent to deleting the object in question (A-1.1, A-3.1, A-4.1, A-5.1, and A-6.1) 🍂.

A-2.4.2 A manifest may be modified to add one or more objects ➕. If an added object has a valid signature (and isn't expired), RPs will accept it and process it accordingly 🥳. If the INR holder had previously deleted the added object, this action is equivalent to suppressing that deletion 🔄. If the object is newly created or modified, it's equivalent to a modification or injection action for that object type, so it's covered in the relevant section for those actions for that object type 📚.

A-2.4.3 A manifest may be modified to list an incorrect hash for one or more objects 🔢. An RP may ignore an object with an incorrect hash 🙈. So the effect might be like corrupting that object, although the error RP software reports would be different from the one it reports for a corrupted object 🧩. (The manifest specifications don't require an RP to ignore an object that has a valid signature, isn't revoked or expired, but whose hash doesn't match the object. However, an RP may choose to do so 🤷‍♀️.)

A-2.5 Revocation

A-2.5.1 A manifest may be revoked by putting its EE certificate on the CRL for the publication point 🚫. A revoked manifest will be ignored by an RP, which probably would go back to an older (cached) manifest 🕰️. For new or changed objects, the implications for RPs are the same as A-2.1 🔁.

A-2.6 Injection

A-2.6.1 A manifest representing different objects may be injected into a publication point 💉. The effects are the same as for a modified manifest (see above) 🎀. The impact depends on the type of the affected object(s), so it's discussed in the relevant section(s) for each object type 💖.

2.3. Certificate Revocation List 📜

okay so every publication point comes with a CRL 🎀, which is basically the list of revoked (but not yet expired) certs issued by the CA attached to that publication point [RFC6481]. messing with a CRL can cause these errors, so pay attention bestie 💀

A-3.1 Deletion

A-3.1.1 If a CRL gets deleted, RPs will keep using an older CRL they fetched before, which is giving stale vibes 🥀. So they won't hear about any changes in revocation status for subordinate CA or router certificates, or the EE certificates of signed objects (like ROAs, e.g., ROAs). This action is equivalent to corrupting a CRL, since an RP will never accept a corrupted CRL 🙅‍♀️.
A-3.1.2 Deleting a CRL could make an RP keep accepting a ROA that no longer matches what the INR holder meant ✨. The result? An announcement for the affected prefixes gets marked as Valid when it should be NotFound or Invalid 😭. In this case, the effect is analogous to A-5.2.
A-3.1.3 Picture this: a router certificate gets revoked, but the CRL is deleted. RPs have no clue about the revocation 🫠 and might keep accepting that old, revoked router certificate. If it was revoked because the router's private key got compromised, RPs are vulnerable to accepting routes signed by an unauthorized entity. Not it 🚨.
A-3.1.4 If a subordinate CA certificate was revoked on the deleted CRL, the revocation just doesn't take effect 🥲. That could mess up a transfer of address space from the subordinate CA, which would hurt routing to the new holder of that space.

A-3.2 Suppression

A-3.2.1 If the most recent CRL gets its publication suppressed, an RP won't learn the latest revocation status of a subordinate CA or router certificates, or the EE certificates of signed objects 👀. If an EE certificate was revoked but its signed object is still sitting in the publication point, an RP might wrongly treat that object as valid. (This would happen if the object is still in the manifest, or if the RP is set up to process valid objects that aren't on the manifest.) This type of action is especially concerning when the affected object is a ROA, a router certificate, or a subordinate CA certificate 🚩. The effects are equivalent to CRL deletion (A-3.1), but suppressing a new CRL might not even be reported as an error, i.e., if the suppressed CRL was issued before the NextUpdate time (of the previous CRL). sneaky, right? 🥷

A-3.3 Corruption

A-3.3.1 If a CRL is corrupted, an RP will reject it 🙅‍♀️. If a prior CRL hasn't passed its NextUpdate time yet, an RP will keep using that prior CRL. Even if the prior CRL has gone past the NextUpdate time, an RP may choose to keep relying on it 🤷‍♀️. The effects are basically the same as suppression or deletion of a CRL (A-3.1 and A-3.2).

A-3.4 Modification

A-3.4.1 If a CRL is modified to wrongly list a signed object's EE certificate as revoked, that object gets treated as invalid by RPs, even if it's sitting in a publication point 💔. If the object is a ROA, the (legitimate) binding it expresses gets ignored by an RP (see A-5.5). If a CRL is modified to wrongly list a router certificate as revoked, a path signature tied to that certificate gets treated as Not Valid by RPs (see A-6.5).
A-3.4.2 If a CRL is modified to wrongly list a CA certificate as revoked, that CA and all of its subordinate signed objects get treated as invalid by RPs 😱. Depending on where the affected CA sits in the hierarchy, this can get really big, causing routes that should be Valid to be treated as NotFound.
A-3.4.3 If a CRL is modified to leave out a revoked EE, router, or CA certificate, RPs will likely keep accepting the revoked, signed object as valid 🙃. That goes against what the INR holder intended. If an RP keeps accepting a revoked ROA, it may make routing decisions based on data that's no longer valid. This could cause valid routes to be de-preferenced and invalid routes to keep getting accepted 💅.

A-3.5 Revocation

A-3.5.1 A CRL can't be revoked per se 🙅‍♀️, but it will fail validation if the CA certificate it was issued under gets revoked. See A-1.5 for a discussion of that action.

A-3.6 Injection

A-3.6.1 Injecting a bogus CRL can have the same effects as the ones listed above for a modified CRL, depending on how the injected CRL differs from the correct one 🧚.

2.4. ROA 🌸

ngl this one's a whole vibe. In addition to the generic RPKI object syntax checks, ROA validation requires that the signature on the ROA can be validated using the public key from the EE certificate embedded in the ROA [RFC6482]. It also requires that the EE certificate be validated consistently with the procedures described in [RFC6482] and [RFC6487]. Adverse actions against a ROA can cause the following errors:

A-4.1 Deletion

A-4.1.1 A ROA may be deleted from the indicated publication point 🗑️. That voids the binding between the prefix(es) and the Autonomous System (AS) number in the ROA. An RP that used to see this binding as authentic won't have any evidence about its validity anymore 😵. For origin validation, that means a legitimate route gets treated as NotFound (if there are no other ROAs for the same prefix) or Invalid (if there's another ROA for the same prefix, but with a different AS number).

A-4.2 Suppression

A-4.2.1 Publication of a newer ROA may be suppressed 🤐. If the INR holder meant to change the binding between the prefix(es) and the AS number in the ROA, that change won't go through. So RPs may keep believing an old prefix/ASN binding that the INR holder no longer intends.
A-4.2.2 If an INR holder plans to issue and publish two (or more) new ROAs for the same address space, one (or more) of the new ROAs may be suppressed while the other gets published 👯. In this case, RPs will de-preference the suppressed prefix/ASN binding. Suppressing the new ROA might send traffic to an ASN other than the one(s) the INR holder intended 🚦.
A-4.2.3 If an INR holder plans to delete all ROAs for the same address space, some of them may be kept while the others get deleted 🫣. Preventing the deletion of some ROAs can keep traffic flowing to the ASNs that were advertised by those ROAs. Deleting all ROAs is consistent with transferring address space to a different INR holder in phases, so this sort of attack could mess up that transfer of the affected address space (until the prefixes are removed from the previous INR holder's CA certificate) 💔.

A-4.3 Corruption

A-4.3.1 A ROA may be corrupted 🫠. A corrupted ROA gets ignored by an RP, so the effect is basically the same as for A-4.1 and A-4.5. One possible difference: an RP may be alerted that the ROA was corrupted, which might draw attention to the attack 🚨.

A-4.4 Modification

A-4.4.1 A ROA may be modified so that the Autonomous System Number (ASN) or one or more of the address blocks in the ROA differ from the values the INR holder intended for it ✏️. (This action assumes that the modified ROA's ASN and address ranges are authorized for use by the INR holder.) This attack will make RPs de-preference the legitimate prefix/ASN binding the INR holder intended 📉.

A-4.5 Revocation

A-4.5.1 A ROA may be revoked (by placing its EE certificate on the CRL for the publication point) 🚫. This has the same effect as A-4.1.

A-4.6 Injection

A-4.6.1 A ROA expressing different bindings than the ones published by the INR holder may be injected into a publication point 💉. This action could authorize an additional ASN to advertise the specified prefix, letting that ASN originate routes for the prefix, which enables route origin spoofing 👻. In this case, the injected ROA is considered to be in competition with any existing authorized ROAs for the specified prefix ⚔️.
A-4.6.2 An injected ROA might express a different prefix for an ASN that's already authorized to originate a route, e.g., a longer prefix 📏. That could let the ASN override other advertisements using shorter prefixes. If there are other ROAs authorizing different ASNs to advertise routes to the injected ROA's prefix, then the injected ROA is in competition with those ROAs 🥊.

2.5. Ghostbusters Record ✨

okay so the Ghostbusters Record [RFC6493] is a signed object 👻 that may be included at a publication point, totally at the discretion of the INR holder or publication point operator 💅. It gets validated according to [RFC6488]. On top of that, the syntax gets checked against the vCard profile from Section 5 of [RFC6493] 🎀. Now here's the lowkey iconic part: errors in this record do NOT affect RP processing 🙈. BUT if an RP runs into a problem with objects at a publication point, the RP may use info from the record to contact the publication point operator 📞🫶.

Adverse actions against a Ghostbusters Record can cause the following error:

   A-5.1  Deletion, suppression, corruption, or revocation of a
          Ghostbusters Record could prevent an RP from contacting the
          appropriate entity when a problem is detected by the RP.
          Modification or injection of a Ghostbusters Record could
          cause an RP to contact the wrong entity, thus delaying
          remediation of a detected anomaly.  All of these actions
          are viewed as equivalent from an RP processing perspective;
          they do not alter RP validation of ROAs or router
          certificates.  However, these actions can interfere with
          remediation of a problem when detected by an RP.

bestie this is giving "the contact card can get messed with and it's a mess, but the ROAs and router certs are still validated the same way" 😭💀. The remediation is what gets hurt, not the validation 🥺.

2.6. Router Certificates 🦋

Router certificates are how RPs verify signatures on BGPsec_PATH attributes carried in UPDATE messages 💜✨.

Each AS gets to decide how granular it wants to manage router certificates [RFC8209] 💅. Each participating AS is represented by one or more router certificates 🌸. During key or algorithm rollover, multiple router certificates will show up in a publication point, even if the AS is normally represented by just one such certificate 🔄🌈.

Adverse actions against router certificates can cause the following errors:

   A-6.1  Deletion

          A-6.1.1  Deletion of a router certificate would cause an RP
                   to be unable to verify signatures applied to
                   BGPsec_PATH attributes on behalf of the AS in
                   question.  In turn, this would cause the route to
                   be treated with lower preference than competing
                   routes that have valid BGPsec_PATH attribute
                   signatures.  (However, if another router
                   certificate for the affected AS is valid and
                   contains the same AS number and public key, and it
                   is in use by that AS, there would be no effect on
                   routing.  This scenario will arise if a router
                   certificate is renewed, i.e., issued with a new
                   validity interval.)

   A-6.2  Suppression

          A-6.2.1  Suppression of a router certificate could have the
                   same impact as deletion of a certificate of this
                   type, i.e., if no router certificate was
                   available, BGPsec attributes that should be
                   verified using the certificate would fail
                   validation.  If an older certificate existed and
                   has not expired, it would be used by RPs.  If the
                   older certificate contained a different ASN, the
                   impact would be the same as in A-6.4.

   A-6.3  Corruption

          A-6.3.1  Corruption of a router certificate will result in
                   the certificate being rejected by RPs.  Absent a
                   valid router certificate, BGPsec_PATH attributes
                   associated with that certificate will be
                   unverifiable.  In turn, this would cause the route
                   to be treated with lower preference than competing
                   routes that have valid BGPsec_PATH attribute
                   signatures.

   A-6.4  Modification

          A-6.4.1  If a router certificate is modified to represent a
                   different ASN, but it still passes syntax checks,
                   then this action could cause signatures on
                   BGPsec_PATH attributes to be associated with the
                   wrong AS.  This could cause signed routes to be
                   inconsistent with the intent of the INR holder,
                   e.g., traffic might be routed via a different AS
                   than intended.

   A-6.5  Revocation

          A-6.5.1  If a router certificate were revoked, BGPsec_PATH
                   attributes verifiable using that certificate would
                   no longer be considered valid.  The impact would
                   be the same as for a deleted certificate, as
                   described in A-6.1.

   A-6.6  Injection

          A-6.6.1  Insertion of a router certificate could authorize
                   additional routers to sign BGPsec traffic for the
                   targeted ASN, and thus undermine fundamental
                   BGPsec security guarantees.  If there are
                   existing, authorized router certificates for the
                   same ASN, then the injected router certificate is
                   in competition with these existing certificates.

⚠️ bestie the router cert stuff is SERIOUS. Deleting, corrupting, or revoking one means routes lose their BGPsec cred and get ranked lower 📉😱, and injecting or modifying one can let the wrong AS (or extra routers) sign BGPsec traffic. That's basically undermining BGPsec security 💀🚨.

3. Analysis of Actions Relative to Scenarios 💖

okay so this section looks at the problems that can pop up in four scenarios 🔍. We're talking mistakes, (successful) attacks against a CA or a publication point, and situations where a CA or publication point manager gets forced into action by a law enforcement authority 🚔😳.

We explore the following four scenarios:

   A.  An INR holder operates its own CA and manages its own
       repository publication point.

   B.  An INR holder operates its own CA, but outsources management
       of its repository publication point to its parent or another
       entity.

   C.  An INR holder outsources management of its CA to its parent,
       but manages its own repository publication point.

   D.  An INR holder outsources management of its CA and its
       publication point to its parent.

Note that these scenarios focus on the affected INR holder as the party directly affected by an adverse action 🎯. The most serious cases happen when the INR holder shows up as a high-tier CA in the RPKI hierarchy; in those situations, subordinate INR holders may get affected too 👑😬. A mistake by or attack against a "leaf" has more limited impact, because all the affected INRs belong to the INR holder itself 🍃.

In Scenario A, actions by the INR holder can adversely affect all of its resources and, transitively, resources of any subordinate CAs 🌊. (If the CA is a "leaf" in the RPKI, then it has no subordinate CAs and the damage is limited to its own INRs 🙌.)

In Scenario B, actions by the (outsourced) repository operator can also adversely affect the resources of the INR holder and those of any subordinates CAs 🫠. (If the CA is a "leaf" in the RPKI, then it has no subordinate CAs and the damage is limited, as in Scenario A.) The range of adverse effects here includes those in Scenario A and adds a new potential source of adverse actions, i.e., the outsourced repository operator 🧚.

In Scenario C, all signed objects associated with the INR holder are generated by the parent CA but are self-hosted 🏠. (We expect this scenario to be rare, because an INR holder that elects to outsource CA operation seems unlikely to manage its own repository publication point 🤔.) Because that CA has the private key used to sign them, it can generate alternative signed objects -- ones not authorized by the INR holder 😱. However, erroneous objects created by the parent CA will not be published by the INR holder IF the holder checks them first ✅. Because the parent CA is acting on behalf of the INR holder, mistakes by or attacks against that entity are equivalent to ones effected by the INR holder in Scenario A 🔁.

The INR holder is most vulnerable in Scenario D 🚨💔. Actions by the parent CA, acting on behalf of the INR holder, can adversely affect all signed objects associated with that INR holder, including any subordinate CA certificates 🫣. These actions will presumably translate directly into publication point changes, because the parent CA is managing the publication point for the INR holder 📂. The range of adverse effects here includes those in Scenarios A, B, and C 💅✨.

3.1. Scenario A 🌸

In this scenario, the INR holder acts as its own CA and manages its own publication point 🙌. Actions by the INR holder can adversely affect all of its resources and, transitively, resources of any subordinate CAs 🌊. (If the CA is a "leaf" in the RPKI, then it has no subordinate CAs and the damage is limited to its own INRs 🍃.) Mistakes by the INR holder can cause any of the actions noted in Section 2 🙈. A successful attack against this CA can effect all of the modification, revocation, or injection actions noted in that section 💥. (We assume that objects generated by the CA are automatically published 🤖.) An attack against the publication point can effect all of the deletion, suppression, or corruption actions noted in that section 😤.

3.2. Scenario B 🦋

In this scenario, the INR holder acts as its own CA but delegates management of its own publication point to a third party 🤝. Mistakes by the INR holder can cause any of the modification, revocation, or injection actions described in Section 2 🫢. Actions by the repository operator can adversely affect the resources of the INR holder, and those of any subordinate CAs 😬. (If the CA is a "leaf" in the RPKI, then it has no subordinate CAs and the damage is limited, as in Scenario A.) The range of adverse effects here includes those in Scenario A, and adds a new potential source of adverse actions, i.e., the third party repository operator 🧩. A successful attack against the CA can effect all of the modification, revocation, or injection actions noted in that section (assuming that objects generated by the CA are automatically published) 💅. Here, actions by the publication point manager (or attacks against that entity) can effect all of the deletion, suppression, or corruption actions noted in Section 2 🚨💜.

3.3. Scenario C 🎀

okay so Scenario C is giving "I'll handle the paperwork, you handle the shelf" 📦. The INR holder hands its CA management to its parent, but keeps its own repository publication point. Every signed object tied to the holder gets generated by the parent CA and then self-hosted by the holder. (We expect this one to be rare, bestie, because an INR holder that outsources CA operation seems unlikely to also run its own publication point 🙈.)

Here's the tea ☕: the parent CA holds the private key used to sign these objects, so it can generate alternative signed objects that the INR holder never authorized 💀. BUT erroneous objects from the parent CA will NOT get published by the INR holder IF the holder checks them first ✅.

Since the parent CA is acting on behalf of the INR holder, mistakes by or attacks against that entity are the same as the ones the INR holder could cause in Scenario A 🫶. Mistakes made by the INR holder, which the parent CA then acts on, can cause any of the actions noted in Section 2 😭. Actions the parent CA takes unilaterally can have the same effect too, unless the INR holder checks the signed objects before publishing them.

A successful attack against the parent CA can pull off all of the modification, revocation, or injection actions noted in Section 2, unless the INR holder checks the signed objects before publishing them 🔥. An attack against the INR holder (in its role as repository operator) can pull off all of the deletion, suppression, or corruption actions noted in Section 2, because the holder is running its publication point, unless it checks the signed objects before publishing them 👑. (An attack against the INR holder implies that the path it uses to direct the parent CA to issue and publish objects has been compromised 🚨.)

3.4. Scenario D 🌈

In Scenario D, an INR holder outsources management of BOTH its CA and its publication point to its parent 🧚. This is the most vulnerable spot for the INR holder, no cap 😭. Actions by the parent CA, acting on behalf of the INR holder, can negatively affect ALL signed objects tied to that INR holder, including any subordinate CA certificates 💅. These actions will presumably turn into publication point changes directly, because the parent CA is managing the publication point for the INR holder 🍓. The range of adverse effects here includes the ones from Scenarios A, B, and C, so it's a whole buffet of chaos 🙈.

Mistakes by the INR holder, acted upon by the parent CA, can cause any of the actions noted in Section 2. Actions the parent CA takes unilaterally can also have the same effect. A successful attack against the parent CA can pull off all of the modification, revocation, or injection actions noted in Section 2. An attack against the parent CA can also pull off all of the deletion, suppression, or corruption actions noted in Section 2, because the parent CA is managing the INR holder's publication point 💜.

4. Security Considerations 🔐

This informational document describes a threat model for the RPKI, and it focuses on mistakes by or attacks against CAs and independent repository managers 👀. It's meant to be a foundation for designing future RPKI security mechanisms that tackle the concerns tied to those actions 🛠️.

The analysis in this document points out a bunch of situations where attacks or errors can seriously impact routing 😱. One ought not read this as a condemnation of the RPKI, though! It's just documenting the implications of a wide range of attacks and errors in the RPKI context 🌸. The main alternative for sharing routing information is Internet Routing Registry (IRR) technology [RFC2650] [RFC2725], which uses the Routing Policy Specification Language (RPSL) [RFC2622]. IRR technology has its own set of security problems, which are covered in [RFC7682] 🧐.

5. IANA Considerations 🦋

This document does not require any IANA actions ✨.

6. References 📚

6.1. Normative References

[RFC3779]  Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
           Addresses and AS Identifiers", RFC 3779,
           DOI 10.17487/RFC3779, June 2004,
           <https://www.rfc-editor.org/info/rfc3779>.

[RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
           Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
           February 2012, <https://www.rfc-editor.org/info/rfc6480>.

[RFC6481]  Huston, G., Loomans, R., and G. Michaelson, "A Profile for
           Resource Certificate Repository Structure", RFC 6481,
           DOI 10.17487/RFC6481, February 2012,
           <https://www.rfc-editor.org/info/rfc6481>.

[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>.

[RFC6483]  Huston, G. and G. Michaelson, "Validation of Route
           Origination Using the Resource Certificate Public Key
           Infrastructure (PKI) and Route Origin Authorizations
           (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012,
           <https://www.rfc-editor.org/info/rfc6483>.

[RFC6486]  Austein, R., Huston, G., Kent, S., and M. Lepinski,
           "Manifests for the Resource Public Key Infrastructure
           (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012,
           <https://www.rfc-editor.org/info/rfc6486>.

[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>.

[RFC6488]  Lepinski, M., Chi, A., and S. Kent, "Signed Object
           Template for the Resource Public Key Infrastructure
           (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012,
           <https://www.rfc-editor.org/info/rfc6488>.

[RFC6489]  Huston, G., Michaelson, G., and S. Kent, "Certification
           Authority (CA) Key Rollover in the Resource Public Key
           Infrastructure (RPKI)", BCP 174, RFC 6489,
           DOI 10.17487/RFC6489, February 2012,
           <https://www.rfc-editor.org/info/rfc6489>.

[RFC6493]  Bush, R., "The Resource Public Key Infrastructure (RPKI)
           Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493,
           February 2012, <https://www.rfc-editor.org/info/rfc6493>.

[RFC6916]  Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility
           Procedure for the Resource Public Key Infrastructure
           (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April
           2013, <https://www.rfc-editor.org/info/rfc6916>.

[RFC7935]  Huston, G. and G. Michaelson, Ed., "The Profile for
           Algorithms and Key Sizes for Use in the Resource Public
           Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935,
           August 2016, <https://www.rfc-editor.org/info/rfc7935>.

[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>.

[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>.

6.2. Informative References

[RFC2622]  Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
           Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra,
           "Routing Policy Specification Language (RPSL)", RFC 2622,
           DOI 10.17487/RFC2622, June 1999,
           <https://www.rfc-editor.org/info/rfc2622>.

[RFC2650]  Meyer, D., Schmitz, J., Orange, C., Prior, M., and C.
           Alaettinoglu, "Using RPSL in Practice", RFC 2650,
           DOI 10.17487/RFC2650, August 1999,
           <https://www.rfc-editor.org/info/rfc2650>.

[RFC2725]  Villamizar, C., Alaettinoglu, C., Meyer, D., and S.
           Murphy, "Routing Policy System Security", RFC 2725,
           DOI 10.17487/RFC2725, December 1999,
           <https://www.rfc-editor.org/info/rfc2725>.

[RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
           RFC 5652, DOI 10.17487/RFC5652, September 2009,
           <https://www.rfc-editor.org/info/rfc5652>.

[RFC7132]  Kent, S. and A. Chi, "Threat Model for BGP Path Security",
           RFC 7132, DOI 10.17487/RFC7132, February 2014,
           <https://www.rfc-editor.org/info/rfc7132>.

[RFC7682]  McPherson, D., Amante, S., Osterweil, E., Blunk, L., and
           D. Mitchell, "Considerations for Internet Routing
           Registries (IRRs) and Routing Policy Configuration",
           RFC 7682, DOI 10.17487/RFC7682, December 2015,
           <https://www.rfc-editor.org/info/rfc7682>.

Acknowledgements 💖

The authors thank Richard Hansen and David Mandelberg for their extensive review, feedback, and editorial assistance 🫶. Thanks also go to Daiming Li for her editorial assistance 🌷.

Authors' Addresses 💌

Stephen Kent
BBN Technologies
10 Moulton St
Cambridge, MA  02138-1119
United States of America

Email: kent@alum.mit.edu


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

Email: madi@zdns.cn

📦 where this page comes from

ietf: rfc8211 2017-09
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms