| Internet-Draft | Publication Protocol V2 | October 2022 |
| Bruijnzeels | Expires 27 April 2023 | [Page] |
The RPKI Publication Protocol first described in RFC 8181 has worked very well. That said, as it turns out, there are a number of requirements emerging from operational experience which cannot be supported by the current protocol. In particular, identity key roll overs, support for publication quota and stricter verification of content by the server.¶
This document is an early write-up with the following goals: (1) support discussions about requirements for additional work and (2) explore a possible version 2 with solutions to meet those requirements.¶
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.¶
The RPKI Publication Protocol first described in RFC 8181 has worked very well. At the time of this writing, there are at least four completely independent interoperable software implementations, and over 50 separate deployments. At least one server deployment has well over 1000 remote publishers communicating to it using the RFC 8181 protocol.¶
That said, as it turns out, there are a number of requirements emerging from operational experience which cannot be supported by the current protocol. In particular, identity key roll overs, support for publication quota and stricter verification of content by the server.¶
This document is an early write-up with the following goals: (1) support discussions about requirements for additional work and (2) explore a possible version 2 with solutions to meet those requirements.¶
It should be noted that a key feature in the possible solution discussed in this document is the support for seamless version negotiations between publishers (RPKI Certification Authorities) and the RPKI Publication Server. Any version 2 capable publisher will simply continue to use version 1 (RFC 8181) if the Publication Server is not capable to do version 2, and vice versa, version 2 capable servers will simply continue to use version 1 for version 2 non-capable publishers. This is important because it allows for incremental deployment of this new version without the need for centralised coordination on upgrades.¶
An RPKI Certification Authority which implements the client side of the protocol defined in this document - i.e. it uses a 'server' to publish its RPKI content.¶
Publishers and servers can negotiate whether to use V1 or V2 without requiring either party to implement V2. This is important because it allows for incremental deployment of V2 without the need for centralised coordination.¶
For this reason all V2 capable Publishers and Servers SHOULD also support V1. An exception can be made if the Publisher and Server have prior knowledge that both support V2, in which case this protocol version negotiation is not applicable.¶
Given that Publishers contact the Server in V1 over an HTTP based client- server protocol, we can leverage HTTP "Accept" and "Content-Type" headers to support version negotiation.¶
The Publisher MUST use V1 queries as long as the Server is not known to be V2 capable. The publisher SHOULD initiate version negotiation whenever it sends any V1 query by including the following additional HTTP header:¶
Accept: application/rpki-publication, application/rpki-publication-v2¶
If the Server is not V2 capable then it can ignore this header and respond with the normal applicable V1 reply which will include a Content-Type header with the value "application/rpki-publication".¶
If the server supports V2 then it MUST respond with a V2 "Repository Info Reply" and use a Content-Type header with the value "application/rpki-publication-v2", instead of performing any action that would normally be done in response to the V1 query. The Publisher MUST then proceed to use V2 for subsequent queries using the (possibly new) service URI in that reply.¶
In case a server receives a V2 request, and for some reason it no longer supports V2, then it may be expected according to [RFC8181] that a V1 <report_error/> is returned and the content type "application/rpki-publication" is used in the response.¶
If the Publisher gets the V1 content type "application/rpki-publication" in response to any V2 request that it sent, then it MUST fall back to using using the V1 protocol. But, it MAY continue to initiate protocol version negotiation as described above in future requests.¶
The publication protocol uses a simple request/response interaction over HTTPS. We will refer to requests sent by the publisher as 'queries', and we will refer to responses returned by the server as 'replies'.¶
All queries and replies MUST use the Content-Type header. The value of this header MUST be:¶
application/rpki-publication-v2¶
Queries and replies are RPKI Publication Protocol Version 2 Messages, which are signed Cryptographic Message Syntax (CMS) messages. The CMS encapsulation is similar to the definition in V1 (section 2 of [RFC8181]), and almost identical to that used in Section 3.1 of [RFC6492], with the following notable differences.¶
A key difference with the eContent specification from Section 3.1.1.3.2 of [RFC6492] is that we will use DER encoded content here, rather than the XML message content that is used in [RFC6492] and [RFC8181].¶
Note that one of the reasons for preferring DER over XML is that it will allow for more concise messages. For example V1 uses base64 encoded (DER) objects wrapped in XML for publication queries. This is rather wasteful.¶
Another reason is that we may benefit from formal ASN.1 notations, rather than XML schema definitions. While ASN.1 may not be very widely known in general, implementing Publishers and Servers are already required to understand and deal with ASN.1 and DER in many other parts of this protocol, and the RPKI standards in general, so using it here does not seem to place a huge additional burden.¶
On the other hand, it is understood that the threshold to implement may be lower if XML is used as it will require fewer changes in existing code. So, this idea is not cast in stone.¶
eContent ::= SEQUENCE {
nonce UUID,
MessageType MessageType,
MessageContent [0] EXPLICIT OCTET STRING OPTIONAL,
}
UUID ::= OCTET STRING (SIZE(16))
-- constrained to a UUID
MessageType ::= PrintableString (SIZE (1..32))
MessageContent ::= OCTET STRING
-- constrained to DER encoded message type
-- specific content - specified in the relevant
-- sections of this document.
¶
Note that each query and response type defined in this document will specify its own MessageType value and MessageContent definition.¶
Because we no longer use XML based eContent, we will also use a new eContentType OID, rather the value defined in Section 3.1.1.3.1 of [RFC6492].¶
The eContentType for the RPKI Publication Protocol Version 2 Message object is defined as "To be determined", and has numerical value of "To be determined". TODO: Request OID from IANA.¶
Single use EE certificates MUST be used in the CMS wrapper. Each EE certificate MUST use a new unique key-pair. As specified in [RFC6492] either the signing-time attribute, or binary-signing-time attribute, or both attributes MUST be present. Their values MUST represent the actual time of signing the CMS.¶
The EE certificate SHOULD use a 'notBefore' time that is set to 5 minutes before the signing time, and a 'notAfter' time that is set to 5 minutes after the signing time. The reason for this is there may be a small amount of clock skew between a publisher and server, and because the protocol messages are generated moments before they are sent, small time differences could lead to rejection of all messages. Note that this protocol uses additional measures to protect against replays.¶
The publisher MUST generate a new unique UUID that will be used as the nonce value for any query that it sends to the server. The server MUST keep track of received nonce values for all received queries for which the EE certificate is not yet expired, and the server MUST reject any query that is found to re-use any such existing nonce.¶
The server MUST use the nonce value from the applicable query whenever it generates a reply for that query. The publisher MUST verify that the nonce is any reply matches the query that they sent, and MUST reject the reply if this is not the case.¶
All protocol exchanges are initiated by the Publisher. In a typical exchange the Publisher sends a specific type of Query and then gets a matching Reply from the Server in response.¶
There are a number of generic replies that the server could return in response to a query:¶
The server MAY enforce a rate limit on publisher connections. If the server does this, then it SHOULD enforce rate limits on a per publisher basis in order to avoid that a bad actor publisher can impact other publishers. Furthermore, if a rate limit is used then it MUST be included in the Status Reply to publishers.¶
One of the main motivations for rate limiting publisher connections is to protect the server from resource exhaustion because of publisher query parsing and validation, and generating and signing replies.¶
For this reason the rate limit response will use a plain "429 Too Many Requests" response (section 4 of [RFC6585]) in case the rate limit threshold is set. If a rate limit response is sent then the query MUST NOT be processed by the server.¶
When a publisher encounters a rate limit response, then it MUST NOT try to contact the server again for at least the last known rate limit period received in a status reply, or 5 minutes if no such limit is known to the publisher.¶
The server SHOULD return a '404 Not Found' response ([RFC9110]) if a publisher is not known.¶
Note that all publishers SHOULD each get a unique unguessable service URI in their initial [RFC8183] response so that the server can efficiently determine that a publisher is unknown. Strictly speaking it is possible to guess which publisher sent a message by looking at the Authority Key Identifier of the embedded EE certificate in a query message CMS wrapper, but doing so would be extremely inefficient and leave the server vulnerable to denial of service attacks.¶
This type of Reply is used in case of general issues with the request that was sent, rather than the content of the query in the request CMS.¶
The server SHOULD return a '400 Bad Request' response ([RFC9110]) in case the protocol message could not be parsed or validated. The message body MAY contain a clear text hint as a courtesy to the publisher. The message MUST NOT be longer 128 characters, SHOULD use visible 7-bit ASCII characters, and SHOULD be written in english.¶
Theoretically, we could have the server return detailed and signed error replies. However, this (signing) would cause load on the server and could be abused as an attack vector, and on top of that detailed errors could aid malicious attackers.¶
The following fairly minimal message bodies are RECOMMENDED for error conditions:¶
| message | explanation |
|---|---|
| "invalid syntax" | Message could not be parsed |
| "replay detected" | Message may be valid, but was seen before |
| "key unknown" | Message EE AKI does not match key for publisher |
| "not yet valid" | Message EE not-before is after now |
| "expired" | Message EE not-after is before now |
| "message invalid" | Message validation failed for some other reason |
Publishers SHOULD log any Bad Request Response in a way that would be visible to the operators of the publisher, because in many cases manual intervention will be required to resolve the issue.¶
If the error is caused by "message key unknown" then this is indicative of an issue where the publisher and server are out-of-sync with regards to the BPKI TA key pair used by the publisher. In this case the operator of the publisher should try to re-exchanges [RFC8183] XML with the server.¶
Other errors are most likely caused by clock skew, or a bug on either the publisher or server side. Because the issue could be on the server side and be fixed there, the publisher SHOULD keep retrying to contact the server albeit with the same timing constrains as mentioned in relation to Rate Limit Responses.¶
The server SHOULD NOT return any 5xx type HTTP error responses. However, this kind of response can occur as a result of an unrecoverable error at the server.¶
Publishers SHOULD treat any 5xx responses they encounter as though they were Rate Limit Responses, but it is RECOMMENDED that they are logged in order to help debugging should they persist.¶
Note that exchanges define their own typed error replies where applicable. That said, the server SHOULD return a General Server Error Reply in case it encountered some unexpected error that it could recover from.¶
Publisher MUST treat this type of reply similar to a 5xx response.¶
The MessageType for this query is: "general-server-error"¶
This response MAY include a human readable, preferably english, error message directed at operators. Note that the publisher software can only log this information, but it cannot take any specific action based on the content.¶
MessageContent ::= PrintableString(SIZE (0..127))¶
The Ok Reply is used in some exchanges where the server wants to inform the publisher that their query was successfully processed, but there is no additional information to include in the response.¶
The MessageType for this query is: "ok-reply"¶
There is no content to include for this reply.¶
The reply of this exchange is used in protocol version negotiation and serves to inform the Publisher about the possibly new service URI that it should use for V2, as well as further applicable constrains.¶
The Publisher MAY initiate a new repository info exchange later, but the response SHOULD NOT change over time, with the possible exception of the value of "SupportedTypes". (perhaps that means that does not belong here)¶
Publisher ---- Repository Info Query -----> Server
<--- Repository Info Reply ------
¶
The MessageType for this query is "repository-info-query", and the MessageContent is omitted.¶
The MessageType for this reply is "repository-info-reply", and the MessageContent is as follows:¶
MessageContent ::= SEQUENCE {
ServiceUri [0] ServiceUri,
RsyncModuleUri [1] RsyncModuleUri,
BasePath [2] BasePath,
RrdpNotifyUri [3] RrdpNotifyUri OPTIONAL,
SupportedTypes [4] SupportedTypes OPTIONAL,
}
HttpsUri ::= IA5String
-- Constrained to an HTTPS URI
BasePath ::= IA5String,
-- relative base path for the publisher
RsyncModuleUri ::= IA5String
-- Constrained to an rsync URI
-- MUST end with a slash and refer to the base
-- directory of the publication server's
-- rsync module.
RrdpNotifyUri ::= IA5String
-- Constrained to an HTTP(s) URI
-- MUST refer to the RRDP Notification URI [RFC8182]
-- for this publication server.
SupportedTypes ::= SEQUENCE (SIZE(1..MAX)) OF RpkiObjectType
RpkiObjectType ::= PrintableString (SIZE (4))
-- Constrained to a '.' character followed
-- by a three letter extension specified in
-- the IANA "RPKI Repository Name Scheme" registry
¶
Contains the unique service URI for this publisher. If this is a new URI, then it MUST be on the same host (avoid key theft and MiTM redirecting publishers).¶
V2 will require unique URIs so that we do not need to send publisher handles in each query but can do it as a path parameter. It also allows more efficient processing for unknown publishers and per publisher rate limits to be enforced more intuitively and without the need for object parsing which could be a DoS vector otherwise.¶
This is an rsync URI [RFC5781] pointing to the base rsync module used by the publication server.¶
This is the relative base path under the rsync module where the querying publisher is allowed to publish their objects. The BasePath MUST NOT be empty if the server supports multiple publishers.¶
The BasePath MUST be a unix style relative directory path. It MUST use the following ABNF syntax [RFC5234]:¶
BasePath = empty / sub-dir empty = "" sub-dir = dir *(dir) dir = *(DIGIT / ALPHA / "-" / "_" ) "/"¶
Note that publishers will specify relative object paths under their base path during the publication exchange defined below to ensure that all objects are always constrained to the publishers space. This eliminates the possibility of Publishers trying to update any object outside of their own "jail". In V1 the full path was used for objects, and the Server would response with a "permission_failure" error code in case a Publisher tried to use an URI it was not authorised to use.¶
The publisher can derive public URIs for their objects, e.g. for use in SIA and AIA fields of certificates and objects they sign, by concatenating the following:¶
URI = Rsync Base Uri / Base Path / Relative Object Path¶
If the publication server supports the RRDP [RFC8182], then it MUST include the public HTTPS URI [RFC8820] for the RRDP notification file here.¶
If the server enforces RPKI object type restrictions, then it MUST include the full list of supported object types. Object types are defined by the extension registered in the IANA "RPKI Repository Name Scheme" registry. E.g. the object type for ROA is ".roa".¶
The status exchange is used to query the server for the current objects and quota state for this publisher. Furthermore, the server can communicate a planned key rollover of its identity key in this exchange.¶
Publishers SHOULD initiate a status exchange before initiating any publication exchange.¶
Publisher ---------- Status Query ---------> Server
<--------- Status Reply ----------
¶
The MessageType for this query is: "status-query", the MessageContent is omitted.¶
The MessageType for this query is: "status-reply". The MessageContent is as follows:¶
MessageContent ::= SEQUENCE {
CurrentFiles CurrentFiles,
QuotaNumberInfo [0] QuotaNumberInfo OPTIONAL
QuotaSizeInfo [1] QuotaSizeInfo OPTIONAL
NewBpkiTaCert [2] NewBpkiTaCert OPTIONAL
}
CurrentFiles ::= SEQUENCE (SIZE(0..MAX)) OF CurrentFile
CurrentFile ::= SEQUENCE {
RelativePath IA5String,
Hash BitString
}
QuotaNumberInfo ::= SEQUENCE {
used Integer,
warn Integer,
limit Integer
}
QuotaSizeInfo ::= SEQUENCE {
used Integer,
warn Integer,
limit Integer
}
NewBpkiTaCert ::= OCTET STRING
-- constrained to a DER encoded self-signed
-- BPKI TA certificate
¶
Contains the full list of current published files. Files are described by their relative path under the publisher's base path and use the SHA-256 hash.¶
Optional element that MUST be included if the server enforces any quota based on the number of files published by a publisher. It is RECOMMENDED that servers enforce such quota. If they do, they SHOULD choose a number for the warn level that is significantly lower than the limit.¶
Optional element that MUST be included if the server enforces any quota based on the combined size of files published by a publisher. Numbers are in kB, rounded up in case of 'used'. It is RECOMMENDED that servers enforce this type of quota. If they do, they SHOULD choose a number for the warn level that is significantly lower than the limit.¶
Servers may wish to perform a key roll of their BPKI TA certificate (see [RFC8183]). To achieve this the server can generate a new keypair and self-signed BPKI TA certificate - which can be used for publishers in future [RFC8183] out-of-band setup exchanges.¶
However, it would be extremely impractical to require that all existing publishers re-do such an exchange. Furthermore, the server has no active way to reach out to publishers because all exchanges are initiated by the publishers.¶
By including the optional NewBpkiTaCert element in a status reply the Server MAY communicate to Publishers that they intend to migrate to a new identity key.¶
If a publisher sees a new BPKI TA certificate included this way, then they SHOULD perform a "Server Key Accept Exchange" (see elsewhere in doc) at their earliest convenience. The server MUST NOT include this element to publishers which have accepted the new key.¶
Note that if a publisher wishes to perform a key roll of their own BPKI TA certificate, they need to initiate a "Publisher Key Change Exchange" (section ..).¶
The publishers initiates a publication exchange in order to request adding, updating, or withdrawing objects under its designated publication point at the server.¶
The server reply can be an empty ok reply, a warning reply which indicates that publication was successful but the publisher should be aware of certain things (like quota warnings), or an error reply which indicates that publication was rejected.¶
Publisher ---- Publication Query ----------> Server
<-- Publication Ok Reply ---------
one of: <-- Publication Warning Reply ----
<-- Publication Error Reply ------
¶
The MessageType for this query is: "publication-query". The MessageContent is as follows:¶
MessageContent ::= SEQUENCE {
Additions SEQUENCE (SIZE(0..MAX)) OF AddedFile
Updates SEQUENCE (SIZE(0..MAX)) OF UpdatedFile
Withdrawals SEQUENCE (SIZE(0..MAX)) OF WithdrawnFile
}
AddedFile ::= SEQUENCE {
RelativePath RelativePath,
Content OctetString
}
UpdatedFile ::= SEQUENCE {
RelativePath RelativePath,
Content OctetString,
OldFileHash Hash
}
WithdrawnFile ::= SEQUENCE {
RelativePath RelativePath,
OldFileHash Hash
}
RelativePath ::= IA5String
Hash ::= BIT STRING
¶
The MessageType for this reply is: "publication-ok-reply", and the MessageContent is omitted.¶
The MessageType for this reply is: "publication-warning-reply", the MessageContent is as follows:¶
MessageContent ::= SEQUENCE {
QuotaNumberWarning [0] QuotaNumberInfo OPTIONAL
QuotaSizeWarning [1] QuotaSizeInfo OPTIONAL
}
QuotaNumberInfo ::= SEQUENCE {
used Integer,
warn Integer,
limit Integer
}
QuotaSizeInfo ::= SEQUENCE {
used Integer,
warn Integer,
limit Integer
}
¶
A publication warning reply MUST contain at least one of the possible warnings. If there is nothing to warn about then either a "Publication Ok Replay" or "Publication Error Reply" would be applicable.¶
Publisher software SHOULD log any publication warning reply it receives in a way that is visible to operators so that they could enter in a dialogue with their server operator.¶
Publisher software MAY try to reduce the number and size of objects by aggregating ROAs for the same origin ASN. Normally it is recommended that separate ROA objects are made for each ROA prefix and origin ASN because otherwise the loss of one prefix on a covering certificate would invalidate the complete ROA object. But, in case of quota issues this risk aversion may not outweigh the potential benefit of space saving through aggregation.¶
The MessageType for this reply is: "publication-error-reply"¶
Format to be determined.¶
Publication rejected. Some possible reasons from V1: adding duplicate object, trying update/withdraw object for unknown relative path - or hash mismatch.¶
Some new reasons we may wish to support: unsupported object type included, object could not be parsed, publication point inconsistent (w.r.t. manifest).¶
We will need more discussion on which errors we wish to flag, how to communicate relevant constraints at setup / protocol negotiation time, and how to report run time errors here. Some errors may be general, others may be specific to objects.¶
Dependent on the errors we define, we may need specific instructions to Publishers about how to deal with them. For example, if an object type is not supported by the Server, then the Publisher may still wish to publish other object types and inform their user - who may then wish to migrate to another publication server.¶
This exchange SHOULD be initiated by the publisher at its earliest convenience after learning (Status Exchange) that a new key exists. It will confirm to the server that it can now use the new key instead of the previous key to sign replies.¶
The typical reply is an ok reply signed with the new key. Or an error reply.¶
The MessageType for this reply is: "server-key-accept"¶
The Publisher repeats the new BPKI TA Certificate that it believes the Server intends to migrate towards:¶
MessageContent ::= SEQUENCE {
NewBpkiTaCert NewBpkiTaCert
-- Use a SEQUENCE for extensibility?
}
NewBpkiTaCert ::= OCTET STRING
-- constrained to a DER encoded self-signed
-- BPKI TA certificate
¶
The MessageType for this reply is: "server-key-accept-ok". There is no content, but the response is signed using the now accepted key.¶
The Publisher MAY now forget the (now) old server key and MUST expect the new (now current) key to be used in future replies signed by the Server.¶
The Server SHOULD no longer inform this Publisher about the new key in in new Status Reply responses. If this was the last Publisher to accept the new key, the Server MAY now delete its old key pair.¶
It is not expected that an error is returned. However, it could be that the Publisher was confused an sent a Server Key Accepted Query for a key that the Server does not wish to migrate to. Or the server changed its mind in between last informing the the Publisher in a Status Reply and now. In any event.. the server MUST return an error in this case, an the Publisher MUST continue to expect the current server key to be used for signing replies.¶
The MessageType for this reply is: "server-key-accepted-error". There is no content.¶
The MessageType for this query is: "client-key-change"¶
The publisher sends its new key to the server by means of a (validly self-signed) BPKI TA certificate.¶
MessageContent ::= SEQUENCE {
NewBpkiTaCert NewBpkiTaCert
-- Use a SEQUENCE for extensibility?
}
NewBpkiTaCert ::= OCTET STRING
-- constrained to a DER encoded self-signed
-- BPKI TA certificate
¶
The MessageType for this reply is: "client-key-change-ok". There is no content.¶
The Publisher MUST now use the new key in future exchanges, at least until the new key itself is changed of course. The Server MAY now forget the previous key for the Publisher and MUST now expect this new key to be used.¶
The MessageType for this reply is: "client-key-change-error". There is no content.¶
The server SHOULD return this error only in case it finds that the new BPKI TA Certificate is not validly signed. I.e. there was no proof of possession of the private key.¶
This is unlikely to happen and it would point at a serious issue with either the Publisher or the Server software, or both..¶
Both the Publisher and Server should alert their operators in the applicable ways that can (log, report status error etc). The Publisher SHOULD continue to use its previous key, it MUST NOT start to use its intended new key until this issue is resolved - presumably after operator and/or developer actions.¶
OID needs to be requested.¶
To be determined. As it stands this document represents early ideas about a possible direction for a next version of the publication protocol. There have been some informal discussions with various people.¶
It's not certain yet how we will proceed. Perhaps this will become a working group document, perhaps it will only serve discussion and another document or documents follow. So.. to be determined.¶