draft-ietf-sidrops-rp-00.txt   draft-ietf-sidrops-rp-01.txt 
SIDROPS D. Ma SIDROPS D. Ma
Internet-Draft ZDNS Internet-Draft ZDNS
Intended status: Informational S. Kent Intended status: Informational S. Kent
Expires: May 15, 2018 BBN Expires: August 25, 2018 BBN
November 11, 2017 February 21, 2018
Requirements for Resource Public Key Infrastructure (RPKI) Relying Requirements for Resource Public Key Infrastructure (RPKI) Relying
Parties Parties
draft-ietf-sidrops-rp-00 draft-ietf-sidrops-rp-01
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). It cites requirements that appear in several
RPKI RFCs, making it easier for implementers to become aware of these RPKI RFCs, making it easier for implementers to become aware of these
requirements that are segmented with orthogonal functionalities. requirements that are segmented with orthogonal functionalities.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 May 15, 2018. This Internet-Draft will expire on August 25, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
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
skipping to change at page 2, line 20 skipping to change at page 2, line 20
2. Fetching and Caching RPKI Repository Objects . . . . . . . . 3 2. Fetching and Caching RPKI Repository Objects . . . . . . . . 3
2.1. TAL Acquisition and Processing . . . . . . . . . . . . . 4 2.1. TAL Acquisition and Processing . . . . . . . . . . . . . 4
2.2. Locating RPKI Objects Using Authority and Subject 2.2. Locating RPKI Objects Using Authority and Subject
Information Extensions . . . . . . . . . . . . . . . . . 4 Information Extensions . . . . . . . . . . . . . . . . . 4
2.3. Dealing with Key Rollover . . . . . . . . . . . . . . . . 4 2.3. Dealing with Key Rollover . . . . . . . . . . . . . . . . 4
2.4. Dealing with Algorithm Transition . . . . . . . . . . . . 4 2.4. Dealing with Algorithm Transition . . . . . . . . . . . . 4
2.5. Strategies for Efficient Cache Maintenance . . . . . . . 5 2.5. Strategies for Efficient Cache Maintenance . . . . . . . 5
3. Certificate and CRL Processing . . . . . . . . . . . . . . . 5 3. Certificate and CRL Processing . . . . . . . . . . . . . . . 5
3.1. Verifying Resource Certificate and Syntax . . . . . . . . 5 3.1. Verifying Resource Certificate and Syntax . . . . . . . . 5
3.2. Certificate Path Validation . . . . . . . . . . . . . . . 5 3.2. Certificate Path Validation . . . . . . . . . . . . . . . 5
3.3. CRL Processing . . . . . . . . . . . . . . . . . . . . . 5 3.3. CRL Processing . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The RPKI RP software is used by network operators and others to The RPKI RP software is used by network operators and others to
acquire and verify Internet Number Resource (INR) data stored in the acquire and verify Internet Number Resource (INR) data stored in the
RPKI repository system. RPKI data, when verified, allow an RP to RPKI repository system. RPKI data, when verified, allow an RP to
verify assertions about which Autonomous Systems (ASes) are verify assertions about which Autonomous Systems (ASes) are
authorized to originate routes for IP address prefixes. RPKI data authorized to originate routes for IP address prefixes. RPKI data
also establishes binding between public keys and BGP routers, and also establishes binding between public keys and BGP routers, and
indicates the AS numbers that each router is authorized to represent. indicates the AS numbers that each router is authorized to represent.
skipping to change at page 3, line 42 skipping to change at page 3, line 42
o Processing Certificates and CRLs o Processing Certificates and CRLs
o Processing RPKI Repository Signed Objects o Processing RPKI Repository Signed Objects
o Delivering Validated Cache Data to BGP Speakers o Delivering Validated Cache Data to BGP Speakers
This document will be update to reflect new or changed requirements This document will be update to reflect new or changed requirements
as these RFCs are updated, or new RFCs are written. as these RFCs are updated, or new RFCs are written.
2. Fetching and Caching RPKI Repository Objects 2. Fetching and Caching RPKI Repository Objects
RP software uses synchronization mechanisms supported by targeted RP software uses synchronization mechanisms supported by targeted
repositories (e.g., [rsync]) to download all RPKI changed data repositories (e.g., [rsync], RRDP [RFC8182]) to download all RPKI
objects in the repository system and cache them locally. The changed data objects in the repository system and cache them locally.
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 relying party (RP) chooses its own set of trust
anchors (TAs). Consistent with the extant INR allocation hierarchy, anchors (TAs). Consistent with the extant INR allocation hierarchy,
the IANA and/or the five RIRs are obvious candidates to be default the IANA and/or the five RIRs are obvious candidates to be default
TAs for the RP. TAs for the RP.
skipping to change at page 5, line 26 skipping to change at page 5, line 26
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
Certificates in the RPKI are called resource certificates, and they Certificates in the RPKI are called resource certificates, and they
are required to conform to the profile [RFC6487]. An RP is required are required to conform to the profile [RFC6487]. An RP is required
to verify that a resource certificate adheres to the profile to verify that a resource certificate adheres to the profile
established by [RFC6487]. This means that all extensions mandated by established by Section 4 of [RFC6487]. This means that all
[RFC6487] must be present and value of each extension must be within extensions mandated by Section 4.8 of [RFC6487] must be present and
the range specified by this RFC. Moreover, any extension excluded by value of each extension must be within the range specified by this
[RFC6487] must be omitted. RFC. Moreover, any extension excluded by Section 4.8 of [RFC6487]
must be omitted.
Section 7.1 of [RFC6487] gives the procedure that the RP should Section 7.1 of [RFC6487] gives the procedure that the RP should
follow to verify resource certificate and syntax. follow to verify resource certificate and syntax.
3.2. Certificate Path Validation 3.2. Certificate Path Validation
In the RPKI, issuer can only assign and/or allocate public INRs In the RPKI, issuer can only assign and/or allocate public INRs
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
fragility will migrate to the new OIDs
[I-D.ietf-sidr-rpki-validation-reconsidered], informing the RP of
using an alternative RPKI validation algorithm. An RP is expected to
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 [RFC6487]. CRLs in the RPKI are tightly constrained; only the in Section 5 of [RFC6487]. CRLs in the RPKI are tightly constrained;
AuthorityKeyIndetifier and CRLNumber extensions are allowed, and they only the AuthorityKeyIndetifier and CRLNumber extensions are allowed,
MUST be present. No other CRL extensions are allowed, and no and they MUST be present. No other CRL extensions are allowed, and
CRLEntry extensions are permitted. RPs are required to verify that no CRLEntry extensions are permitted. RPs are required to verify
these constraints have been met. Each CRL in the RPI MUST be that these constraints have been met. Each CRL in the RPKI MUST be
verified using the public key from the certificate of the CA that verified using the public key from the certificate of the CA that
issued the CRL. issued the CRL.
In the RPKI, RPs are expected to pay extra attention when dealing In the RPKI, RPs are expected to pay extra attention when dealing
with a CRL that is not consistent with the Manifest associated with with a CRL that is not consistent with the Manifest associated with
the publication point associated with the CRL. the publication point associated with the CRL.
Processing of a CRL that is not consistent with a manifest is a Processing of a CRL that is not consistent with a manifest is a
matter of local policy, as described in the fourth paragraph of matter of local policy, as described in the fourth paragraph of
Section 6.6 of [RFC6486]. Section 6.6 of [RFC6486].
skipping to change at page 7, line 40 skipping to change at page 7, line 48
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
For a given publication point, the RP ought to perform tests to For a given publication point, the RP ought to perform tests, as
determine the state of the Manifest at the publication point. A specified in Section 6.1 of [RFC6486], to determine the state of the
Manifest can be classified as either valid or invalid, and a valid Manifest at the publication point. A Manifest can be classified as
Manifest is either current and stale. An RP decides how to make use either valid or invalid, and a valid Manifest is either current and
of a Manifest based on its state, according to local (RP) policy. stale. An RP decides how to make use of a Manifest based on its
state, according to local (RP) policy.
If there are valid objects in a publication point that are not If there are valid objects in a publication point that are not
present on a Manifest, [RFC6486] does not mandate specific RP present on a Manifest, [RFC6486] does not mandate specific RP
behavior with respect to such objects. However, most RP software behavior with respect to such objects. However, most RP software
ignores such objects and this document recommends that this behavior ignores such objects and this document recommends that this behavior
be adopted uniformly. be adopted uniformly.
In the absence of a Manifest, an RP is expected to accept all valid In the absence of a Manifest, an RP is expected to accept all valid
signed objects present in the publication point. If a Manifest is signed objects present in the publication point. If a Manifest is
stale (see [RFC6486]) and an RP has no way to acquire a more recent stale or invalid (see [RFC6486]) and an RP has no way to acquire a
Manifest, the RP is expected to (TBD). more recently valid Manifest, the RP is expected to contact the
repository manager via Ghostbusters record and thereafter make
decision according to local (RP) policy.
4.4. What to Do with Ghostbusters Information 4.4. What to Do with Ghostbusters Information
An RP may encounter a stale Manifest or CRL, or an expired CA An RP may encounter a stale Manifest or CRL, or an expired CA
certificate or ROA at a publication point. An RP is expected to use certificate or ROA at a publication point. An RP is expected to use
the information from the Ghostbusters record to contact the the information from the Ghostbusters record to contact the
maintainer of the publication point where any stale/expired objects maintainer of the publication point where any stale/expired objects
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.
skipping to change at page 8, line 30 skipping to change at page 8, line 40
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].
6. Security considerations 6. Security considerations
TBD The RP links the RPKI provisioning side and the routing system,
establishing the local view of global RPKI data to BGP speakers. The
security of the RP is critical to BGP messages exchanging. The RP
implementation is expected to offer cache backup management to
facilitate recovery from outage state. The RP implementation also
should support application of secure transport (e.g., IPsec) 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 33 skipping to change at page 11, line 13
<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>.
9.2. Informative References 9.2. Informative References
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support [RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, "The RPKI Repository Delta Protocol (RRDP)", RFC 8182,
February 2012, <https://www.rfc-editor.org/info/rfc6480>. DOI 10.17487/RFC8182, July 2017,
<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
 End of changes. 16 change blocks. 
36 lines changed or deleted 59 lines changed or added

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