draft-ietf-sidr-adverse-actions-04.txt   rfc8211.txt 
SIDR S. Kent Internet Engineering Task Force (IETF) S. Kent
Internet-Draft BBN Technologies Request for Comments: 8211 BBN Technologies
Intended status: Informational D. Ma Category: Informational D. Ma
Expires: July 16, 2017 ZDNS ISSN: 2070-1721 ZDNS
January 12, 2017 September 2017
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-04
Abstract Abstract
This document analyzes actions by or against a CA or independent This document analyzes actions by or against a Certification
repository manager in the RPKI that can adversely affect the Internet Authority (CA) or an independent repository manager in the RPKI that
Number Resources (INRs) associated with that CA or its subordinate can adversely affect the Internet Number Resources (INRs) associated
CAs. The analysis is done from the perspective of an affected INR with that CA or its subordinate CAs. The analysis is done from the
holder. The analysis is based on examination of the data items in perspective of an affected INR holder. The analysis is based on
the RPKI repository, as controlled by a CA (or independent repository examination of the data items in the RPKI repository, as controlled
manager) and fetched by Relying Parties (RPs). The analysis does not by a CA (or an independent repository manager) and fetched by Relying
purport to be comprehensive; it does represent an orderly way to Parties (RPs). The analysis does not purport to be comprehensive; it
analyze a number of ways that errors by or attacks against a CA or does represent an orderly way to analyze a number of ways that errors
repository manager can affect the RPKI and routing decisions based on by or attacks against a CA or repository manager can affect the RPKI
RPKI data. and routing decisions based on RPKI data.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It has been approved for publication by the Internet
time. It is inappropriate to use Internet-Drafts as reference Engineering Steering Group (IESG). Not all documents approved by the
material or to cite them other than as "work in progress." IESG are a candidate for any level of Internet Standard; see
Section 2 of RFC 7841.
This Internet-Draft will expire on July 16, 2017. 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.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Analysis of RPKI Repository Objects . . . . . . . . . . . . . 3 2. Analysis of RPKI Repository Objects . . . . . . . . . . . . . 4
2.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 5 2.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 6
2.2. Manifest . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Manifest . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Certificate Revocation List . . . . . . . . . . . . . . . 11 2.3. Certificate Revocation List . . . . . . . . . . . . . . . 12
2.4. ROA . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.4. ROA . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5. Ghostbusters Record . . . . . . . . . . . . . . . . . . . 16 2.5. Ghostbusters Record . . . . . . . . . . . . . . . . . . . 17
2.6. Router Certificates . . . . . . . . . . . . . . . . . . . 17 2.6. Router Certificates . . . . . . . . . . . . . . . . . . . 18
3. Analysis of Actions Relative to Scenarios . . . . . . . . . . 18 3. Analysis of Actions Relative to Scenarios . . . . . . . . . . 19
3.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . . 20 3.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . . 21
3.2. Scenario B . . . . . . . . . . . . . . . . . . . . . . . 20 3.2. Scenario B . . . . . . . . . . . . . . . . . . . . . . . 21
3.3. Scenario C . . . . . . . . . . . . . . . . . . . . . . . 20 3.3. Scenario C . . . . . . . . . . . . . . . . . . . . . . . 21
3.4. Scenario D . . . . . . . . . . . . . . . . . . . . . . . 21 3.4. Scenario D . . . . . . . . . . . . . . . . . . . . . . . 22
4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 4. Security Considerations . . . . . . . . . . . . . . . . . . . 22
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.1. Normative References . . . . . . . . . . . . . . . . . . 23
7.1. Normative References . . . . . . . . . . . . . . . . . . 22 6.2. Informative References . . . . . . . . . . . . . . . . . 25
7.2. Informative References . . . . . . . . . . . . . . . . . 24 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
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 diminishes the set of Key Infrastructure (RPKI) [RFC6480] that diminishes the set of
Internet Number Resources (INRs) associated with an INR holder, and Internet Number Resources (INRs) associated with an INR holder, and
that is contrary to the holder's wishes, is termed "adverse". This that is contrary to the holder's wishes, is termed "adverse". This
analysis is done from the perspective of an affected INR holder. An analysis is done from the perspective of an affected INR holder. An
action that results in an adverse charge (as defined above), may be 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 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 error by or an attack on a repository operator. Note that the CA
that allocated the affected INRs may be acting in accordance with that allocated the affected INRs may be acting in accordance with
established policy, and thus the change may be contractually established policy; thus, the change may be contractually justified
justified, even though viewed as adverse by the INR holder. This even though viewed as adverse by the INR holder. This document
document examines the implications of adverse actions within the RPKI examines the implications of adverse actions within the RPKI with
with respect to INRs irrespective of the cause of the actions. respect to INRs, irrespective of the cause of the actions.
Additionally, when a ROA or router certificate is created that Additionally, when a Route Origin Authorization (ROA) or router
"competes" with an existing ROA or router certificate (respectively), certificate is created that "competes" with an existing ROA or router
the creation of the new ROA or router certificate may be adverse. (A certificate (respectively), the creation of the new ROA or router
newer ROA competes with an older ROA if the newer ROA points to a certificate may be adverse. (A newer ROA competes with an older ROA
different ASN, contains the same or a more specific prefix, and is if the newer ROA points to a different Autonomous System Number
issued by a different CA. A newer router certificate competes with (ASN), contains the same or a more specific prefix, and is issued by
an older router certificate if the newer one contains the same ASN a 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 different public key, and is issued by a different CA.) Note that
transferring resources, or changing of upstream providers may yield transferring resources or changing of upstream providers may yield
competing ROAs and/or router certificates, under some circumstances. competing ROAs and/or router certificates under some circumstances.
Thus not all instances of competition are adverse actions. Thus, not all instances of competition are adverse actions.
As noted above, adverse changes to RPKI data may arise due to several 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 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 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 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. objects, then the effect is analogous to the CA making mistakes.
There is also the possibility that a CA or repository operator may be 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 subject to legal measures that compel them to make adverse changes to
RPKI data. In many cases, such actions may be hard to distinguish RPKI data. In many cases, such actions may be hard to distinguish
from mistakes or attacks, other than with respect to the time from mistakes or attacks, other than with respect to the time
required to remedy the adverse action. (Presumably the CA will take required to remedy the adverse action. (Presumably, the CA will take
remedial action when a mistake or an attack is detected, so the remedial action when a mistake or an attack is detected, so the
effects are similar in these cases. If a CA has been legally effects are similar in these cases. If a CA has been legally
compelled to effect an adverse change, remediation will likely not be compelled to effect an adverse change, remediation will likely not be
swift.) swift.)
This document analyzes the various types of actions by a CA (or This document analyzes the various types of actions by a CA (or an
independent repository operator) that can adversely affect the INRs independent repository operator) that can adversely affect the INRs
associated with that CA, as well as the INRs of subordinate CAs. The 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 analysis is based on examination of the data items in the RPKI
repository, as controlled by a CA (or independent repository repository, as controlled by a CA (or an independent repository
operator) and fetched by Relying Parties (RPs). operator) and fetched by RPs.
2. Analysis of RPKI Repository Objects 2. Analysis of RPKI Repository Objects
This section enumerates the RPKI repository system objects and This section enumerates the RPKI repository system objects and
examines how changes to them affect Route Origination Authorizations examines how changes to them affect Route Origin Authorizations
(ROAs) and router certificate validation. Identifiers are assigned (ROAs) and router certificate validation. Identifiers are assigned
to errors for reference by later sections of this document. Note to errors for reference by later sections of this document. Note
that not all adverse actions may be encompassed by this taxonomy. that not all adverse actions may be encompassed by this taxonomy.
The RPKI repository [RFC6481] contains a number of (digitally signed) The RPKI repository [RFC6481] contains a number of (digitally signed)
objects that are fetched and processed by RPs. Until the deployment objects that are fetched and processed by RPs. Until the deployment
of BGPsec [I-D.ietf-sidr-bgpsec-protocol], the principal goal of the of BGPsec [RFC8205], the principal goal of the RPKI is to enable an
RPKI is to enable an RP to validate ROAs [RFC6482]. A ROA binds RP to validate ROAs [RFC6482]. A ROA binds address space to an ASN.
address space to an Autonomous System Number (ASN). A ROA can be A ROA can be used to verify BGP announcements with respect to route
used to verify BGP announcements with respect to route origin origin [RFC6483]. The most important objects in the RPKI for origin
[RFC6483]. The most important objects in the RPKI for origin
validation are ROAs; all of the other RPKI objects exist to enable validation are ROAs; all of the other RPKI objects exist to enable
the validation of ROAs in a fashion consistent with the INR the validation of ROAs in a fashion consistent with the INR
allocation system. Thus errors that result in changes to a ROA, or 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 to RPKI objects needed to validate a ROA, can cause RPs to reach
different (from what was intended) conclusions about the validity of different (from what was intended) conclusions about the validity of
the bindings expressed in a ROA. the bindings expressed in a ROA.
When BGPsec is deployed, router certificates When BGPsec is deployed, router certificates [RFC8209] will be added
[I-D.ietf-sidr-bgpsec-pki-profiles] will be added to repository to repository publication points. These are end entity (EE)
publication points. These are End-Entity (EE) certificates used to certificates used to verify signatures applied to BGP update data and
verify signatures applied to BGP update data, to enable path to enable path validation [RFC8205]. Router certificates are as
validation [I-D.ietf-sidr-bgpsec-protocol]. Router certificates are important to path validation as ROAs are to origin validation.
as important to path validation as ROAs are to origin validation.
The objects contained in the RPKI repository are of two types: The objects contained in the RPKI repository are of two types:
conventional PKI objects (certificates and Certificate Revocation conventional PKI objects (certificates and Certificate Revocation
Lists (CRLs)) and RPKI-specific signed objects. The latter make use Lists (CRLs)) and RPKI-specific signed objects. The latter make use
of a common encapsulation format [RFC6488] based on the Cryptographic of a common encapsulation format [RFC6488] based on the Cryptographic
Message Syntax (CMS) [RFC5652]. A syntax error in this common format 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 will cause an RP to reject the object, e.g., a ROA or manifest, as
invalid. invalid.
Adverse actions take several forms: Adverse actions take several forms:
* Deletion (D) is defined as removing an object from a * Deletion (D) is defined as removing an object from a
publication point, without the permission of the INR holder. publication point, without the permission of the INR holder.
* Suppression (S) is defined as not deleting an object, or not * Suppression (S) is defined as not deleting an object, or not
publishing an object, as intended by an INR holder. This publishing an object, as intended by an INR holder. This
action also includes retaining a prior version of an object in action also includes retaining a prior version of an object in
a publication point when a newer version is available for a publication point when a newer version is available for
publication. publication.
* Corruption (C) is defined as modification of a signed object in * Corruption (C) is defined as modification of a signed object in
a fashion not requiring access to the private key used to sign a fashion not requiring access to the private key used to sign
the object. Thus a corrupted object will not carry a valid the object. Thus, a corrupted object will not carry a valid
signature. Implicitly, the corrupted object replaces the signature. Implicitly, the corrupted object replaces the
legitimate version. legitimate version.
* Modification (M) is defined as publishing a syntactically * Modification (M) is defined as publishing a syntactically
valid, verifiable version of an object that differs from the valid, verifiable version of an object that differs from the
(existing) version authorized by the INR holder. Implicitly, (existing) version authorized by the INR holder. Implicitly,
the legitimate version of the affected object is deleted and the legitimate version of the affected object is deleted and
replaced by the modified object. replaced by the modified object.
* Revocation (R) is defined as revoking a certificate (EE or CA) * Revocation (R) is defined as revoking a certificate (EE or CA)
by placing its serial number on the appropriate CRL, without by placing its Serial Number on the appropriate CRL, without
authorization of the INR holder. authorization of the INR holder.
* Injection (I) is defined as introducing an instance of a signed * Injection (I) is defined as introducing an instance of a signed
object into a publication point (without authorization of the object into a publication point (without authorization of the
INR holder). It assumes that the signature on the object will INR holder). It assumes that the signature on the object will
be viewed as valid by RPs. be viewed as valid by RPs.
The first three of these actions (deletion, suppression, and The first three of these actions (deletion, suppression, and
corruption) can be effected by any entity that manages the corruption) can be effected by any entity that manages the
publication point of the affected INR holder. Also, an entity with publication point of the affected INR holder. Also, an entity with
skipping to change at page 5, line 28 skipping to change at page 5, line 40
repository can effect these actions with respect to the RP in repository can effect these actions with respect to the RP in
question. question.
The latter three actions (modification, revocation, and injection) The latter three actions (modification, revocation, and injection)
nominally require access to the private key of the INR holder. 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 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 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 different public key, matching a private key to which the parent CA
has access. The CA could generate new signed objects using the has access. The CA could generate new signed objects using the
private key associated with the reissued certificate, and publish private key associated with the reissued certificate and publish
these objects at a location of its choosing. these objects at a location of its choosing.
Most of these actions may be performed independently or in Most of these actions may be performed independently or in
combination with one another. For example, a ROA may be revoked and combination with one another. For example, a ROA may be revoked and
deleted or revoked and replaced with a modified ROA. Where deleted or revoked and replaced with a modified ROA. Where
appropriate, the analysis of adverse actions will distinguish between appropriate, the analysis of adverse actions will distinguish between
individual actions, or combinations thereof, that yield different individual actions, or combinations thereof, that yield different
outcomes for RPs. Recall that the focus of the analysis is the outcomes for RPs. Recall that the focus of the analysis is the
impact on ROAs and router certificates, with respect to RP impact on ROAs and router certificates, with respect to RP
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 [RFC6493], we condensed the discussion of the
because the impact is the same in each case.) actions because the impact is the same in each case.)
2.1. CA Certificates 2.1. CA Certificates
Every INR holder is represented by one or more CA certificates. An Every INR holder is represented by one or more CA certificates. An
INR holder has multiple CA certificates if it holds resources INR holder has multiple CA certificates if it holds resources
acquired from different sources. Also, every INR holder has more acquired from different sources. Also, every INR holder has more
than one CA certificate during key rollover [RFC6489] and algorithm than one CA certificate during key rollover [RFC6489] and algorithm
rollover [RFC6916]. rollover [RFC6916].
If a publication point is not a leaf in the RPKI hierarchy, then the If a publication point is not a "leaf" in the RPKI hierarchy, then
publication point will contain one or more CA certificates, each the publication point will contain one or more CA certificates, each
representing a subordinate CA. Each subordinate CA certificate representing a subordinate CA. Each subordinate CA certificate
contains a pointer (SIA) to the publication point where the signed contains a Subject Information Access (SIA) pointer to the
objects associated with that CA can be found [RFC6487]. 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 CA certificate is a complex data structure; thus, errors in that
structure may have different implications for RPs depending on the structure may have different implications for RPs depending on the
specific data that is in error. specific data that is in error.
Adverse actions against a CA certificate can cause the following Adverse actions against a CA certificate can cause the following
errors: errors:
A-1.1 Deletion A-1.1 Deletion
A-1.1.1 Deletion of a CA certificate would cause an RP to A-1.1.1 Deletion of a CA certificate would cause an RP to
not be able to locate signed objects generated by not be able to locate signed objects generated by
that CA, except those that have been cached by the that CA, except those that have been cached by the
RP. Thus an RP would be unaware of changed or new RP. Thus, an RP would be unaware of changed or
(issued after the cached data) INR bindings new (issued after the cached data) INR bindings
asserted in subordinate ROAs, and the RP would be asserted in subordinate ROAs, and the RP would be
unable to validate new or changed router unable to validate new or changed router
certificates. If the missed objects were intended certificates. If the missed objects were intended
to replace ROAs or router certificates prior to to replace ROAs or router certificates prior to
expiration, then when those objects expire, RPs expiration, then when those objects expire, RPs
may cease to view them as valid. As a result, may cease to view them as valid. As a result,
valid routes may be viewed as NotFound or Invalid. valid routes may be viewed as NotFound or Invalid.
A-1.2 Suppression A-1.2 Suppression
A-1.2.1 If publication of a CA certificate is suppressed, A-1.2.1 If publication of a CA certificate is suppressed,
the impact depends on what changes appeared in the the impact depends on what changes appeared in the
suppressed certificate. If the SIA value changed, suppressed certificate. If the SIA value changed,
the effect would be the same as in A-1.1 or the effect would be the same as in A-1.1 or
A-1.4.3. If the [RFC3779] extensions in the A-1.4.3. If the [RFC3779] extensions in the
suppressed certificate changed, the impact would suppressed certificate changed, the impact would
be the same as in A-1.4.1. If the AIA extension be the same as in A-1.4.1. If the Authority
changed in the suppressed certificate, the impact Information Access (AIA) extension changed in the
would be the same as in A-1.4.4. Suppression of a suppressed certificate, the impact would be the
renewed/re-issued certificate may cause an old same as in A-1.4.4. Suppression of a renewed/
certificate to expire and thus be rejected by RPs. re-issued certificate may cause an old certificate
to expire and thus be rejected by RPs.
A-1.3 Corruption A-1.3 Corruption
A-1.3.1 Corruption of a CA certificate will cause it to be A-1.3.1 Corruption of a CA certificate will cause it to be
rejected by RPs. In turn, this may cause rejected by RPs. In turn, this may cause
subordinate signed objects to become invalid. An subordinate signed objects to become invalid. An
RP that has cached the subtree under the affected RP that has cached the subtree under the affected
CA certificate may continue to view it as valid, CA certificate may continue to view it as valid,
until objects expire. But changed or new objects until objects expire. But changed or new objects
might not be retrieved, depending on details of might not be retrieved, depending on details of
the design of the RP software. Thus this action the design of the RP software. Thus, this action
may be equivalent to suppressing changes to the may be equivalent to suppressing changes to the
affected subtree. affected subtree.
A-1.4 Modification A-1.4 Modification
A-1.4.1 If a CA certificate is modified, but still A-1.4.1 If a CA certificate is modified but still conforms
conforms to the RPKI certificate profile to the RPKI certificate profile [RFC7935], it will
[RFC7935], it will be accepted by RPs. If an be accepted by RPs. If an [RFC3779] extension in
[RFC3779] extension in this certificate is changed this certificate is changed to exclude INRs that
to exclude INRs that were previously present, then were previously present, then subordinate signed
subordinate signed objects will become invalid if objects will become invalid if they rely on the
they rely on the excised INRs. If these objects excised INRs. If these objects are CA
are CA certificates, their subordinate signed certificates, their subordinate signed objects
objects will be treated as invalid. If the will be treated as invalid. If the objects are
objects are ROAs, the binding expressed by the ROAs, the binding expressed by the affected ROAs
affected ROAs will be ignored by RPs. If the will be ignored by RPs. If the objects are router
objects are router certificates, BGPsec_Path certificates, BGPsec_PATH attributes [RFC8205]
attributes [I-D.ietf-sidr-bgpsec-protocol]
verifiable under these certificates will be verifiable under these certificates will be
considered invalid. considered invalid.
A-1.4.2 If the SIA extension of a CA certificate is A-1.4.2 If the SIA extension of a CA certificate is
modified to refer to another publication point, modified to refer to another publication point,
this will cause an RP to look at another location this will cause an RP to look at another location
for subordinate objects. This could cause RPs to for subordinate objects. This could cause RPs to
not acquire the objects that the INR holder not acquire the objects that the INR holder
intended to be retrieved - manifests, ROAs, router intended to be retrieved -- manifests, ROAs,
certificates, Ghostbuster records, or any router certificates, Ghostbuster Records, or any
subordinate CA certificates associated with that subordinate CA certificates associated with that
CA. If the objects at this new location contain CA. If the objects at this new location contain
invalid signatures or appear to be corrupted, they invalid signatures or appear to be corrupted, they
may be rejected. In this case, cached versions of may be rejected. In this case, cached versions of
the objects may be viewed as valid by an RP, until the objects may be viewed as valid by an RP, until
they expire. If the objects at the new location they expire. If the objects at the new location
have valid signatures and pass path validation have valid signatures and pass path validation
checks, they will replace the cached objects, checks, they will replace the cached objects,
effectively replacing the INR holder's objects. effectively replacing the INR holder's objects.
A-1.4.3 If the AIA extension in a CA certificate is A-1.4.3 If the AIA extension in a CA certificate is
modified, it would point to a different CA modified, it would point to a different CA
certificate, not the parent CA certificate. This certificate, not the parent CA certificate. This
extension is used only for path discovery, not extension is used only for path discovery, not
path validation. Path discovery in the RPKI is path validation. Path discovery in the RPKI is
usually performed on a top-down basis, starting usually performed on a top-down basis, starting
with TAs and recursively descending the RPKI with trust anchors (TAs) and recursively
hierarchy. Thus there may be no impact on the descending the RPKI hierarchy. Thus, there may be
ability of clients to acquire and validate no impact on the ability of clients to acquire and
certificates if the AIA is modified. validate certificates if the AIA is modified.
A-1.4.4 If the Subject Public Key Info (and Subject Key A-1.4.4 If the Subject Public Key Info (and Subject Key
Identifier extension) in a CA certificate is Identifier extension) in a CA certificate is
modified to contain a public key corresponding to modified to contain a public key corresponding to
a private key held by the parent, the parent could a private key held by the parent, the parent could
sign objects as children of the affected CA sign objects as children of the affected CA
certificate. With this capability, the parent certificate. With this capability, the parent
could replace the INR holder, issuing new signed could replace the INR holder, issuing new signed
objects that would be accepted by RPs (as long as objects that would be accepted by RPs (as long as
they do not violate the path validation criteria). they do not violate the path validation criteria).
This would enable the parent to effect This would enable the parent to effect
modification, revocation, and injection actions modification, revocation, and injection actions
against all of the objects under the affected CA against all of the objects under the affected CA
certificate, including subordinate CA certificate, including subordinate CA
certificates. (Note that key rollover also yields certificates. (Note that key rollover also yields
a new CA certificate. However, the new a new CA certificate. However, the new
certificate will co-exist with the old one for a certificate will coexist with the old one for a
while, which may help distinguish this legitimate while, which may help distinguish this legitimate
activity from an adverse action.) activity from an adverse action.)
A-1.5 Revocation A-1.5 Revocation
A-1.5.1 If a CA certificate is revoked an RP will treat as A-1.5.1 If a CA certificate is revoked, an RP will treat
invalid all subordinate signed objects, both as invalid all subordinate signed objects, both
immediate and transitively. The effects are immediate and transitive. The effects are
essentially the same as described in A-3.4.2. essentially the same as described in A-3.4.2.
A-1.6 Injection A-1.6 Injection
A-1.6.1 If a CA certificate is injected the impact will A-1.6.1 If a CA certificate is injected, the impact will
depend on the data contained in the injected depend on the data contained in the injected
certificate. Changes will generally be equivalent certificate. Changes will generally be equivalent
to modification actions as described in A-1.4. to modification actions as described in A-1.4.
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
RP to determine if the named file content matches what the INR holder to determine if the named file content matches what the INR holder
identified in the manifest. identified in the manifest.
A manifest is an RPKI signed object, so it is validated as per 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 [RFC6488]. If a manifest is modified in a way that causes any of
these checks to fail, the manifest will be considered invalid. these checks to fail, the manifest will be considered invalid.
Suppression of a manifest itself (indicated by a stale manifest) also Suppression of a manifest itself (indicated by a stale manifest) can
can cause an RP to not detect suppression of other signed objects at also cause an RP to not detect suppression of other signed objects at
the publication point. (Note that if a Manifest's EE certificate the publication point. (Note that if a manifest's EE certificate
expires at the time that the Manifest is scheduled to be replaced, a expires at the time that the manifest is scheduled to be replaced, a
delay in publication will cause the Manifest to become invalid, not delay in publication will cause the manifest to become invalid, not
merely stale. This very serious outcome should be avoided, e.g., by merely stale. This very serious outcome should be avoided, e.g., by
making the Manifest EE certificate's notAfter value the same as that 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 of the CA certificate under which it was issued). If a signed object
at a publication point can be validated (using the rules applicable at a publication point can be validated (using the rules applicable
for that object type), then an RP may accept that object, even if 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 there is no matching entry for it on the manifest. However, it
appears that most RP software ignores publication point data that appears that most RP software ignores publication point data that
fails to match Manifest entries (at the time this document was fails to match manifest entries (at the time this document was
written). written).
Corruption, suppression, modification, or deletion of a manifest Corruption, suppression, modification, or deletion of a manifest
might not affect RP processing of other publication point objects, as might not affect RP processing of other publication point objects, as
specified in [RFC6486]. However, as noted above, many RP specified in [RFC6486]. However, as noted above, many RP
implementations ignore objects that are present at a publication implementations ignore objects that are present at a publication
point but not listed in a valid Manifest. Thus the following actions point but not listed in a valid manifest. Thus, the following
against a manifest can impact RP processing: actions against a manifest can impact RP processing:
A-2.1 Deletion A-2.1 Deletion
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
elect to use the previous Manifest (if available), may elect to use the previous manifest (if
and may ignore any new/changed objects at the available) and may ignore any new/changed objects
publication point. The implications of this at the publication point. The implications of
action are equivalent to suppression of this 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-1.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-4.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; thus, those objects
objects might be ignored by an RP, equivalent to might be ignored by an RP, which is 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,
A-5.1, A-6.1). A-5.1, and A-6.1).
A-2.3 Corruption A-2.3 Corruption
A-2.3.1 A Manifest may be corrupted. A corrupted Manifest A-2.3.1 A manifest may be corrupted. A corrupted manifest
will be rejected by RPs. This may cause RPs to will be rejected by RPs. This may cause RPs to
rely on a previous manifest, with the same impact rely on a previous manifest, with the same impact
as A-2.2. If an RP does not revert to using a as A-2.2. If an RP does not revert to using a
cached Manifest, the impact of this action is very cached manifest, the impact of this action is very
severe, i.e., all publication point objects severe, i.e., all publication point objects will
probably will be viewed as invalid, including probably be viewed as invalid, including
subordinate tree objects. This is equivalent to subordinate tree objects. This is equivalent to
revoking or deleting an entire subtree (see revoking or deleting an entire subtree (see
A-4.4.2). A-4.4.2).
A-2.4 Modification A-2.4 Modification
A-2.4.1 A Manifest may be modified to remove one or more A-2.4.1 A manifest may be modified to remove one or more
objects. Because the modified Manifest is viewed objects. Because the modified manifest is viewed
as valid by RPs, any objects that were removed may as valid by RPs, any objects that were removed may
be ignored by RPs. This is equivalent to deleting be ignored by RPs. This is equivalent to deleting
these objects from the repository. The impact of these objects from the repository. The impact of
this action will vary, depending on which objects this action will vary, depending on which objects
are (effectively) removed. However, the impact is are (effectively) removed. However, the impact is
equivalent to deletion of the object in question, equivalent to deletion of the object in question,
(A-1.1, A-3.1, A-4.1, A-5.1, A-6.1). (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 A-2.4.2 A manifest may be modified to add one or more
objects. If an added object has a valid signature objects. If an added object has a valid signature
(and is non-expired), it will be accepted by RPs (and is not expired), it will be accepted by RPs
and processed accordingly. If the added object and processed accordingly. If the added object
was previously deleted by the INR holder, this was previously deleted by the INR holder, this
action is equivalent to suppressing deletion of action is equivalent to suppressing deletion of
that object. If the object is newly created, or that object. If the object is newly created or
modified, it is equivalent to a modification or modified, it is equivalent to a modification or
injection action for the type of object in injection action for the type of object in
question, and thus is discussed in the relevant question and is thus discussed in the relevant
section for those actions for the object type. section for those actions for the object type.
A-2.4.3 A Manifest may be modified to list an incorrect A-2.4.3 A manifest may be modified to list an incorrect
hash for one or more objects. An object with an hash for one or more objects. An object with an
incorrect hash may be ignored by an RP. Thus the incorrect hash may be ignored by an RP. Thus, the
effect may be equivalent to corrupting the object effect may be equivalent to corrupting the object
in question, although the error reported by RP in question, although the error reported by RP
software would differ from that reported for a software would differ from that reported for a
corrupted object. (The Manifest specifications do corrupted object. (The manifest specifications do
not require an RP to ignore an object that has a not require an RP to ignore an object that has a
valid signature and that is not revoked or valid signature and that is not revoked or
expired, but for which the hash doesn't match the expired, but for which the hash doesn't match the
object. However, an RP may elect to do so.) object. However, an RP may elect to do so.)
A-2.5 Revocation A-2.5 Revocation
A-2.5.1 A Manifest may be revoked (by including its EE A-2.5.1 A manifest may be revoked (by including its EE
certificate on the CRL for the publication point). certificate on the CRL for the publication point).
A revoked Manifest will be ignored by an RP, which A revoked manifest will be ignored by an RP, which
probably would revert to an older (cached) probably would revert to an older (cached)
Manifest. The implications for RPs are equivalent manifest. The implications for RPs are equivalent
to A-2.1, with regard to new/changed objects. to A-2.1 with regard to new/changed objects.
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 is thus discussed in the
relevant section(s) for each object type. relevant section(s) for each object type.
2.3. Certificate Revocation List 2.3. 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:
skipping to change at page 12, line 17 skipping to change at page 12, line 40
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-3.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-5.2. case, the effect is analogous to A-5.2.
A-3.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-3.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-3.2 Suppression A-3.2 Suppression
A-3.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 a 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 if the RP is configured to process
objects that are not on the manifest.) This type valid objects that are not on the manifest.) This
of action is of special concern if the affected type of action is of special concern if the
object is a ROA, a router certificate, or a affected object is a ROA, a router certificate, or
subordinate CA certificate. The effects here are a subordinate CA certificate. The effects here
equivalent to CRL deletion (A-3.1), but are 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-3.3 Corruption A-3.3 Corruption
A-3.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-3.1, to suppression or deletion of a CRL (A-3.1 and
A-3.2). A-3.2).
A-3.4 Modification A-3.4 Modification
A-3.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
skipping to change at page 13, line 40 skipping to change at page 14, line 27
A-3.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-3.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 will likely 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-3.5 Revocation A-3.5 Revocation
A-3.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-1.5 for a discussion was issued is revoked. See A-1.5 for a discussion
of that action. of that action.
A-3.6 Injection A-3.6 Injection
A-3.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.
skipping to change at page 14, line 26 skipping to change at page 15, line 18
requires that the signature on the ROA can be validated using the requires that the signature on the ROA can be validated using the
public key from the EE certificate embedded in the ROA [RFC6482]. It public key from the EE certificate embedded in the ROA [RFC6482]. It
also requires that the EE certificate be validated consistently with also requires that the EE certificate be validated consistently with
the procedures described in [RFC6482] and [RFC6487]. Adverse actions the procedures described in [RFC6482] and [RFC6487]. Adverse actions
against a ROA can cause the following errors: against a ROA can cause the following errors:
A-4.1 Deletion A-4.1 Deletion
A-4.1.1 A ROA may be deleted from the indicated A-4.1.1 A ROA may be deleted from the indicated
publication point. The result is to void the publication point. The result is to void the
binding between the prefix(es) and the AS number binding between the prefix(es) and the Autonomous
in the ROA. An RP that previously viewed this System (AS) number in the ROA. An RP that
binding as authentic will now not have any previously viewed this binding as authentic will
evidence about its validity. For origin now not have any evidence about its validity. For
validation, this means that a legitimate route origin validation, this means that a legitimate
will be treated as NotFound (if there are no other route will be treated as NotFound (if there are no
ROAs for the same prefix) or Invalid (if there is other ROAs for the same prefix) or Invalid (if
another ROA for the same prefix, but with a there is another ROA for the same prefix, but with
different AS number). a different AS number).
A-4.2 Suppression A-4.2 Suppression
A-4.2.1 Publication of a newer ROA may be suppressed. If A-4.2.1 Publication of a newer ROA may be suppressed. If
the INR holder intended to change the binding the INR holder intended to change the binding
between the prefix(es) and the AS number in the between the prefix(es) and the AS number in the
ROA, this change will not be effected. As a ROA, this change will not be effected. As a
result, RPs may continue to believe an old prefix/ result, RPs may continue to believe an old prefix/
ASN binding that is no longer what the INR holder ASN binding that is no longer what the INR holder
intended. intended.
skipping to change at page 15, line 16 skipping to change at page 16, line 12
flow to an ASN other than the one(s) intended by flow to an ASN other than the one(s) intended by
the INR holder. the INR holder.
A-4.2.3 If an INR holder intends to delete all ROAs for A-4.2.3 If an INR holder intends to delete all ROAs for
the same address space, some of them may be the same address space, some of them may be
retained while the others are deleted. Preventing retained while the others are deleted. Preventing
the deletion of some ROAs can cause traffic to the deletion of some ROAs can cause traffic to
continue to be delivered to the ASNs that were continue to be delivered to the ASNs that were
advertised by these ROAs. Deletion of all ROAs is advertised by these ROAs. Deletion of all ROAs is
consistent with a transfer of address space to a consistent with a transfer of address space to a
different INR holder, in a phased fashion. Thus different INR holder in a phased fashion. Thus,
this sort of attack could interfere with the this sort of attack could interfere with the
successful transfer of the affected address space successful transfer of the affected address space
(until such time as the prefixes are removed from (until such time as the prefixes are removed from
the previous INR holder's CA certificate). the previous INR holder's CA certificate).
A-4.3 Corruption A-4.3 Corruption
A-4.3.1 A ROA may be corrupted. A corrupted ROA will be A-4.3.1 A ROA may be corrupted. A corrupted ROA will be
ignored by an RP, so the effect is essentially the ignored by an RP, so the effect is essentially the
same as for A-4.1 and A-4.5. A possible same as for A-4.1 and A-4.5. A possible
skipping to change at page 16, line 25 skipping to change at page 17, line 28
for an ASN already authorized to originate a for an ASN already authorized to originate a
route, e.g., a longer prefix, which could enable route, e.g., a longer prefix, which could enable
that ASN to override other advertisements using that ASN to override other advertisements using
shorter prefixes. If there are other ROAs that shorter prefixes. If there are other ROAs that
authorize different ASNs to advertise routes to authorize different ASNs to advertise routes to
the injected ROA's prefix, then the injected ROA the injected ROA's prefix, then the injected ROA
is in competition with these ROAs. is in competition with these ROAs.
2.5. Ghostbusters Record 2.5. Ghostbusters Record
The Ghostbusters record [RFC6493] is a signed object that may be The Ghostbusters Record [RFC6493] is a signed object that may be
included at a publication point, at the discretion of the INR holder included at a publication point, at the discretion of the INR holder
or publication point operator. The record is validated according to or publication point operator. The record is validated according to
[RFC6488]. Additionally, the syntax of the record is verified based [RFC6488]. Additionally, the syntax of the record is verified based
on the vCard profile from Section 5 of [RFC6493]. Errors in this on the vCard profile from Section 5 of [RFC6493]. Errors in this
record do not affect RP processing. However, if an RP encounters a record do not affect RP processing. However, if an RP encounters a
problem with objects at a publication point, the RP may use problem with objects at a publication point, the RP may use
information from the record to contact the publication point information from the record to contact the publication point
operator. operator.
Adverse actions against a Ghostbusters record can cause the following Adverse actions against a Ghostbusters Record can cause the following
error: error:
A-5.1 Deletion, suppression, corruption, or revocation of a A-5.1 Deletion, suppression, corruption, or revocation of a
Ghostbusters record could prevent an RP from contacting the Ghostbusters Record could prevent an RP from contacting the
appropriate entity when a problem is detected by the RP. appropriate entity when a problem is detected by the RP.
Modification or injection of a Ghostbusters record could Modification or injection of a Ghostbusters Record could
cause an RP to contact the wrong entity, thus delaying cause an RP to contact the wrong entity, thus delaying
remediation of a detected anomaly. All of these actions remediation of a detected anomaly. All of these actions
are viewed as equivalent from an RP processing perspective; are viewed as equivalent from an RP processing perspective;
they do not alter RP validation of ROAs or router they do not alter RP validation of ROAs or router
certificates. However, these actions can interfere with certificates. However, these actions can interfere with
remediation of a problem when detected by an RP. 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 [RFC8209]. Each participating AS is
participating AS is represented by one or more router certificates. represented by one or more router certificates. During key or
During key or algorithm rollover, multiple router certificates will algorithm rollover, multiple router certificates will be present in a
be present in a publication point, even if the AS is normally publication point, even if the AS is normally represented by just one
represented by just one such certificate. such certificate.
Adverse actions against router certificates can cause the following Adverse actions against router certificates can cause the following
errors: errors:
A-6.1 Deletion A-6.1 Deletion
A-6.1.1 Deletion of a router certificate would cause an RP A-6.1.1 Deletion of a router certificate would cause an RP
to not be able to verify signatures applied to to be unable to verify signatures applied to
BGPsec_Path attributes on behalf of the AS in BGPsec_PATH attributes on behalf of the AS in
question. In turn, this would cause the route to question. In turn, this would cause the route to
be treated with lower preference than competing be treated with lower preference than competing
routes that have valid BGPsec_Path attribute routes that have valid BGPsec_PATH attribute
signatures. (However, if another router signatures. (However, if another router
certificate for the affected AS is valid and certificate for the affected AS is valid and
contains the same AS number and public key, and is contains the same AS number and public key, and it
in use by that AS, there would be no effect on is in use by that AS, there would be no effect on
routing. This scenario will arise if a router routing. This scenario will arise if a router
certificate is renewed, i.e., issued with a new certificate is renewed, i.e., issued with a new
validity interval.) validity interval.)
A-6.2 Suppression A-6.2 Suppression
A-6.2.1 Suppression of a router certificate could have the A-6.2.1 Suppression of a router certificate could have the
same impact as deletion of a certificate of this same impact as deletion of a certificate of this
type, i.e., if no router certificate was type, i.e., if no router certificate was
available, BGPsec attributes that should be available, BGPsec attributes that should be
verified using the certificate would fail verified using the certificate would fail
validation. If an older certificate existed, and validation. If an older certificate existed and
had not expired, it would be used by RPs. If the has not expired, it would be used by RPs. If the
older certificate contained a different ASN, the older certificate contained a different ASN, the
impact would be the same as in A-6.4. impact would be the same as in A-6.4.
A-6.3 Corruption A-6.3 Corruption
A-6.3.1 Corruption of a router certificate will result in A-6.3.1 Corruption of a router certificate will result in
the certificate being rejected by RPs. Absent a the certificate being rejected by RPs. Absent a
valid router certificate, BGPsec_Path attributes valid router certificate, BGPsec_PATH attributes
associated with that certificate will be associated with that certificate will be
unverifiable. In turn, this would cause the route unverifiable. In turn, this would cause the route
to be treated with lower preference than competing to be treated with lower preference than competing
routes that have valid BGPsec_Path attribute routes that have valid BGPsec_PATH attribute
signatures. signatures.
A-6.4 Modification A-6.4 Modification
A-6.4.1 If a router certificate is modified to represent a A-6.4.1 If a router certificate is modified to represent a
different ASN, but it still passes syntax checks, different ASN, but it still passes syntax checks,
then this action could cause signatures on then this action could cause signatures on
BGPsec_Path attributes to be associated with the BGPsec_PATH attributes to be associated with the
wrong AS. This could cause signed routes to be wrong AS. This could cause signed routes to be
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 no 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
skipping to change at page 19, line 21 skipping to change at page 20, line 23
C. An INR holder outsources management of its CA to its parent, C. An INR holder outsources management of its CA to its parent,
but manages its own repository publication point. but manages its own repository publication point.
D. An INR holder outsources management of its CA and its D. An INR holder outsources management of its CA and its
publication point to its parent. publication point to its parent.
Note that these scenarios focus on the affected INR holder as the Note that these scenarios focus on the affected INR holder as the
party directly affected by an adverse action. The most serious cases 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 arise when the INR holder appears as a high-tier CA in the RPKI
hierarchy; in such situations subordinate INR holders may be affected hierarchy; in such situations, subordinate INR holders may be
as a result of an action. A mistake by or an attack against a "leaf" affected as a result of an action. A mistake by or an attack against
has more limited impact because all of the affected INRs belong to a "leaf" has more limited impact because all of the affected INRs
the INR holder itself. belong to the INR holder itself.
In Scenario A, actions by the INR holder can adversely affect all of In Scenario A, actions by the INR holder can adversely affect all of
its resources and, transitively, resources of any subordinate CAs. its resources and, transitively, resources of any subordinate CAs.
(If the CA is a "leaf" in the RPKI, then it has no 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.) and the damage is limited to its own INRs.)
In Scenario B, actions by the (outsourced) repository operator also In Scenario B, actions by the (outsourced) repository operator can
can adversely affect the resources of the INR holder, and those of 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 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.) 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 The range of adverse effects here includes those in Scenario A and
adds a new potential source of adverse actions, i.e., the outsourced adds a new potential source of adverse actions, i.e., the outsourced
repository operator. repository operator.
In Scenario C, all signed objects associated with the INR holder are In Scenario C, all signed objects associated with the INR holder are
generated by the parent CA but are self-hosted. (We expect this generated by the parent CA but are self-hosted. (We expect this
scenario to be rare, because an INR holder that elects to outsource scenario to be rare, because an INR holder that elects to outsource
CA operation seems unlikely to manage its own repository publication CA operation seems unlikely to manage its own repository publication
point.) Because that CA has the private key used to sign them, it point.) Because that CA has the private key used to sign them, it
can generate alternative signed objects---ones not authorized by the can generate alternative signed objects -- ones not authorized by the
INR holder. However, erroneous objects created by the parent CA will INR holder. However, erroneous objects created by the parent CA will
not be published by the INR holder IF the holder checks them first. 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 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 by or attacks against that entity are equivalent to ones effected by
the INR holder in Scenario A. the INR holder in Scenario A.
The INR holder is most vulnerable in Scenario D. Actions by the The INR holder is most vulnerable in Scenario D. Actions by the
parent CA, acting on behalf of the INR holder, can adversely affect parent CA, acting on behalf of the INR holder, can adversely affect
all signed objects associated with that INR holder, including any all signed objects associated with that INR holder, including any
subordinate CA certificates. These actions will presumably translate subordinate CA certificates. These actions will presumably translate
directly into publication point changes, because the parent CA is directly into publication point changes because the parent CA is
managing the publication point for the INR holder. The range of managing the publication point for the INR holder. The range of
adverse effects here includes those in Scenarios A, B, and C. adverse effects here includes those in Scenarios A, B, and C.
3.1. Scenario A 3.1. Scenario A
In this scenario, the INR holder acts as its own CA and it manages 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 its own publication point. Actions by the INR holder can adversely
affect all of its resources and, transitively, resources of any 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. (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 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 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, successful attack against this CA can effect all of the modification,
revocation, or injection actions noted in that section. (We assume revocation, or injection actions noted in that section. (We assume
that objects generated by the CA are automatically published). An that objects generated by the CA are automatically published). An
attack against the publication point can effect all of the deletion, attack against the publication point can effect all of the deletion,
suppression, or corruption actions noted in that section. suppression, or corruption actions noted in that section.
3.2. Scenario B 3.2. Scenario B
In this scenario, the INR holder acts as its own CA and but it In this scenario, the INR holder acts as its own CA but it delegates
delegates management of it own publication point to a third party. management of it own publication point to a third party. Mistakes by
Mistakes by the INR holder can cause any of the modification, the INR holder can cause any of the modification, revocation, or
revocation, or injection actions described in Section 2. Actions by injection actions described in Section 2. Actions by the repository
the repository operator can adversely affect the resources of the INR operator can adversely affect the resources of the INR holder, and
holder, and those of any subordinate CAs. (If the CA is a "leaf" in those of any subordinate CAs. (If the CA is a "leaf" in the RPKI,
the RPKI, then it has no subordinate CAs and the damage is limited, then it has no subordinate CAs and the damage is limited, as in
as in Scenario A.) The range of adverse effects here includes those Scenario A.) The range of adverse effects here includes those in
in Scenario A, and adds a new potential source of adverse actions, Scenario A, and adds a new potential source of adverse actions, i.e.,
i.e., the third party repository operator. A successful attack the third party repository operator. A successful attack against the
against the CA can effect all of the modification, revocation, or CA can effect all of the modification, revocation, or injection
injection actions noted in that section (assuming that objects actions noted in that section (assuming that objects generated by the
generated by the CA are automatically published). Here, actions by CA are automatically published). Here, actions by the publication
the publication point manager (or attacks against that entity) can point manager (or attacks against that entity) can effect all of the
effect all of the deletion, suppression, or corruption actions noted deletion, suppression, or corruption actions noted in Section 2.
in Section 2.
3.3. Scenario C 3.3. Scenario C
In this scenario, the INR holder outsources management of its CA to In this scenario, the INR holder outsources management of its CA to
its parent, but manages its own repository publication point. All its parent, but manages its own repository publication point. All
signed objects associated with the INR holder are generated by the signed objects associated with the INR holder are generated by the
parent CA but are self-hosted. (We expect this scenario to be rare, parent CA but are self-hosted. (We expect this scenario to be rare,
because an INR holder that elects to outsource CA operation seems because an INR holder that elects to outsource CA operation seems
unlikely to manage its own repository publication point.) Because unlikely to manage its own repository publication point.) Because
that CA has the private key used to sign them, it can generate that CA has the private key used to sign them, it can generate
skipping to change at page 21, line 26 skipping to change at page 22, line 27
before publishing them. An attack against the INR holder (in its before publishing them. An attack against the INR holder (in its
role as repository operator) can effect all of the deletion, role as repository operator) can effect all of the deletion,
suppression, or corruption actions noted in Section 2 (because the suppression, or corruption actions noted in Section 2 (because the
INR holder is managing its publication point), unless the INR holder INR holder is managing its publication point), unless the INR holder
checks the signed objects before publishing them. (An attack against checks the signed objects before publishing them. (An attack against
the INR holder implies that the path it uses to direct the parent CA the INR holder implies that the path it uses to direct the parent CA
to issue and publish objects has been compromised.) to issue and publish objects has been compromised.)
3.4. Scenario D 3.4. Scenario D
In this scenario an INR holder outsources management of both its CA In this scenario, an INR holder outsources management of both its CA
and its publication point to its parent. The INR holder is most and its publication point to its parent. The INR holder is most
vulnerable in this scenario. Actions by the parent CA, acting on vulnerable in this scenario. Actions by the parent CA, acting on
behalf of the INR holder, can adversely affect all signed objects behalf of the INR holder, can adversely affect all signed objects
associated with that INR holder, including any subordinate CA associated with that INR holder, including any subordinate CA
certificates. These actions will presumably translate directly into certificates. These actions will presumably translate directly into
publication point changes, because the parent CA is managing the publication point changes, because the parent CA is managing the
publication point for the INR holder. The range of adverse effects publication point for the INR holder. The range of adverse effects
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
skipping to change at page 22, line 9 skipping to change at page 23, line 9
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
an attempt to document the implications of a wide range of attacks an attempt to document the implications of a wide range of attacks
and errors, in the context of the RPKI. The primary alternative and errors in the context of the RPKI. The primary alternative
mechanism for disseminating routing information is Internet Routing mechanism for disseminating routing information is Internet Routing
Registry (IRR) technology ([RFC2650], [RFC2725]), which uses the Registry (IRR) technology [RFC2650] [RFC2725], which uses the Routing
Routing Policy Specification Language (RPSL) [RFC2622]. IRR Policy Specification Language (RPSL) [RFC2622]. IRR technology
technology exhibits its own set of security problems, which are exhibits its own set of security problems, which are discussed in
discussed in [RFC7682]. [RFC7682].
5. IANA Considerations 5. IANA Considerations
This document has no actions for IANA. This document does not require any IANA actions.
6. 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.
7. References
7.1. Normative References
[I-D.ietf-sidr-bgpsec-pki-profiles] 6. References
Reynolds, M., Turner, S., and S. Kent, "A Profile for
BGPsec Router Certificates, Certificate Revocation Lists,
and Certification Requests", draft-ietf-sidr-bgpsec-pki-
profiles-18 (work in progress), July 2016.
[I-D.ietf-sidr-bgpsec-protocol] 6.1. Normative References
Lepinski, M. and K. Sriram, "BGPsec Protocol
Specification", draft-ietf-sidr-bgpsec-protocol-21 (work
in progress), December 2016.
[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>. <https://www.rfc-editor.org/info/rfc3779>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <http://www.rfc-editor.org/info/rfc6480>. February 2012, <https://www.rfc-editor.org/info/rfc6480>.
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for
Resource Certificate Repository Structure", RFC 6481, Resource Certificate Repository Structure", RFC 6481,
DOI 10.17487/RFC6481, February 2012, DOI 10.17487/RFC6481, February 2012,
<http://www.rfc-editor.org/info/rfc6481>. <https://www.rfc-editor.org/info/rfc6481>.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)", RFC 6482, Origin Authorizations (ROAs)", RFC 6482,
DOI 10.17487/RFC6482, February 2012, DOI 10.17487/RFC6482, February 2012,
<http://www.rfc-editor.org/info/rfc6482>. <https://www.rfc-editor.org/info/rfc6482>.
[RFC6483] Huston, G. and G. Michaelson, "Validation of Route [RFC6483] Huston, G. and G. Michaelson, "Validation of Route
Origination Using the Resource Certificate Public Key Origination Using the Resource Certificate Public Key
Infrastructure (PKI) and Route Origin Authorizations Infrastructure (PKI) and Route Origin Authorizations
(ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012, (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012,
<http://www.rfc-editor.org/info/rfc6483>. <https://www.rfc-editor.org/info/rfc6483>.
[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski,
"Manifests for the Resource Public Key Infrastructure "Manifests for the Resource Public Key Infrastructure
(RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012,
<http://www.rfc-editor.org/info/rfc6486>. <https://www.rfc-editor.org/info/rfc6486>.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487, X.509 PKIX Resource Certificates", RFC 6487,
DOI 10.17487/RFC6487, February 2012, DOI 10.17487/RFC6487, February 2012,
<http://www.rfc-editor.org/info/rfc6487>. <https://www.rfc-editor.org/info/rfc6487>.
[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object
Template for the Resource Public Key Infrastructure Template for the Resource Public Key Infrastructure
(RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012,
<http://www.rfc-editor.org/info/rfc6488>. <https://www.rfc-editor.org/info/rfc6488>.
[RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification
Authority (CA) Key Rollover in the Resource Public Key Authority (CA) Key Rollover in the Resource Public Key
Infrastructure (RPKI)", BCP 174, RFC 6489, Infrastructure (RPKI)", BCP 174, RFC 6489,
DOI 10.17487/RFC6489, February 2012, DOI 10.17487/RFC6489, February 2012,
<http://www.rfc-editor.org/info/rfc6489>. <https://www.rfc-editor.org/info/rfc6489>.
[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI)
Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493,
February 2012, <http://www.rfc-editor.org/info/rfc6493>. February 2012, <https://www.rfc-editor.org/info/rfc6493>.
[RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility
Procedure for the Resource Public Key Infrastructure Procedure for the Resource Public Key Infrastructure
(RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April
2013, <http://www.rfc-editor.org/info/rfc6916>. 2013, <https://www.rfc-editor.org/info/rfc6916>.
[RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for [RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for
Algorithms and Key Sizes for Use in the Resource Public Algorithms and Key Sizes for Use in the Resource Public
Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935,
August 2016, <http://www.rfc-editor.org/info/rfc7935>. August 2016, <https://www.rfc-editor.org/info/rfc7935>.
7.2. Informative References [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
Specification", RFC 8205, DOI 10.17487/RFC8205, September
2017, <https://www.rfc-editor.org/info/rfc8205>.
[RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for
BGPsec Router Certificates, Certificate Revocation Lists,
and Certification Requests", RFC 8209,
DOI 10.17487/RFC8209, September 2017,
<https://www.rfc-editor.org/info/rfc8209>.
6.2. Informative References
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra,
"Routing Policy Specification Language (RPSL)", RFC 2622, "Routing Policy Specification Language (RPSL)", RFC 2622,
DOI 10.17487/RFC2622, June 1999, DOI 10.17487/RFC2622, June 1999,
<http://www.rfc-editor.org/info/rfc2622>. <https://www.rfc-editor.org/info/rfc2622>.
[RFC2650] Meyer, D., Schmitz, J., Orange, C., Prior, M., and C. [RFC2650] Meyer, D., Schmitz, J., Orange, C., Prior, M., and C.
Alaettinoglu, "Using RPSL in Practice", RFC 2650, Alaettinoglu, "Using RPSL in Practice", RFC 2650,
DOI 10.17487/RFC2650, August 1999, DOI 10.17487/RFC2650, August 1999,
<http://www.rfc-editor.org/info/rfc2650>. <https://www.rfc-editor.org/info/rfc2650>.
[RFC2725] Villamizar, C., Alaettinoglu, C., Meyer, D., and S. [RFC2725] Villamizar, C., Alaettinoglu, C., Meyer, D., and S.
Murphy, "Routing Policy System Security", RFC 2725, Murphy, "Routing Policy System Security", RFC 2725,
DOI 10.17487/RFC2725, December 1999, DOI 10.17487/RFC2725, December 1999,
<http://www.rfc-editor.org/info/rfc2725>. <https://www.rfc-editor.org/info/rfc2725>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<http://www.rfc-editor.org/info/rfc5652>. <https://www.rfc-editor.org/info/rfc5652>.
[RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", [RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security",
RFC 7132, DOI 10.17487/RFC7132, February 2014, RFC 7132, DOI 10.17487/RFC7132, February 2014,
<http://www.rfc-editor.org/info/rfc7132>. <https://www.rfc-editor.org/info/rfc7132>.
[RFC7682] McPherson, D., Amante, S., Osterweil, E., Blunk, L., and [RFC7682] McPherson, D., Amante, S., Osterweil, E., Blunk, L., and
D. Mitchell, "Considerations for Internet Routing D. Mitchell, "Considerations for Internet Routing
Registries (IRRs) and Routing Policy Configuration", Registries (IRRs) and Routing Policy Configuration",
RFC 7682, DOI 10.17487/RFC7682, December 2015, RFC 7682, DOI 10.17487/RFC7682, December 2015,
<http://www.rfc-editor.org/info/rfc7682>. <https://www.rfc-editor.org/info/rfc7682>.
Acknowledgements
The authors thank Richard Hansen and David Mandelberg for their
extensive review, feedback, and editorial assistance. Thanks also go
to Daiming Li for her editorial assistance.
Authors' Addresses 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 United States of America
Email: kent@alum.mit.edu Email: kent@alum.mit.edu
Di Ma Di Ma
ZDNS ZDNS
4 South 4th St. Zhongguancun 4 South 4th St. Zhongguancun
Haidian, Beijing 100190 Haidian, Beijing 100190
China China
Email: madi@zdns.cn Email: madi@zdns.cn
 End of changes. 123 change blocks. 
290 lines changed or deleted 287 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/