draft-ietf-sidrops-rp-02.txt   draft-ietf-sidrops-rp-03.txt 
SIDROPS D. Ma SIDROPS D. Ma
Internet-Draft ZDNS Internet-Draft ZDNS
Intended status: Informational S. Kent Intended status: Informational S. Kent
Expires: February 21, 2019 Independent Expires: August 1, 2019 Independent
August 20, 2018 January 28, 2019
Requirements for Resource Public Key Infrastructure (RPKI) Relying Requirements for Resource Public Key Infrastructure (RPKI) Relying
Parties Parties
draft-ietf-sidrops-rp-02 draft-ietf-sidrops-rp-03
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) in the context of securing Internet routing. Infrastructure (RPKI) in the context of securing Internet routing.
It cites requirements that appear in several RPKI RFCs, making it It cites requirements that appear in several RPKI RFCs, making it
easier for implementers to become aware of these requirements that easier for implementers to become aware of these requirements that
are segmented with orthogonal functionalities. are segmented with orthogonal functionalities.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 February 21, 2019. This Internet-Draft will expire on August 1, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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 31 skipping to change at page 2, line 31
3.3. CRL Processing . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . . . 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. Distributing Validated Cache . . . . . . . . . . . . . . . . 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
skipping to change at page 3, line 18 skipping to change at page 3, line 18
practices, as follows: 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 7935 (Algorithms) RFC 7935 (Algorithms)
RFC 8209 (Router Certificates) RFC 8209 (Router Certificates)
RFC 8210 (RPKI to Router Protocol,Version 1) RFC 8210 (RPKI to Router Protocol,Version 1)
RFC 8360 (Certificate Validation Procedure) RFC 8360 (Certificate Validation Procedure)
I-D.ietf-sidrops-https-tal (Trust Anchor Locator)
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 'the role of the generalized RP requirements is going to help have 'the role of the
RP' well 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
o Delivering Validated Cache Data to BGP Speakers o Distributing Validated Cache of the RPKI Data
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], 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
skipping to change at page 4, line 18 skipping to change at page 4, line 18
In the RPKI, each RP chooses its own set of trust anchors (TAs). In the RPKI, each RP chooses its own set of trust anchors (TAs).
Consistent with the extant INR allocation hierarchy, the IANA and/or Consistent with the extant INR allocation hierarchy, the IANA and/or
the five RIRs are obvious candidates to be default TAs for the RP. the five RIRs are obvious candidates to be default 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 TA. each TA.
TAL acquisition and processing are specified in Section 3 of TAL acquisition and processing are specified in Section 3 of
[RFC7730]. [I-D.ietf-sidrops-https-tal].
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 Subject Information Access (SIA) and the Authority points using the Subject Information Access (SIA) and the Authority
Information Access (AIA) extensions from (validated) certificates. Information Access (AIA) extensions from (validated) certificates.
skipping to change at page 8, line 29 skipping to change at page 8, line 29
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.
5. Delivering Validated Cache to BGP Speakers 5. Distributing Validated Cache
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 validated cache
The RP passes this information to BGP speakers to enable them to of RPKI data. The RP may either transfer the validated data to the
verify the authenticity of routing announcements. The specification BGP speakers directly, or it may transfer the validated data to a
of the protocol designed to deliver validated cache data from an RP cache server that is responsible for provisioning such data to BGP
to a BGP Speaker is provided in [RFC6810] and [RFC8210]. speakers. The specification of the protocol designed to deliver
validated cache data 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 should support application of secure transport (e.g., IPsec
[RFC4301]) that is able to protect validated cache delivery in a [RFC4301]) that is able to protect validated cache delivery in a
skipping to change at page 9, line 19 skipping to change at page 9, line 19
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-sidrops-https-tal]
Huston, G., Weiler, S., Michaelson, G., Kent, S., and T.
Bruijnzeels, "Resource Public Key Infrastructure (RPKI)
Trust Anchor Locator", draft-ietf-sidrops-https-tal-06
(work in progress), January 2019.
[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 19 skipping to change at page 10, line 24
[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>.
[RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent,
"Resource Public Key Infrastructure (RPKI) Trust Anchor
Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016,
<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>.
[RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key [RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key
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>.
 End of changes. 13 change blocks. 
20 lines changed or deleted 23 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/