idnits 2.17.1 draft-ietf-sidr-lta-use-cases-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 : ---------------------------------------------------------------------------- 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 (February 6, 2014) is 3729 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 February 6, 2014 5 Expires: August 10, 2014 7 RPKI Local Trust Anchor Use Cases 8 draft-ietf-sidr-lta-use-cases-00 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 August 10, 2014. 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 autoritative, 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, a geo-political region, ... may wish to have a specialized 102 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 andchors, [RFC6481]. 109 4. Example Uses 111 Carol, a RIPE member, is a victim of the "Dutch Court Attack" 112 (someone convinces a Dutch court to force the RIPE/NCC to remove or 113 modify records) and we all want to save the ability to route to 114 Carol's network(s). There is need for some channel through which we 115 can exchange some local trust command and data gorp necessary to 116 propagate patches local to all our caches. 118 Bob has a multi-AS network under his administration and some of those 119 ASs use private ([RFC1918]) or 'borrowed' US military space, and he 120 wishes to certify them for use in his internal routing. 122 Alice runs the root trust for a large organization where upper 123 management has the router geeks pointing their competitors' prefixes 124 to pictures of kittens and unicorns, and Alice is responsible for 125 making the CA hierarchy have validated certificates for those 126 redirected resources as well as the rest of the internet. 128 5. Notes 130 In these examples, it is ultimately the ROAs, not the certificates, 131 which one wants to modify. But one can't just hack new ROAs as one 132 does not have the private keys needed to sign them. Hence one has to 133 first hack the 3779 certificates. 135 But we should not lose sight of the goal that it is the ROAs and 136 Ghostbuster Records which need re-issuing under the new 3779 137 certificates. 139 Further, since we're not the NSA, GCHQ, ..., we can not assume that 140 we can reissue down from the root trust anchor at the IANA or from 141 the RIRs' certificates. So we have to create a new trust anchor 142 which, for ease of use, will contain the new/hacked certificates and 143 ROAs as well as the unmodified remainder of the Global RPKI. 145 And, because Alice, Bob, and Carol want to be able to archive, 146 reproduce, and send to friends the data necessary to recreate their 147 hacks, there will need to be a formally defind set of data which is 148 input to a well-defind process to take an existing Global RPKI tree 149 and produce the desired modified re-anchored tree. 151 6. Security Considerations 153 These use cases are all about violating global security, albeit 154 within a constrained local context. 156 7. IANA Considerations 158 This document has no IANA Considerations. 160 8. Acknowledgments 162 The author wishes to thank Rob Austein. 164 9. References 166 9.1. Normative References 168 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 169 Resource Certificate Repository Structure", RFC 6481, 170 February 2012. 172 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 173 Origin Authorizations (ROAs)", RFC 6482, February 2012. 175 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 176 Ghostbusters Record", RFC 6493, February 2012. 178 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 179 Austein, "BGP Prefix Origin Validation", RFC 6811, January 180 2013. 182 9.2. Informative References 184 [I-D.lepinski-bgpsec-overview] 185 Lepinski, M. and S. Turner, "An Overview of BGPSEC", 186 draft-lepinski-bgpsec-overview-00 (work in progress), 187 March 2011. 189 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 190 and E. Lear, "Address Allocation for Private Internets", 191 BCP 5, RFC 1918, February 1996. 193 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 194 Secure Internet Routing", RFC 6480, February 2012. 196 Author's Address 198 Randy Bush 199 Internet Initiative Japan 200 5147 Crystal Springs 201 Bainbridge Island, Washington 98110 202 US 204 Email: randy@psg.com