--- 1/draft-ietf-sidrops-lta-use-cases-04.txt 2019-03-10 15:13:18.295632658 -0700 +++ 2/draft-ietf-sidrops-lta-use-cases-05.txt 2019-03-10 15:13:18.319633248 -0700 @@ -1,18 +1,18 @@ Network Working Group R. Bush Internet-Draft Internet Initiative Japan -Intended status: Informational October 1, 2018 -Expires: April 4, 2019 +Intended status: Informational March 10, 2019 +Expires: September 11, 2019 Use Cases for Localized Versions of the RPKI - draft-ietf-sidrops-lta-use-cases-04 + draft-ietf-sidrops-lta-use-cases-05 Abstract There are a number of critical circumstances where a localized routing domain needs to augment or modify its view of the Global RPKI. This document attempts to outline a few of them. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -21,25 +21,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 4, 2019. + This Internet-Draft will expire on September 11, 2019. Copyright Notice - Copyright (c) 2018 IETF Trust and the persons identified as the + Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -48,41 +48,41 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 2 3. What is 'Local' . . . . . . . . . . . . . . . . . . . . . . . 2 4. Example Uses . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Some Approaches . . . . . . . . . . . . . . . . . . . . . . . 3 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 9.2. Informative References . . . . . . . . . . . . . . . . . 5 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction Today RPKI-based Origin Validation, [RFC6811], relies on widespread deployment of the Global Resource Public Key Infrastructure (RPKI), [RFC6480]. In the future, RPKI-based Path Validation, [I-D.ietf-sidr-bgpsec-overview], will be even more reliant on the Global RPKI. But there are critical circumstances in which a local, clearly- scoped, administrative and/or routing domain will want to augment and/or modify their internal view of the Global RPKI. This document attempts to lay out a few of those use cases. It is not intended to be authoritative, complete, or to become a standard. - It merely tries to lay out a few critical examples to help frame the - issues. + It is informative laying out a few critical examples to help frame + the issues. 2. Suggested Reading It is assumed that the reader understands the RPKI, see [RFC6480], the RPKI Repository Structure, see [RFC6481], Route Origin Authorizations (ROAs), see [RFC6482], and GhostBusters Records, see [RFC6493]. 3. What is 'Local' @@ -109,22 +109,23 @@ 4. Example Uses We explore this space using three examples. Carol, a resource holder (LIR, PI holder, ...), operates outside of the country in which her RIR is based. Someone convinces the RIR's local court to force the RIR to remove or modify some or all of Carol's certificates, ROAs, etc. or the resources they represent, and the operational community wants to retain the ability to route to Carol's network(s). There is need for some channel through which - operators can exchange local trust, command, and data collections - necessary to propagate patches local to all their RPKI views. + operators can permit Carol to be believed and exchange local trust, + command, and data collections necessary to propagate patches local to + all their RPKI views. Bob has a multi-AS network under his administration and some of those ASs use private ([RFC1918]) or 'borrowed' address space which is not announced on the global Internet (not to condone borrowing), and he wishes to certify them for use in his internal routing. Alice is responsible for the trusted routing for a large organization, commercial or geo-political, in which management requests routing engineering to redirect their competitors' prefixes to socially acceptable data. Alice is responsible for making the CA @@ -157,20 +158,25 @@ and send to other operators the data necessary to reproduce their modified view of the global RPKI, there will need to be a formally defined set of data which is input to a well-defined process to take an existing Global RPKI tree and produce the desired modified re- anchored tree. It is possible that an operator may need to accept and process modification data from more than one source. Hence there is a need to merge modification 'recipes'. + Simplified Local Internet Number Resource Management with the RPKI + (SLURM), [RFC8416], addresses many, but not all, of these issues and + approaches. This document was originally a gating requirements + document for SLURM and other approaches. + 6. Security Considerations Though the above use cases are all constrained to local contexts, they violate the model of a single global PKI, albeit to meet real operational needs. Hence they MUST be implemented to assure the local constraint. Authentication of modification 'recipes' will be needed. 7. IANA Considerations @@ -201,20 +208,25 @@ [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, February 2012, . [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, . + [RFC8416] Ma, D., Mandelberg, D., and T. Bruijnzeels, "Simplified + Local Internet Number Resource Management with the RPKI + (SLURM)", RFC 8416, DOI 10.17487/RFC8416, August 2018, + . + 9.2. Informative References [I-D.ietf-sidr-bgpsec-overview] Lepinski, M. and S. Turner, "An Overview of BGPSEC", draft-ietf-sidr-bgpsec-overview-02 (work in progress), May 2012. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,