wdiff draft-ietf-sidrops-rp-06.original draft-ietf-sidrops-rp-07-xml2.txt

SIDROPS D. Ma
Internet-Draft ZDNS
Intended status: Informational S. Kent
Expires: April 9, November 14, 2020 Independent
October 7, 2019
May 13, 2020

Requirements for Resource Public Key Infrastructure (RPKI) Relying
Parties
draft-ietf-sidrops-rp-06
draft-ietf-sidrops-rp-07

Abstract

This document provides a single reference point for requirements for
Relying Party (RP) software for use in the Resource Public Key
Infrastructure (RPKI) in the context of securing Internet routing. (RPKI). It cites requirements that appear in several
RPKI RFCs, making it easier for implementers to become aware of these requirements
requirements. This document will be updated to reflect changes in
the RFCs that
are segmented with orthogonal functionalities. it cites as normative.

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 9, November 14, 2020.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Fetching and Caching RPKI Repository Objects . . . . . . . . 3
2.1. TAL Acquisition Configuration and Processing . . . . . . . . . . . . . 4
2.2. Locating RPKI Objects Using Authority and Subject
Information Extensions . . . . . . . . . . . . . . . . . 4
2.3. Dealing with Key Rollover . . . . . . . . . . . . . . . . 4
2.4. Dealing with Algorithm Transition . . . . . . . . . . . . 4
2.5. Strategies for Efficient Cache Maintenance . . . . . . . 5
3. Certificate and CRL Processing . . . . . . . . . . . . . . . 5
3.1. Verifying Resource Certificate and Syntax . . . . . . . . 5
3.2. Certificate Path Validation . . . . . . . . . . . . . . . 5
3.3. CRL Processing . . . . . . . . . . . . . . . . . . . . . 6
4. Processing RPKI Repository Signed Objects . . . . . . . . . . 6
4.1. Basic Signed Object Syntax Checks . . . . . . . . . . . . 6
4.2. Syntax and Validation for Each Type of Signed Object . . 6
4.2.1. Manifest . . . . . . . . . . . . . . . . . . . . . . 6
4.2.2. ROA . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.3. Ghostbusters . . . . . . . . . . . . . . . . . . . . 7
4.2.4. Verifying BGPsec Router Certificate . . . . . . . . . 7
4.3. How to Make Use of Manifest Data . . . . . . . . . . . . 7 8
4.4. What to Do with Ghostbusters Information . . . . . . . . 8
5. Distributing Validated Cache . . . . . . . . . . . . . . . . 8
6. Local Control . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12

1. Introduction

The

RPKI Relying Party (RP) software is used by network operators and
others to acquire and verify Internet Number Resource (INR) data
stored in the RPKI repository system. RPKI data, when verified,
allow
allows an RP to verify assertions about which Autonomous Systems
(ASes) are authorized to originate routes for IP address prefixes.
RPKI data also establishes a binding between public keys and BGP
routers, and indicates the AS numbers that each router is authorized
to represent.

Noting that the

The essential requirements imposed on RPs RP software to support securing
Internet routing ([RFC6480]) are scattered throughout numerous RFC
documents that are protocol specific protocol-specific or provide best
practices, as follows: practices. The
following RFCs define these requirements (or best practices):

RFC 6481 (Repository Structure)
RFC 6482 (ROA format)
RFC 6486 (Manifests)
RFC 6487 (Certificate and CRL profile)
RFC 6488 (RPKI Signed Objects)
RFC 6489 (Key Rollover)
RFC 6810 (RPKI to Router Protocol)
RFC 6916 (Algorithm Agility)
RFC 7935 (Algorithms)
RFC 8209 (Router Certificates)
RFC 8210 (RPKI to Router Protocol,Version 1)
RFC 8360 (Certificate Validation Procedure)
RFC 8630 (Trust Anchor Locator)

This

The distribution of RPKI RP requirements across these 13 documents
makes it hard for an implementer to be confident that he/she has
addressed all of these generalized requirements. Besides, Additionaly, good software
engineering calls practice may call for how to segment segmenting the RP system into
components with orthogonal functionalities, so that those components could
may be
distributed across the operational timeline distributed. A taxonomy of the user. Taxonomy of
generalized collected RP software
requirements is going to can help have 'the clarify the role of the
RP' well framed. RP.

To consolidate RP software requirements in one document, with
pointers to all the relevant RFCs, this document outlines a set of
baseline requirements imposed on RPs and provides a single reference
point for requirements for RP software for use in the RPKI, as segmented with
orthogonal functionalities: RPKI. The
requirements are organized into four groups:

o Fetching and Caching RPKI Repository Objects
o Processing Certificates and CRLs
o Processing RPKI Repository Signed Objects
o Distributing Validated Cache of the RPKI Data

This document will be update updated to reflect new or changed requirements
as these RFCs are updated, or new additional RFCs are written.

2. Fetching and Caching RPKI Repository Objects

RP software uses synchronization mechanisms supported by targeted
repositories (e.g., [rsync], [rsync] or RRDP [RFC8182]) to download all RPKI
changed data
signed objects in from the repository system and cache them locally.
The system, in order to update a local
cache. These mechanisms download only those objects that have been
added, or replaced with new versions, since the time when the RP most
recently checked the repository. RP software validates the RPKI data
and uses it to generate authenticated data identifying which ASes are
authorized to originate routes for address prefixes, and which
routers are authorized to sign BGP updates on behalf of specified
ASes.

2.1. TAL Acquisition Configuration and Processing

In the RPKI, each RP chooses its own a set of trust anchors (TAs).
Consistent with the extant INR allocation hierarchy, the IANA and/or
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
(TALs) is used by each RP software to retrieve and verify the authenticity
of each TA.

TAL acquisition configuration and processing are specified in Section 3 of
[RFC8630].

2.2. Locating RPKI Objects Using Authority and Subject Information
Extensions

The

TThe RPKI repository system is a distributed one, consisting of
multiple repository instances. Each repository instance contains one
or more repository publication points. An RP software discovers
publication points using the Subject Information Access (SIA) and the
Authority Information Access (AIA) extensions from (validated)
certificates.

Section 5 of [RFC6481] specifies how an RP software locates all RPKI objects
by
objectsby using the SIA and AIA extensions. Detailed specifications
of SIA and AIA extensions in a resource certificate are described in
Section 4 4.8.8 of [RFC6487]. [RFC6481] and Section 4.8.7 of [RFC6481]
respectively.

2.3. Dealing with Key Rollover

RP software takes the key rollover period into account with regard to
its frequency of synchronization with the RPKI repository system.

RP software requirements in for dealing with key rollover are described
in Section 3 of [RFC6489] and Section 3 of [RFC8634].

2.4. Dealing with Algorithm Transition

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
established for the algorithm transition and what actions are
required at every juncture.

RP software requirements for dealing with algorithm transition are
specified in Section 4 of [RFC6916].

2.5. Strategies for Efficient Cache Maintenance

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
publication point data as the RP's frequency of checking permits.

The last paragraph of Section 5 of [RFC6481] provides guidance for
maintenance of a local cache.

3. Certificate and CRL Processing

The RPKI make makes use of X.509 certificates and CRLs, but it profiles
these standard formats [RFC6487]. The major change to the profile
established in [RFC5280] is the mandatory use of a new extension to
X.509 certificate in
RPKI certificates, defined in [RFC3779].

3.1. Verifying Resource Certificate and Syntax

Certificates in the RPKI are called resource certificates, and they
are required to conform to the profile [RFC6487]. An RP is required
to verify that a resource certificate adheres to the profile
established by Section 4 of [RFC6487]. This means that all
extensions mandated by Section 4.8 of [RFC6487] must be present and
the value of each extension must be within the range specified by this
RFC.
[RFC6487]. Moreover, any extension excluded by Section 4.8 of
[RFC6487] must be omitted.

Section 7.1 of [RFC6487] gives specifies the procedure that the RP should
follow to verify resource certificate and syntax. software
follows when verifying [RFC3779] extensions.

3.2. Certificate Path Validation

The

Initially, the INRs in issuer's certificate are required to encompass
the INRs in the subject's certificate. This is one of the necessary
principles of certificate path validation in addition to
cryptographic verification i.e., verification of the signature on
each certificate using the public key of the parent certificate).

Section 7.2 of [RFC6487] gives specifies the procedure that the RP software
should follow to perform certificate path validation.

Certificate

Certification Authorities that want to reduce aspects of operational
fragility will migrate to the new OIDs [RFC8360], informing the RP of
using
software to use an alternative RPKI validation algorithm. An RP is
expected to support the amended procedure to handle with accidental over-claim.
overclaiming, which is described in Section 4 of [RFC8360].

3.3. CRL Processing

The CRL processing requirements imposed on CAs and RP are described
in Section 5 of [RFC6487]. CRLs in the RPKI are tightly constrained;
only the AuthorityKeyIndetifier AuthorityKeyIndentifier (Section 4.8.3 of [[RFC6487]) and CRLNumber
CRLNumber(Section 5.2.3 of [RFC5280]) extensions are allowed, and
they are required to be present. No other CRL extensions are
allowed, and no CRLEntry extensions are permitted. RPs are RP software is
required to verify 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 issued the CRL.

In the RPKI, RPs are expected to pay extra attention when dealing
with a CRL that is not consistent with the Manifest associated with
the publication point associated with the CRL.

Processing of a CRL that is not consistent with a manifest is a
matter of local policy, as described in the fourth fifth paragraph of
Section 6.6 of [RFC6486].

4. Processing RPKI Repository Signed Objects

4.1. Basic Signed Object Syntax Checks

Before an RP can use a signed object from the RPKI repository, the RP
software is required to check the signed object syntax.

Section 3 of [RFC6488] lists all the steps that the RP software is
required to execute in order to validate the top level syntax of a
repository signed object.

Note that these checks are necessary, but not sufficient. Additional
validation checks must be performed based on the specific type of
signed object. object as described in Section 4.2.

4.2. Syntax and Validation for Each Type of Signed Object

4.2.1. Manifest

To determine whether a manifest is valid, the RP software is required to
perform manifest-specific checks in addition to those the generic signed
object checks specified in [RFC6488].

Specific checks for a Manifest are described in Section 4 of
[RFC6486]. If any of these checks fails, indicating that the
manifest is invalid, then the manifest will be discarded and treated RP
software will act as though no manifest were present.

4.2.2. ROA

To validate a ROA, the RP software is required to perform all the checks
specified in [RFC6488] as well as the additional additional, ROA-specific validation
steps. The IP address delegation extension [RFC3779] present in the
end-entity (EE) certificate (contained within the ROA), must
encompass each of the IP address prefix(es) in the ROA.

More details for ROA validation are specified in Section 4 of
[RFC6482].

4.2.3. Ghostbusters

The Ghostbusters Record is optional; a publication point in the RPKI
can have zero or more associated Ghostbuster Records. If a CA has at
least one Ghostbuster Record, RP software is required to verify that
this Ghostbusters Record conforms to the syntax of signed object
defined in [RFC6488].

The payload of this signed object is a (severely) profiled vCard. An RP
software is required to verify that the payload of Ghostbusters
conforms to format as profiled in [RFC6493].

4.2.4. Verifying BGPsec Router Certificate

A BGPsec Router Certificate is a resource certificate, so it is
required to comply with [RFC6487]. Additionally, the certificate
must contain an AS Identifier Delegation extension, extension (Section 4.8.11 of
[RFC6487]), and must not contain an IP Address Delegation extension. extension
(Section 4.8.10 of [RFC6487]). The validation procedure used for
BGPsec Router Certificates is identical analogous to the validation procedure
described in Section 7 of [RFC6487], but using it uses the constraints applied come from specification of
defined in Section 7 3 of [RFC8209].

Note that the cryptographic algorithms used by BGPsec routers are
found in [RFC8208]. Currently, the algorithms specified in
[RFC8208]and [RFC8208]
and [RFC7935] are different. BGPsec RPs RP software will need to support
algorithms that are used to validate BGPsec signatures as well as the
algorithms that are needed to validate signatures on BGPsec
certificates, RPKI CA certificates, and RPKI CRLs.

4.3. How to Make Use of Manifest Data

For a given publication point, the RP software ought to perform tests, as
specified in Section 6.1 of [RFC6486], to determine the state of the
Manifest at the publication point. A Manifest can be classified as
either valid or invalid, and a valid Manifest is either current and or
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
present on a Manifest, [RFC6486] does not mandate specific RP
behavior with respect to such objects. However, most RP software
ignores such objects and the authors of this document suggest this
behavior be adopted uniformly.

In the absence of a Manifest, an RP is expected to accept all valid
signed objects present in the publication point. point (see Section 6.2 of
[RFC6486]). If a Manifest is stale or invalid (see [RFC6486]) and an RP has no way
to acquire a more recently recent valid Manifest, the RP is expected to
contact the repository manager via Ghostbusters record and thereafter
make
decision decisions according to local (RP) policy. policy (see Section 6.3 of
[RFC6486] and Section 6.4 of [RFC6486]).

4.4. What to Do with Ghostbusters Information

RP software may encounter a stale Manifest or CRL, or an expired CA
certificate or ROA at a publication point. An RP is expected to use
the information from the Ghostbusters record to contact the
maintainer of the publication point where any stale/expired objects
were encountered. The intent here is to encourage the relevant CA
and/or repository manager to update the slate stale or expired objects.

5. Distributing Validated Cache

On a periodic basis, BGP speakers within an AS request updated
validated origin AS data and router/ASN data from the (local)
validated cache of RPKI data. The RP may either transfer the
validated data to the BGP speakers directly, or it may transfer the
validated data to a cache server that is responsible for provisioning
such data to BGP speakers. The specification specifications of the protocol
designed to deliver validated cache data to a BGP Speaker is provided
in [RFC6810] and [RFC8210].

6. Local Control

ISPs may want to establish a local view of exceptions to the RPKI
data in the form of local filters and additions. For instance, a
network operator might wish to make use of a local override
capability to protect routes from adverse actions [RFC8211] . [RFC8211]. The
mechanisms developed to provide this capability to network operators
are called "Simplified Local Internet Number Resource Management with
the RPKI (SLURM). If an ISP wants to implement SLURM, its RP system
can follow the instruction specified in [RFC8416] . [RFC8416].

7. Security Considerations

This document doesn't introduce any new security considerations; it
is a resource for implementers. The RP links the RPKI provisioning
side and the routing system, establishing the a verified, local view of
global RPKI data to BGP speakers. The security of the RP is critical
to BGP messages exchanging. The exchanges. Each RP implementation is expected to
offer cache backup management to facilitate recovery from outage state. The outages.
RP implementation software also should support application of secure transport
(e.g., IPsec [RFC4301]) that is able to protect validated cache
delivery in a unsafe environment. This document highlights many
validation actions applied to RPKI signed objects, an essential
element of secure operation of RPKI security.

8. IANA Considerations

This document has no actions for IANA.

9. Acknowledgements

The authors thank David Mandelberg, Wei Wang, Tim Bruijnzeels, George
Michaelson and Oleg Muravskiy for their review, feedback and
editorial assistance in preparing this document.

10. References

10.1. Normative References

[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779,
DOI 10.17487/RFC3779, June 2004,
<https://www.rfc-editor.org/info/rfc3779>.

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.

[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for
Resource Certificate Repository Structure", RFC 6481,
DOI 10.17487/RFC6481, February 2012,
<https://www.rfc-editor.org/info/rfc6481>.

[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)", RFC 6482,
DOI 10.17487/RFC6482, February 2012,
<https://www.rfc-editor.org/info/rfc6482>.

[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski,
"Manifests for the Resource Public Key Infrastructure
(RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012,
<https://www.rfc-editor.org/info/rfc6486>.

[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487,
DOI 10.17487/RFC6487, February 2012,
<https://www.rfc-editor.org/info/rfc6487>.

[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object
Template for the Resource Public Key Infrastructure
(RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012,
<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)
Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493,
February 2012, <https://www.rfc-editor.org/info/rfc6493>.

[RFC6810] Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol", RFC 6810,
DOI 10.17487/RFC6810, January 2013,
<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>.

[RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for
Algorithms and Key Sizes for Use in the Resource Public
Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935,
August 2016, <https://www.rfc-editor.org/info/rfc7935>.

[RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key
Formats, and Signature Formats", RFC 8208,
DOI 10.17487/RFC8208, September 2017,
<https://www.rfc-editor.org/info/rfc8208>.

[RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for
BGPsec Router Certificates, Certificate Revocation Lists,
and Certification Requests", RFC 8209,
DOI 10.17487/RFC8209, September 2017,
<https://www.rfc-editor.org/info/rfc8209>.

[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>.

[RFC8630] Huston, G., Weiler, S., Michaelson, G., Kent, S., and T.
Bruijnzeels, "Resource Public Key Infrastructure (RPKI)
Trust Anchor Locator", RFC 8630, DOI 10.17487/RFC8630,
August 2019, <https://www.rfc-editor.org/info/rfc8630>.

[RFC8634] Weis, B., Gagliano, R., and K. Patel, "BGPsec Router
Certificate Rollover", BCP 224, RFC 8634,
DOI 10.17487/RFC8634, August 2019,
<https://www.rfc-editor.org/info/rfc8634>.

10.2. Informative References

[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>.

[RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,
"The RPKI Repository Delta Protocol (RRDP)", RFC 8182,
DOI 10.17487/RFC8182, July 2017,
<https://www.rfc-editor.org/info/rfc8182>.

[RFC8211] Kent, S. and D. Ma, "Adverse Actions by a Certification
Authority (CA) or Repository Manager in the Resource
Public Key Infrastructure (RPKI)", RFC 8211,
DOI 10.17487/RFC8211, September 2017,
<https://www.rfc-editor.org/info/rfc8211>.

[RFC8416] Ma, D., Mandelberg, D., and T. Bruijnzeels, "Simplified
Local Internet Number Resource Management with the RPKI
(SLURM)", RFC 8416, DOI 10.17487/RFC8416, August 2018,
<https://www.rfc-editor.org/info/rfc8416>.

[RFC8634] Weis, B., Gagliano, R., and K. Patel, "BGPsec Router
Certificate Rollover", BCP 224, RFC 8634,
DOI 10.17487/RFC8634, August 2019,
<https://www.rfc-editor.org/info/rfc8634>.

[rsync] "rsync web page", <http://rsync.samba.org/>.

Authors' Addresses

Di Ma
ZDNS
4 South 4th St. Zhongguancun
Haidian, Beijing 100190
China

Email: madi@zdns.cn

Stephen Kent
Independent

Email: kent@alum.mit.edu