idnits 2.17.1 draft-rir-rpki-allres-ta-app-statement-00.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 (March 21, 2016) is 2958 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 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: September 22, 2016 LACNIC 6 D. Shaw 7 AfriNIC 8 T. Bruijnzeels 9 RIPE NCC 10 B. Ellacott 11 APNIC 12 March 21, 2016 14 RPKI Multiple "All Resources" Trust Anchors Applicability Statement 15 draft-rir-rpki-allres-ta-app-statement-00 17 Abstract 19 This document provides an applicability statement for the use of 20 multiple, overclaiming 'all resources' (0/0) RPKI root certificates 21 operated by the Regional Internet Registry community to help mitigate 22 the risk of massive downstream invalidation in the case of transient 23 registry inconsistencies. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 22, 2016. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 3. Applicability to reduce overclaiming possibilities . . . . . 3 62 4. Normative References . . . . . . . . . . . . . . . . . . . . 4 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 65 1. Requirements Language 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in RFC 2119 [RFC2119]. 71 2. Introduction 73 RPKI is a hierarchical cryptologic system that uses certificates to 74 match and validate holdership of IP addresses as it moves down the 75 allocation change from IANA to a RIR to ISPs and ending up at end 76 users who uses the address block. Since these allocations can be 77 cryptographically validated, one could then tie assertions made by 78 the holder of that IP address space. As an improvement of this 79 system, RPKI was improved to add origin routing announcements via 80 ROAs to this system. These ROAs then can be independently validated 81 via cryptologic means by third parties to assure themselves that the 82 origin of the announcement can be checked via what is in the actual 83 routing system. 85 Since this system is envisioned to be used by ISPs to determine their 86 routing decisions, there is a goal to be 100% correct 100% of the 87 time. This goal could be achieved if it was to be contained in a 88 static environment where there is little to no movement of holdership 89 changes from one organization to another for IP addresses. 90 Unfortunately, this state can not be achieved as there is now 91 movement of IP addresses from organization to organization based on 92 IPv4 runout. 94 Unfortunately, this state is infeasible in a model where separate 95 entities are operating independently, yet rely critically on each 96 others' perfect synchronisation at all times. 98 Because the current validation mechanism is all-or-nothing, any 99 inconsistency at all at a high apex CA invalidates a large number of 100 additional INRs. The higher the apex, and the larger the total set 101 of INRs maintained by the CA, the greater the impact of even a small 102 inconsistency. 104 As resources change at high apex CAs for a variety of reasons, the 105 likelihood of a small inconsistency is non-zero, and the likelihood 106 of a transitional inconsistency is moderate. Due to the distributed 107 nature of the RPKI repository mechanism, even if all CAs were able to 108 operate in perfect synchronicity, there is a reasonable likelihood 109 that a given client may witness a temporarily inconsistent state of 110 the system as a whole. A risk of wide-spread invalidity therefore 111 exists as a very high impact and moderate likelihood event. 113 This brittleness in the RPKI validation rules has been identified and 114 presented by the current RPKI TA operators to the IETF. A solution 115 has also been proposed (insert ref to validation reconsidered), a 116 solution that would allow for accidental over-claiming only to 117 invalidate the resource that is incorrectly listed and allow the 118 remaining to continue to be valid. This draft has had little forward 119 progress in the IETF to date. 121 3. Applicability to reduce overclaiming possibilities 123 The consequences to a RIR over-claiming are grave given that every 124 ISP within their certificate would be invalidated. If routing was to 125 be reliant on RPKI at this point, all routes by those ISPs by the 126 affected RIR certificate would no longer work. 128 To mitigate risk and alleviate this threat, each RIR will move from a 129 Trust Anchor that reflects their current holdings to one that 130 reflects all holdings (e.g. 0/0) so that over-claiming can not occur 131 at a RIR level when dealing with transfers from one RIR to another. 132 RPKI validators will not see the five Trust anchors from the RIRs as 133 over-claiming and validation can proceed normally. 135 For those who want to audit the RIRs to ensure that RIRs are not 136 allocating the same IP addresses in separate regions, they can audit 137 the RIRs by matching the inventories of each RIR (**extended stats 138 reference here) that is provided on a daily basis to the certificates 139 issued by the RIRs within RPKI. Note that there will be a minor 140 change from time to time to account for movements from IP address 141 holdings that is in flight from one RIR to another. 143 4. Normative References 145 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 146 Requirement Levels", BCP 14, RFC 2119, 147 DOI 10.17487/RFC2119, March 1997, 148 . 150 Authors' Addresses 152 Andrew Newton (editor) 153 ARIN 154 Chantilly VA 155 United States 157 Email: andy@arin.net 159 Carlos Martinez-Cagnazzo (editor) 160 LACNIC 161 Montevideo 162 Uruguay 164 Email: carlos@lacnic.net 166 Daniel Shaw 167 AfriNIC 168 Cybercity Ebene 169 Republic of Mauritius 171 Email: daniel@afrinic.net 173 Tim Bruijnzeels 174 RIPE NCC 175 Amsterdam 176 Netherlands 178 Email: tim@ripe.net 180 Byron Ellacott 181 APNIC 182 Brisbane 183 Australia 185 Email: bje@apnic.net