Internet-Draft Change Publication Server October 2022
Bruijnzeels Expires 27 April 2023 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-timbru-sidrops-change-pubserver-00
Published:
Intended Status:
Informational
Expires:
Author:
T. Bruijnzeels
NLnet Labs

Change Publication Server used by an RPKI CA

Abstract

This draft outlines how Krill, an RPKI CA and Publication Server, implements the process that allows a CA to change the Publication Server it uses, migrating its content from the old server, to the new server's repository.

The current implementation is modelled after the RPKI CA Key Rollover process defined in RFC 6489, except that in this case a new location is used for the new key.

It incudes some discussion about possible improvements to the process.

The goal of this draft is to serve as a starting point for a broader discussion on how RPKI Repository Migration should be done. If adopted as a working group item, the status could be changed to standard or bcp, and the intent would of course be to update the content to reflect working group consensus rather than what happens to have been implemented in Krill at this time.

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 27 April 2023.

Table of Contents

1. Requirements notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Introduction

There are a number of reasons why a CA may wish to migrate from its current Publication Server to a new one.

One reason may be that an organisation is running their own Publication Server, but they wish to migrate to a server operated by their parent (e.g. a Regional Internet Registry). Possibly because their parent did not offer this service when they first set up their CA, but now they do.

Another reason may be that the current Publication Server used by a CA is failing behind in terms of their availability on either the publication protocol [RFC8181], or the public rsync or RRDP [RFC8182] repository compared to other options.

If the current Publication Server has become unavailable, and there is no sign that it will become available again, then that may constitute an even more urgent reason to migrate to a new server.

In this document we explain how Krill, an RPKI CA and Publication Server implementation, currently uses a modified RPKI Key Rollover [RFC6489] process to allow a CA to change the Publication Server used.

3. Migration Process

3.1. Upload new Repository Response

The migration to a new Publication Server is initiated by uploading a new [RFC8183] Repository Response XML for that new server.

When the XML is uploaded the CA verifies that it can communicate with the new server by sending it an [RFC8181] list query. If the query is successful, the new server is accepted and the CA proceeds to the next step.

3.2. Create new Key

The second step in the process is that the CA generates a new key pair, and then requests a new certificate for this key from its parent (using [!@RFC6492]). The Certificate Sign Request for this new key uses the URIs that pertain to the new Publication Server.

3.3. Manifest and CRL for new Key

When the CA receives a certificate for the new key, which uses the new Publication Server, it generates a CRL and Manifest and publishes these at the new server.

RPKI signed objects such as ROAs or possibly CA certificates for its own children are only published under the "current" key. I.e. they are not yet published at the new server. This is similar to step 3 in the CA Key Rollover Procedure defined in section 2 of [!@RFC6489].

3.4. Staging Period

According to step 4, in section 2 of [!@RFC6489] a staging period of at least 24 hours SHOULD be used. The current implementation in Krill leaves this decision to the operators. A shorter period is advisable if the current Publication Server is unavailable.

3.5. Activate new Key

When the new key is activated all RPKI signed objects are published under the new key, and therefore published at the new Publication Server, and they are removed from the current key's manifest and publication point.

This is essentially the same as defined in step 5 of section 2 of [!@RFC6489], except that keys use a different Publication Servers and they will typically use a different [RFC8183] "siabase" and "rrdpnotification_uri".

3.6. Revoke old Key

The final step in the process is that the CA requests revocation of its, previously CURRENT, now OLD key. When this key is revoked the CA removes all content from the OLD publication server for this key.

4. Possible Improvements

4.1. AIA

It should be noted that the AIA URIs for delegated CA certificates will change when the new repository is used, even if the child CA keys and subjects did not change, and even if the produced .cer files have the same name - they will be published in a different publication point.

Relying Parties may warn when AIA URIs in the RPKI signed objects (Manifest, ROAs, etc) and possible certificates (delegated CA or BGPSec Router certificates) published do not match the location of the signing CA certificate in the new publication point, but they would accept them as long as they are otherwise valid.

4.2. Timing Issues

One important thing to note is that the CA needs to publish in two different locations when the new key is activated in the process defined here.

This can lead to timing issues where Relying Parties see equivalent objects under both keys. This happens if they get the NEW objects before seeing them disappear from the OLD key. This is not expected to lead to significant issues.

On the other hand, it may also turn out that the Relying Party sees the objects disappear from under the OLD key, but it has not yet seen the equivalent objects under the NEW key. This can have a big impact. All ROAs would disappear temporarily which could impact routing even if announcements would fall back to the ROV state "Not Found" ([RFC6811]). But, any delegated CA certificates would also disappear (temporarily) and as a consequence any ROAs or other objects published by children. So, if this happens to a CA near the top of the RPKI tree the impact can be quite significant.

For this reason we may want to change the "Activate Key" step to use three separate steps:

  • publish objects under the NEW key,
  • enter a staging period
  • only then remove the objects from the (now OLD) key

4.3. Duplication?

If we would use the staging period mentioned in the previous section, then Relying Parties will find any possible delegated CA certificates under both publication points for some time. Both CA certificates will use the same subject key and SIA values. Therefore, Relying Parties will find the published objects under two paths - and they will appear valid under both.

This will cause RPs to keep more data. This is not expected to be a huge issue.. as any duplicated Validated ROA Prefixes [RFC6811] would be filtered out in the RPKI-RTR protocol ([RFC8210]).

5. IANA Considerations

OID needs to be requested.

6. Security Considerations

TBD

7. Acknowledgements

TBD

8. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[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, , <https://www.rfc-editor.org/info/rfc6489>.
[RFC6811]
Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, , <https://www.rfc-editor.org/info/rfc6811>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8181]
Weiler, S., Sonalker, A., and R. Austein, "A Publication Protocol for the Resource Public Key Infrastructure (RPKI)", RFC 8181, DOI 10.17487/RFC8181, , <https://www.rfc-editor.org/info/rfc8181>.
[RFC8182]
Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, DOI 10.17487/RFC8182, , <https://www.rfc-editor.org/info/rfc8182>.
[RFC8183]
Austein, R., "An Out-of-Band Setup Protocol for Resource Public Key Infrastructure (RPKI) Production Services", RFC 8183, DOI 10.17487/RFC8183, , <https://www.rfc-editor.org/info/rfc8183>.
[RFC8210]
Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1", RFC 8210, DOI 10.17487/RFC8210, , <https://www.rfc-editor.org/info/rfc8210>.

Author's Address

Tim Bruijnzeels
NLnet Labs