idnits 2.17.1 draft-kwvanhove-sidrops-rpki-tree-hints-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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (13 December 2021) is 865 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: 'RFCxxxx' is mentioned on line 213, but not defined ** Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force K.W. van Hove 3 Internet-Draft University of Twente 4 Intended status: Standards Track 13 December 2021 5 Expires: 16 June 2022 7 Tree Hints for the Resource Public Key Infrastructure (RPKI) 8 draft-kwvanhove-sidrops-rpki-tree-hints-01 10 Abstract 12 In the Resource Public Key Infrastructure (RPKI), holders of IP 13 address space can become a Certification Authority (CA), optionally 14 hosting their repository. They can also delegate (part of) their 15 resources to subordinate CAs, who in turn may do the same. This CA 16 hierarchy forms a tree structure. Relying Party (RP) software walks 17 this tree and determines the current valid objects. An underlying 18 assumption is that this tree is a reasonable size, and that the 19 information can be processed within reasonable time. This assumption 20 is not guaranteed to hold. This document describes two new 21 extensions, "maxDescendants" and "maxVrps", that add constraints for 22 use in RP processing that ensure this assumption holds. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 16 June 2022. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Revised BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Revised BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Resource Certificate Extensions . . . . . . . . . . . . . . . 4 61 3.1. maxDescendants . . . . . . . . . . . . . . . . . . . . . 4 62 3.2. maxVrps . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Validation . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 Appendix A. Example Resource Certificate . . . . . . . . . . . . 7 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 In the RPKI, holders of IP address space can host their own 74 repositories and act as their own CA. They have full control over 75 that repository and any objects signed by their CA. They may, for 76 example, sign one or more certificates that hold a subset of the 77 resources from the parent certificate. These certificates may 78 reference publication points in the same repository or different 79 ones. These new certificates can, in turn, do the same, ad 80 infinitum. The nested structure of CAs forms a tree structure. The 81 root of these trees are defined by the Trust Anchor Locators (TALs) 82 [RFC8630]. RP software is assumed to walk this tree, visit every 83 node, and retrieve all objects (e.g. Manifests [RFC6486], Route 84 Origin Authorizations [RFC6482], Ghostbuster records [RFC6493], other 85 certificates [RFC6481], etc.). RP software collects all information 86 from the objects and processes it. It is important to note that RP 87 software needs to visit every repository and consider every object 88 CAs put on manifests. If it would exclude any repository or CA, then 89 a BGP advertisement that should be valid can become invalid. For 90 example, if a ROA for the prefix 2001:DB8::/32 and AS64496 is 91 included, but the ROA for 2001:DB8:123::/48 and AS64497 (from another 92 CA) is not, then a BGP speaker performing ROV validation may falsely 93 reject the latter, more specific, announcement. 95 For RP software to fully walk the tree, the tree needs to be finite 96 and reasonably sized. However, the size of the tree can only be 97 determined while traversing the tree - RP software cannot verify 98 these properties in advance. A malicious CA could, for example, 99 create its children in an ad-hoc fashion while RP software is 100 discovering it, thereby violating the implicit assumption that the 101 tree is finite. That specific behaviour can be countered by RP 102 software by setting a maximum depth for a certificate chain. 103 However, at 10 children per child, the number of repositories would 104 already reach 1111111111 (10^0 + 10^1 + ... + 10^9) after a modest 10 105 levels. With other strategies, such as serving gigabytes of data and 106 simulating a very low bandwidth, a malicious repository can violate 107 our second assumption that the tree is reasonably sized. Using 108 malicious repository content, any CA can cause the process to take so 109 unreasonably long that RP software does not finish processing in a 110 reasonable amount of time (possibly years). The size and structure 111 of nodes in the RPKI tree varies. For example, a NIR may have a 112 legitimate need for hundreds of child-CAs, while a regular CA under 113 the same parent does not. This diversity makes heuristics unsuitable 114 for detecting this issue adequately, only discarding the malicious 115 repository and its children, without heavily restricting the freedom 116 of the structure of RPKI or causing false positives capping future 117 growth. 119 Likewise, there may be valid reasons for splitting a prefix into many 120 subprefixes, or authorising subprefixes for many autonomous system 121 numbers (ASNs), but allowing any party to add limitless prefix-ASN 122 pairs may overflow BGP Origin Validation tables. Setting a fixed 123 limit may be problematic in these cases. 125 The new certificate extensions, "maxDescendants" and "maxVrps", are 126 added to mitigate this issue by providing RP software prior knowledge 127 about the tree limits before walking the tree. 129 1.1. Requirements Language 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC 2119 [RFC2119]. 135 2. Scope 137 The scope of "maxDescendants" and "maxVrps" is to provide guidance 138 for RP software regarding the expected structure of the tree, as well 139 as impose requirements on other aspects of the CA and its repository. 140 Following the information in "maxDescendants" and "maxVrps" is 141 RECOMMENDED. However, local policy MAY prevail. 143 3. Resource Certificate Extensions 145 These extensions extend the already defined extensions for PKIX 146 Resource Certificates as defined in RFC 6487 section 4.8 [RFC6487]. 147 Both maxDescendants and maxVrps SHOULD appear at least once in each 148 certificate chain. If these extensions are absent on a certificate, 149 it means that this certificate imposes no additional limits. 151 3.1. maxDescendants 153 This extension is a non-critical extension that defines the maximum 154 cumultative amount of descendants under this CA. BGPsec Router 155 Certificates [RFC8209] are not counted because they do not add child- 156 objects to the validation tree. At a value of 0, an RP SHOULD NOT 157 visit any of the child CAs listed on the manifest. At a value of N, 158 an RP SHOULD at most visit N descendants of this CA. This does not 159 affect the amount of EE certificates used for signing objects like 160 manifests and ROAs - those are not affected by this limit. This does 161 include children and children of children. If maxDescendants is 162 defined at multiple levels in the certificate chain, then the 163 strictest limit MUST prevail. 165 The maxDescendants extension contains the maximum amount of children 166 the CA may at most have. This number SHOULD be lower than the 167 effective maxDescendants value for this CA. A value higher than or 168 equal to the effective maxDescendants value will cause the children 169 to have an effective maxDescendants value equal to the effective 170 maxDescendants value of this CA minus one. 172 3.2. maxVrps 174 This extension is a non-critical extension that defines the maximum 175 cumultative amount of Validated ROA Payloads (VRPs) [RFC6811] under 176 this CA. At a value of 0, an RP SHOULD NOT accept any of the ROAs 177 under this CA. At a value of N, an RP SHOULD create most accept N 178 VRPs based on data from this CA and its descendants. This means that 179 at a limit of 25, one can create five ROAs with different ASNs with 180 each five prefixes, or one ROA with 25 prefixes, or any combination 181 that ensures the VRP count stays less or equal to maxVrps. This 182 includes data from ROAs at children and children of children. If 183 maxDescendants is defined at multiple levels in the certificate 184 chain, then the strictest limit MUST prevail. 186 4. Validation 188 In order to validate the limits, RP software constructs the chain of 189 certificates from the current certificate up to the root. For each 190 limit, RP software should check for each certificate in this chain 191 whether that certificate defines a limit. Then the most strict limit 192 of all limits present in the chain should be used as limit. During 193 evaluation the RP software checks whether any limits have been 194 violated, and if so, stops processing below the violating branch of 195 the tree. If a limit is absent from the entire chain, a reasonable 196 default SHOULD be used. Root CAs SHOULD define all limits on 197 certificates for third-parties. 199 5. IANA Considerations 201 This document registers the following RPKI extensions: 203 Name: maxDescendants 205 OID: xxx 207 Reference: [RFCxxxx] (this document) 209 Name: maxVrps 211 OID: xxx 213 Reference: [RFCxxxx] (this document) 215 6. Security Considerations 217 This document contains security enhancements for the tree discovery 218 process in the RPKI protocol. maxDescendants and maxVrps can help 219 prevent a number of denial of service attacks against RP instances. 221 There may be maxDescendants and maxVrps extensions published at the 222 root level with very large allowances, thereby effectively negating 223 the protections offered. The same precautions described in [RFC8630] 224 apply here as well. 226 CAs should be careful with setting their maxDescendants limits. If 227 the maxDescendants value times the amount of children of a CA is 228 higher than the effective maxDescendants value of that CA, then one 229 or more children may cause the maximum amount of children to be 230 exceeded, even if none act malicious. This may cause routing data to 231 not be retrieved. For example, take a CA A with three children: AA, 232 AB, and AC. A has an effective maxDescendants of 10, and sets its 233 maxDescendants value to 5, which thus applies to AA, AB, and AC. If 234 both AA and AB decide to fully use their five children, for example 235 by creating AAA, AAB, AAC, AACA, AACB, ABA, ABAA, ABAAA, ABAAAA, and 236 ABAAAAA, then RP software may no longer check AC, as AA and AB 237 together already hit the effective maxDescendants of A. Note that 238 the retrieval order is not defined, thus different RP software may 239 decide to first retrieve AA, AB, and AC, and exclude a different CA, 240 for example ABAAAAA. This also applies to maxVrps. 242 This may lead to RP software not retrieving data from certain CAs, 243 which can lead to partial data. The threat that comes with partial 244 data is that, for example, a BGP advertisement that should be valid, 245 may become invalid, as the ROA for the advertisement is missing, and 246 the less-specific prefix does have a ROA that was retrieved. When 247 choosing limits, careful consideration must be taken to ensure that 248 malicious actors cannot disrupt RPKI, whilst the data from valid 249 actors is still retrieved. 251 7. References 253 7.1. Normative References 255 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 256 Requirement Levels", BCP 14, RFC 2119, 257 DOI 10.17487/RFC2119, March 1997, 258 . 260 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 261 Resource Certificate Repository Structure", RFC 6481, 262 DOI 10.17487/RFC6481, February 2012, 263 . 265 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 266 Origin Authorizations (ROAs)", RFC 6482, 267 DOI 10.17487/RFC6482, February 2012, 268 . 270 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 271 "Manifests for the Resource Public Key Infrastructure 272 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 273 . 275 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 276 X.509 PKIX Resource Certificates", RFC 6487, 277 DOI 10.17487/RFC6487, February 2012, 278 . 280 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 281 Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, 282 February 2012, . 284 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 285 Austein, "BGP Prefix Origin Validation", RFC 6811, 286 DOI 10.17487/RFC6811, January 2013, 287 . 289 [RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for 290 BGPsec Router Certificates, Certificate Revocation Lists, 291 and Certification Requests", RFC 8209, 292 DOI 10.17487/RFC8209, September 2017, 293 . 295 [RFC8630] Huston, G., Weiler, S., Michaelson, G., Kent, S., and T. 296 Bruijnzeels, "Resource Public Key Infrastructure (RPKI) 297 Trust Anchor Locator", RFC 8630, DOI 10.17487/RFC8630, 298 August 2019, . 300 Appendix A. Example Resource Certificate 302 The following is the example resource certificate from RFC 6487 303 [RFC6487] adapted with maxDescendants and maxVrps. 305 Certificate Name: 9JfgAEcq7Q-47IwMC5CJIJr6EJs.cer 307 Data: 308 Version: 3 (0x2) 309 Serial: 1500 (0x5dc) 310 Signature Algorithm: SHA256WithRSAEncryption 311 Issuer: CN=APNIC Production-CVPQSgUkLy7pOXdNeVWGvnFX_0s 312 Validity 313 Not Before: Oct 25 12:50:00 2008 GMT 314 Not After : Jan 31 00:00:00 2010 GMT 315 Subject: CN=A91872ED 316 Subject Public Key Info: 317 Public Key Algorithm: rsaEncryption 318 RSA Public Key: (2048 bit) 319 Modulus (2048 bit): 320 00:bb:fb:4a:af:a4:b9:dc:d0:fa:6f:67:cc:27:39: 321 34:d1:80:40:37:de:88:d1:64:a2:f1:b3:fa:c6:7f: 322 bb:51:df:e1:c7:13:92:c3:c8:a2:aa:8c:d1:11:b3: 323 aa:99:c0:ac:54:d3:65:83:c6:13:bf:0d:9f:33:2d: 324 39:9f:ab:5f:cd:a3:e9:a1:fb:80:7d:1d:d0:2b:48: 325 a5:55:e6:24:1f:06:41:35:1d:00:da:1f:99:85:13: 326 26:39:24:c5:9a:81:15:98:fb:5f:f9:84:38:e5:d6: 327 70:ce:5a:02:ca:dd:61:85:b3:43:2d:0b:35:d5:91: 329 98:9d:da:1e:0f:c2:f6:97:b7:97:3e:e6:fc:c1:c4: 330 3f:30:c4:81:03:25:99:09:4c:e2:4a:85:e7:46:4b: 331 60:63:02:43:46:51:4d:ed:fd:a1:06:84:f1:4e:98: 332 32:da:27:ee:80:82:d4:6b:cf:31:ea:21:af:6f:bd: 333 70:34:e9:3f:d7:e4:24:cd:b8:e0:0f:8e:80:eb:11: 334 1f:bc:c5:7e:05:8e:5c:7b:96:26:f8:2c:17:30:7d: 335 08:9e:a4:72:66:f5:ca:23:2b:f2:ce:54:ec:4d:d9: 336 d9:81:72:80:19:95:57:da:91:00:d9:b1:e8:8c:33: 337 4a:9d:3c:4a:94:bf:74:4c:30:72:9b:1e:f5:8b:00: 338 4d:e3 339 Exponent: 65537 (0x10001) 340 X509v3 extensions: 341 X509v3 Subject Key Identifier: 342 F4:97:E0:00:47:2A:ED:0F:B8:EC:8C:0C:0B:90:89: 343 20:9A:FA:10:9B 345 X509v3 Authority Key Identifier: 346 keyid:09:53:D0:4A:05:24:2F:2E:E9:39:77:4D:79: 347 55:86:BE:71:57:FF:4B 349 X509v3 Key Usage: critical 350 Certificate Sign, CRL Sign 352 X509v3 Basic Constraints: critical 353 CA:TRUE 355 X509v3 CRL Distribution Points: 356 URI:rsync://rpki.apnic.net/repository/A3C38A24 357 D60311DCAB08F31979BDBE39/CVPQSgUkLy7pOXdNe 358 VWGvnFX_0s.crl 360 Authority Information Access: 361 CA Issuers - URI:rsync://rpki.apnic.net/repos 362 itory/8BDFC7DED5FD11DCB14CF4B1A703F9B7/CVP 363 QSgUkLy7pOXdNeVWGvnFX_0s.cer 365 X509v3 Certificate Policies: critical 366 Policy: 1.3.6.1.5.5.7.14.2 368 Subject Information Access: 369 CA Repository - URI:rsync://rpki.apnic.net/mem 370 ber_repository/A91872ED/06A83982887911DD81 371 3F432B2086D636/ 372 Manifest - URI:rsync://rpki.apnic.net/member_r 373 epository/A91872ED/06A83982887911DD813F432 374 B2086D636/9JfgAEcq7Q-47IwMC5CJIJr6EJs.mft 376 sbgp-autonomousSysNum: critical 377 Autonomous System Numbers: 378 24021 379 38610 380 131072 381 131074 383 sbgp-ipAddrBlock: critical 384 IPv4: 385 203.133.248.0/22 386 203.147.108.0/23 388 maxDescendants: 389 16 391 maxVrps: 392 2048 394 Author's Address 396 Koen van Hove 397 University of Twente 399 Email: koen@koenvh.nl