idnits 2.17.1 draft-rir-rpki-allres-ta-app-statement-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 document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 18, 2017) is 2475 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-sidr-rpki-validation-reconsidered-06 Summary: 2 errors (**), 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 A. Newton, Ed. 3 Internet-Draft ARIN 4 Intended status: Informational C. Martinez-Cagnazzo, Ed. 5 Expires: January 19, 2018 LACNIC 6 D. Shaw 7 AFRINIC 8 T. Bruijnzeels 9 RIPE NCC 10 B. Ellacott 11 APNIC 12 July 18, 2017 14 RPKI Multiple "All Resources" Trust Anchors Applicability Statement 15 draft-rir-rpki-allres-ta-app-statement-02 17 Abstract 19 This document provides an applicability statement for the use of 20 multiple, over-claiming 'all resources' (0/0) RPKI certificate 21 authorities (CA) certificates used as trust anchors (TAs) operated by 22 the Regional Internet Registry community to help mitigate the risk of 23 massive downstream invalidation in the case of transient registry 24 inconsistencies. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 19, 2018. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 3. Applicability to reduce overclaiming possibilities . . . . . 3 63 4. Normative References . . . . . . . . . . . . . . . . . . . . 4 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 66 1. Requirements Language 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in RFC 2119 [RFC2119]. 72 2. Introduction 74 The RPKI is a hierarchical cryptologic system that uses X.509 75 certificates to match and validate holdership of Internet number 76 resources. This validation follows the allocation change from IANA 77 to an RIR, to an NIR or LIR, and ending with end users who make use 78 of the address block. Since these allocations can be 79 cryptographically validated, this can then be tied to assertions made 80 by the holder of those number resources. As an improvement of this 81 system, the RPKI was updated to add validation of origin routing 82 announcements via ROAs. These ROAs can then be independently and 83 cryptographically validated by third parties to assure themselves 84 that the origin of the announcement as seen in the actual routing 85 system is valid. 87 Since this system is envisioned to be used by network operators and 88 ISPs to determine their routing decisions, there is a goal to be 100% 89 correct 100% of the time. This goal could be achieved if the system 90 was contained in a static environment where there is little or no 91 movement of holdership changes from one organization to another of 92 number resources. Unfortunately, this state cannot be achieved 93 today, as movement of number resouces from from organization to 94 organization is becoming common largely due to IPv4 scarcity. 96 Unfortunately, this state of 100% correctness at all times is 97 infeasible in a model where separate entities are operating 98 independently, yet rely critically on each others' perfect 99 synchronisation at all times. 101 Because the current validation mechanism is all-or-nothing, any 102 inconsistency at all at a high apex CA has the potential to 103 invalidate a large number of additional Internet Number Resources. 104 The higher the apex, and the larger the total set of INRs maintained 105 by the CA, the greater the impact of even a small inconsistency. 107 As resources do change at high apex CAs for a variety of reasons, the 108 likelihood of a small inconsistency is non-zero. And the likelihood 109 of a transitional inconsistency is moderate. Due to the distributed 110 nature of the RPKI repository mechanism, even if all CAs were able to 111 operate in perfect synchronicity at all times, there is a reasonable 112 likelihood that a given validating client may witness a temporarily 113 inconsistent state of the system as a whole. A risk of wide-spread 114 invalidity therefore exists as a very high impact and moderate 115 likelihood event. 117 This brittleness in the RPKI validation rules has been identified and 118 presented by the current RPKI TA operators to the IETF. A solution 119 has also been proposed 120 ([I-D.ietf-sidr-rpki-validation-reconsidered]), a solution that would 121 allow for accidental over-claiming only to invalidate the resource 122 that is incorrectly listed and allow the remaining to continue to be 123 valid. As the implementation and deployment of solutions to this 124 problem will occur according to timelines outside the control of the 125 current TA operators, the workaround proposed in the present draft 126 provides an acceptable trade-off. 128 3. Applicability to reduce overclaiming possibilities 130 The consequences of an RIR over-claiming are grave given that every 131 ISP within their certificate would be invalidated. If routing was to 132 be reliant on RPKI at this point, all routes announced by those ISPs 133 below the affected RIR certificate would cease to work. 135 To mitigate risk and alleviate this threat, each RIR will move from a 136 Trust Anchor that reflects their current holdings only, to one that 137 reflects all holdings (e.g. 0/0). This will then ensure that over- 138 claiming can not occur at a RIR level when dealing with transfers 139 from one RIR to another. RPKI validators will not see the five Trust 140 anchors from the RIRs as over-claiming and validation can proceed 141 normally. 143 For those who may want to audit the RIRs to ensure that RIRs are not 144 allocating the same IP addresses in separate regions, this can be 145 done by matching the inventory of each RIR ([NROSTATS]) that is 146 provided by the RIRs with the certificates issued by the RIRs within 147 the RPKI. 149 Note that there will be minor changes from time to time to account 150 for movements from IP address holdings that are in flight from one 151 RIR to another and that transient overlaps can, and probably will, 152 occur as inter-RIR transfers become more and more common. 154 4. Normative References 156 [I-D.ietf-sidr-rpki-validation-reconsidered] 157 Huston, G., Michaelson, G., Martinez, C., Bruijnzeels, T., 158 Newton, A., and D. Shaw, "RPKI Validation Reconsidered", 159 draft-ietf-sidr-rpki-validation-reconsidered-06 (work in 160 progress), July 2016. 162 [NROSTATS] 163 "NRO Extended Stats File", July 2016, 164 . 167 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 168 Requirement Levels", BCP 14, RFC 2119, 169 DOI 10.17487/RFC2119, March 1997, 170 . 172 Authors' Addresses 174 Andrew Newton (editor) 175 ARIN 176 Chantilly VA 177 United States 179 Email: andy@arin.net 181 Carlos Martinez-Cagnazzo (editor) 182 LACNIC 183 Montevideo 184 Uruguay 186 Email: carlos@lacnic.net 187 Daniel Shaw 188 AFRINIC 189 Cybercity Ebene 190 Republic of Mauritius 192 Email: daniel@afrinic.net 194 Tim Bruijnzeels 195 RIPE NCC 196 Amsterdam 197 Netherlands 199 Email: tim@ripe.net 201 Byron Ellacott 202 APNIC 203 Brisbane 204 Australia 206 Email: bje@apnic.net