idnits 2.17.1 draft-ietf-sidr-lta-use-cases-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 : ---------------------------------------------------------------------------- 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 (December 30, 2014) is 3377 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 December 30, 2014 5 Expires: July 3, 2015 7 RPKI Local Trust Anchor Use Cases 8 draft-ietf-sidr-lta-use-cases-02 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 July 3, 2015. 33 Copyright Notice 35 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . 4 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, well-scoped, 72 administrative and/or routing domain will need to augment and/or 73 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 scope 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 presents a single global view, although 95 only a loosely consistent view, depending on timing, updating, 96 fetching, etc. There is no 'fix' for this, it is not broken, it is 97 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 be the local distribution of one 107 or more specialized trust anchors, [RFC6481]. 109 4. Example Uses 111 Carol, a RIPE resource holder (LIR, PI holder, ...), statistically 112 likely not to actually be in the Netherlands, is a victim of the 113 "Dutch Court Attack," i.e. someone convinces a Dutch court to force 114 the RIPE/NCC to remove or modify some or all of Carol's certificates, 115 ROAs, etc. or the resources they represent, and the operational 116 community wants to retain the ability to route to Carol's network(s). 117 There is need for some channel through which operators can exchange 118 local trust, command, and data collections necessary to propagate 119 patches local to all their caches. 121 Bob has a multi-AS network under his administration and some of those 122 ASs use private ([RFC1918]) or 'borrowed' address space which is 123 otherwise unrouted in the global Internet (US military space is 124 popular), and he wishes to certify them for use in his internal 125 routing. 127 Alice runs the root trust for a large organization, commercial or 128 geo-political, where upper management requests routing engineering to 129 redirect their competitors' prefixes to socially acceptable data, and 130 Alice is responsible for making the CA hierarchy have validated 131 certificates for those redirected resources as well as the rest of 132 the Internet. 134 5. Notes 136 In these examples, it is ultimately the ROAs, not the certificates, 137 which one wants to modify. But one can't just hack new ROAs as one 138 does not have the private keys needed to sign them. Hence one has to 139 first hack the 3779 certificates. 141 But we should not lose sight of the goal that it is the ROAs and 142 GhostBuster Records which need re-issuing under the new 3779 143 certificates. 145 Further, since we're not the NSA, GCHQ, ..., we can not assume that 146 we can reissue down from the root trust anchor at the IANA or from 147 the RIRs' certificates. So we have to create a new trust anchor 148 which, for ease of use, will contain the new/hacked certificates and 149 ROAs as well as the unmodified remainder of the Global RPKI. 151 And, because Alice, Bob, and Carol want to be able to archive, 152 reproduce, and send to friends the data necessary to recreate their 153 hacks, there will need to be a formally defined set of data which is 154 input to a well-defind process to take an existing Global RPKI tree 155 and produce the desired modified re-anchored tree. 157 6. Security Considerations 159 These use cases are all about violating global security, albeit 160 within a constrained local context. 162 7. IANA Considerations 164 This document has no IANA Considerations. 166 8. Acknowledgments 168 The author wishes to thank Rob Austein, Steve Kent, and Karen Seo. 170 9. References 172 9.1. Normative References 174 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 175 Resource Certificate Repository Structure", RFC 6481, 176 February 2012. 178 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 179 Origin Authorizations (ROAs)", RFC 6482, February 2012. 181 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 182 Ghostbusters Record", RFC 6493, February 2012. 184 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 185 Austein, "BGP Prefix Origin Validation", RFC 6811, January 186 2013. 188 9.2. Informative References 190 [I-D.lepinski-bgpsec-overview] 191 Lepinski, M. and S. Turner, "An Overview of BGPSEC", 192 draft-lepinski-bgpsec-overview-00 (work in progress), 193 March 2011. 195 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 196 and E. Lear, "Address Allocation for Private Internets", 197 BCP 5, RFC 1918, February 1996. 199 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 200 Secure Internet Routing", RFC 6480, February 2012. 202 Author's Address 204 Randy Bush 205 Internet Initiative Japan 206 5147 Crystal Springs 207 Bainbridge Island, Washington 98110 208 US 210 Email: randy@psg.com