draft-ietf-sidrops-rp-01.txt   draft-ietf-sidrops-rp-02.txt 
SIDROPS D. Ma SIDROPS D. Ma
Internet-Draft ZDNS Internet-Draft ZDNS
Intended status: Informational S. Kent Intended status: Informational S. Kent
Expires: August 25, 2018 BBN Expires: February 21, 2019 Independent
February 21, 2018 August 20, 2018
Requirements for Resource Public Key Infrastructure (RPKI) Relying Requirements for Resource Public Key Infrastructure (RPKI) Relying
Parties Parties
draft-ietf-sidrops-rp-01 draft-ietf-sidrops-rp-02
Abstract Abstract
This document provides a single reference point for requirements for This document provides a single reference point for requirements for
Relying Party (RP) software for use in the Resource Public Key Relying Party (RP) software for use in the Resource Public Key
Infrastructure (RPKI). It cites requirements that appear in several Infrastructure (RPKI) in the context of securing Internet routing.
RPKI RFCs, making it easier for implementers to become aware of these It cites requirements that appear in several RPKI RFCs, making it
requirements that are segmented with orthogonal functionalities. easier for implementers to become aware of these requirements that
are segmented with orthogonal functionalities.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 August 25, 2018. This Internet-Draft will expire on February 21, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://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
skipping to change at page 2, line 31 skipping to change at page 2, line 32
4. Processing RPKI Repository Signed Objects . . . . . . . . . . 6 4. Processing RPKI Repository Signed Objects . . . . . . . . . . 6
4.1. Basic Signed Object Syntax Checks . . . . . . . . . . . . 6 4.1. Basic Signed Object Syntax Checks . . . . . . . . . . . . 6
4.2. Syntax and Validation for Each Type of Signed Object . . 6 4.2. Syntax and Validation for Each Type of Signed Object . . 6
4.2.1. Manifest . . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. Manifest . . . . . . . . . . . . . . . . . . . . . . 6
4.2.2. ROA . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2.2. ROA . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.3. Ghostbusters . . . . . . . . . . . . . . . . . . . . 7 4.2.3. Ghostbusters . . . . . . . . . . . . . . . . . . . . 7
4.2.4. Verifying BGPsec Router Certificate . . . . . . . . . 7 4.2.4. Verifying BGPsec Router Certificate . . . . . . . . . 7
4.3. How to Make Use of Manifest Data . . . . . . . . . . . . 7 4.3. How to Make Use of Manifest Data . . . . . . . . . . . . 7
4.4. What to Do with Ghostbusters Information . . . . . . . . 8 4.4. What to Do with Ghostbusters Information . . . . . . . . 8
5. Delivering Validated Cache to BGP Speakers . . . . . . . . . 8 5. Delivering Validated Cache to BGP Speakers . . . . . . . . . 8
6. Security considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The RPKI RP software is used by network operators and others to The RPKI Relying Party (RP) software is used by network operators and
acquire and verify Internet Number Resource (INR) data stored in the others to acquire and verify Internet Number Resource (INR) data
RPKI repository system. RPKI data, when verified, allow an RP to stored in the RPKI repository system. RPKI data, when verified,
verify assertions about which Autonomous Systems (ASes) are allow an RP to verify assertions about which Autonomous Systems
authorized to originate routes for IP address prefixes. RPKI data (ASes) are authorized to originate routes for IP address prefixes.
also establishes binding between public keys and BGP routers, and RPKI data also establishes binding between public keys and BGP
indicates the AS numbers that each router is authorized to represent. routers, and indicates the AS numbers that each router is authorized
to represent.
Noting that the essential requirements imposed on RPs are scattered Noting that the essential requirements imposed on RPs to support
throughout numerous RFC documents that are protocol specific or securing Internet routing ([RFC6480]) are scattered throughout
provide best practices, as follows: numerous RFC documents that are protocol specific or provide best
practices, as follows:
RFC 6481 (Repository Structure) RFC 6481 (Repository Structure)
RFC 6482 (ROA format) RFC 6482 (ROA format)
RFC 6486 (Manifests) RFC 6486 (Manifests)
RFC 6487 (Certificate and CRL profile) RFC 6487 (Certificate and CRL profile)
RFC 6488 (RPKI Signed Objects) RFC 6488 (RPKI Signed Objects)
RFC 6489 (Key Rollover) RFC 6489 (Key Rollover)
RFC 6810 (RPKI to Router Protocol) RFC 6810 (RPKI to Router Protocol)
RFC 6916 (Algorithm Agility) RFC 6916 (Algorithm Agility)
RFC 7730 (Trust Anchor Locator) RFC 7730 (Trust Anchor Locator)
RFC 7935 (Algorithms) RFC 7935 (Algorithms)
RFC 8209 (Router Certificates) RFC 8209 (Router Certificates)
RFC 8210 (RPKI to Router Protocol,Version 1)
RFC 8360 (Certificate Validation Procedure)
This makes it hard for an implementer to be confident that he/she has This makes it hard for an implementer to be confident that he/she has
addressed all of these generalized requirements. Besides, software addressed all of these generalized requirements. Besides, software
engineering calls for how to segment the RP system into components engineering calls for how to segment the RP system into components
with orthogonal functionalities, so that those components could be with orthogonal functionalities, so that those components could be
distributed across the operational timeline of the user. Taxonomy of distributed across the operational timeline of the user. Taxonomy of
generalized RP requirements is going to help have 'RP role' well generalized RP requirements is going to help have 'the role of the
framed. RP' well framed.
To consolidate RP requirements in one document, with pointers to all To consolidate RP requirements in one document, with pointers to all
the relevant RFCs, this document outlines a set of baseline the relevant RFCs, this document outlines a set of baseline
requirements imposed on RPs and provides a single reference point for requirements imposed on RPs and provides a single reference point for
requirements for RP software for use in the RPKI, as segmented with requirements for RP software for use in the RPKI, as segmented with
orthogonal functionalities: orthogonal functionalities:
o Fetching and Caching RPKI Repository Objects o Fetching and Caching RPKI Repository Objects
o Processing Certificates and CRLs o Processing Certificates and CRLs
o Processing RPKI Repository Signed Objects o Processing RPKI Repository Signed Objects
skipping to change at page 4, line 7 skipping to change at page 4, line 9
RP software uses synchronization mechanisms supported by targeted RP software uses synchronization mechanisms supported by targeted
repositories (e.g., [rsync], RRDP [RFC8182]) to download all RPKI repositories (e.g., [rsync], RRDP [RFC8182]) to download all RPKI
changed data objects in the repository system and cache them locally. changed data objects in the repository system and cache them locally.
The software validates the RPKI data and uses it to generate The software validates the RPKI data and uses it to generate
authenticated data identifying which ASes are authorized to originate authenticated data identifying which ASes are authorized to originate
routes for address prefixes, and which routers are authorized to sign routes for address prefixes, and which routers are authorized to sign
BGP updates on behalf of ASes. BGP updates on behalf of ASes.
2.1. TAL Acquisition and Processing 2.1. TAL Acquisition and Processing
In the RPKI, each relying party (RP) chooses its own set of trust In the RPKI, each RP chooses its own set of trust anchors (TAs).
anchors (TAs). Consistent with the extant INR allocation hierarchy, Consistent with the extant INR allocation hierarchy, the IANA and/or
the IANA and/or the five RIRs are obvious candidates to be default the five RIRs are obvious candidates to be default TAs for the RP.
TAs for the RP.
An RP does not retrieve TAs directly. A set of Trust Anchor Locators An RP does not retrieve TAs directly. A set of Trust Anchor Locators
(TALs) is used by each RP to retrieve and verify the authenticity of (TALs) is used by each RP to retrieve and verify the authenticity of
each trust anchor. each TA.
TAL acquisition and processing are specified in Section 3 of TAL acquisition and processing are specified in Section 3 of
[RFC7730]. [RFC7730].
2.2. Locating RPKI Objects Using Authority and Subject Information 2.2. Locating RPKI Objects Using Authority and Subject Information
Extensions Extensions
The RPKI repository system is a distributed one, consisting of The RPKI repository system is a distributed one, consisting of
multiple repository instances. Each repository instance contains one multiple repository instances. Each repository instance contains one
or more repository publication points. An RP discovers publication or more repository publication points. An RP discovers publication
points using the SIA and AIA extensions from (validated) points using the Subject Information Access (SIA) and the Authority
certificates. Information Access (AIA) extensions from (validated) certificates.
Section 5 of [RFC6481] specifies how an RP locates all RPKI objects Section 5 of [RFC6481] specifies how an RP locates all RPKI objects
by using the SIA and AIA extensions. Detailed specifications of SIA by using the SIA and AIA extensions. Detailed specifications of SIA
and AIA extensions in a resource certificate are described in section and AIA extensions in a resource certificate are described in
4 of [RFC6487]. Section 4 of [RFC6487].
2.3. Dealing with Key Rollover 2.3. Dealing with Key Rollover
An RP takes the key rollover period into account with regard to its An RP takes the key rollover period into account with regard to its
frequency of synchronization with RPKI repository system. frequency of synchronization with RPKI repository system.
RP requirements in dealing with key rollover are described in section RP requirements in dealing with key rollover are described in
3 of [RFC6489]. Section 3 of [RFC6489] and Section 3 of
[I-D.ietf-sidrops-bgpsec-rollover].
2.4. Dealing with Algorithm Transition 2.4. Dealing with Algorithm Transition
The set of cryptographic algorithms used with the RPKI is expected to The set of cryptographic algorithms used with the RPKI is expected to
change over time. Each RP is expected to be aware of the milestones change over time. Each RP is expected to be aware of the milestones
established for the algorithm transition and what actions are established for the algorithm transition and what actions are
required at every juncture. required at every juncture.
RP requirements for dealing with algorithm transition are specified RP requirements for dealing with algorithm transition are specified
in section 4 of [RFC6916]. in Section 4 of [RFC6916].
2.5. Strategies for Efficient Cache Maintenance 2.5. Strategies for Efficient Cache Maintenance
Each RP is expected to maintain a local cache of RPKI objects. The Each RP is expected to maintain a local cache of RPKI objects. The
cache needs to be as up to date and consistent with repository cache needs to be as up to date and consistent with repository
publication point data as the RP's frequency of checking permits. publication point data as the RP's frequency of checking permits.
The last paragraph of section 5 of [RFC6481] provides guidance for The last paragraph of Section 5 of [RFC6481] provides guidance for
maintenance of a local cache. maintenance of a local cache.
3. Certificate and CRL Processing 3. Certificate and CRL Processing
The RPKI make use of X.509 certificates and CRLs, but it profiles The RPKI make use of X.509 certificates and CRLs, but it profiles
these standard formats [RFC6487]. The major change to the profile these standard formats [RFC6487]. The major change to the profile
established in [RFC5280] is the mandatory use of a new extension to established in [RFC5280] is the mandatory use of a new extension to
X.509 certificate [RFC3779]. X.509 certificate [RFC3779].
3.1. Verifying Resource Certificate and Syntax 3.1. Verifying Resource Certificate and Syntax
skipping to change at page 5, line 48 skipping to change at page 5, line 48
belong to it, thus the INRs in issuer's certificate are required to belong to it, thus the INRs in issuer's certificate are required to
encompass the INRs in the subject's certificate. This is one of encompass the INRs in the subject's certificate. This is one of
necessary principles of certificate path validation in addition to necessary principles of certificate path validation in addition to
cryptographic verification i.e., verification of the signature on cryptographic verification i.e., verification of the signature on
each certificate using the public key of the parent certificate). each certificate using the public key of the parent certificate).
Section 7.2 of [RFC6487] gives the procedure that the RP should Section 7.2 of [RFC6487] gives the procedure that the RP should
follow to perform certificate path validation. follow to perform certificate path validation.
Certificate Authorities that want to reduce aspects of operational Certificate Authorities that want to reduce aspects of operational
fragility will migrate to the new OIDs fragility will migrate to the new OIDs [RFC8360], informing the RP of
[I-D.ietf-sidr-rpki-validation-reconsidered], informing the RP of
using an alternative RPKI validation algorithm. An RP is expected to using an alternative RPKI validation algorithm. An RP is expected to
support the amended procedure to handle with accidental over-claim. support the amended procedure to handle with accidental over-claim.
3.3. CRL Processing 3.3. CRL Processing
The CRL processing requirements imposed on CAs and RP are described The CRL processing requirements imposed on CAs and RP are described
in Section 5 of [RFC6487]. CRLs in the RPKI are tightly constrained; in Section 5 of [RFC6487]. CRLs in the RPKI are tightly constrained;
only the AuthorityKeyIndetifier and CRLNumber extensions are allowed, only the AuthorityKeyIndetifier and CRLNumber extensions are allowed,
and they MUST be present. No other CRL extensions are allowed, and and they MUST be present. No other CRL extensions are allowed, and
no CRLEntry extensions are permitted. RPs are required to verify no CRLEntry extensions are permitted. RPs are required to verify
skipping to change at page 6, line 47 skipping to change at page 6, line 47
signed object. signed object.
4.2. Syntax and Validation for Each Type of Signed Object 4.2. Syntax and Validation for Each Type of Signed Object
4.2.1. Manifest 4.2.1. Manifest
To determine whether a manifest is valid, the RP is required to To determine whether a manifest is valid, the RP is required to
perform manifest-specific checks in addition to those specified in perform manifest-specific checks in addition to those specified in
[RFC6488]. [RFC6488].
Specific checks for a Manifest are described in section 4 of Specific checks for a Manifest are described in Section 4 of
[RFC6486]. If any of these checks fails, indicating that the [RFC6486]. If any of these checks fails, indicating that the
manifest is invalid, then the manifest will be discarded and treated manifest is invalid, then the manifest will be discarded and treated
as though no manifest were present. as though no manifest were present.
4.2.2. ROA 4.2.2. ROA
To validate a ROA, the RP is required perform all the checks To validate a ROA, the RP is required perform all the checks
specified in [RFC6488] as well as the additional ROA-specific specified in [RFC6488] as well as the additional ROA-specific
validation steps. The IP address delegation extension [RFC3779] validation steps. The IP address delegation extension [RFC3779]
present in the end-entity (EE) certificate (contained within the present in the end-entity (EE) certificate (contained within the
ROA), must encompass each of the IP address prefix(es) in the ROA. ROA), must encompass each of the IP address prefix(es) in the ROA.
More details for ROA validation are specified in section 2 of More details for ROA validation are specified in Section 2 of
[RFC6482]. [RFC6482].
4.2.3. Ghostbusters 4.2.3. Ghostbusters
The Ghostbusters Record is optional; a publication point in the RPKI The Ghostbusters Record is optional; a publication point in the RPKI
can have zero or more associated Ghostbuster Records. If a CA has at can have zero or more associated Ghostbuster Records. If a CA has at
least one Ghostbuster Record, RP is required to verify that this least one Ghostbuster Record, RP is required to verify that this
Ghostbusters Record conforms to the syntax of signed object defined Ghostbusters Record conforms to the syntax of signed object defined
in [RFC6488]. in [RFC6488].
skipping to change at page 7, line 36 skipping to change at page 7, line 36
format as profiled in [RFC6493]. format as profiled in [RFC6493].
4.2.4. Verifying BGPsec Router Certificate 4.2.4. Verifying BGPsec Router Certificate
A BGPsec Router Certificate is a resource certificate, so it is A BGPsec Router Certificate is a resource certificate, so it is
required to comply with [RFC6487]. Additionally, the certificate required to comply with [RFC6487]. Additionally, the certificate
must contain an AS Identifier Delegation extension, and must not must contain an AS Identifier Delegation extension, and must not
contain an IP Address Delegation extension. The validation procedure contain an IP Address Delegation extension. The validation procedure
used for BGPsec Router Certificates is identical to the validation used for BGPsec Router Certificates is identical to the validation
procedure described in Section 7 of [RFC6487], but using the procedure described in Section 7 of [RFC6487], but using the
constraints applied come from specification of section 7 of constraints applied come from specification of Section 7 of
[RFC8209]. [RFC8209].
Note that the cryptographic algorithms used by BGPsec routers are Note that the cryptographic algorithms used by BGPsec routers are
found in [RFC8208]. Currently, the algorithms specified in found in [RFC8208]. Currently, the algorithms specified in
[RFC8208]and [RFC7935] are different. BGPsec RPs will need to [RFC8208]and [RFC7935] are different. BGPsec RPs will need to
support algorithms that are used to validate BGPsec signatures as support algorithms that are used to validate BGPsec signatures as
well as the algorithms that are needed to validate signatures on well as the algorithms that are needed to validate signatures on
BGPsec certificates, RPKI CA certificates, and RPKI CRLs. BGPsec certificates, RPKI CA certificates, and RPKI CRLs.
4.3. How to Make Use of Manifest Data 4.3. How to Make Use of Manifest Data
skipping to change at page 8, line 36 skipping to change at page 8, line 36
were encountered. The intent here is to encourage the relevant CA were encountered. The intent here is to encourage the relevant CA
and/or repository manager to update the slate or expired objects. and/or repository manager to update the slate or expired objects.
5. Delivering Validated Cache to BGP Speakers 5. Delivering Validated Cache to BGP Speakers
On a periodic basis, BGP speakers within an AS request updated On a periodic basis, BGP speakers within an AS request updated
validated origin AS data and router/ASN data from the RP's cache. validated origin AS data and router/ASN data from the RP's cache.
The RP passes this information to BGP speakers to enable them to The RP passes this information to BGP speakers to enable them to
verify the authenticity of routing announcements. The specification verify the authenticity of routing announcements. The specification
of the protocol designed to deliver validated cache data from an RP of the protocol designed to deliver validated cache data from an RP
to a BGP Speaker is provided in [RFC6810]. to a BGP Speaker is provided in [RFC6810] and [RFC8210].
6. Security considerations 6. Security Considerations
The RP links the RPKI provisioning side and the routing system, The RP links the RPKI provisioning side and the routing system,
establishing the local view of global RPKI data to BGP speakers. The establishing the local view of global RPKI data to BGP speakers. The
security of the RP is critical to BGP messages exchanging. The RP security of the RP is critical to BGP messages exchanging. The RP
implementation is expected to offer cache backup management to implementation is expected to offer cache backup management to
facilitate recovery from outage state. The RP implementation also facilitate recovery from outage state. The RP implementation also
should support application of secure transport (e.g., IPsec) that is should support application of secure transport (e.g., IPsec
able to protect validated cache delivery in a unsafe environment. [RFC4301]) that is able to protect validated cache delivery in a
unsafe environment.
7. IANA Considerations 7. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
8. Acknowledgements 8. Acknowledgements
The authors thank David Mandelberg, Wei Wang and Tim Bruijnzeels for The authors thank David Mandelberg, Wei Wang and Tim Bruijnzeels for
their review, feedback and editorial assistance in preparing this their review, feedback and editorial assistance in preparing this
document. document.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-sidr-rpki-validation-reconsidered]
Huston, G., Michaelson, G., Martinez, C., Bruijnzeels, T.,
Newton, A., and D. Shaw, "RPKI Validation Reconsidered",
draft-ietf-sidr-rpki-validation-reconsidered-10 (work in
progress), December 2017.
[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,
<https://www.rfc-editor.org/info/rfc3779>. <https://www.rfc-editor.org/info/rfc3779>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
skipping to change at page 10, line 15 skipping to change at page 10, line 10
[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,
<https://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,
<https://www.rfc-editor.org/info/rfc6488>. <https://www.rfc-editor.org/info/rfc6488>.
[RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification
Authority (CA) Key Rollover in the Resource Public Key
Infrastructure (RPKI)", BCP 174, RFC 6489,
DOI 10.17487/RFC6489, February 2012,
<https://www.rfc-editor.org/info/rfc6489>.
[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) [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, <https://www.rfc-editor.org/info/rfc6493>. February 2012, <https://www.rfc-editor.org/info/rfc6493>.
[RFC6810] Bush, R. and R. Austein, "The Resource Public Key [RFC6810] Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol", RFC 6810, Infrastructure (RPKI) to Router Protocol", RFC 6810,
DOI 10.17487/RFC6810, January 2013, DOI 10.17487/RFC6810, January 2013,
<https://www.rfc-editor.org/info/rfc6810>. <https://www.rfc-editor.org/info/rfc6810>.
[RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility
Procedure for the Resource Public Key Infrastructure
(RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April
2013, <https://www.rfc-editor.org/info/rfc6916>.
[RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent, [RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent,
"Resource Public Key Infrastructure (RPKI) Trust Anchor "Resource Public Key Infrastructure (RPKI) Trust Anchor
Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016, Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016,
<https://www.rfc-editor.org/info/rfc7730>. <https://www.rfc-editor.org/info/rfc7730>.
[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, <https://www.rfc-editor.org/info/rfc7935>. August 2016, <https://www.rfc-editor.org/info/rfc7935>.
skipping to change at page 11, line 11 skipping to change at page 10, line 40
Formats, and Signature Formats", RFC 8208, Formats, and Signature Formats", RFC 8208,
DOI 10.17487/RFC8208, September 2017, DOI 10.17487/RFC8208, September 2017,
<https://www.rfc-editor.org/info/rfc8208>. <https://www.rfc-editor.org/info/rfc8208>.
[RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for [RFC8209] 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", RFC 8209, and Certification Requests", RFC 8209,
DOI 10.17487/RFC8209, September 2017, DOI 10.17487/RFC8209, September 2017,
<https://www.rfc-editor.org/info/rfc8209>. <https://www.rfc-editor.org/info/rfc8209>.
[RFC8210] Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol, Version 1",
RFC 8210, DOI 10.17487/RFC8210, September 2017,
<https://www.rfc-editor.org/info/rfc8210>.
[RFC8360] Huston, G., Michaelson, G., Martinez, C., Bruijnzeels, T.,
Newton, A., and D. Shaw, "Resource Public Key
Infrastructure (RPKI) Validation Reconsidered", RFC 8360,
DOI 10.17487/RFC8360, April 2018,
<https://www.rfc-editor.org/info/rfc8360>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-sidrops-bgpsec-rollover]
Weis, B., Gagliano, R., and K. Patel, "BGPsec Router
Certificate Rollover", draft-ietf-sidrops-bgpsec-
rollover-04 (work in progress), December 2017.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <https://www.rfc-editor.org/info/rfc6480>.
[RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification
Authority (CA) Key Rollover in the Resource Public Key
Infrastructure (RPKI)", BCP 174, RFC 6489,
DOI 10.17487/RFC6489, February 2012,
<https://www.rfc-editor.org/info/rfc6489>.
[RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility
Procedure for the Resource Public Key Infrastructure
(RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April
2013, <https://www.rfc-editor.org/info/rfc6916>.
[RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, [RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,
"The RPKI Repository Delta Protocol (RRDP)", RFC 8182, "The RPKI Repository Delta Protocol (RRDP)", RFC 8182,
DOI 10.17487/RFC8182, July 2017, DOI 10.17487/RFC8182, July 2017,
<https://www.rfc-editor.org/info/rfc8182>. <https://www.rfc-editor.org/info/rfc8182>.
[rsync] "rsync web page", <http://rsync.samba.org/>. [rsync] "rsync web page", <http://rsync.samba.org/>.
Authors' Addresses Authors' Addresses
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
Stephen Kent Stephen Kent
BBN Independent
10 Moulton St
Cambridge, MA 02138-1119
USA
Email: kent@alum.mit.edu Email: kent@alum.mit.edu
 End of changes. 29 change blocks. 
63 lines changed or deleted 83 lines changed or added

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