| Internet-Draft | Change Publication Server | October 2022 |
| Bruijnzeels | Expires 27 April 2023 | [Page] |
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.¶
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.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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.¶
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.¶
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.¶
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.¶
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].¶
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.¶
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".¶
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.¶
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.¶
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:¶
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]).¶
OID needs to be requested.¶
TBD¶