idnits 2.17.1 draft-ymbk-lta-use-cases-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 (September 24, 2013) is 3868 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4271' is defined on line 196, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). 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 September 24, 2013 5 Expires: March 28, 2014 7 RPKI Local Trust Anchor Use Cases 8 draft-ymbk-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 the Global RPKI. This 14 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 March 28, 2014. 33 Copyright Notice 35 Copyright (c) 2013 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 This document may not be modified, and derivative works of it may not 49 be created, and it may not be published except as an Internet-Draft. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 2 55 3. What is 'Local' . . . . . . . . . . . . . . . . . . . . . . . 2 56 4. Example Uses . . . . . . . . . . . . . . . . . . . . . . . . 3 57 5. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 59 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 60 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 9.1. Normative References . . . . . . . . . . . . . . . . . . 4 63 9.2. Informative References . . . . . . . . . . . . . . . . . 4 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 66 1. Introduction 68 Today RPKI-based Origin Validation, [RFC6811], relies on widespread 69 deployment of the Global Resource Public Key Infrastructure (RPKI), 70 [RFC6480]. In the future, RPKI-based Path Validation, 71 [I-D.lepinski-bgpsec-overview], will be even more reliant on the 72 Global RPKI. 74 But there are critical circumstances in which a local, well-scoped, 75 administrative and/or routing domain will need to augment and/or 76 modify their internal view of the Global RPKI. 78 This document attempts to lay out a few of those use cases. It is 79 not intended to be autoritative, complete, or to become a standard. 80 It merely tries to lay out a few critical examples to help scope the 81 issues. 83 2. Suggested Reading 85 It is assumed that the reader understands the RPKI, see [RFC6480], 86 the RPKI Repository Structure, see [RFC6481], Route Origin 87 Authorizations (ROAs), see [RFC6482], and Ghostbusters Records, see 88 [RFC6493]. 90 3. What is 'Local' 92 The RPKI is a distributed database containing certificates, CRLs, 93 manifests, ROAs, and Ghostbusters Records as described in [RFC6481]. 94 Policies and considerations for RPKI object generation and 95 maintenance are discussed elsewhere. 97 Like the DNS, the Global RPKI presents a single global view, although 98 only a loosely consistent view, depending on timing, updating, 99 fetching, etc. There is no 'fix' for this, it is not broken, it is 100 the nature of distributed data with distributed caches. 102 There are critical uses of the RPKI where a local administrative and/ 103 or routing domain, e.g. an end-user site, a particular ISP or content 104 provider, a geo-political region, ... may wish to have a special view 105 of the RPKI. 107 For the purposes of this exploration, we refer to this localized view 108 as a 'Local Trust Anchor', mostly for historical reasons, but also 109 because implementation would likely be the local distribution of one 110 or more specialized trust andchors, [RFC6481]. 112 4. Example Uses 114 Carol, a RIPE member, is a victim of the "Dutch Court Attack" 115 (someone convinces a Dutch court to force the RIPE/NCC to remove or 116 modify records) and we all want to save the ability to route to 117 Carol's network(s). There is need for some channel through which we 118 can exchange some local trust command and data gorp necessary to 119 create patches local to all our caches. 121 Bob has a multi-AS network under his administration and some of those 122 ASs use private ([RFC1918]) or 'borrowed' US military space, and he 123 wishes to certify them for use in his internal routing. 125 Alice runs the root trust for a large organization where upper 126 management has the router geeks pointing their competitors' prefixes 127 to pictures of kittens and unicorns, and Alice is responsible for 128 making the CA hierarchy have validated certificates for those 129 redirected resources and the rest of the internet. 131 5. Notes 133 In these examples, it is ultimately the ROAs, not the certificates, 134 which one wants to modify. But one can't just hack new ROAs as one 135 does not have the private keys needed to sign them. Hence one has to 136 first hack the 3779 certificates. 138 But we should not lose sight of the goal that it is the ROAs and 139 Ghostbuster Records which need re-issuing under the new 3779 140 certificates. 142 Further, since we're not the NSA, GCHQ, ..., we can not assume that 143 we can reissue down from the root trust anchor at the IANA or from 144 the RIRs' certificates. So we have to create a new trust anchor 145 which, for ease of use, will contain the new/hacked certificates and 146 ROAs as well as the unmodified remainder of the Global RPKI. 148 And, because Alice, Bob, and Carol want to be able to archive, 149 reproduce, and send to friends the data necessary to recreate their 150 hacks, there will need to be a formally defind set of data which is 151 input to a well-defind process to take an existing Global RPKI tree 152 and produce the desired modified re-anchored tree. 154 6. Security Considerations 156 These use cases are all about violating global security, albeit 157 within a constrained local context. 159 7. IANA Considerations 161 This document has no IANA Considerations. 163 8. Acknowledgments 165 The author wishes to thank Rob Austein. 167 9. References 169 9.1. Normative References 171 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 172 Resource Certificate Repository Structure", RFC 6481, 173 February 2012. 175 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 176 Origin Authorizations (ROAs)", RFC 6482, February 2012. 178 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 179 Ghostbusters Record", RFC 6493, February 2012. 181 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 182 Austein, "BGP Prefix Origin Validation", RFC 6811, January 183 2013. 185 9.2. Informative References 187 [I-D.lepinski-bgpsec-overview] 188 Lepinski, M. and S. Turner, "An Overview of BGPSEC", 189 draft-lepinski-bgpsec-overview-00 (work in progress), 190 March 2011. 192 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 193 and E. Lear, "Address Allocation for Private Internets", 194 BCP 5, RFC 1918, February 1996. 196 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 197 Protocol 4 (BGP-4)", RFC 4271, January 2006. 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