idnits 2.17.1 draft-ietf-sidr-lta-use-cases-03.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 (June 24, 2015) is 3222 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 June 24, 2015 5 Expires: December 26, 2015 7 RPKI Local Trust Anchor Use Cases 8 draft-ietf-sidr-lta-use-cases-03 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 http://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 December 26, 2015. 33 Copyright Notice 35 Copyright (c) 2015 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 (http://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. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 56 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 57 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 58 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 9.1. Normative References . . . . . . . . . . . . . . . . . . 4 60 9.2. Informative References . . . . . . . . . . . . . . . . . 5 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 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, 68 [I-D.lepinski-bgpsec-overview], will be even more reliant on the 69 Global RPKI. 71 But there are critical circumstances in which a local, clearly- 72 scoped, administrative and/or routing domain will want to augment 73 and/or modify their internal view of the Global RPKI. 75 This document attempts to lay out a few of those use cases. It is 76 not intended to be authoritative, complete, or to become a standard. 77 It merely tries to lay out a few critical examples to help frame the 78 issues. 80 2. Suggested Reading 82 It is assumed that the reader understands the RPKI, see [RFC6480], 83 the RPKI Repository Structure, see [RFC6481], Route Origin 84 Authorizations (ROAs), see [RFC6482], and GhostBusters Records, see 85 [RFC6493]. 87 3. What is 'Local' 89 The RPKI is a distributed database containing certificates, CRLs, 90 manifests, ROAs, and GhostBusters Records as described in [RFC6481]. 91 Policies and considerations for RPKI object generation and 92 maintenance are discussed elsewhere. 94 Like the DNS, the Global RPKI tries to present a single global view, 95 although only a loosely consistent view, depending on timing, 96 updating, fetching, etc. There is no 'fix' for this, it is not 97 broken, it is the nature of distributed data with distributed caches. 99 There are critical uses of the RPKI where a local administrative and/ 100 or routing domain, e.g. an end-user site, a particular ISP or content 101 provider, an organization, a geo-political region, ... may wish to 102 have a specialized view of the RPKI. 104 For the purposes of this exploration, we refer to this localized view 105 as a 'Local Trust Anchor', mostly for historical reasons, but also 106 because implementation would likely require the local distribution of 107 one or more specialized trust anchors, [RFC6481]. 109 4. Example Uses 111 We explore this space using three examples. 113 Carol, a RIPE resource holder (LIR, PI holder, ...), operates outside 114 of the Netherlands. Someone convinces a Dutch court to force the 115 RIPE/NCC to remove or modify some or all of Carol's certificates, 116 ROAs, etc. or the resources they represent, and the operational 117 community wants to retain the ability to route to Carol's network(s). 118 There is need for some channel through which operators can exchange 119 local trust, command, and data collections necessary to propagate 120 patches local to all their RPKI views. 122 Bob has a multi-AS network under his administration and some of those 123 ASs use private ([RFC1918]) or 'borrowed' address space which is not 124 announced on the global Internet, and he wishes to certify them for 125 use in his internal routing. 127 Alice is responsible for the trusted routing for a large 128 organization, commercial or geo-political, in which management 129 requests routing engineering to redirect their competitors' prefixes 130 to socially acceptable data, and Alice is responsible for making the 131 CA hierarchy have validated certificates for those redirected 132 resources as well as the rest of the Internet. 134 5. Notes 136 In these examples, it is ultimately the ROAs, not the certificates, 137 which one wants to modify or replace. But one probably can not 138 simply create new ROAs as one does not have the private keys needed 139 to sign them. Hence it is likely that one has to also do something 140 about the [RFC6480] certificates. 142 The goal is to modify, create, and/or replace ROAs and GhostBuster 143 Records which are needed to present the localized view of the RPKI 144 data. 146 One wants to reproduce only as much of the Global RPKI as needed. 147 Replicating more than is needed would amplify tracking and 148 maintenance. 150 One can not reissue down from the root trust anchor at the IANA or 151 from the RIRs' certificates because one do not have the private keys 152 required. So one has to create a new trust anchor which, for ease of 153 use, will contain the new/modified certificates and ROAs as well as 154 the unmodified remainder of the Global RPKI. 156 Because Alice, Bob, and Carol want to be able to archive, reproduce, 157 and send to other operators the data necessary to reproduce their 158 modified view of the global RPKI, there will need to be a formally 159 formally defined set of data which is input to a well-defined process 160 to take an existing Global RPKI tree and produce the desired modified 161 re-anchored tree. 163 It is possible that an operator may need to accept and process 164 modification data from more than one source. Hence modification 165 'recipes' should be mergable. 167 6. Security Considerations 169 These use cases are all about violating global security, albeit 170 within a constrained local context. 172 Authentication of modification 'recipes' will be needed. 174 7. IANA Considerations 176 This document has no IANA Considerations. 178 8. Acknowledgments 180 The author wishes to thank Rob Austein, Steve Kent, and Karen Seo. 182 9. References 184 9.1. Normative References 186 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 187 Secure Internet Routing", RFC 6480, February 2012. 189 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 190 Resource Certificate Repository Structure", RFC 6481, 191 February 2012. 193 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 194 Origin Authorizations (ROAs)", RFC 6482, February 2012. 196 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 197 Ghostbusters Record", RFC 6493, February 2012. 199 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 200 Austein, "BGP Prefix Origin Validation", RFC 6811, January 201 2013. 203 9.2. Informative References 205 [I-D.lepinski-bgpsec-overview] 206 Lepinski, M. and S. Turner, "An Overview of BGPSEC", 207 draft-lepinski-bgpsec-overview-00 (work in progress), 208 March 2011. 210 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 211 and E. Lear, "Address Allocation for Private Internets", 212 BCP 5, RFC 1918, February 1996. 214 Author's Address 216 Randy Bush 217 Internet Initiative Japan 218 5147 Crystal Springs 219 Bainbridge Island, Washington 98110 220 US 222 Email: randy@psg.com