idnits 2.17.1 draft-rogaglia-sidr-multiple-publication-points-02.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 (February 25, 2013) is 4075 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 199, but not defined == Missing Reference: 'RFC4648' is mentioned on line 206, but not defined == Unused Reference: 'RFC6484' is defined on line 287, but no explicit reference was found in the text == Unused Reference: 'RFC6485' is defined on line 291, but no explicit reference was found in the text == Unused Reference: 'RFC6492' is defined on line 303, 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: August 29, 2013 C. Martinez 7 LACNIC 8 February 25, 2013 10 Multiple Repository Publication Points support in the Resource Public 11 Key Infrastructure (RPKI) 12 draft-rogaglia-sidr-multiple-publication-points-02 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 August 29, 2013. 45 Copyright Notice 47 Copyright (c) 2013 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 . . . . . . . . . . . 6 65 3.1. Update to RFC 6490 Section 2.1 . . . . . . . . . . . . . . 6 66 3.2. Rules for Relying Parties (RP) . . . . . . . . . . . . . . 7 67 4. Multiple Operators support in Certificates . . . . . . . . . . 8 68 4.1. Rules for Relying Parties (RP) . . . . . . . . . . . . . . 8 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 72 8. Normative References . . . . . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 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 The RPKI repository system described in [RFC6481] requires 84 scalability and diversity in order to address challenges such as 85 Distributed Denial of Service (DDoS) attacks, to secure the 86 availability of the system when performing maintenance activities and 87 against possible security incidents in one particular implementation. 88 Additionally, when a single operator manages a RPKI Repository 89 Publication Point, it is more probable to introduce circular 90 dependencies when the Route Origin Authorization (ROA) signed objects 91 for the Repository Publication Point IP addresses are hosted in 92 servers that uses those same addresses. 94 The current toolset for a CA to diversify its repository system is 95 limited for both TA distribution and CA publication point management. 96 In the case of trust anchors, [RFC6490] requires a unique URI per key 97 on each TAL file. Conversely, in the case of the different 98 publication points and although supported by [RFC6487] , there is no 99 current guidance on how RPs should support multiple publication 100 points for the same object. 102 When using a single URI, the options for diversity and scalability 103 are reduced to: 105 1. Give the content to a Content Delivery Network (CDN) to have the 106 content distributed (as long as the CDN supports the CA's access 107 method , which is not currently the case for rsync). The 108 implementation will typically require the configuration of a 109 CNAME resource record in the authoritative server pointing to a 110 server farm inside the CDN who will handle load-balancing by 111 using a set of internally defined metrics. If, for the sake of 112 diversity, a CA administrator would like to use two different 113 CDNs for the same URI it will need to modify the authoritative 114 name server behavior to break RFC1034 standard behavior and allow 115 multiple CNAME records for the same alias. This modification is 116 not available by default on most of the more widely deployed DNS 117 servers. 119 2. Copy the content to different Repository Publication Points 120 around the globe (i.e. using [I-D.ietf-sidr-publication]) and 121 load balance the content using different Domain Name System (DNS) 122 techniques. The load balancing implementation will need to 123 verify the availability of the target server before providing a 124 DNS response to avoid blackholes caused by unavailable servers or 125 clusters. This "feature" needs also be added to the 126 authoritative name server or the full DNS resolution or 127 outsourced to a third party (which would introduce another non- 128 diversified element). 130 This document addresses this problem by enabling multiple operators 131 for trust anchor material, and, while not making it mandatory, 132 recommends the use of multiple publication points in signed objects. 134 The main idea is that the a CA will host its RPKI signed objects in 135 different locations, using diverse routing paths and diverse DNS 136 resolution. The RP will have more processing to perform to fetch the 137 different objects when dealing with exceptions. 139 The first thing that is needed is to add multiple URIs support for 140 each Trust Anchor. [RFC6490] requires that each TAL file includes a 141 unique URI. This document removes this requirement by allowing one 142 or more URI for each public key in a TAL file. In steady state, an 143 RP should receive the same material from each of the different URI 144 for the same root certificate. An exception could happen when the 145 certificate is been updated or rolled-over, a process which should 146 not have operational consequences. 148 For the root certificate trust anchor, this proposal has an 149 additional consequence: it would create the idea of root-CA 150 repository operators. This concept has worked well in the case of 151 DNS, where one organization is responsible for creating the root zone 152 material and a number of different organizations are responsible in 153 running the root servers. 155 A CA can add support for multiple Repository Publication Points 156 operators by adding more than one respective object for the Authority 157 Information Access (AIA), the Subject Information Access (SIA) and 158 the CRL Distribution Points (CRLDP) and which is supported by 159 [RFC5280] and [RFC6487] . This document provides guidance on the RP 160 expected behavior when analyzing signed objects with multiple 161 Repository Publication Points in Section 4. 163 3. Multiple Operators support in TAL files 165 The idea of multiples operators support for a TA certificate 166 expressed on its TAL file is similar to the support for several Root 167 Server operators in a DNS hints file. 169 An example of such a TAL file with 3 operators would be: 171 rsync://rpki.operator1.org/rpki/hedgehog/root.cer 172 rsync://rpki.operator2.net/rpki/hedgehog/root.cer 173 rsync://rpki.operator3.biz/rpki/hedgehog/root.cer 175 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAovWQL2lh6knDx 176 GUG5hbtCXvvh4AOzjhDkSHlj22gn/1oiM9IeDATIwP44vhQ6L/xvuk7W6 177 Kfa5ygmqQ+xOZOwTWPcrUbqaQyPNxokuivzyvqVZVDecOEqs78q58mSp9 178 nbtxmLRW7B67SJCBSzfa5XpVyXYEgYAjkk3fpmefU+AcxtxvvHB5OVPIa 179 BfPcs80ICMgHQX+fphvute9XLxjfJKJWkhZqZ0v7pZm2uhkcPx1PMGcrG 180 ee0WSDC3fr3erLueagpiLsFjwwpX6F+Ms8vqz45H+DKmYKvPSstZjCCq9 181 aJ0qANT9OtnfSDOS+aLRPjZryCNyvvBHxZXqj5YCGKtwIDAQAB 183 As we can see in this example, a RP would have different URI where to 184 fetch the self-signed certificate for the trust anchor. In each 185 location, the same result should be expected as all the URI share the 186 same public key. 188 In order to increase diversity, It is RECOMMENDED that the different 189 FQDN could be resolved to IP addresses included in ROA objects from 190 different CAs and hosted in diverse repository publication points. 192 3.1. Update to RFC 6490 Section 2.1 194 The following text will replace the last paragraph on Section 2.1 of 195 RFC 6490: 197 The TAL is an ordered sequence of: 199 1) One or more rsync URI [RFC5781], 201 2) A or line break after each URI, 203 3) A line containing a single or line break, and 205 4) A subjectPublicKeyInfo [RFC5280] in DER format [X.509], encoded in 206 Base64 (see Section 4 of [RFC4648]).A 208 3.2. Rules for Relying Parties (RP) 210 A RP can use different rules to select the URI from where fetch the 211 Trust Anchor certificate. Some examples are: 213 o Using the order provided in the TAL file 215 o Selecting the URI randomly from the available list 217 o Creating a prioritized list of URIs based on RP specific 218 parameters such as connection establishment delay 220 If the connection to the preferred URI fails or the fetched 221 certificate public key does not match the TAL public key, the RP 222 SHOULD fetch the TA certificate from the next URI of preference. 224 4. Multiple Operators support in Certificates 226 The support for multiple operators in the RPKI Certificate Authority 227 (CA) and End Entity (EE) certificates is supported as the RFC 5082 228 allows multiple repository publication point operators as the SIA, 229 AIA and CRLDP are implemented as sequences. Consequently, no changes 230 are needed on the existing RPKI standard and this section could be 231 considered informative. 233 In the case of the SIA extension, for each operator, the 234 accessMethods for both the CA repository publication point and for 235 the correspondent manifest needs to be added. 237 4.1. Rules for Relying Parties (RP) 239 A RP can use different rules to select the URI to fetch the different 240 repository objects and when performing the validation. 242 When a RP needs to fetch one or more object from a list of possible 243 URIs, it can chose the URI by adopting a locally defined rule that 244 could be: 246 o Using the order provided in the correspondent certificate 248 o Selecting the URI randomly from the available list 250 o Creating a prioritized list of URIs based on RP specific 251 parameters such as connection establishment delay 253 If the connection to the preferred URI fails , the RP SHOULD fetch 254 the repository objects from the next URI of preference. 256 5. IANA Considerations 258 No IANA requirements 260 6. Security Considerations 262 TBA 264 7. Acknowledgements 266 TBA. 268 8. Normative References 270 [I-D.ietf-sidr-publication] 271 "A Publication Protocol for the Resource Public Key 272 Infrastructure (RPKI)", . 275 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 276 Requirement Levels", BCP 14, RFC 2119, March 1997. 278 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 279 Housley, R., and W. Polk, "Internet X.509 Public Key 280 Infrastructure Certificate and Certificate Revocation List 281 (CRL) Profile", RFC 5280, May 2008. 283 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 284 Resource Certificate Repository Structure", RFC 6481, 285 February 2012. 287 [RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate 288 Policy (CP) for the Resource Public Key Infrastructure 289 (RPKI)", BCP 173, RFC 6484, February 2012. 291 [RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for 292 Use in the Resource Public Key Infrastructure (RPKI)", 293 RFC 6485, February 2012. 295 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 296 X.509 PKIX Resource Certificates", RFC 6487, 297 February 2012. 299 [RFC6490] Huston, G., Weiler, S., Michaelson, G., and S. Kent, 300 "Resource Public Key Infrastructure (RPKI) Trust Anchor 301 Locator", RFC 6490, February 2012. 303 [RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A 304 Protocol for Provisioning Resource Certificates", 305 RFC 6492, February 2012. 307 Authors' Addresses 309 Roque Gagliano 310 Cisco Systems 311 Avenue des Uttins 5 312 Rolle, 1180 313 Switzerland 315 Email: rogaglia@cisco.com 317 Terry Manderson 318 ICANN 320 Email: terry.manderson@icann.org 322 Carlos Martinez 323 LACNIC 325 Email: carlos@lacnic.net