GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc8211

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc8211.txt · Last modified: 2017/09/28 04:04 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki