idnits 2.17.1 draft-ietf-sidrops-lta-use-cases-06.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 30, 2019) is 1822 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Bush 3 Internet-Draft Internet Initiative Japan 4 Intended status: Informational April 30, 2019 5 Expires: November 1, 2019 7 Use Cases for Localized Versions of the RPKI 8 draft-ietf-sidrops-lta-use-cases-06 10 Abstract 12 There are a number of critical circumstances where a localized 13 routing domain needs to augment or modify its view of the Global 14 RPKI. This document attempts to outline a few of them. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on November 1, 2019. 33 Copyright Notice 35 Copyright (c) 2019 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 2 52 3. What is 'Local' . . . . . . . . . . . . . . . . . . . . . . . 2 53 4. Example Uses . . . . . . . . . . . . . . . . . . . . . . . . 3 54 5. Some Approaches . . . . . . . . . . . . . . . . . . . . . . . 3 55 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 56 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 57 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 58 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 60 9.2. Informative References . . . . . . . . . . . . . . . . . 5 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 63 1. Introduction 65 Today RPKI-based Origin Validation, [RFC6811], relies on widespread 66 deployment of the Global Resource Public Key Infrastructure (RPKI), 67 [RFC6480]. In the future, RPKI-based Path Validation, [RFC8205], 68 will be even more reliant on the Global RPKI. 70 But there are critical circumstances in which a local, clearly- 71 scoped, administrative and/or routing domain will want to augment 72 and/or modify their internal view of the Global RPKI. 74 This document attempts to lay out a few of those use cases. It is 75 not intended to be authoritative, complete, or to become a standard. 76 It is informative laying out a few critical examples to help frame 77 the issues. 79 2. Suggested Reading 81 It is assumed that the reader understands the RPKI, see [RFC6480], 82 the RPKI Repository Structure, see [RFC6481], Route Origin 83 Authorizations (ROAs), see [RFC6482], and GhostBusters Records, see 84 [RFC6493]. 86 3. What is 'Local' 88 The RPKI is a distributed database containing certificates, CRLs, 89 manifests, ROAs, and GhostBusters Records as described in [RFC6481]. 90 Policies and considerations for RPKI object generation and 91 maintenance are discussed elsewhere. 93 Like the DNS, the Global RPKI tries to present a single global view, 94 although only a loosely consistent view, depending on timing, 95 updating, fetching, etc. There is no 'fix' for this, it is not 96 broken, it is the nature of distributed data with distributed caches. 98 There are critical uses of the RPKI where a local administrative and/ 99 or routing domain, e.g. an end-user site, a particular ISP or content 100 provider, an organization, a geo-political region, ... may wish to 101 have a specialized view of the RPKI. 103 For the purposes of this exploration, we refer to this localized view 104 as a 'Local Trust Anchor', mostly for historical reasons, but also 105 because implementation would likely require the local distribution of 106 one or more specialized trust anchors, [RFC6481]. 108 4. Example Uses 110 We explore this space using three examples. 112 Carol, a resource holder (Local Internet Registry (LIR), Provider 113 Independent address space (PI) holder, ...), operates outside of the 114 country in which her Regional Internet Registry (RIR) is based. 115 Someone convinces the RIR's local court to force the RIR to remove or 116 modify some or all of Carol's certificates, ROAs, etc. or the 117 resources they represent, and the operational community wants to 118 retain the ability to route to Carol's network(s). There is need for 119 some channel through which operators can permit Carol to be believed 120 and exchange local trust, command, and data collections necessary to 121 propagate patches local to all their RPKI views. 123 Bob has a multi-AS network under his administration and some of those 124 ASs use private ([RFC1918]) or 'borrowed' address space which is not 125 announced on the global Internet (not to condone borrowing), and he 126 wishes to certify them for use in his internal routing. 128 Alice is responsible for the trusted routing for a large 129 organization, commercial or geo-political, in which management 130 requests routing engineering to redirect their competitors' prefixes 131 to socially acceptable data. Alice is responsible for making the 132 Certificate Authority (CA) hierarchy have validated certificates for 133 those redirected resources as well as the rest of the Internet. 135 5. Some Approaches 137 In these examples, it is ultimately the ROAs, not the certificates, 138 which one wants to modify or replace. But one probably can not 139 simply create new ROAs as one does not have the private keys needed 140 to sign them. Hence it is likely that one has to also do something 141 about the [RFC6480] certificates. 143 The goal is to modify, create, and/or replace ROAs and GhostBuster 144 Records which are needed to present the localized view of the RPKI 145 data. 147 One wants to reproduce only as much of the Global RPKI as needed. 148 Replicating more than is needed would amplify tracking and 149 maintenance. 151 One can not reissue down from the root trust anchor at the IANA or 152 from the RIRs' certificates because one does not have the private 153 keys required. So one has to create a new trust anchor which, for 154 ease of use, will contain the new/modified certificates and ROAs as 155 well as the unmodified remainder of the Global RPKI. 157 Because Alice, Bob, and Carol want to be able to archive, reproduce, 158 and send to other operators the data necessary to reproduce their 159 modified view of the global RPKI, there will need to be a formally 160 defined set of data which is input to a well-defined process to take 161 an existing Global RPKI tree and produce the desired modified re- 162 anchored tree. 164 It is possible that an operator may need to accept and process 165 modification data from more than one source. Hence there is a need 166 to merge modification 'recipes'. 168 Simplified Local Internet Number Resource Management with the RPKI 169 (SLURM), [RFC8416], addresses many, but not all, of these issues and 170 approaches. This document was originally a gating requirements 171 document for SLURM and other approaches. 173 6. Security Considerations 175 Though the above use cases are all constrained to local contexts, 176 they violate the model of a single Global RPKI, albeit to meet real 177 operational needs. Hence the result must be able to be validated as 178 if the changed data were part of the validatable Global RPKI while 179 including the local context, perhaps with the addition of trust 180 anchors or authenticatable patching of trust. 182 Modification 'recipes' may lack authentication. E.g., if 183 modifications to the tree are passed around a la SLURM files, see 184 [RFC8416], what was object security becomes, at best, transport 185 security, or authentication by other trust domains such as PGP. 187 7. IANA Considerations 189 This document has no IANA Considerations. 191 8. Acknowledgments 193 The author thanks Chris Morrow, Karen Seo, Rob Austein, and Steve 194 Kent for comments and suggestions. 196 9. References 198 9.1. Normative References 200 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 201 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 202 February 2012, . 204 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 205 Resource Certificate Repository Structure", RFC 6481, 206 DOI 10.17487/RFC6481, February 2012, 207 . 209 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 210 Origin Authorizations (ROAs)", RFC 6482, 211 DOI 10.17487/RFC6482, February 2012, 212 . 214 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 215 Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, 216 February 2012, . 218 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 219 Austein, "BGP Prefix Origin Validation", RFC 6811, 220 DOI 10.17487/RFC6811, January 2013, 221 . 223 [RFC8416] Ma, D., Mandelberg, D., and T. Bruijnzeels, "Simplified 224 Local Internet Number Resource Management with the RPKI 225 (SLURM)", RFC 8416, DOI 10.17487/RFC8416, August 2018, 226 . 228 9.2. Informative References 230 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 231 and E. Lear, "Address Allocation for Private Internets", 232 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 233 . 235 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 236 Specification", RFC 8205, DOI 10.17487/RFC8205, September 237 2017, . 239 Author's Address 241 Randy Bush 242 Internet Initiative Japan 243 5147 Crystal Springs 244 Bainbridge Island, Washington 98110 245 US 247 Email: randy@psg.com