draft-ietf-sidr-adverse-actions-00.txt   draft-ietf-sidr-adverse-actions-01.txt 
SIDR S. Kent SIDR S. Kent
Internet-Draft BBN Internet-Draft BBN Technologies
Intended status: Informational D. Ma Intended status: Informational D. Ma
Expires: October 15, 2016 ZDNS Expires: January 26, 2017 ZDNS
April 13, 2016 July 25, 2016
Adverse Actions by a Certification Authority (CA) or Repository Manager Adverse Actions by a Certification Authority (CA) or Repository Manager
in the Resource Public Key Infrastructure (RPKI) in the Resource Public Key Infrastructure (RPKI)
draft-ietf-sidr-adverse-actions-00 draft-ietf-sidr-adverse-actions-01
Abstract Abstract
This document analyzes actions by or against a CA or independent This document analyzes actions by or against a CA or independent
repository manager in the RPKI that can adversely affect the Internet repository manager in the RPKI that can adversely affect the Internet
Number Resources (INRs) associated with that CA or its subordinate Number Resources (INRs) associated with that CA or its subordinate
CAs. The analysis is based on examination of the data items in the CAs. The analysis is based on examination of the data items in the
RPKI repository, as controlled by a CA (or independent repository RPKI repository, as controlled by a CA (or independent repository
manager) and fetched by Relying Parties (RPs). The analysis is manager) and fetched by Relying Parties (RPs). The analysis is
performed from the perspective of an affected INR holder. The performed from the perspective of an affected INR holder. The
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 15, 2016. This Internet-Draft will expire on January 26, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 20
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Analysis of RPKI Repository Objects . . . . . . . . . . . . . 3 2. Analysis of RPKI Repository Objects . . . . . . . . . . . . . 3
2.1. ROA . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 6
2.2. Manifest . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Manifest . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Ghostbusters Record . . . . . . . . . . . . . . . . . . . 10 2.3. Certificate Revocation List . . . . . . . . . . . . . . . 11
2.4. Certificate Revocation List . . . . . . . . . . . . . . . 11 2.4. ROA . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5. CA Certificates . . . . . . . . . . . . . . . . . . . . . 14 2.5. Ghostbusters Record . . . . . . . . . . . . . . . . . . . 16
2.6. Router Certificates . . . . . . . . . . . . . . . . . . . 17 2.6. Router Certificates . . . . . . . . . . . . . . . . . . . 17
3. Analysis of Actions Relative to Scenarios . . . . . . . . . . 18 3. Analysis of Actions Relative to Scenarios . . . . . . . . . . 18
3.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . . 20 3.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . . 20
3.2. Scenario B . . . . . . . . . . . . . . . . . . . . . . . 20 3.2. Scenario B . . . . . . . . . . . . . . . . . . . . . . . 20
3.3. Scenario C . . . . . . . . . . . . . . . . . . . . . . . 21 3.3. Scenario C . . . . . . . . . . . . . . . . . . . . . . . 20
3.4. Scenario D . . . . . . . . . . . . . . . . . . . . . . . 21 3.4. Scenario D . . . . . . . . . . . . . . . . . . . . . . . 21
4. Security Considerations . . . . . . . . . . . . . . . . . . . 22 4. Security considerations . . . . . . . . . . . . . . . . . . . 21
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Normative References . . . . . . . . . . . . . . . . . . 22 7.1. Normative References . . . . . . . . . . . . . . . . . . 22
7.2. Informative References . . . . . . . . . . . . . . . . . 24 7.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
In the context of this document, any change to the Resource Public In the context of this document, any change to the Resource Public
Key Infrastructure (RPKI) [RFC6480] that results in a diminution of Key Infrastructure (RPKI) [RFC6480] that results in a diminution of
the set of Internet Numeric Resources (INRs) associated with an INR the set of Internet Numeric Resources (INRs) associated with an INR
holder contrary to the holder's wishes is termed "adverse". holder contrary to the holder's wishes is termed "adverse".
Additionally, when a ROA or router certificate is created that Additionally, when a ROA or router certificate is created that
"competes" with an existing ROA or router certificate (respectively), "competes" with an existing ROA or router certificate (respectively),
the creation of the new ROA or router certificate is considered the creation of the new ROA or router certificate may be adverse. (A
adverse. (A newer ROA competes with an older ROA if the newer ROA newer ROA competes with an older ROA if the newer ROA points to a
points to a different ASN and contains the same or a more specific different ASN, contains the same or a more specific prefix, and is
prefix. A newer router certificate competes with an older router issued by a different CA. A newer router certificate competes with
certificate if the newer one contains the same ASN and a different an older router certificate if the newer one contains the same ASN a
public key.) 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.
The SIDR WG is exploring proposals to address mistakes by RPKI The SIDR WG is exploring proposals to address mistakes by RPKI
Certification Authorities (CAs) and to accommodate INR transfers. Certification Authorities (CAs) and to accommodate INR transfers.
Mistakes are not the only way that adverse changes to RPKI data can Mistakes are not the only way that adverse changes to RPKI data can
arise. A CA or repository operator might be subject to an attack arise. A CA or repository operator might be subject to an attack
[RFC7132]. For a CA, if an attack allows an adversary to use the [RFC7132]. For a CA, if an attack allows an adversary to use the
private keys of that CA to sign RPKI objects, then the effect is private keys of that CA to sign RPKI objects, then the effect is
analogous to the CA making mistakes. There is also the possibility analogous to the CA making mistakes. There is also the possibility
that a CA or repository operator may be subject to legal measures that a CA or repository operator may be subject to legal measures
that compel them to generate "bogus" signed objects or remove that compel them to generate "bogus" signed objects or remove
legitimate repository data. In many cases, such actions may be hard legitimate repository data. In many cases, such actions may be hard
skipping to change at page 5, line 48 skipping to change at page 6, line 5
processing. processing.
The following sections examine how the actions enumerated above The following sections examine how the actions enumerated above
affect objects in the RPKI repository system. Each action is affect objects in the RPKI repository system. Each action is
addressed in order (Deletion, Suppression, Corruption, Modification, addressed in order (Deletion, Suppression, Corruption, Modification,
Revocation, and Injection) for each object, making it easy to see how Revocation, and Injection) for each object, making it easy to see how
each action has been considered with regard to each object. (For the each action has been considered with regard to each object. (For the
GhostBusters record we condensed the discussion of the actions GhostBusters record we condensed the discussion of the actions
because the impact is the same in each case.) because the impact is the same in each case.)
2.1. ROA 2.1. CA Certificates
In addition to the generic RPKI object syntax checks, ROA validation Every INR holder is represented by one or more CA certificates. An
requires that the signature on the ROA can be validated using the INR holder has multiple CA certificates if it holds resources
public key from the EE certificate embedded in the ROA [RFC6482]. It acquired from different sources. Also, every INR holder has more
also requires that the EE certificate be validated consistently with than one CA certificate during key rollover [RFC6489] and algorithm
the procedures described in [RFC6482] and [RFC6487]. Adverse actions rollover [RFC6916].
against a ROA can cause the following errors:
A-1.1 Deletion 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 pointer (SIA) to the publication point where the signed
objects associated with that CA can be found [RFC6487].
A-1.1.1 A ROA may be deleted from the indicated A CA certificate is a complex data structure and thus errors in that
publication point. The result is to void the structure may have different implications for RPs depending on the
binding between the prefix(es) and the AS number specific data that is in error.
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-1.2 Suppression Adverse actions against a CA certificate can cause the following
errors:
A-1.2.1 Publication of a newer ROA may be suppressed. If A-1.1 Deletion
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-1.2.2 If an INR holder intends to issue and publish two A-1.1.1 Deletion of a CA certificate would cause an RP to
(or more) new ROAs for the same address space, one not be able to locate signed objects generated by
(or more) of the new ROAs may be suppressed while that CA, except those that have been cached by the
the other is published. In this case, RPs will RP. Thus an RP would be unaware of changed or new
de-preference the suppressed prefix/ASN binding. (issued after the cached data) INR bindings
Suppression of the new ROA might cause traffic to asserted in subordinate ROAs, and the RP would be
flow to an ASN other than the one(s) intended by unable to validate new or changed router
the INR holder. 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.
A-1.2.3 If an INR holder intends to delete all ROAs for A-1.2 Suppression
the same address space, some of them may be
retained while the others are deleted. Preventing A-1.2.1 If publication of a CA certificate is suppressed,
the deletion of some ROAs can cause traffic to the impact depends on what changes appeared in the
continue to be delivered to the ASNs that were suppressed certificate. If the SIA value changed,
advertised by these ROAs. Deletion of all ROAs is the effect would be the same as in A-1.1 or 1.4.3.
consistent with a transfer of address space to a If the 3779 extensions in the suppressed
different INR holder, in a phased fashion. Thus certificate changed, the impact would be the same
this sort of attack could interfere with the as in 1.4.1. If the AIA extension changed in the
successful transfer of the affected address space suppressed certificate, the impact would be the
(until such time as the prefixes are removed from same as in 1.4.4.
the previous INR holder's CA certificate).
A-1.3 Corruption A-1.3 Corruption
A-1.3.1 A ROA may be corrupted. A corrupted ROA will be A-1.3.1 Corruption of a CA certificate will cause it to be
ignored by an RP, so the effect is essentially the rejected by RPs. In turn, this may cause
same as for A-1.1 and 1.5. A possible difference subordinate signed objects to become invalid. An
is that an RP may be alerted to the fact that the RP that has cached the subtree under the affected
ROA was corrupted, which might attract attention CA certificate may continue to view it as valid,
to the attack. 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 Modification
A-1.4.1 A ROA may be modified so that the Autonomous A-1.4.1 If a CA certificate is modified, but still
System Number (ASN) or one or more of the address conforms to the RPKI certificate profile
blocks in a ROA is different from the values the [RFC6485], it will be accepted by RPs. If an
INR holder intended for this ROA. (This action [RFC3779] extension in this certificate is changed
assumes that the modified ROA's ASN and address to exclude INRs that were previously present, then
ranges are authorized for use by the INR holder.) subordinate signed objects will become invalid if
This attack will cause RPs to de-preference the they rely on the excised INRs. If these objects
legitimate prefix/ASN binding intended by the INR are CA certificates, their subordinate signed
holder. 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 [I-D.ietf-sidr-bgpsec-protocol]
verifiable under these certificates will be
considered invalid.
A-1.4.2 If the SIA extension of a CA certificate is
modified to refer to another publication point,
this will cause an RP to look 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 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 co-exist with the old one for a
while, which may help distinguish this legitimate
activity from an adverse action.)
A-1.5 Revocation A-1.5 Revocation
A-1.5.1 A ROA may be revoked (by placing its EE A-1.5.1 If a CA certificate is revoked an RP will treat as
certificate on the CRL for the publication point). invalid all subordinate signed objects, both
This has the same effect as A-1.1. immediate and transitively. The effects are
essentially the same as described in A-3.4.2.
A-1.6 Injection A-1.6 Injection
A-1.6.1 A ROA expressing different bindings than those A-1.6.1 If a CA certificate is injected the impact will
published by the INR holder may be injected into a depend on the data contained in the injected
publication point. This action could authorize an certificate. Changes will generally be equivalent
additional ASN to advertise the specified prefix, to modification actions as described in A-1.4.
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-1.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.2. Manifest 2.2. Manifest
Each repository publication point contains a manifest [RFC6486]. The Each repository publication point contains a manifest [RFC6486]. The
RPKI incorporates manifests to enable RPs to detect suppression and/ RPKI incorporates manifests to enable RPs to detect suppression and/
or substitution of (more recent) publication point objects, as the or substitution of (more recent) publication point objects, as the
result of a mistake or attack. A manifest enumerates (by filename) result of a mistake or attack. A manifest enumerates (by filename)
all of the other signed objects at the publication point. The all of the other signed objects at the publication point. The
manifest also contains a hash of each enumerated file, to enable an 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 RP to determine if the named file content matches what the INR holder
skipping to change at page 9, line 10 skipping to change at page 10, line 6
A-2.1.1 A Manifest may be deleted from the indicated A-2.1.1 A Manifest may be deleted from the indicated
publication point. In this circumstance an RP may publication point. In this circumstance an RP may
elect to use the previous Manifest (if available), elect to use the previous Manifest (if available),
and may ignore any new/changed objects at the and may ignore any new/changed objects at the
publication point. The implications of this publication point. The implications of this
action are equivalent to suppression of action are equivalent to suppression of
publication of the objects that are not recognized publication of the objects that are not recognized
by RPs because the new objects are not present in by RPs because the new objects are not present in
the old Manifest. For example, a new ROA could be the old Manifest. For example, a new ROA could be
ignored (A-1.2). A newly issued CA certificate ignored (A-1.2). A newly issued CA certificate
might be ignored (A-5.1). A subordinate CA might be ignored (A-1.1). A subordinate CA
certificate that was revoked might still be viewed certificate that was revoked might still be viewed
as valid by RPs (A-4.1). A new or changed router as valid by RPs (A-4.1). A new or changed router
certificate might be ignored (A-6.2) as would a certificate might be ignored (A-6.2) as would a
revised Ghostbusters record (A-3.1). revised Ghostbusters record (A-4.1).
A-2.2 Suppression A-2.2 Suppression
A-2.2.1 Publication of a newer Manifest may be suppressed. A-2.2.1 Publication of a newer Manifest may be suppressed.
Suppression of a newer Manifest probably will Suppression of a newer Manifest probably will
cause an RP to rely on a cached Manifest (if cause an RP to rely on a cached Manifest (if
available). The older Manifest would not available). The older Manifest would not
enumerate newly added objects, and thus those enumerate newly added objects, and thus those
objects might be ignored by an RP, equivalent to objects might be ignored by an RP, equivalent to
deletion of those objects (A-1.1, A-3.1, A-4.1, deletion of those objects (A-1.1, A-3.1, A-4.1,
skipping to change at page 10, line 47 skipping to change at page 11, line 42
A-2.6 Injection A-2.6 Injection
A-2.6.1 A Manifest representing different objects may be A-2.6.1 A Manifest representing different objects may be
injected into a publication point. The effects injected into a publication point. The effects
are the same as for a modified Manifest (see are the same as for a modified Manifest (see
above). The impact will depend on the type of the above). The impact will depend on the type of the
affected object(s), and thus is discussed in the affected object(s), and thus is discussed in the
relevant section(s) for each object type. relevant section(s) for each object type.
2.3. Ghostbusters Record 2.3. Certificate Revocation List
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-3.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.
2.4. Certificate Revocation List
Each publication point contains a CRL that enumerates revoked (not Each publication point contains a CRL that enumerates revoked (not
yet expired) certificates issued by the CA associated with the yet expired) certificates issued by the CA associated with the
publication point [RFC6481]. publication point [RFC6481].
Adverse actions against a CRL can cause the following errors: Adverse actions against a CRL can cause the following errors:
A-4.1 Deletion A-3.1 Deletion
A-4.1.1 If a CRL is deleted, RPs will continue to use an A-3.1.1 If a CRL is deleted, RPs will continue to use an
older, previously fetched Certificate Revocation older, previously fetched Certificate Revocation
List. As a result, they will not be informed of List. As a result, they will not be informed of
any changes in revocation status of subordinate CA any changes in revocation status of subordinate CA
or router certificates or the EE certificates of or router certificates or the EE certificates of
signed objects, e.g., ROAs. This action is signed objects, e.g., ROAs. This action is
equivalent to corruption of a CRL, since a equivalent to corruption of a CRL, since a
corrupted CRL will not be accepted by an RP. corrupted CRL will not be accepted by an RP.
A-4.1.2 Deletion of a CRL could cause an RP to continue to A-3.1.2 Deletion of a CRL could cause an RP to continue to
accept a ROA that no longer expresses the intent accept a ROA that no longer expresses the intent
of an INR holder. As a result, an announcement of an INR holder. As a result, an announcement
for the affected prefixes would be viewed as for the affected prefixes would be viewed as
Valid, instead of NotFound or Invalid. In this Valid, instead of NotFound or Invalid. In this
case, the effect is analogous to A-1.2. case, the effect is analogous to A-5.2.
A-4.1.3 If a router certificate were revoked, and the CRL A-3.1.3 If a router certificate were revoked, and the CRL
were deleted, RPs would not be aware of the were deleted, RPs would not be aware of the
revocation. They might continue to accept the revocation. They might continue to accept the
old, revoked, router certificate. If the old, revoked, router certificate. If the
certificate had been revoked due to a compromise certificate had been revoked due to a compromise
of the router's private key, RPs would be of the router's private key, RPs would be
vulnerable to accepting routes signed by an vulnerable to accepting routes signed by an
unauthorized entity. unauthorized entity.
A-4.1.4 If a subordinate CA certificate were revoked on A-3.1.4 If a subordinate CA certificate were revoked on
the deleted CRL, the revocation would not take the deleted CRL, the revocation would not take
effect. This could interfere with a transfer of effect. This could interfere with a transfer of
address space from the subordinate CA, adversely address space from the subordinate CA, adversely
affecting routing to the new holder of the space. affecting routing to the new holder of the space.
A-4.2 Suppression A-3.2 Suppression
A-4.2.1 If publication of the most recent CRL is A-3.2.1 If publication of the most recent CRL is
suppressed, an RP will not be informed of the most suppressed, an RP will not be informed of the most
recent revocation status of subordinate CA or recent revocation status of subordinate CA or
router certificates or the EE certificates of router certificates or the EE certificates of
signed objects. If an EE certificate has been signed objects. If an EE certificate has been
revoked and the associated signed object is still revoked and the associated signed object is still
present in the publication point, an RP might present in the publication point, an RP might
mistakenly treat that object as valid. (This mistakenly treat that object as valid. (This
would happen if the object is still in the would happen if the object is still in the
manifest or the RP is configured to process valid manifest or the RP is configured to process valid
objects that are not on the manifest.) This type objects that are not on the manifest.) This type
of action is of special concern if the affected of action is of special concern if the affected
object is a ROA, a router certificate, or a object is a ROA, a router certificate, or a
subordinate CA certificate. The effects here are subordinate CA certificate. The effects here are
equivalent to CRL deletion (A-4.1), but equivalent to CRL deletion (A-3.1), but
suppression of a new CRL may not even be reported suppression of a new CRL may not even be reported
as an error, i.e., if the suppressed CRL were as an error, i.e., if the suppressed CRL were
issued before the NextUpdate time (of the previous issued before the NextUpdate time (of the previous
CRL). CRL).
A-4.3 Corruption A-3.3 Corruption
A-4.3.1 If a CRL is corrupted, an RP will reject it. If a A-3.3.1 If a CRL is corrupted, an RP will reject it. If a
prior CRL has not yet exceeded its NextUpdate prior CRL has not yet exceeded its NextUpdate
time, an RP will continue to use the prior CRL. time, an RP will continue to use the prior CRL.
Even if the prior CRL has passed the NextUpdate Even if the prior CRL has passed the NextUpdate
time, an RP may choose to continue to rely on the time, an RP may choose to continue to rely on the
prior CRL. The effects are essentially equivalent prior CRL. The effects are essentially equivalent
to suppression or deletion of a CRL (A-4.1, A-4.2) to suppression or deletion of a CRL (A-3.1,
A-3.2).
A-4.4 Modification A-3.4 Modification
A-4.4.1 If a CRL is modified to erroneously list a signed A-3.4.1 If a CRL is modified to erroneously list a signed
object's EE certificate as revoked, the object's EE certificate as revoked, the
corresponding object will be treated as invalid by corresponding object will be treated as invalid by
RPs, even if it is present in a publication point. RPs, even if it is present in a publication point.
If this object is a ROA, the (legitimate) binding If this object is a ROA, the (legitimate) binding
expressed by the ROA will be ignored by an RP (see expressed by the ROA will be ignored by an RP (see
A-1.5). If a CRL is modified to erroneously list A-5.5). If a CRL is modified to erroneously list
a router certificate as revoked, a path signature a router certificate as revoked, a path signature
associated with that certificate will be treated associated with that certificate will be treated
as Not Valid by RPs (see A-6.5). as Not Valid by RPs (see A-6.5).
A-4.4.2 If a CRL is modified to erroneously list a CA A-3.4.2 If a CRL is modified to erroneously list a CA
certificate as revoked, that CA and all certificate as revoked, that CA and all
subordinate signed objects will be treated as subordinate signed objects will be treated as
invalid by RPs. Depending on the location of the invalid by RPs. Depending on the location of the
affected CA in the hierarchy, these effects could affected CA in the hierarchy, these effects could
be very substantial, causing routes that should be be very substantial, causing routes that should be
Valid to be treated as NotFound. Valid to be treated as NotFound.
A-4.4.3 If a CRL is modified to omit a revoked EE, router, A-3.4.3 If a CRL is modified to omit a revoked EE, router,
or CA certificate, RPs likely will continue to or CA certificate, RPs likely will continue to
accept the revoked, signed object as valid. This accept the revoked, signed object as valid. This
contravenes the intent of the INR holder. If an contravenes the intent of the INR holder. If an
RP continues to accept a revoked ROA, it may make RP continues to accept a revoked ROA, it may make
routing decisions on now-invalid data. This could routing decisions on now-invalid data. This could
cause valid routes to be de-preferenced and cause valid routes to be de-preferenced and
invalid routes to continue to be accepted. invalid routes to continue to be accepted.
A-4.5 Revocation A-3.5 Revocation
A-4.5.1 A CRL cannot be revoked, per se, but it will fail A-3.5.1 A CRL cannot be revoked, per se, but it will fail
validation if the CA certificate under which it validation if the CA certificate under which it
was issued is revoked. See A-5.5 for a discussion was issued is revoked. See A-1.5 for a discussion
of that action. of that action.
A-4.6 Injection A-3.6 Injection
A-4.6.1 Insertion of a bogus CRL can have the same effects A-3.6.1 Insertion of a bogus CRL can have the same effects
as listed above for a modified CRL, depending on as listed above for a modified CRL, depending on
how the inserted CRL differs from the correct CRL. how the inserted CRL differs from the correct CRL.
2.5. CA Certificates 2.4. ROA
Every INR holder is represented by one or more CA certificates. An In addition to the generic RPKI object syntax checks, ROA validation
INR holder has multiple CA certificates if it holds resources requires that the signature on the ROA can be validated using the
acquired from different sources. Also, every INR holder has more public key from the EE certificate embedded in the ROA [RFC6482]. It
than one CA certificate during key rollover [RFC6489] and algorithm also requires that the EE certificate be validated consistently with
rollover [RFC6916]. the procedures described in [RFC6482] and [RFC6487]. Adverse actions
against a ROA can cause the following errors:
If a publication point is not a leaf in the RPKI hierarchy, then the A-4.1 Deletion
publication point will contain one or more CA certificates, each
representing a subordinate CA. Each subordinate CA certificate
contains a pointer (SIA) to the publication point where the signed
objects associated with that CA can be found [RFC6487].
A CA certificate is a complex data structure and thus errors in that A-4.1.1 A ROA may be deleted from the indicated
structure may have different implications for RPs depending on the publication point. The result is to void the
specific data that is in error. binding between the prefix(es) and the 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).
Adverse actions against a CA certificate can cause the following A-4.2 Suppression
errors:
A-5.1 Deletion 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-5.1.1 Deletion of a CA certificate would cause an RP to A-4.2.2 If an INR holder intends to issue and publish two
not be able to locate signed objects generated by (or more) new ROAs for the same address space, one
that CA, except those that have been cached by the (or more) of the new ROAs may be suppressed while
RP. Thus an RP would be unaware of changed or new the other is published. In this case, RPs will
(issued after the cached data) INR bindings de-preference the suppressed prefix/ASN binding.
asserted in subordinate ROAs, and the RP would be Suppression of the new ROA might cause traffic to
unable to validate new or changed router flow to an ASN other than the one(s) intended by
certificates. If the missed objects were intended the INR holder.
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.
A-5.2 Suppression 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-5.2.1 If publication of a CA certificate is suppressed, A-4.3 Corruption
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-5.1 or 5.4.3.
If the 3779 extensions in the suppressed
certificate changed, the impact would be the same
as in 5.4.1. If the AIA extension changed in the
suppressed certificate, the impact would be the
same as in 5.4.4.
A-5.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 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-5.3.1 Corruption of a CA certificate will cause it to be A-4.4 Modification
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-5.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-5.4.1 If a CA certificate is modified, but still A-4.5 Revocation
conforms to the RPKI certificate profile
[RFC6485], 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 [I-D.ietf-sidr-bgpsec-protocol]
verifiable under these certificates will be
considered invalid.
A-5.4.2 If an [RFC3779] extension in this certificate is A-4.5.1 A ROA may be revoked (by placing its EE
changed to include INRs that were previously certificate on the CRL for the publication point).
absent in this certificate, and are still absent This has the same effect as A-4.1.
in the issuer's certificate, then this certificate
will fail validation and be treated as invalid.
The impact of this is the same as in A-5.5.
A-5.4.3 If the SIA extension of a CA certificate is A-4.6 Injection
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-5.4.4 If the AIA extension in a CA certificate is A-4.6.1 A ROA expressing different bindings than those
modified, it would point to a different CA published by the INR holder may be injected into a
certificate, not the parent CA certificate. This publication point. This action could authorize an
extension is used only for path discovery, not additional ASN to advertise the specified prefix,
path validation. Path discovery in the RPKI is allowing that ASN to originate routes for the
usually performed on a top-down basis, starting prefix, thus enabling route origin spoofing. In
with TAs and recursively descending the RPKI this case, the injected ROA is considered to be in
hierarchy. Thus there may be no impact on the competition with any existing authorized ROAs for
ability of clients to acquire and validate the specified prefix.
certificates if the AIA is modified.
A-5.4.5 If the Subject Public Key Info (and Subject Key A-4.6.2 An injected ROA might express a different prefix
Identifier extension) in a CA certificate is for an ASN already authorized to originate a
modified to contain a public key corresponding to route, e.g., a longer prefix, which could enable
a private key held by the parent, the parent could that ASN to override other advertisements using
sign objects as children of the affected CA shorter prefixes. If there are other ROAs that
certificate. With this capability, the parent authorize different ASNs to advertise routes to
could replace the INR holder, issuing new signed the injected ROA's prefix, then the injected ROA
objects that would be accepted by RPs (as long as is in competition with these ROAs.
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.
A-5.5 Revocation 2.5. Ghostbusters Record
A-5.5.1 If a CA certificate is revoked an RP will treat as The Ghostbusters record [RFC6493] is a signed object that MAY be
invalid all subordinate signed objects, both included at a publication point, at the discretion of the INR holder
immediate and transitively. The effects are or publication point operator. The record is validated according to
essentially the same as described in A-4.4.2. [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.
A-5.6 Injection Adverse actions against a Ghostbusters record can cause the following
error:
A-5.6.1 If a CA certificate is injected the impact will A-5.1 Deletion, suppression, corruption, or revocation of a
depend on the data contained in the injected Ghostbusters record could prevent an RP from contacting the
certificate. Changes will generally be equivalent appropriate entity when a problem is detected by the RP.
to modification actions as described in A-5.4. 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.
2.6. Router Certificates 2.6. Router Certificates
Router certificates are used by RPs to verify signatures on Router certificates are used by RPs to verify signatures on
BGPsec_Path attributes carried in Update messages. BGPsec_Path attributes carried in Update messages.
Each AS is free to determine the granularity at which router Each AS is free to determine the granularity at which router
certificates are managed [I-D.ietf-sidr-bgpsec-pki-profiles]. Each certificates are managed [I-D.ietf-sidr-bgpsec-pki-profiles]. Each
participating AS is represented by one or more router certificates. participating AS is represented by one or more router certificates.
During key or algorithm rollover, multiple router certificates will During key or algorithm rollover, multiple router certificates will
skipping to change at page 18, line 33 skipping to change at page 18, line 30
inconsistent with the intent of the INR holder, inconsistent with the intent of the INR holder,
e.g., traffic might be routed via a different AS e.g., traffic might be routed via a different AS
than intended. than intended.
A-6.5 Revocation A-6.5 Revocation
A-6.5.1 If a router certificate were revoked, BGPsec_Path A-6.5.1 If a router certificate were revoked, BGPsec_Path
attributes verifiable using that certificate would attributes verifiable using that certificate would
not longer be considered valid. The impact would not longer be considered valid. The impact would
be the same as for a deleted certificate, as be the same as for a deleted certificate, as
described in A-6.1 described in A-6.1.
A-6.6 Injection A-6.6 Injection
A-6.6.1 Insertion of a router certificate could authorize A-6.6.1 Insertion of a router certificate could authorize
additional routers to sign BGPsec traffic for the additional routers to sign BGPsec traffic for the
targeted ASN, and thus undermine fundamental targeted ASN, and thus undermine fundamental
BGPsec security guarantees. If there are BGPsec security guarantees. If there are
existing, authorized router certificates for the existing, authorized router certificates for the
same ASN, then the injected router certificate is same ASN, then the injected router certificate is
in competition with these existing certificates. in competition with these existing certificates.
skipping to change at page 22, line 5 skipping to change at page 21, line 44
here includes those in Scenarios A, B, and C. Mistakes by the INR 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 holder, acted upon by the parent CA, can cause any of the actions
noted in Section 2. Actions unilaterally undertaken by the parent CA noted in Section 2. Actions unilaterally undertaken by the parent CA
also can have the same effect. A successful attack against the also can have the same effect. A successful attack against the
parent CA can effect all of the modification, revocation, or parent CA can effect all of the modification, revocation, or
injection actions noted in Section 2. An attack against the parent injection actions noted in Section 2. An attack against the parent
CA can also effect all of the deletion, suppression, or corruption CA can also effect all of the deletion, suppression, or corruption
actions noted in Section 2 (because the parent CA is managing the INR actions noted in Section 2 (because the parent CA is managing the INR
holder's publication point). holder's publication point).
4. Security Considerations 4. Security considerations
This informational document describes a threat model for the RPKI, This informational document describes a threat model for the RPKI,
focusing on mistakes by or attacks against CAs and independent focusing on mistakes by or attacks against CAs and independent
repository managers. It is intended to provide a basis for the repository managers. It is intended to provide a basis for the
design of future RPKI security mechanisms that seek to address the design of future RPKI security mechanisms that seek to address the
concerns associated with such actions. concerns associated with such actions.
The analysis in this document identifies a number of circumstances in The analysis in this document identifies a number of circumstances in
which attacks or errors can have significant impacts on routing. One which attacks or errors can have significant impacts on routing. One
ought not interpret this as a condemnation of the RPKI. It is only ought not interpret this as a condemnation of the RPKI. It is only
skipping to change at page 22, line 31 skipping to change at page 22, line 23
technology exhibits its own set of security problems, which are technology exhibits its own set of security problems, which are
discussed in [RFC7682]. discussed in [RFC7682].
5. IANA Considerations 5. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
6. Acknowledgements 6. Acknowledgements
The authors thank Richard Hansen and David Mandelberg for their The authors thank Richard Hansen and David Mandelberg for their
review, feedback and editorial assistance. extensive review, feedback and editorial assistance.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-sidr-bgpsec-overview] [I-D.ietf-sidr-bgpsec-overview]
Lepinski, M., "An Overview of BGPsec", draft-ietf-sidr- Lepinski, M. and S. Turner, "An Overview of BGPsec",
bgpsec-overview-07 (work in progress), June 2015. draft-ietf-sidr-bgpsec-overview-08 (work in progress),
June 2016.
[I-D.ietf-sidr-bgpsec-pki-profiles] [I-D.ietf-sidr-bgpsec-pki-profiles]
Reynolds, M. and S. Kent, "A Profile for BGPsec Router Reynolds, M., Turner, S., and S. Kent, "A Profile for
Certificates, Certificate Revocation Lists, and BGPsec Router Certificates, Certificate Revocation Lists,
Certification Requests", draft-ietf-sidr-bgpsec-pki- and Certification Requests", draft-ietf-sidr-bgpsec-pki-
profiles-16 (work in progress), March 2016. profiles-18 (work in progress), July 2016.
[I-D.ietf-sidr-bgpsec-protocol] [I-D.ietf-sidr-bgpsec-protocol]
Lepinski, M. and K. Sriram, "BGPsec Protocol Lepinski, M. and K. Sriram, "BGPsec Protocol
Specification", draft-ietf-sidr-bgpsec-protocol-15 (work Specification", draft-ietf-sidr-bgpsec-protocol-17 (work
in progress), March 2016. in progress), June 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, Addresses and AS Identifiers", RFC 3779,
DOI 10.17487/RFC3779, June 2004, DOI 10.17487/RFC3779, June 2004,
<http://www.rfc-editor.org/info/rfc3779>. <http://www.rfc-editor.org/info/rfc3779>.
skipping to change at page 25, line 19 skipping to change at page 25, line 13
<http://www.rfc-editor.org/info/rfc7682>. <http://www.rfc-editor.org/info/rfc7682>.
Authors' Addresses Authors' Addresses
Stephen Kent Stephen Kent
BBN Technologies BBN Technologies
10 Moulton St 10 Moulton St
Cambridge, MA 02138-1119 Cambridge, MA 02138-1119
USA USA
EMail: kent@bbn.com Email: kent@bbn.com
Di Ma Di Ma
ZDNS ZDNS
4 South 4th St. 4 South 4th St. Zhongguancun
Zhongguancun
Haidian, Beijing 100190 Haidian, Beijing 100190
China China
EMail: madi@zdns.cn Email: madi@zdns.cn
 End of changes. 75 change blocks. 
288 lines changed or deleted 290 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/