draft-ietf-sidr-publication-01.txt | draft-ietf-sidr-publication-02.txt | |||
---|---|---|---|---|
Network Working Group S. Weiler | Network Working Group S. Weiler | |||
Internet-Draft A. Sonalker | Internet-Draft A. Sonalker | |||
Intended status: Standards Track SPARTA, Inc. | Intended status: Standards Track SPARTA, Inc. | |||
Expires: January 12, 2012 R. Austein | Expires: September 13, 2012 R. Austein | |||
ISC | Dragon Research Labs | |||
July 11, 2011 | March 12, 2012 | |||
A Publication Protocol for the Resource Public Key Infrastructure (RPKI) | A Publication Protocol for the Resource Public Key Infrastructure (RPKI) | |||
draft-ietf-sidr-publication-01 | draft-ietf-sidr-publication-02 | |||
Abstract | Abstract | |||
This document defines a protocol for publishing Resource Public Key | This document defines a protocol for publishing Resource Public Key | |||
Infrastructure (RPKI) objects. Even though the RPKI will have many | Infrastructure (RPKI) objects. Even though the RPKI will have many | |||
participants issuing certificates and creating other objects, it is | participants issuing certificates and creating other objects, it is | |||
operationally useful to consolidate the publication of those objects. | operationally useful to consolidate the publication of those objects. | |||
This document provides the protocol for doing so. | This document provides the protocol for doing so. | |||
Status of this Memo | Status of this Memo | |||
skipping to change at page 1, line 36 | skipping to change at page 1, line 36 | |||
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 http://datatracker.ietf.org/drafts/current/. | Drafts is at http://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 January 12, 2012. | This Internet-Draft will expire on September 13, 2012. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2011 IETF Trust and the persons identified as the | Copyright (c) 2012 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 | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://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 21 | skipping to change at page 2, line 21 | |||
2. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Protocol Specification . . . . . . . . . . . . . . . . . . . . 4 | 3. Protocol Specification . . . . . . . . . . . . . . . . . . . . 4 | |||
3.1. Common Details . . . . . . . . . . . . . . . . . . . . . . 4 | 3.1. Common Details . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3.1.1. Common XML Message Format . . . . . . . . . . . . . . 4 | 3.1.1. Common XML Message Format . . . . . . . . . . . . . . 4 | |||
3.2. Control Sub-Protocol . . . . . . . . . . . . . . . . . . . 5 | 3.2. Control Sub-Protocol . . . . . . . . . . . . . . . . . . . 5 | |||
3.2.1. Config Object . . . . . . . . . . . . . . . . . . . . 5 | 3.2.1. Config Object . . . . . . . . . . . . . . . . . . . . 5 | |||
3.2.2. Client Object . . . . . . . . . . . . . . . . . . . . 5 | 3.2.2. Client Object . . . . . . . . . . . . . . . . . . . . 5 | |||
3.3. Publication Sub-Protocol . . . . . . . . . . . . . . . . . 6 | 3.3. Publication Sub-Protocol . . . . . . . . . . . . . . . . . 6 | |||
3.4. Error handling . . . . . . . . . . . . . . . . . . . . . . 7 | 3.4. Error handling . . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 7 | 3.5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
4. Operational Considerations . . . . . . . . . . . . . . . . . . 9 | 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | 4.1. Config Set Query and Response . . . . . . . . . . . . . . 9 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | 4.2. Config Get Query and Response . . . . . . . . . . . . . . 10 | |||
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 4.3. Example 3: Client Create Query and Reply . . . . . . . . . 11 | |||
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 | 4.4. Example 4: Client Set Query and Reply . . . . . . . . . . 12 | |||
7.2. Informative References . . . . . . . . . . . . . . . . . . 10 | 4.5. Example 5: Client Get Query and Reply . . . . . . . . . . 13 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 | 4.6. Example 6: Client List Query and Reply . . . . . . . . . . 13 | |||
4.7. Example 7: Client Destroy Query and Reply . . . . . . . . 14 | ||||
4.8. Example 8: Publish Query and Reply . . . . . . . . . . . . 14 | ||||
4.9. Example 9: Withdraw Query and Reply . . . . . . . . . . . 15 | ||||
4.10. Example 10: Report Error Reply . . . . . . . . . . . . . . 16 | ||||
5. Operational Considerations . . . . . . . . . . . . . . . . . . 16 | ||||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 | ||||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 | ||||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 | ||||
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 | ||||
8.2. Informative References . . . . . . . . . . . . . . . . . . 19 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 | ||||
1. Introduction | 1. Introduction | |||
This document assumes a working knowledge of the Resource Public Key | This document assumes a working knowledge of the Resource Public Key | |||
Infrastructure (RPKI), which is intended to support improved routing | Infrastructure (RPKI), which is intended to support improved routing | |||
security on the Internet. [I-D.ietf-sidr-arch] | security on the Internet. [RFC6480] | |||
In order to make participation in the RPKI easier, it is helpful to | In order to make participation in the RPKI easier, it is helpful to | |||
have a few consolidated repositories for RPKI objects, thus saving | have a few consolidated repositories for RPKI objects, thus saving | |||
every participant from the cost of maintaining a new service. | every participant from the cost of maintaining a new service. | |||
Similarly, relying parties using the RPKI objects will find it faster | Similarly, relying parties using the RPKI objects will find it faster | |||
and more reliable to retrieve the necessary set from a smaller number | and more reliable to retrieve the necessary set from a smaller number | |||
of repositories. | of repositories. | |||
These consolidated RPKI object repositories will in many cases be | These consolidated RPKI object repositories will in many cases be | |||
outside the administrative scope of the organization issuing a given | outside the administrative scope of the organization issuing a given | |||
skipping to change at page 4, line 35 | skipping to change at page 4, line 35 | |||
corresponding response. | corresponding response. | |||
A message exchange commences with the client initiating an HTTP POST | A message exchange commences with the client initiating an HTTP POST | |||
with content type of "application/rpki-publication", with the message | with content type of "application/rpki-publication", with the message | |||
object as the body. The server's response will similarly be the body | object as the body. The server's response will similarly be the body | |||
of the response with a content type of "application/ | of the response with a content type of "application/ | |||
rpki-publication". | rpki-publication". | |||
The content of the POST and the server's response will be a well- | The content of the POST and the server's response will be a well- | |||
formed Cryptographic Message Syntax (CMS) [RFC5652] object with OID = | formed Cryptographic Message Syntax (CMS) [RFC5652] object with OID = | |||
1.2.840.113549.1.7.2 as described in Section 3.1 of | 1.2.840.113549.1.7.2 as described in Section 3.1 of [RFC6492]. | |||
[I-D.ietf-sidr-rescerts-provisioning]. | ||||
3.1.1. Common XML Message Format | 3.1.1. Common XML Message Format | |||
The XML schema for this protocol (including both subprotocols) is | The XML schema for this protocol (including both subprotocols) is | |||
below in Section 3.5. Both subprotocols use the same basic XML | below in Section 3.5. Both subprotocols use the same basic XML | |||
message format, which looks like: | message format, which looks like: | |||
<?xml version='1.0' encoding='us-ascii'?> | <?xml version='1.0' encoding='us-ascii'?> | |||
<msg xmlns="http://www.hactrn.net/uris/rpki/publication-spec/" | <msg xmlns="http://www.hactrn.net/uris/rpki/publication-spec/" | |||
version="2" | version="2" | |||
skipping to change at page 5, line 52 | skipping to change at page 5, line 52 | |||
destroyed. Its use is typically restricted to the repository | destroyed. Its use is typically restricted to the repository | |||
operator. | operator. | |||
The <config/> object only has one data element that can be set: the | The <config/> object only has one data element that can be set: the | |||
bpki_crl. This is used by the publication server when authenticating | bpki_crl. This is used by the publication server when authenticating | |||
clients. | clients. | |||
3.2.2. Client Object | 3.2.2. Client Object | |||
Unlike the <config/> object, the <client/> object represents one | Unlike the <config/> object, the <client/> object represents one | |||
client authorized to use the publication server. There may well be | client authorized to use the publication server. There may be more | |||
more than one <client/> object on each publication server. Again, | than one <client/> object on each publication server. Again, its use | |||
its use is typically restricted to the respository operator. | is typically restricted to the respository operator. | |||
The <client/> object supports five actions: "create", "set", "get", | The <client/> object supports five actions: "create", "set", "get", | |||
"list", and "destroy". Each client has a "client_handle" attribute, | "list", and "destroy". Each client has a "client_handle" attribute, | |||
which is used in responses and must be specified in "create", "set", | which is used in responses and must be specified in "create", "set", | |||
"get", or "destroy" actions. | "get", or "destroy" actions. | |||
Payload data which can be configured in a <client/> object include: | Payload data which can be configured in a <client/> object include: | |||
o base_uri (attribute): This attribute represents the base URI below | o base_uri (attribute): This attribute represents the base URI below | |||
which the client will be allowed to publish data. Additional | which the client will be allowed to publish data. Additional | |||
skipping to change at page 6, line 39 | skipping to change at page 6, line 39 | |||
pathological cross-certification cases which require a two- | pathological cross-certification cases which require a two- | |||
certificate chain due to issuer name conflicts. When being used, | certificate chain due to issuer name conflicts. When being used, | |||
issuing order is that the bpki_glue certificate should be the | issuing order is that the bpki_glue certificate should be the | |||
issuer of the bpki_cert certificate. Otherwise, it should be | issuer of the bpki_cert certificate. Otherwise, it should be | |||
issued by the publication engine's bpki_ta certificate. Since | issued by the publication engine's bpki_ta certificate. Since | |||
this is an optional use certificate, it may be left unset if not | this is an optional use certificate, it may be left unset if not | |||
needed. | needed. | |||
3.3. Publication Sub-Protocol | 3.3. Publication Sub-Protocol | |||
The sub-publication protocol requests publication or withdrawal from | The publication sub-protocol requests publication or withdrawal from | |||
publication of RPKI objects. | publication of RPKI objects. | |||
The publication protocol uses a common message format to request | The publication protocol uses a common message format to request | |||
publication of any RPKI object. This format was chosen specifically | publication of any RPKI object. This format was chosen specifically | |||
to allow this protocol to accommodate new types of RPKI objects | to allow this protocol to accommodate new types of RPKI objects | |||
without needing changes to this protocol. | without needing changes to this protocol. | |||
Both the <publish/> and <withdraw/> objects have a payload of an | Both the <publish/> and <withdraw/> objects have a payload of an | |||
optional tag and a URI. The <publish/> query also contains the DER | optional tag and a URI. The <publish/> query also contains the DER | |||
object to be published, encoded in Base64. | object to be published, encoded in Base64. | |||
skipping to change at page 7, line 45 | skipping to change at page 7, line 45 | |||
occurred. | occurred. | |||
The body of the <report_error/> element itself is an optional text | The body of the <report_error/> element itself is an optional text | |||
string; if present, this is debugging information. | string; if present, this is debugging information. | |||
3.5. XML Schema | 3.5. XML Schema | |||
The following is a RelaxNG compact form schema describing the | The following is a RelaxNG compact form schema describing the | |||
Publication Protocol. | Publication Protocol. | |||
default namespace = "http://www.hactrn.net/uris/rpki/publication-spec/" | default namespace = "http://www.hactrn.net/uris/rpki/publication-spec/" | |||
# Top level PDU | # Top level PDU | |||
start = element msg { | start = element msg { | |||
attribute version { "2" } , | attribute version { "2" } , | |||
( ( attribute type { "query" }, query_elt*) | | ( ( attribute type { "query" }, query_elt*) | | |||
(attribute type { "reply" }, reply_elt*)) | (attribute type { "reply" }, reply_elt*)) | |||
} | } | |||
# PDUs allowed in a query | # PDUs allowed in a query | |||
query_elt = ( config_query | client_query | publish_query | | query_elt = ( config_query | client_query | publish_query | | |||
skipping to change at page 9, line 35 | skipping to change at page 9, line 35 | |||
withdraw_reply |= element withdraw { tag?, uri } | withdraw_reply |= element withdraw { tag?, uri } | |||
# <report_error/> element | # <report_error/> element | |||
error = xsd:token { maxLength="1024" } | error = xsd:token { maxLength="1024" } | |||
report_error_reply = element report_error { | report_error_reply = element report_error { | |||
tag?, | tag?, | |||
attribute error_code { error }, | attribute error_code { error }, | |||
xsd:string { maxLength="512000" }? | xsd:string { maxLength="512000" }? | |||
} | } | |||
4. Operational Considerations | 4. Examples | |||
Placeholder section to talk about nesting children under parents in | Following are various queries and the corresponding replies for the | |||
the same repository, to allow for a single rsync to fetch both | RPKI publication protocol | |||
(observing that the rsync setup times tends to dominate over the sync | ||||
time). And, more distressingly, talk about the access control | ||||
impacts of that nesting. | ||||
5. IANA Considerations | 4.1. Config Set Query and Response | |||
A. Config "Set" Query | ||||
<msg xmlns="http://www.hactrn.net/uris/rpki/publication-spec/" | ||||
type="query" version="2"> | ||||
<config action="set"> | ||||
<bpki_crl> | ||||
MIIBezBlAgEBMA0GCSqGSIb3DQEBCwUAMCMxITAfBgNVBAMTGFRlc3QgQ2Vyd | ||||
GlmaWNhdGUgcHViZCBUQRcNMDgwNjAyMjE0OTQ1WhcNMDgwNzAyMjE0OTQ1Wq | ||||
AOMAwwCgYDVR0UBAMCAQEwDQYJKoZIhvcNAQELBQADggEBAFWCWgBl4ljVqX/ | ||||
CHo+RpqYtvmKMnjPVflMXUB7i28RGP4DAq4l7deDU7Q82xEJyE4TXMWDWAV6U | ||||
G6uUGum0VHWOcj9ohqyiZUGfOsKg2hbwkETm8sAENOsi1yNdyKGk6jZ16aF5f | ||||
ubxQqZa1pdGCSac1/ZYC5sLLhEz3kmz+B9z9mXFVc5TgAh4dN3Gy5ftF8zZAF | ||||
pDGnS4biCnRVqhGv6R0Lh/5xmii+ZU6kNDhbeMsjJg+ZOmtN+wMeHSIbjiy0W | ||||
uuaZ3k2xSh0C94anrHBZAvvCRhbazjR0Ef5OMZ5lcllw3uO8IHuoisHKkehy4 | ||||
Y0GySdj98fV+OuiRTH9vt/M= | ||||
</bpki_crl> | ||||
</config> | ||||
</msg> | ||||
B. Config "Set" Reply | ||||
<msg xmlns="http://www.hactrn.net/uris/rpki/publication-spec/" | ||||
type="reply" version="2"> | ||||
<config action="set"/> | ||||
</msg> | ||||
4.2. Config Get Query and Response | ||||
A. Config "Get" Query | ||||
<msg xmlns="http://www.hactrn.net/uris/rpki/publication-spec/" | ||||
type="query" version="2"> | ||||
<config action="get"/> | ||||
</msg> | ||||
B. Config "Get" Reply | ||||
<msg xmlns="http://www.hactrn.net/uris/rpki/publication-spec/" | ||||
type="reply" version="2"> | ||||
<config action="get"> | ||||
<bpki_crl> | ||||
MIIBezBlAgEBMA0GCSqGSIb3DQEBCwUAMCMxITAfBgNVBAMTGFRlc3QgQ2Vyd | ||||
GlmaWNhdGUgcHViZCBUQRcNMDgwNjAyMjE0OTQ1WhcNMDgwNzAyMjE0OTQ1Wq | ||||
AOMAwwCgYDVR0UBAMCAQEwDQYJKoZIhvcNAQELBQADggEBAFWCWgBl4ljVqX/ | ||||
CHo+RpqYtvmKMnjPVflMXUB7i28RGP4DAq4l7deDU7Q82xEJyE4TXMWDWAV6U | ||||
G6uUGum0VHWOcj9ohqyiZUGfOsKg2hbwkETm8sAENOsi1yNdyKGk6jZ16aF5f | ||||
ubxQqZa1pdGCSac1/ZYC5sLLhEz3kmz+B9z9mXFVc5TgAh4dN3Gy5ftF8zZAF | ||||
pDGnS4biCnRVqhGv6R0Lh/5xmii+ZU6kNDhbeMsjJg+ZOmtN+wMeHSIbjiy0W | ||||
uuaZ3k2xSh0C94anrHBZAvvCRhbazjR0Ef5OMZ5lcllw3uO8IHuoisHKkehy4 | ||||
Y0GySdj98fV+OuiRTH9vt/M= | ||||
</bpki_crl> | ||||
</config> | ||||
</msg> | ||||
4.3. Example 3: Client Create Query and Reply | ||||
A. Client "Create" Query | ||||
<msg xmlns="http://www.hactrn.net/uris/rpki/publication-spec/" | ||||
version="2" type="query"> | ||||
<client action="create" client_handle="3" | ||||
base_uri="rsync://wombat.invalid/"> | ||||
<bpki_cert> | ||||
MIIDGzCCAgOgAwIBAgIJAKi+/+wUhQlxMA0GCSqGSIb3DQEBBQUAMCQxIjAgB | ||||
gNVBAMTGVRlc3QgQ2VydGlmaWNhdGUgQm9iIFJvb3QwHhcNMDcwODAxMTk1Mz | ||||
EwWhcNMDcwODMxMTk1MzEwWjAkMSIwIAYDVQQDExlUZXN0IENlcnRpZmljYXR | ||||
lIEJvYiBSb290MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArKYU | ||||
tJaM5PH5917SG2ACc7iBYdQO2HYyu8Gb6i9Q2Gxc3cWEX7RTBvgOL79pWf3GI | ||||
dnoupzMnoZVtY3GUx2G/0WkmLui2TCeDhcfXdQ4rcp8J3V/6ESj+yuEPPOG8U | ||||
N17mUKKgujrch6ZvgCDO9AyOK/uXu+ABQXTPsn2pVe2EVh3V004ShLi8GKgVd | ||||
qb/rW/6GTg0Xb/zLT6WWMuT++6sXTlztJdQYkRamJvKfQDU1naC8mAkGf79Tb | ||||
a0xyBGAUII0GfREY6t4/+NAP2Yyb3xNlBqcJoTov0JfNKHZcCZePr79j7LK/h | ||||
kZxxip+Na9xDpE+oQRV+DRukCRJdiqg+wIDAQABo1AwTjAMBgNVHRMEBTADAQ | ||||
H/MB0GA1UdDgQWBBTDEsXJe6pjAQD4ULlB7+GMDBlimTAfBgNVHSMEGDAWgBT | ||||
DEsXJe6pjAQD4ULlB7+GMDBlimTANBgkqhkiG9w0BAQUFAAOCAQEAWWkNcW6S | ||||
1tKKqtzJsdfhjJiAAPQmOXJskv0ta/8f6Acgcum1YieNdtT0n96P7CUHOWP8Q | ||||
Bb91JzeewR7b6WJLwb1Offs3wNq3kk75pJe89r4XY39EZHhMW+Dv0PhIKu2Cg | ||||
D4LeyH1FVTQkF/QObGEmkn+s+HTsuzd1l2VLwcP1Smsqep6LAlFj62qqaIJzN | ||||
eQ9NVkBqtkygnYlBOkaBTHfQTux3jYNpEo8JJB5e/WFdHYyMNrG2xMOtIC7T4 | ||||
+IOHgT8PgrNhaeDg9ctewj0X8Qi9nI9nXeinicLX8vj6hdEq3ORv7RZMJNYqv | ||||
1HQ3wUE2B7fCPFv7EUwzaCds1kgRQ== | ||||
</bpki_cert> | ||||
</client> | ||||
</msg> | ||||
B. Client "Create" Reply | ||||
<msg xmlns="http://www.hactrn.net/uris/rpki/publication-spec/" | ||||
version="2" type="reply"> | ||||
<client action="create" client_handle="3"/> | ||||
</msg> | ||||
4.4. Example 4: Client Set Query and Reply | ||||
A. Client "Set" Query | ||||
<msg xmlns="http://www.hactrn.net/uris/rpki/publication-spec/" | ||||
version="2" type="query"> | ||||
<client action="set" client_handle="3"> | ||||
<bpki_glue> | ||||
MIIDGzCCAgOgAwIBAgIJAKi+/+wUhQlxMA0GCSqGSIb3DQEBBQUAMCQxIjAgB | ||||
gNVBAMTGVRlc3QgQ2VydGlmaWNhdGUgQm9iIFJvb3QwHhcNMDcwODAxMTk1Mz | ||||
EwWhcNMDcwODMxMTk1MzEwWjAkMSIwIAYDVQQDExlUZXN0IENlcnRpZmljYXR | ||||
lIEJvYiBSb290MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArKYU | ||||
tJaM5PH5917SG2ACc7iBYdQO2HYyu8Gb6i9Q2Gxc3cWEX7RTBvgOL79pWf3GI | ||||
dnoupzMnoZVtY3GUx2G/0WkmLui2TCeDhcfXdQ4rcp8J3V/6ESj+yuEPPOG8U | ||||
N17mUKKgujrch6ZvgCDO9AyOK/uXu+ABQXTPsn2pVe2EVh3V004ShLi8GKgVd | ||||
qb/rW/6GTg0Xb/zLT6WWMuT++6sXTlztJdQYkRamJvKfQDU1naC8mAkGf79Tb | ||||
a0xyBGAUII0GfREY6t4/+NAP2Yyb3xNlBqcJoTov0JfNKHZcCZePr79j7LK/h | ||||
kZxxip+Na9xDpE+oQRV+DRukCRJdiqg+wIDAQABo1AwTjAMBgNVHRMEBTADAQ | ||||
H/MB0GA1UdDgQWBBTDEsXJe6pjAQD4ULlB7+GMDBlimTAfBgNVHSMEGDAWgBT | ||||
DEsXJe6pjAQD4ULlB7+GMDBlimTANBgkqhkiG9w0BAQUFAAOCAQEAWWkNcW6S | ||||
1tKKqtzJsdfhjJiAAPQmOXJskv0ta/8f6Acgcum1YieNdtT0n96P7CUHOWP8Q | ||||
Bb91JzeewR7b6WJLwb1Offs3wNq3kk75pJe89r4XY39EZHhMW+Dv0PhIKu2Cg | ||||
D4LeyH1FVTQkF/QObGEmkn+s+HTsuzd1l2VLwcP1Smsqep6LAlFj62qqaIJzN | ||||
eQ9NVkBqtkygnYlBOkaBTHfQTux3jYNpEo8JJB5e/WFdHYyMNrG2xMOtIC7T4 | ||||
+IOHgT8PgrNhaeDg9ctewj0X8Qi9nI9nXeinicLX8vj6hdEq3ORv7RZMJNYqv | ||||
1HQ3wUE2B7fCPFv7EUwzaCds1kgRQ== | ||||
</bpki_glue> | ||||
</client> | ||||
</msg> | ||||
B. Client "Set" Reply | ||||
<msg xmlns="http://www.hactrn.net/uris/rpki/publication-spec/" | ||||
version="2" type="reply"> | ||||
<client action="set" client_handle="3"/> | ||||
</msg> | ||||
4.5. Example 5: Client Get Query and Reply | ||||
A. Client "Get" Query | ||||
<msg xmlns="http://www.hactrn.net/uris/rpki/publication-spec/" | ||||
version="2" type="query"> | ||||
<client action="get" client_handle="3"/> | ||||
</msg> | ||||
B. Client "Get" Reply | ||||
<msg xmlns="http://www.hactrn.net/uris/rpki/publication-spec/" | ||||
version="2" type="reply"> | ||||
<client action="get" client_handle="3" | ||||
base_uri="rsync://wombat.invalid/"> | ||||
<bpki_cert> | ||||
MIIDGzCCAgOgAwIBAgIJAKi+/+wUhQlxMA0GCSqGSIb3DQEBBQUAMCQxIjAgB | ||||
gNVBAMTGVRlc3QgQ2VydGlmaWNhdGUgQm9iIFJvb3QwHhcNMDcwODAxMTk1Mz | ||||
EwWhcNMDcwODMxMTk1MzEwWjAkMSIwIAYDVQQDExlUZXN0IENlcnRpZmljYXR | ||||
lIEJvYiBSb290MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArKYU | ||||
tJaM5PH5917SG2ACc7iBYdQO2HYyu8Gb6i9Q2Gxc3cWEX7RTBvgOL79pWf3GI | ||||
dnoupzMnoZVtY3GUx2G/0WkmLui2TCeDhcfXdQ4rcp8J3V/6ESj+yuEPPOG8U | ||||
N17mUKKgujrch6ZvgCDO9AyOK/uXu+ABQXTPsn2pVe2EVh3V004ShLi8GKgVd | ||||
qb/rW/6GTg0Xb/zLT6WWMuT++6sXTlztJdQYkRamJvKfQDU1naC8mAkGf79Tb | ||||
a0xyBGAUII0GfREY6t4/+NAP2Yyb3xNlBqcJoTov0JfNKHZcCZePr79j7LK/h | ||||
kZxxip+Na9xDpE+oQRV+DRukCRJdiqg+wIDAQABo1AwTjAMBgNVHRMEBTADAQ | ||||
H/MB0GA1UdDgQWBBTDEsXJe6pjAQD4ULlB7+GMDBlimTAfBgNVHSMEGDAWgBT | ||||
DEsXJe6pjAQD4ULlB7+GMDBlimTANBgkqhkiG9w0BAQUFAAOCAQEAWWkNcW6S | ||||
1tKKqtzJsdfhjJiAAPQmOXJskv0ta/8f6Acgcum1YieNdtT0n96P7CUHOWP8Q | ||||
Bb91JzeewR7b6WJLwb1Offs3wNq3kk75pJe89r4XY39EZHhMW+Dv0PhIKu2Cg | ||||
D4LeyH1FVTQkF/QObGEmkn+s+HTsuzd1l2VLwcP1Smsqep6LAlFj62qqaIJzN | ||||
eQ9NVkBqtkygnYlBOkaBTHfQTux3jYNpEo8JJB5e/WFdHYyMNrG2xMOtIC7T4 | ||||
+IOHgT8PgrNhaeDg9ctewj0X8Qi9nI9nXeinicLX8vj6hdEq3ORv7RZMJNYqv | ||||
1HQ3wUE2B7fCPFv7EUwzaCds1kgRQ== | ||||
</bpki_cert> | ||||
</client> | ||||
</msg> | ||||
4.6. Example 6: Client List Query and Reply | ||||
A. Client "List" Query | ||||
<msg xmlns="http://www.hactrn.net/uris/rpki/publication-spec/" | ||||
version="2" type="query"> | ||||
<client action="list"/> | ||||
</msg> | ||||
B. Client "List" Reply | ||||
<msg xmlns="http://www.hactrn.net/uris/rpki/publication-spec/" | ||||
version="2" type="reply"> | ||||
<client action="list" client_handle="3"> | ||||
<bpki_cert> | ||||
MIIDGzCCAgOgAwIBAgIJAKi+/+wUhQlxMA0GCSqGSIb3DQEBBQUAMCQxIjAgB | ||||
gNVBAMTGVRlc3QgQ2VydGlmaWNhdGUgQm9iIFJvb3QwHhcNMDcwODAxMTk1Mz | ||||
EwWhcNMDcwODMxMTk1MzEwWjAkMSIwIAYDVQQDExlUZXN0IENlcnRpZmljYXR | ||||
lIEJvYiBSb290MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArKYU | ||||
tJaM5PH5917SG2ACc7iBYdQO2HYyu8Gb6i9Q2Gxc3cWEX7RTBvgOL79pWf3GI | ||||
dnoupzMnoZVtY3GUx2G/0WkmLui2TCeDhcfXdQ4rcp8J3V/6ESj+yuEPPOG8U | ||||
N17mUKKgujrch6ZvgCDO9AyOK/uXu+ABQXTPsn2pVe2EVh3V004ShLi8GKgVd | ||||
qb/rW/6GTg0Xb/zLT6WWMuT++6sXTlztJdQYkRamJvKfQDU1naC8mAkGf79Tb | ||||
a0xyBGAUII0GfREY6t4/+NAP2Yyb3xNlBqcJoTov0JfNKHZcCZePr79j7LK/h | ||||
kZxxip+Na9xDpE+oQRV+DRukCRJdiqg+wIDAQABo1AwTjAMBgNVHRMEBTADAQ | ||||
H/MB0GA1UdDgQWBBTDEsXJe6pjAQD4ULlB7+GMDBlimTAfBgNVHSMEGDAWgBT | ||||
DEsXJe6pjAQD4ULlB7+GMDBlimTANBgkqhkiG9w0BAQUFAAOCAQEAWWkNcW6S | ||||
1tKKqtzJsdfhjJiAAPQmOXJskv0ta/8f6Acgcum1YieNdtT0n96P7CUHOWP8Q | ||||
Bb91JzeewR7b6WJLwb1Offs3wNq3kk75pJe89r4XY39EZHhMW+Dv0PhIKu2Cg | ||||
D4LeyH1FVTQkF/QObGEmkn+s+HTsuzd1l2VLwcP1Smsqep6LAlFj62qqaIJzN | ||||
eQ9NVkBqtkygnYlBOkaBTHfQTux3jYNpEo8JJB5e/WFdHYyMNrG2xMOtIC7T4 | ||||
+IOHgT8PgrNhaeDg9ctewj0X8Qi9nI9nXeinicLX8vj6hdEq3ORv7RZMJNYqv | ||||
1HQ3wUE2B7fCPFv7EUwzaCds1kgRQ== | ||||
</bpki_cert> | ||||
</client> | ||||
</msg> | ||||
4.7. Example 7: Client Destroy Query and Reply | ||||
A. Client "Destroy" Query | ||||
<msg xmlns="http://www.hactrn.net/uris/rpki/publication-spec/" | ||||
version="2" type="query"> | ||||
<client action="destroy" client_handle="3"/> | ||||
</msg> | ||||
B. Client "Destroy" Reply | ||||
<msg xmlns="http://www.hactrn.net/uris/rpki/publication-spec/" | ||||
version="2" type="reply"> | ||||
<client action="destroy" client_handle="3"/> | ||||
</msg> | ||||
4.8. Example 8: Publish Query and Reply | ||||
A. Publish Query | ||||
<msg xmlns="http://www.hactrn.net/uris/rpki/publication-spec/" | ||||
version="2" type="query"> | ||||
<publish uri="rsync://wombat.invalid/testbed/RIR/1/j7ghjwblCr | ||||
cCp9ltyPDNzYKPfxc.cer"> | ||||
MIIE+jCCA+KgAwIBAgIBDTANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEyhER | ||||
jRBODAxN0U2NkE5RTkxNzJFNDYxMkQ4Q0Y0QzgzRjIzOERFMkEzMB4XDTA4MD | ||||
UyMjE4MDUxMloXDTA4MDUyNDE3NTQ1M1owMzExMC8GA1UEAxMoOEZCODIxOEY | ||||
wNkU1MEFCNzAyQTdEOTZEQzhGMENEQ0Q4MjhGN0YxNzCCASIwDQYJKoZIhvcN | ||||
AQEBBQADggEPADCCAQoCggEBAMeziKp0k5nP7v6SZoNsXIMQYRgNtC6Fr/9Xm | ||||
/1yQHomiPqHUk47rHhGojYiK5AhkrwoYhkH4UjJl2iwklDYczXuaBU3F5qrKl | ||||
Z4aZnjIxdlP7+hktVpeApL6yuJTUAYeC3UIxnLDVdD6phydZ/FOQluffiNDjz | ||||
teCCvoyOUatqt8WB+oND6LToHp028g1YUYLHG6mur0dPdcHOVXLSmUDuZ1HDz | ||||
1nDuYvIVKjB/MpH9aW9XeaQ6ZFIlZVPwuuvI2brR+ThH7Gv27GL/o8qFdC300 | ||||
VQfoTZ+rKPGDE8K1cI906BL4kiwx9z0oiDcE96QCz+B0vsjc9mGaA1jgAxlXW | ||||
sCAwEAAaOCAhcwggITMB0GA1UdDgQWBBSPuCGPBuUKtwKn2W3I8M3Ngo9/FzA | ||||
fBgNVHSMEGDAWgBTfSoAX5mqekXLkYS2M9Mg/I43iozBVBgNVHR8ETjBMMEqg | ||||
SKBGhkRyc3luYzovL2xvY2FsaG9zdDo0NDAwL3Rlc3RiZWQvUklSLzEvMzBxQ | ||||
UYtWnFucEZ5NUdFdGpQVElQeU9ONHFNLmNybDBFBggrBgEFBQcBAQQ5MDcwNQ | ||||
YIKwYBBQUHMAKGKXJzeW5jOi8vbG9jYWxob3N0OjQ0MDAvdGVzdGJlZC9XT01 | ||||
CQVQuY2VyMBgGA1UdIAEB/wQOMAwwCgYIKwYBBQUHDgIwDwYDVR0TAQH/BAUw | ||||
AwEB/zAOBgNVHQ8BAf8EBAMCAQYwgZsGCCsGAQUFBwELBIGOMIGLMDQGCCsGA | ||||
QUFBzAFhihyc3luYzovL2xvY2FsaG9zdDo0NDAwL3Rlc3RiZWQvUklSL1IwLz | ||||
EvMFMGCCsGAQUFBzAKhkdyc3luYzovL2xvY2FsaG9zdDo0NDAwL3Rlc3RiZWQ | ||||
vUklSL1IwLzEvajdnaGp3YmxDcmNDcDlsdHlQRE56WUtQZnhjLm1uZjAaBggr | ||||
BgEFBQcBCAEB/wQLMAmgBzAFAgMA/BUwPgYIKwYBBQUHAQcBAf8ELzAtMCsEA | ||||
gABMCUDAwAKAzAOAwUAwAACAQMFAcAAAiAwDgMFAsAAAiwDBQDAAAJkMA0GCS | ||||
qGSIb3DQEBCwUAA4IBAQCEhuH7jtI2PJY6+zwv306vmCuXhtu9Lr2mmRw2ZEr | ||||
B8EMcb5xypMrNqMoKeu14K2x4a4RPJkK4yAThM81FPNRsU5mM0acIRnAPtxjH | ||||
vPME7PHN2w2nGLASRsZmaa+b8A7SSOxVcFURazENztppsolHeTpm0cpLItK7m | ||||
NpudUg1JGuFo94VLf1MnE2EqARG1vTsNhel/SM/UvOArCCOBvf0Gz7kSuupDS | ||||
Z7qx+LiDmtEsLdbGNQBiYPbLrDk41PHrxdx28qIj7ejZkRzNFw/3pi8/XK281 | ||||
h8zeHoFVu6ghRPy5dbOA4akX/KG6b8XIx0iwPYdLiDbdWFbtTdPcXBauY | ||||
</publish> | ||||
</msg> | ||||
B. Publish Reply | ||||
<msg xmlns="http://www.hactrn.net/uris/rpki/publication-spec/" | ||||
version="2" type="reply"> | ||||
<publish uri="rsync://wombat.invalid/testbed/RIR/1/j7ghjwblCr | ||||
cCp9ltyPDNzYKPfxc.cer"/> | ||||
</msg> | ||||
4.9. Example 9: Withdraw Query and Reply | ||||
A. Withdraw Query | ||||
<msg xmlns="http://www.hactrn.net/uris/rpki/publication-spec/" | ||||
version="2" type="query"> | ||||
<withdraw uri="rsync://wombat.invalid/testbed/RIR/1/j7ghjwblCr | ||||
cCp9ltyPDNzYKPfxc.cer"/> | ||||
</msg> | ||||
B. Withdraw Reply | ||||
<msg xmlns="http://www.hactrn.net/uris/rpki/publication-spec/" | ||||
version="2" type="reply"> | ||||
<withdraw uri="rsync://wombat.invalid/testbed/RIR/1/j7ghjwblCr | ||||
cCp9ltyPDNzYKPfxc.cer"/> | ||||
</msg> | ||||
4.10. Example 10: Report Error Reply | ||||
A. Report Error Reply 1 | ||||
<msg xmlns="http://www.hactrn.net/uris/rpki/publication-spec/" | ||||
version="2" type="reply"> | ||||
<report_error error_code="your_hair_is_on_fire">text string</ | ||||
report_error> | ||||
</msg> | ||||
B. Report Error Reply 2 | ||||
<msg xmlns="http://www.hactrn.net/uris/rpki/publication-spec/" | ||||
version="2" type="reply"> | ||||
<report_error error_code="your_hair_is_on_fire"/> | ||||
</msg> | ||||
5. Operational Considerations | ||||
There are two basic options open to the repository operator as to how | ||||
the publication tree is laid out. The first option is simple: each | ||||
publication client is given its own directory one level below the top | ||||
of the rcynic module, and there is no overlap between the publication | ||||
spaces used by different clients. For example: | ||||
rsync://example.org/rpki/Alice/ | ||||
rsync://example.org/rpki/Bob/ | ||||
rsync://example.org/rpki/Carol/ | ||||
This has the advantage of being very easy for the publication | ||||
operator to manage, but has the drawback of making it difficult for | ||||
relying parties to fetch published objects both safely and as | ||||
efficiently as possible. | ||||
Given that the mandatory-to-implement retrieval protocol for relying | ||||
parties is rsync, a more efficient repository structure would be one | ||||
which minimized the number of rsync fetches required. One such | ||||
structure would be one in which the publication directories for | ||||
subjects were placed underneath the publication directories of their | ||||
issuers: since the normal synchronization tree walk is top-down, this | ||||
can significantly reduce the total number of rsync connections | ||||
required to synchronize. For example: | ||||
rsync://example.org/rpki/Alice/ | ||||
rsync://example.org/rpki/Alice/Bob/ | ||||
rsync://example.org/rpki/Alice/Bob/Carol/ | ||||
Preliminary measurement suggests that, in the case of large numbers | ||||
of small publication directories, the time needed to set up and tear | ||||
down individual rsync connections becomes significant, and that a | ||||
properly optimized tree structure can reduce synchronization time by | ||||
an order of magnitude. | ||||
The more complex tree structure does require careful attention to the | ||||
base_uri attribute values when setting up clients. In the example | ||||
above, assuming that Alice issues to Bob who in turn issues to Carol, | ||||
Alice has ceded control of a portion of her publication space to Bob, | ||||
who has in turn ceded a portion of that to Carol, and the base_uri | ||||
attributes in the <client/> setup messages should reflect this. | ||||
The details of how the repository operator determines that Alice has | ||||
given Bob permission to nest Bob's publication directory under | ||||
Alice's is outside the scope of this protocol. | ||||
6. IANA Considerations | ||||
IANA is asked to register the application/rpki-publication MIME media | IANA is asked to register the application/rpki-publication MIME media | |||
type as follows: | type as follows: | |||
MIME media type name: application | MIME media type name: application | |||
MIME subtype name: rpki-publication | MIME subtype name: rpki-publication | |||
Required parameters: None | Required parameters: None | |||
Optional parameters: None | Optional parameters: None | |||
Encoding considerations: binary | Encoding considerations: binary | |||
Security considerations: Carries an RPKI Publication Protocol | Security considerations: Carries an RPKI Publication Protocol | |||
skipping to change at page 10, line 24 | skipping to change at page 18, line 24 | |||
Applications which use this media type: HTTP | Applications which use this media type: HTTP | |||
Additional information: | Additional information: | |||
Magic number(s): None | Magic number(s): None | |||
File extension(s): | File extension(s): | |||
Macintosh File Type Code(s): | Macintosh File Type Code(s): | |||
Person & email address to contact for further information: | Person & email address to contact for further information: | |||
Rob Austein <sra@isc.org> | Rob Austein <sra@isc.org> | |||
Intended usage: COMMON | Intended usage: COMMON | |||
Author/Change controller: Rob Austein <sra@isc.org> | Author/Change controller: Rob Austein <sra@isc.org> | |||
6. Security Considerations | 7. Security Considerations | |||
7. References | The RPKI publication protocol and the data it publishes use entirely | |||
separate PKIs for authentication. The published data is | ||||
authenticated within the RPKI, and this protocol has nothing to do | ||||
with that authentication, nor does it require that the published | ||||
objects be valid in the RPKI. The publication protocol uses a | ||||
separate Business PKI (BPKI) to authenticate its messages. | ||||
7.1. Normative References | Each of the RPKI publication protocol messages is CMS-signed. | |||
Because of that protection at the application layer, this protocol | ||||
does not require the use of HTTPS or other transport security | ||||
mechanisms. | ||||
[I-D.ietf-sidr-rescerts-provisioning] | Compromise of a publication server, perhaps through mismanagement of | |||
Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A | BPKI keys, could lead to a denial-of-service attack on the RPKI. An | |||
Protocol for Provisioning Resource Certificates", | attacker gaining access to BPKI keys could use this protocol delete | |||
draft-ietf-sidr-rescerts-provisioning-10 (work in | (withdraw) RPKI objects, leading to routing changes or failures. | |||
progress), June 2011. | Accordingly, as in most PKIs, good key management practices are | |||
important. | ||||
8. References | ||||
8.1. Normative References | ||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, | [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, | |||
RFC 5652, September 2009. | RFC 5652, September 2009. | |||
7.2. Informative References | [RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A | |||
Protocol for Provisioning Resource Certificates", | ||||
RFC 6492, February 2012. | ||||
[I-D.ietf-sidr-arch] | 8.2. Informative References | |||
Lepinski, M. and S. Kent, "An Infrastructure to Support | ||||
Secure Internet Routing", draft-ietf-sidr-arch-13 (work in | [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support | |||
progress), May 2011. | Secure Internet Routing", RFC 6480, February 2012. | |||
Authors' Addresses | Authors' Addresses | |||
Samuel Weiler | Samuel Weiler | |||
SPARTA, Inc. | SPARTA, Inc. | |||
7110 Samuel Morse Drive | 7110 Samuel Morse Drive | |||
Columbia, Maryland 21046 | Columbia, Maryland 21046 | |||
US | US | |||
Email: weiler@tislabs.com | Email: weiler@tislabs.com | |||
Anuja Sonalker | Anuja Sonalker | |||
SPARTA, Inc. | SPARTA, Inc. | |||
7110 Samuel Morse Drive | 7110 Samuel Morse Drive | |||
Columbia, Maryland 21046 | Columbia, Maryland 21046 | |||
US | US | |||
Email: Anuja.Sonalker@sparta.com | Email: Anuja.Sonalker@sparta.com | |||
Rob Austein | Rob Austein | |||
ISC | Dragon Research Labs | |||
950 Charter Street | ||||
Redwood City, CA 94063 | ||||
USA | ||||
Email: sra@isc.org | Email: sra@hactrn.net | |||
End of changes. 21 change blocks. | ||||
45 lines changed or deleted | 409 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |