diff options
Diffstat (limited to 'doc/rfc/rfc8211.txt')
| -rw-r--r-- | doc/rfc/rfc8211.txt | 1459 |
1 files changed, 1459 insertions, 0 deletions
diff --git a/doc/rfc/rfc8211.txt b/doc/rfc/rfc8211.txt new file mode 100644 index 0000000..5d99265 --- /dev/null +++ b/doc/rfc/rfc8211.txt @@ -0,0 +1,1459 @@ + + + + + + +Internet Engineering Task Force (IETF) S. Kent +Request for Comments: 8211 BBN Technologies +Category: Informational D. Ma +ISSN: 2070-1721 ZDNS + September 2017 + + +Adverse Actions by a Certification Authority (CA) or Repository Manager + in the Resource Public Key Infrastructure (RPKI) + +Abstract + + This document analyzes actions by or against a Certification + Authority (CA) or an independent repository manager in the RPKI that + can adversely affect the Internet Number Resources (INRs) associated + with that CA or its subordinate CAs. The analysis is done from the + perspective of an affected INR holder. The analysis is based on + examination of the data items in the RPKI repository, as controlled + by a CA (or an independent repository manager) and fetched by Relying + Parties (RPs). The analysis does not purport to be comprehensive; it + does represent an orderly way to analyze a number of ways that errors + by or attacks against a CA or repository manager can affect the RPKI + and routing decisions based on RPKI data. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It has been approved for publication by the Internet + Engineering Steering Group (IESG). Not all documents approved by the + IESG are a candidate for any level of Internet Standard; see + Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8211. + + + + + + + + + + + + + +Kent & Ma Informational [Page 1] + +RFC 8211 RPKI Adverse CA Actions September 2017 + + +Copyright Notice + + Copyright (c) 2017 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided 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 + + + + + + + + + + + + + + +Kent & Ma Informational [Page 2] + +RFC 8211 RPKI Adverse CA Actions September 2017 + + +1. Introduction + + In the context of this document, any change to the Resource Public + Key Infrastructure (RPKI) [RFC6480] that diminishes the set of + Internet Number Resources (INRs) associated with an INR holder, and + that is contrary to the holder's wishes, is termed "adverse". This + analysis is done from the perspective of an affected INR holder. An + action that results in an adverse charge (as defined above) may be + the result of an attack on a CA [RFC7132], an error by a CA, or an + error by or an attack on a repository operator. Note that the CA + that allocated the affected INRs may be acting in accordance with + established policy; thus, the change may be contractually justified + even though viewed as adverse by the INR holder. This document + examines the implications of adverse actions within the RPKI with + respect to INRs, irrespective of the cause of the actions. + + Additionally, when a Route Origin Authorization (ROA) or router + certificate is created that "competes" with an existing ROA or router + certificate (respectively), the creation of the new ROA or router + certificate may be adverse. (A newer ROA competes with an older ROA + if the newer ROA points to a different Autonomous System Number + (ASN), contains the same or a more specific prefix, and is issued by + a different CA. A newer router certificate competes with an older + router certificate if the newer one contains the same ASN, contains a + different public key, and is issued by a different CA.) Note that + transferring resources or changing of upstream providers may yield + competing ROAs and/or router certificates under some circumstances. + Thus, not all instances of competition are adverse actions. + + As noted above, adverse changes to RPKI data may arise due to several + types of causes. A CA may make a mistake in managing the RPKI + objects it signs, or it may be subject to an attack. If an attack + allows an adversary to use the private key of that CA to sign RPKI + objects, then the effect is analogous to the CA making mistakes. + There is also the possibility that a CA or repository operator may be + subject to legal measures that compel them to make adverse changes to + RPKI data. In many cases, such actions may be hard to distinguish + from mistakes or attacks, other than with respect to the time + required to remedy the adverse action. (Presumably, the CA will take + remedial action when a mistake or an attack is detected, so the + effects are similar in these cases. If a CA has been legally + compelled to effect an adverse change, remediation will likely not be + swift.) + + This document analyzes the various types of actions by a CA (or an + independent repository operator) that can adversely affect the INRs + associated with that CA, as well as the INRs of subordinate CAs. The + analysis is based on examination of the data items in the RPKI + + + +Kent & Ma Informational [Page 3] + +RFC 8211 RPKI Adverse CA Actions September 2017 + + + repository, as controlled by a CA (or an independent repository + operator) and fetched by RPs. + +2. Analysis of RPKI Repository Objects + + This section enumerates the RPKI repository system objects and + examines how changes to them affect Route Origin Authorizations + (ROAs) and router certificate validation. Identifiers are assigned + to errors for reference by later sections of this document. Note + that not all adverse actions may be encompassed by this taxonomy. + + The RPKI repository [RFC6481] contains a number of (digitally signed) + objects that are fetched and processed by RPs. Until the deployment + of BGPsec [RFC8205], the principal goal of the RPKI is to enable an + RP to validate ROAs [RFC6482]. A ROA binds address space to an ASN. + A ROA can be used to verify BGP announcements with respect to route + origin [RFC6483]. The most important objects in the RPKI for origin + validation are ROAs; all of the other RPKI objects exist to enable + the validation of ROAs in a fashion consistent with the INR + allocation system. Thus, errors that result in changes to a ROA, or + to RPKI objects needed to validate a ROA, can cause RPs to reach + different (from what was intended) conclusions about the validity of + the bindings expressed in a ROA. + + When BGPsec is deployed, router certificates [RFC8209] will be added + to repository publication points. These are end entity (EE) + certificates used to verify signatures applied to BGP update data and + to enable path validation [RFC8205]. Router certificates are as + important to path validation as ROAs are to origin validation. + + The objects contained in the RPKI repository are of two types: + conventional PKI objects (certificates and Certificate Revocation + Lists (CRLs)) and RPKI-specific signed objects. The latter make use + of a common encapsulation format [RFC6488] based on the Cryptographic + Message Syntax (CMS) [RFC5652]. A syntax error in this common format + will cause an RP to reject the object, e.g., a ROA or manifest, as + invalid. + + Adverse actions take several forms: + + * Deletion (D) is defined as removing an object from a + publication point, without the permission of the INR holder. + + * Suppression (S) is defined as not deleting an object, or not + publishing an object, as intended by an INR holder. This + action also includes retaining a prior version of an object in + a publication point when a newer version is available for + publication. + + + +Kent & Ma Informational [Page 4] + +RFC 8211 RPKI Adverse CA Actions September 2017 + + + * Corruption (C) is defined as modification of a signed object in + a fashion not requiring access to the private key used to sign + the object. Thus, a corrupted object will not carry a valid + signature. Implicitly, the corrupted object replaces the + legitimate version. + + * Modification (M) is defined as publishing a syntactically + valid, verifiable version of an object that differs from the + (existing) version authorized by the INR holder. Implicitly, + the legitimate version of the affected object is deleted and + replaced by the modified object. + + * Revocation (R) is defined as revoking a certificate (EE or CA) + by placing its Serial Number on the appropriate CRL, without + authorization of the INR holder. + + * Injection (I) is defined as introducing an instance of a signed + object into a publication point (without authorization of the + INR holder). It assumes that the signature on the object will + be viewed as valid by RPs. + + The first three of these actions (deletion, suppression, and + corruption) can be effected by any entity that manages the + publication point of the affected INR holder. Also, an entity with + the ability to act as a man-in-the-middle between an RP and a + repository can effect these actions with respect to the RP in + question. + + The latter three actions (modification, revocation, and injection) + nominally require access to the private key of the INR holder. + + All six of these actions also can be effected by a parent CA. A + parent CA could reissue the INR holder's CA certificate, but with a + different public key, matching a private key to which the parent CA + has access. The CA could generate new signed objects using the + private key associated with the reissued certificate and publish + these objects at a location of its choosing. + + Most of these actions may be performed independently or in + combination with one another. For example, a ROA may be revoked and + deleted or revoked and replaced with a modified ROA. Where + appropriate, the analysis of adverse actions will distinguish between + individual actions, or combinations thereof, that yield different + outcomes for RPs. Recall that the focus of the analysis is the + impact on ROAs and router certificates, with respect to RP + processing. + + + + + +Kent & Ma Informational [Page 5] + +RFC 8211 RPKI Adverse CA Actions September 2017 + + + The following sections examine how the actions enumerated above + affect objects in the RPKI repository system. Each action is + addressed in order (deletion, suppression, corruption, modification, + revocation, and injection) for each object, making it easy to see how + each action has been considered with regard to each 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 + + Every INR holder is represented by one or more CA certificates. An + INR holder has multiple CA certificates if it holds resources + acquired from different sources. Also, every INR holder has more + than one CA certificate during key rollover [RFC6489] and algorithm + rollover [RFC6916]. + + If a publication point is not a "leaf" in the RPKI hierarchy, then + the publication point will contain one or more CA certificates, each + representing a subordinate CA. Each subordinate CA certificate + contains a Subject Information Access (SIA) pointer to the + publication point where the signed objects associated with that CA + can be found [RFC6487]. + + A CA certificate is a complex data structure; thus, errors in that + structure may have different implications for RPs depending on the + specific data that is in error. + + Adverse actions against a CA certificate can cause the following + errors: + + A-1.1 Deletion + + A-1.1.1 Deletion of a CA certificate would cause an RP to + not be able to locate signed objects generated by + that CA, except those that have been cached by the + RP. Thus, an RP would be unaware of changed or + new (issued after the cached data) INR bindings + asserted in subordinate ROAs, and the RP would be + unable to validate new or changed router + certificates. If the missed objects were intended + to replace ROAs or router certificates prior to + expiration, then when those objects expire, RPs + may cease to view them as valid. As a result, + valid routes may be viewed as NotFound or Invalid. + + + + + + + +Kent & Ma Informational [Page 6] + +RFC 8211 RPKI Adverse CA Actions September 2017 + + + A-1.2 Suppression + + A-1.2.1 If publication of a CA certificate is suppressed, + the impact depends on what changes appeared in the + suppressed certificate. If the SIA value changed, + the effect would be the same as in A-1.1 or + A-1.4.3. If the [RFC3779] extensions in the + suppressed certificate changed, the impact would + be the same as in A-1.4.1. If the Authority + Information Access (AIA) extension changed in the + suppressed certificate, the impact would be the + same as in A-1.4.4. Suppression of a renewed/ + re-issued certificate may cause an old certificate + to expire and thus be rejected by RPs. + + A-1.3 Corruption + + A-1.3.1 Corruption of a CA certificate will cause it to be + rejected by RPs. In turn, this may cause + subordinate signed objects to become invalid. An + RP that has cached the subtree under the affected + CA certificate may continue to view it as valid, + until objects expire. But changed or new objects + might not be retrieved, depending on details of + the design of the RP software. Thus, 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 is changed to exclude INRs that + were previously present, then subordinate signed + objects will become invalid if they rely on the + excised INRs. If these objects are CA + certificates, their subordinate signed objects + will be treated as invalid. If the objects are + ROAs, the binding expressed by the affected ROAs + will be ignored by RPs. If the objects are router + certificates, BGPsec_PATH attributes [RFC8205] + verifiable under these certificates will be + considered invalid. + + + + + + + +Kent & Ma Informational [Page 7] + +RFC 8211 RPKI Adverse CA Actions September 2017 + + + 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 at another location + for subordinate objects. This could cause RPs to + not acquire the objects that 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 contain + invalid signatures or appear to be corrupted, they + may be rejected. In this case, cached versions of + the objects may be viewed as valid by an RP, until + they expire. 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 used only for path discovery, not + path validation. Path discovery in the RPKI is + usually performed on a top-down basis, starting + with trust anchors (TAs) and recursively + descending the RPKI hierarchy. Thus, there may be + no impact on the ability of clients 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 corresponding to + a private key held by the parent, the parent could + sign objects as children of the affected CA + certificate. With this capability, the parent + could replace the INR holder, issuing new signed + objects that would be accepted by RPs (as long as + they do not violate the path validation criteria). + This would enable the parent to effect + modification, revocation, and injection actions + against all of 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 distinguish this legitimate + activity from an adverse action.) + + + + + +Kent & Ma Informational [Page 8] + +RFC 8211 RPKI Adverse CA Actions September 2017 + + + A-1.5 Revocation + + A-1.5.1 If a CA certificate is revoked, an RP will treat + as invalid all subordinate signed objects, both + immediate and transitive. The effects are + essentially the same as described in A-3.4.2. + + A-1.6 Injection + + A-1.6.1 If a CA certificate is injected, the impact will + depend on the data contained in the injected + certificate. Changes will generally be equivalent + to modification actions as described in A-1.4. + +2.2. Manifest + + Each repository publication point contains a manifest [RFC6486]. The + RPKI incorporates manifests to enable RPs to detect suppression and/ + or substitution of (more recent) publication point objects, as the + result of a mistake or attack. A manifest enumerates (by filename) + all of the other signed objects at the publication point. The + manifest also contains a hash of each enumerated file to enable an RP + to determine if the named file content matches what the INR holder + identified in the manifest. + + A manifest is an RPKI signed object, so it is validated as per + [RFC6488]. If a manifest is modified in a way that causes any of + these checks to fail, the manifest will be considered invalid. + Suppression of a manifest itself (indicated by a stale manifest) can + also cause an RP to not detect suppression of other signed objects at + the publication point. (Note that if a manifest's EE certificate + expires at the time that the manifest is scheduled to be replaced, a + delay in publication will cause the manifest to become invalid, not + merely stale. This very serious outcome should be avoided, e.g., by + making the manifest EE certificate's notAfter value the same as that + of the CA certificate under which it was issued). If a signed object + at a publication point can be validated (using the rules applicable + for that object type), then an RP may accept that object, even if + there is no matching entry for it on the manifest. However, it + appears that most RP software ignores publication point data that + fails to match manifest entries (at the time this document was + written). + + Corruption, suppression, modification, or deletion of a manifest + might not affect RP processing of other publication point objects, as + specified in [RFC6486]. However, as noted above, many RP + + + + + +Kent & Ma Informational [Page 9] + +RFC 8211 RPKI Adverse CA Actions September 2017 + + + implementations ignore objects that are present at a publication + point but not listed in a valid manifest. Thus, the following + actions against a manifest can impact RP processing: + + A-2.1 Deletion + + A-2.1.1 A manifest may be deleted from the indicated + publication point. In this circumstance, an RP + may elect to use the previous manifest (if + available) and may ignore any new/changed objects + at the publication point. The implications of + this action are equivalent to suppression of + publication of the objects that are not recognized + by RPs because the new objects are not present in + the old manifest. For example, a new ROA could be + ignored (A-1.2). A newly issued CA certificate + might be ignored (A-1.1). A subordinate CA + certificate that was revoked might still be viewed + as valid by RPs (A-4.1). A new or changed router + certificate might be ignored (A-6.2) as would a + revised Ghostbusters Record (A-4.1). + + A-2.2 Suppression + + A-2.2.1 Publication of a newer manifest may be suppressed. + Suppression of a newer manifest probably will + cause an RP to rely on a cached manifest (if + available). The older manifest would not + enumerate newly added objects; thus, those objects + might be ignored by an RP, which is equivalent to + deletion of those objects (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 be corrupted. A corrupted manifest + will be rejected by RPs. This may cause RPs to + rely on a previous manifest, with the same impact + as A-2.2. If an RP does not revert to using a + cached manifest, the impact of this action is very + severe, i.e., all publication point objects will + probably be viewed as invalid, including + subordinate tree objects. This is equivalent to + revoking or deleting an entire subtree (see + A-4.4.2). + + + + + + +Kent & Ma Informational [Page 10] + +RFC 8211 RPKI Adverse CA Actions September 2017 + + + A-2.4 Modification + + A-2.4.1 A manifest may be modified to remove one or more + objects. Because the modified manifest is viewed + as valid by RPs, any objects that were removed may + be ignored by RPs. This is equivalent to deleting + these objects from the repository. The impact of + this action will vary, depending on which objects + are (effectively) removed. However, the impact is + equivalent to deletion of 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 is not expired), it will be accepted by RPs + and processed accordingly. If the added object + was previously deleted by the INR holder, this + action is equivalent to suppressing deletion of + that object. If the object is newly created or + modified, it is equivalent to a modification or + injection action for the type of object in + question and is thus discussed in the relevant + section for those actions for the object type. + + A-2.4.3 A manifest may be modified to list an incorrect + hash for one or more objects. An object with an + incorrect hash may be ignored by an RP. Thus, the + effect may be equivalent to corrupting the object + in question, although the error reported by RP + software would differ from that reported for a + corrupted object. (The manifest specifications do + not require an RP to ignore an object that has a + valid signature and that is not revoked or + expired, but for which the hash doesn't match the + object. However, an RP may elect to do so.) + + A-2.5 Revocation + + A-2.5.1 A manifest may be revoked (by including its EE + certificate on the CRL for the publication point). + A revoked manifest will be ignored by an RP, which + probably would revert to an older (cached) + manifest. The implications for RPs are equivalent + to A-2.1 with regard to new/changed objects. + + + + + + + +Kent & Ma Informational [Page 11] + +RFC 8211 RPKI Adverse CA Actions September 2017 + + + 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 will depend on the type of the + affected object(s) and is thus discussed in the + relevant section(s) for each object type. + +2.3. Certificate Revocation List + + Each publication point contains a CRL that enumerates revoked (not + yet expired) certificates issued by the CA associated with the + publication point [RFC6481]. + + Adverse actions against a CRL can cause the following errors: + + A-3.1 Deletion + + A-3.1.1 If a CRL is deleted, RPs will continue to use an + older, previously fetched Certificate Revocation + List. As a result, they will not be informed of + any changes in revocation status of subordinate CA + or router certificates or the EE certificates of + signed objects, e.g., ROAs. This action is + equivalent to corruption of a CRL, since a + corrupted CRL will not be accepted by an RP. + + A-3.1.2 Deletion of a CRL could cause an RP to continue to + accept a ROA that no longer expresses the intent + of an INR holder. As a result, an announcement + for the affected prefixes would be viewed as + Valid, instead of NotFound or Invalid. In this + case, the effect is analogous to A-5.2. + + A-3.1.3 If a router certificate were revoked and the CRL + were deleted, RPs would not be aware of the + revocation. They might continue to accept the + old, revoked router certificate. If the + certificate had been revoked due to a compromise + of the router's private key, RPs would be + vulnerable to accepting routes signed by an + unauthorized entity. + + + + + + + + +Kent & Ma Informational [Page 12] + +RFC 8211 RPKI Adverse CA Actions September 2017 + + + A-3.1.4 If a subordinate CA certificate were revoked on + the deleted CRL, the revocation would not take + effect. This could interfere with a transfer of + address space from the subordinate CA, adversely + affecting routing to the new holder of the space. + + A-3.2 Suppression + + A-3.2.1 If publication of the most recent CRL is + suppressed, an RP will not be informed of the most + recent revocation status of a subordinate CA or + router certificates or the EE certificates of + signed objects. If an EE certificate has been + revoked and the associated signed object is still + present in the publication point, an RP might + mistakenly treat that object as valid. (This + would happen if the object is still in the + manifest or if the RP is configured to process + valid objects that are not on the manifest.) This + type of action is of special concern if the + affected object is a ROA, a router certificate, or + a subordinate CA certificate. The effects here + are equivalent to CRL deletion (A-3.1), but + suppression of a new CRL may not even be reported + as an error, i.e., if the suppressed CRL were + issued before the NextUpdate time (of the previous + CRL). + + A-3.3 Corruption + + A-3.3.1 If a CRL is corrupted, an RP will reject it. If a + prior CRL has not yet exceeded its NextUpdate + time, an RP will continue to use the prior CRL. + Even if the prior CRL has passed the NextUpdate + time, an RP may choose to continue to rely on the + prior CRL. The effects are essentially equivalent + to suppression or deletion of a CRL (A-3.1 and + A-3.2). + + + + + + + + + + + + + +Kent & Ma Informational [Page 13] + +RFC 8211 RPKI Adverse CA Actions September 2017 + + + A-3.4 Modification + + A-3.4.1 If a CRL is modified to erroneously list a signed + object's EE certificate as revoked, the + corresponding object will be treated as invalid by + RPs, even if it is present in a publication point. + If this object is a ROA, the (legitimate) binding + expressed by the ROA will be ignored by an RP (see + A-5.5). If a CRL is modified to erroneously list + a router certificate as revoked, a path signature + associated with that certificate will be treated + as Not Valid by RPs (see A-6.5). + + A-3.4.2 If a CRL is modified to erroneously list a CA + certificate as revoked, that CA and all + subordinate signed objects will be treated as + invalid by RPs. Depending on the location of the + affected CA in the hierarchy, these effects could + be very substantial, causing routes that should be + Valid to be treated as NotFound. + + A-3.4.3 If a CRL is modified to omit a revoked EE, router, + or CA certificate, RPs will likely continue to + accept the revoked, signed object as valid. This + contravenes the intent of the INR holder. If an + RP continues to accept a revoked ROA, it may make + routing decisions on now-invalid data. This could + cause valid routes to be de-preferenced and + invalid routes to continue to be accepted. + + A-3.5 Revocation + + A-3.5.1 A CRL cannot be revoked per se, but it will fail + validation if the CA certificate under which it + was issued is revoked. See A-1.5 for a discussion + of that action. + + A-3.6 Injection + + A-3.6.1 Insertion of a bogus CRL can have the same effects + as listed above for a modified CRL, depending on + how the inserted CRL differs from the correct CRL. + + + + + + + + + +Kent & Ma Informational [Page 14] + +RFC 8211 RPKI Adverse CA Actions September 2017 + + +2.4. ROA + + 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. The result is to void the + binding between the prefix(es) and the Autonomous + System (AS) number in the ROA. An RP that + previously viewed this binding as authentic will + now not have any evidence about its validity. For + origin validation, this means that a legitimate + route will be treated as NotFound (if there are no + other ROAs for the same prefix) or Invalid (if + there is 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 intended to change the binding + between the prefix(es) and the AS number in the + ROA, this change will not be effected. As a + result, RPs may continue to believe an old prefix/ + ASN binding that is no longer what the INR holder + intended. + + A-4.2.2 If an INR holder intends 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 is published. In this case, RPs will + de-preference the suppressed prefix/ASN binding. + Suppression of the new ROA might cause traffic to + flow to an ASN other than the one(s) intended by + the INR holder. + + + + + + + + + + +Kent & Ma Informational [Page 15] + +RFC 8211 RPKI Adverse CA Actions September 2017 + + + A-4.2.3 If an INR holder intends to delete all ROAs for + the same address space, some of them may be + retained while the others are deleted. Preventing + the deletion of some ROAs can cause traffic to + continue to be delivered to the ASNs that were + advertised by these ROAs. Deletion of all ROAs is + consistent with a transfer of address space to a + different INR holder in a phased fashion. Thus, + this sort of attack could interfere with the + successful transfer of the affected address space + (until such time as 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 will be + ignored by an RP, so the effect is essentially the + same as for A-4.1 and A-4.5. A possible + difference is that an RP may be alerted to the + fact that the ROA was corrupted, which might + attract 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 a ROA is different from the values the + INR holder intended for this ROA. (This action + assumes that the modified ROA's ASN and address + ranges are authorized for use by the INR holder.) + This attack will cause RPs to de-preference the + legitimate prefix/ASN binding intended by the INR + holder. + + 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. + + + + + + + + + + + + +Kent & Ma Informational [Page 16] + +RFC 8211 RPKI Adverse CA Actions September 2017 + + + A-4.6 Injection + + A-4.6.1 A ROA expressing different bindings than those + published by the INR holder may be injected into a + publication point. This action could authorize an + additional ASN to advertise the specified prefix, + allowing that ASN to originate routes for the + prefix, thus enabling 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 already authorized to originate a + route, e.g., a longer prefix, which could enable + that ASN to override other advertisements using + shorter prefixes. If there are other ROAs that + authorize different ASNs to advertise routes to + the injected ROA's prefix, then the injected ROA + is in competition with these ROAs. + +2.5. Ghostbusters Record + + The Ghostbusters Record [RFC6493] is a signed object that may be + included at a publication point, at the discretion of the INR holder + or publication point operator. The record is validated according to + [RFC6488]. Additionally, the syntax of the record is verified based + on the vCard profile from Section 5 of [RFC6493]. Errors in this + record do not affect RP processing. However, if an RP encounters a + problem with objects at a publication point, the RP may use + information 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. + + + + + +Kent & Ma Informational [Page 17] + +RFC 8211 RPKI Adverse CA Actions September 2017 + + +2.6. Router Certificates + + Router certificates are used by RPs to verify signatures on + BGPsec_PATH attributes carried in UPDATE messages. + + Each AS is free to determine the granularity at which router + certificates are managed [RFC8209]. Each participating AS is + represented by one or more router certificates. During key or + algorithm rollover, multiple router certificates will be present 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. + + + + + + + + + +Kent & Ma Informational [Page 18] + +RFC 8211 RPKI Adverse CA Actions September 2017 + + + 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. + +3. Analysis of Actions Relative to Scenarios + + This section examines the types of problems that can arise in four + scenarios described below. We consider mistakes, (successful) + attacks against a CA or a publication point, and situations in which + a CA or publication point manager is compelled to take action by a + law enforcement authority. + + + + +Kent & Ma Informational [Page 19] + +RFC 8211 RPKI Adverse CA Actions September 2017 + + + 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 + arise when the INR holder appears as a high-tier CA in the RPKI + hierarchy; in such situations, subordinate INR holders may be + affected as a result of an action. A mistake by or an attack against + a "leaf" has more limited impact because all of 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. + + + + +Kent & Ma Informational [Page 20] + +RFC 8211 RPKI Adverse CA Actions September 2017 + + + 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 it 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 it delegates + management of it 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 + + In this scenario, the INR holder outsources management of its CA to + its parent, but manages its own repository publication point. 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 + + + +Kent & Ma Informational [Page 21] + +RFC 8211 RPKI Adverse CA Actions September 2017 + + + 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. Mistakes by the INR holder, acted upon by + the parent CA, can cause any of the actions noted in Section 2. + Actions unilaterally undertaken by the parent CA also can have the + same effect, unless the INR holder checks the signed objects before + publishing them. A successful attack against the parent CA can + effect 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 effect all of the deletion, + suppression, or corruption actions noted in Section 2 (because the + INR holder is managing its publication point), unless the INR holder + 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 this scenario, an INR holder outsources management of both its CA + and its publication point to its parent. The INR holder is most + vulnerable in this scenario. 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. Mistakes by the INR + holder, acted upon by the parent CA, can cause any of the actions + noted in Section 2. Actions unilaterally undertaken by the parent CA + also can have the same effect. A successful attack against the + parent CA can effect all of the modification, revocation, or + injection actions noted in Section 2. An attack against the parent + CA can also effect 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, + focusing on mistakes by or attacks against CAs and independent + repository managers. It is intended to provide a basis for the + design of future RPKI security mechanisms that seek to address the + concerns associated with such actions. + + + +Kent & Ma Informational [Page 22] + +RFC 8211 RPKI Adverse CA Actions September 2017 + + + The analysis in this document identifies a number of circumstances in + which attacks or errors can have significant impacts on routing. One + ought not interpret this as a condemnation of the RPKI. It is only + an attempt to document the implications of a wide range of attacks + and errors in the context of the RPKI. The primary alternative + mechanism for disseminating routing information is Internet Routing + Registry (IRR) technology [RFC2650] [RFC2725], which uses the Routing + Policy Specification Language (RPSL) [RFC2622]. IRR technology + exhibits its own set of security problems, which are discussed 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>. + + + +Kent & Ma Informational [Page 23] + +RFC 8211 RPKI Adverse CA Actions September 2017 + + + [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>. + + + + + + + + + + + + +Kent & Ma Informational [Page 24] + +RFC 8211 RPKI Adverse CA Actions September 2017 + + +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>. + + + + + + + + + + + + + + + + + + + + +Kent & Ma Informational [Page 25] + +RFC 8211 RPKI Adverse CA Actions September 2017 + + +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 + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kent & Ma Informational [Page 26] + |