draft-ietf-sidr-adverse-actions-03.txt   draft-ietf-sidr-adverse-actions-04.txt 
SIDR S. Kent SIDR S. Kent
Internet-Draft BBN Technologies Internet-Draft BBN Technologies
Intended status: Informational D. Ma Intended status: Informational D. Ma
Expires: March 16, 2017 ZDNS Expires: July 16, 2017 ZDNS
September 12, 2016 January 12, 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-03 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 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 done from the perspective of an affected INR CAs. The analysis is done from the perspective of an affected INR
holder. The analysis is based on examination of the data items in holder. The analysis is based on examination of the data items in
the RPKI repository, as controlled by a CA (or independent repository the RPKI repository, as controlled by a CA (or independent repository
manager) and fetched by Relying Parties (RPs). The analysis does not manager) and fetched by Relying Parties (RPs). The analysis does not
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 March 16, 2017. This Internet-Draft will expire on July 16, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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 (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
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Analysis of RPKI Repository Objects . . . . . . . . . . . . . 3 2. Analysis of RPKI Repository Objects . . . . . . . . . . . . . 3
2.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 6 2.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 5
2.2. Manifest . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. Manifest . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Certificate Revocation List . . . . . . . . . . . . . . . 11 2.3. Certificate Revocation List . . . . . . . . . . . . . . . 11
2.4. ROA . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.4. ROA . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5. Ghostbusters Record . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . . . . . 24
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 Numeric 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, and thus the change may be contractually
justified, even though viewed as adverse by the INR holder. This justified, even though viewed as adverse by the INR holder. This
document examines the implications of adverse actions within the RPKI document examines the implications of adverse actions within the RPKI
with respect to INRs irrespective of the cause of the actions. with respect to INRs irrespective of the cause of the actions.
skipping to change at page 3, line 41 skipping to change at page 3, line 39
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
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 independent repository
operator) and fetched by Relying Parties (RPs). operator) and fetched by Relying Parties (RPs).
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
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 Origination 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 addressed 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-overview], the principal goal of the of BGPsec [I-D.ietf-sidr-bgpsec-protocol], the principal goal of the
RPKI is to enable an RP to validate ROAs [RFC6482]. A ROA binds RPKI is to enable an RP to validate ROAs [RFC6482]. A ROA binds
address space to an Autonomous System Number (ASN). A ROA can be address space to an Autonomous System Number (ASN). A ROA can be
used to verify BGP announcements with respect to route origin used to verify BGP announcements with respect to route 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
[I-D.ietf-sidr-bgpsec-pki-profiles] will be added to repository [I-D.ietf-sidr-bgpsec-pki-profiles] will be added to repository
skipping to change at page 6, line 49 skipping to change at page 6, line 40
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 1.4.3. the effect would be the same as in A-1.1 or
A-1.4.3. If the [RFC3779] extensions in the
If the 3779 extensions in the suppressed suppressed certificate changed, the impact would
certificate changed, the impact would be the same be the same as in A-1.4.1. If the AIA extension
as in 1.4.1. If the AIA extension changed in the changed in the suppressed certificate, the impact
suppressed certificate, the impact would be the would be the same as in A-1.4.4. Suppression of a
same as in 1.4.4. renewed/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.
skipping to change at page 7, line 28 skipping to change at page 7, line 19
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 to the RPKI certificate profile conforms to the RPKI certificate profile
[RFC6485], it will be accepted by RPs. If an [RFC7935], it will be accepted by RPs. If an
[RFC3779] extension in this certificate is changed [RFC3779] extension in this certificate is changed
to exclude INRs that were previously present, then to exclude INRs that were previously present, then
subordinate signed objects will become invalid if subordinate signed objects will become invalid if
they rely on the excised INRs. If these objects they rely on the excised INRs. If these objects
are CA certificates, their subordinate signed are CA certificates, their subordinate signed
objects will be treated as invalid. If the objects will be treated as invalid. If the
objects are ROAs, the binding expressed by the objects are ROAs, the binding expressed by the
affected ROAs will be ignored by RPs. If the affected ROAs will be ignored by RPs. If the
objects are router certificates, BGPsec_Path objects are router certificates, BGPsec_Path
attributes [I-D.ietf-sidr-bgpsec-protocol] attributes [I-D.ietf-sidr-bgpsec-protocol]
skipping to change at page 9, line 30 skipping to change at page 9, line 21
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) also
can cause an RP to not detect suppression of other signed objects at can 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 actions
skipping to change at page 15, line 34 skipping to change at page 15, line 26
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 4.5. A possible difference same as for A-4.1 and A-4.5. A possible
is that an RP may be alerted to the fact that the difference is that an RP may be alerted to the
ROA was corrupted, which might attract attention fact that the ROA was corrupted, which might
to the attack. attract attention to the attack.
A-4.4 Modification A-4.4 Modification
A-4.4.1 A ROA may be modified so that the Autonomous A-4.4.1 A ROA may be modified so that the Autonomous
System Number (ASN) or one or more of the address System Number (ASN) or one or more of the address
blocks in a ROA is different from the values the blocks in a ROA is different from the values the
INR holder intended for this ROA. (This action INR holder intended for this ROA. (This action
assumes that the modified ROA's ASN and address assumes that the modified ROA's ASN and address
ranges are authorized for use by the INR holder.) ranges are authorized for use by the INR holder.)
This attack will cause RPs to de-preference the This attack will cause RPs to de-preference the
skipping to change at page 16, line 31 skipping to change at page 16, line 25
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
skipping to change at page 22, line 38 skipping to change at page 22, line 30
6. Acknowledgements 6. Acknowledgements
The authors thank Richard Hansen and David Mandelberg for their The authors thank Richard Hansen and David Mandelberg for their
extensive review, feedback and editorial assistance. Thanks also go extensive review, feedback and editorial assistance. Thanks also go
to Daiming Li for her editorial assistance. to Daiming Li for her editorial assistance.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-sidr-bgpsec-overview]
Lepinski, M. and S. Turner, "An Overview of BGPsec",
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., Turner, S., and S. Kent, "A Profile for Reynolds, M., Turner, S., and S. Kent, "A Profile for
BGPsec Router Certificates, Certificate Revocation Lists, BGPsec Router Certificates, Certificate Revocation Lists,
and Certification Requests", draft-ietf-sidr-bgpsec-pki- and Certification Requests", draft-ietf-sidr-bgpsec-pki-
profiles-18 (work in progress), July 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-18 (work Specification", draft-ietf-sidr-bgpsec-protocol-21 (work
in progress), August 2016. in progress), December 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<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>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<http://www.rfc-editor.org/info/rfc5652>.
[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, <http://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>. <http://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>. <http://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>. <http://www.rfc-editor.org/info/rfc6483>.
[RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for
Use in the Resource Public Key Infrastructure (RPKI)",
RFC 6485, DOI 10.17487/RFC6485, February 2012,
<http://www.rfc-editor.org/info/rfc6485>.
[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>. <http://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>. <http://www.rfc-editor.org/info/rfc6487>.
skipping to change at page 24, line 25 skipping to change at page 24, line 5
[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, <http://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, <http://www.rfc-editor.org/info/rfc6916>.
[RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", [RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for
RFC 7132, DOI 10.17487/RFC7132, February 2014, Algorithms and Key Sizes for Use in the Resource Public
<http://www.rfc-editor.org/info/rfc7132>. Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935,
August 2016, <http://www.rfc-editor.org/info/rfc7935>.
7.2. Informative References 7.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>. <http://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>. <http://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>. <http://www.rfc-editor.org/info/rfc2725>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<http://www.rfc-editor.org/info/rfc5652>.
[RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security",
RFC 7132, DOI 10.17487/RFC7132, February 2014,
<http://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>. <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@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. 27 change blocks. 
61 lines changed or deleted 44 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/