idnits 2.17.1 draft-rogaglia-sidr-multiple-publication-points-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6490]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 15, 2012) is 4209 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC5781' is mentioned on line 157, but not defined == Missing Reference: 'RFC4648' is mentioned on line 164, but not defined == Unused Reference: 'RFC6484' is defined on line 245, but no explicit reference was found in the text == Unused Reference: 'RFC6485' is defined on line 249, but no explicit reference was found in the text == Unused Reference: 'RFC6492' is defined on line 261, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-sidr-publication-02 ** Obsolete normative reference: RFC 6485 (Obsoleted by RFC 7935) ** Obsolete normative reference: RFC 6490 (Obsoleted by RFC 7730) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Gagliano 3 Internet-Draft Cisco Systems 4 Updates: RFC 6490 (if approved) T. Manderson 5 Intended status: Standards Track ICANN 6 Expires: April 18, 2013 C. Martinez 7 LACNIC 8 October 15, 2012 10 Multiple Repository Publication Points support in the Resource Public 11 Key Infrastructure (RPKI) 12 draft-rogaglia-sidr-multiple-publication-points-01 14 Abstract 16 The Resource Public Key Infrastructure (RPKI) depends on Relying 17 Parties (RP) ability to access its Trust Anchors' certificate 18 specified in the different "Trust Anchor Locator (TAL)" files and the 19 Repository Objects located at the Certificate Authorities (CA) 20 repositories hosted in its respective publication point. This 21 document updates [RFC6490] by allowing multiple URI associated to a 22 single public key in a TAL file and introduces the concept of 23 multiple repository publication point operators for every CA in the 24 RPKI. This document provides also recommendation for the RP behavior 25 when analyzing signed objects that include multiple publications 26 points. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 18, 2013. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 63 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Multiple Operators support in TAL files . . . . . . . . . . . 5 65 3.1. Update to RFC 6490 Section 2.1 . . . . . . . . . . . . . . 5 66 3.2. Rules for Relying Parties (RP) . . . . . . . . . . . . . . 6 67 4. Multiple Operators support in Certificates . . . . . . . . . . 7 68 4.1. Rules for Relying Parties (RP) . . . . . . . . . . . . . . 7 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 72 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 75 1. Requirements notation 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [RFC2119]. 81 2. Introduction 83 When thinking on how to scale the RPKI repository system described in 84 [RFC6481] CA operators have a number of options such as: 86 o Give the content to a Content Delivery Network (CDN) to have the 87 content distributed (as long as the CDN supports the access method 88 for the CA, which at this time is rsync). 90 o Copy the content to different Repository Publication Points around 91 the globe (i.e. using [I-D.ietf-sidr-publication]) and load 92 balance the content using different Domain Name System (DNS) 93 techniques. 95 When using any of these scaling technique to a unique CA Repository 96 Publication Point URI, there is a dependency in the resolution of a 97 single Fully Qualified Domain Name (FQDN). Also, when a single 98 operator manages a RPKI Repository Publication Point, it is possible 99 to introduce circular dependencies when the Route Origin 100 Authorization (ROA) signed objects for the Repository Publication 101 Point IP addresses are hosted in servers that uses those same 102 addresses. The idea of having multiple Repository Publication Points 103 operators for a RPKI CA mitigates these risks and is complementary to 104 any other scaling solution (as the ones described above). 106 The first thing that is needed is to add multiple URIs support for 107 each Trust Anchor. [RFC6490] requires that each TAL file includes a 108 unique URI. This document remove this requirement by allowing one or 109 more URI for each public key in a TAL file. 111 A CA can add support for multiple Repository Publication Points 112 operators by adding more than one respective object for the Authority 113 Information Access (AIA), the Subject Information Access (SIA) and 114 the CRL Distribution Points (CRLDP) and which is supported by 115 [RFC5280] and [RFC6487] . 117 The addition of multiple Repository Publication Points operators for 118 CAs in the RPKI introduces complexity for the RP. This documents 119 provide some recommendations for RP implementors. 121 3. Multiple Operators support in TAL files 123 The idea of multiples operators support for a Trust Anchor 124 certificate expressed on its TAL file is similar to the support for 125 several Root Server operators in a DNS hints file. 127 An example of such a TAL file with 3 operators would be: 129 rsync://rpki.operator1.org/rpki/hedgehog/root.cer 130 rsync://rpki.operator2.net/rpki/hedgehog/root.cer 131 rsync://rpki.operator3.biz/rpki/hedgehog/root.cer 133 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAovWQL2lh6knDx 134 GUG5hbtCXvvh4AOzjhDkSHlj22gn/1oiM9IeDATIwP44vhQ6L/xvuk7W6 135 Kfa5ygmqQ+xOZOwTWPcrUbqaQyPNxokuivzyvqVZVDecOEqs78q58mSp9 136 nbtxmLRW7B67SJCBSzfa5XpVyXYEgYAjkk3fpmefU+AcxtxvvHB5OVPIa 137 BfPcs80ICMgHQX+fphvute9XLxjfJKJWkhZqZ0v7pZm2uhkcPx1PMGcrG 138 ee0WSDC3fr3erLueagpiLsFjwwpX6F+Ms8vqz45H+DKmYKvPSstZjCCq9 139 aJ0qANT9OtnfSDOS+aLRPjZryCNyvvBHxZXqj5YCGKtwIDAQAB 141 As we can see in this example, a RP would have different URI where to 142 fetch the self-signed certificate for the trust anchor. In each 143 location, the same result should be expected as all the URI share the 144 same public key. 146 In order to increase in diversity, It is RECOMMENDED that different 147 FQDN could be resolved to IP addresses included in ROA objects from 148 different CAs and hosted in diverse Repository Publication Points. 150 3.1. Update to RFC 6490 Section 2.1 152 The following text will replace the last paragraph on Section 2.1 of 153 RFC 6490: 155 The TAL is an ordered sequence of: 157 1) One or more rsync URI [RFC5781], 159 2) A or line break after each URI, 161 3) A line containing a single or line break, and 163 4) A subjectPublicKeyInfo [RFC5280] in DER format [X.509], encoded in 164 Base64 (see Section 4 of [RFC4648]).A 166 3.2. Rules for Relying Parties (RP) 168 A RP can use different rules to select the URI from where fetch the 169 Trust Anchor certificate. Some examples are: 171 o Using the order provided in the TAL file 173 o Selecting the URI randomly from the available list 175 o Creating a prioritized list of URIs based on RP specific 176 parameters such as connection establishment delay 178 If the connection to the preferred URI fails or the fetched 179 certificate public key does not match the TAL public key, the RP 180 SHOULD fetch the TA certificate from the next URI of preference. 182 4. Multiple Operators support in Certificates 184 The support for multiple operators in the RPKI Certificate Authority 185 (CA) and End Entity (EE) certificates is supported as the RFC 5082 186 allows multiple repository publication point operators as the SIA, 187 AIA and CRLDP are implemented as sequences. Consequently, no changes 188 are needed on the existing RPKI standard and this section could be 189 considered informative. 191 In the case of the SIA extension, for each operator, the 192 accessMethods for both the CA repository publication point and for 193 the correspondent manifest needs to be added. 195 4.1. Rules for Relying Parties (RP) 197 A RP can use different rules to select the URI to fetch the different 198 repository objects and when performing the validation. 200 When a RP needs to fetch one or more object from a list of possible 201 URIs, it can chose the URI by adopting a locally defined rule that 202 could be: 204 o Using the order provided in the correspondent certificate 206 o Selecting the URI randomly from the available list 208 o Creating a prioritized list of URIs based on RP specific 209 parameters such as connection establishment delay 211 If the connection to the preferred URI fails , the RP SHOULD fetch 212 the repository objects from the next URI of preference. 214 5. IANA Considerations 216 No IANA requirements 218 6. Security Considerations 220 TBA 222 7. Acknowledgements 224 TBA. 226 8. Normative References 228 [I-D.ietf-sidr-publication] 229 "A Publication Protocol for the Resource Public Key 230 Infrastructure (RPKI)", . 233 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 234 Requirement Levels", BCP 14, RFC 2119, March 1997. 236 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 237 Housley, R., and W. Polk, "Internet X.509 Public Key 238 Infrastructure Certificate and Certificate Revocation List 239 (CRL) Profile", RFC 5280, May 2008. 241 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 242 Resource Certificate Repository Structure", RFC 6481, 243 February 2012. 245 [RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate 246 Policy (CP) for the Resource Public Key Infrastructure 247 (RPKI)", BCP 173, RFC 6484, February 2012. 249 [RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for 250 Use in the Resource Public Key Infrastructure (RPKI)", 251 RFC 6485, February 2012. 253 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 254 X.509 PKIX Resource Certificates", RFC 6487, 255 February 2012. 257 [RFC6490] Huston, G., Weiler, S., Michaelson, G., and S. Kent, 258 "Resource Public Key Infrastructure (RPKI) Trust Anchor 259 Locator", RFC 6490, February 2012. 261 [RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A 262 Protocol for Provisioning Resource Certificates", 263 RFC 6492, February 2012. 265 Authors' Addresses 267 Roque Gagliano 268 Cisco Systems 269 Avenue des Uttins 5 270 Rolle, 1180 271 Switzerland 273 Email: rogaglia@cisco.com 275 Terry Manderson 276 ICANN 278 Email: terry.manderson@icann.org 280 Carlos Martinez 281 LACNIC 283 Email: carlos@lacnic.net