draft-ietf-sidrops-lta-use-cases-05.txt   draft-ietf-sidrops-lta-use-cases-06.txt 
Network Working Group R. Bush Network Working Group R. Bush
Internet-Draft Internet Initiative Japan Internet-Draft Internet Initiative Japan
Intended status: Informational March 10, 2019 Intended status: Informational April 30, 2019
Expires: September 11, 2019 Expires: November 1, 2019
Use Cases for Localized Versions of the RPKI Use Cases for Localized Versions of the RPKI
draft-ietf-sidrops-lta-use-cases-05 draft-ietf-sidrops-lta-use-cases-06
Abstract Abstract
There are a number of critical circumstances where a localized There are a number of critical circumstances where a localized
routing domain needs to augment or modify its view of the Global routing domain needs to augment or modify its view of the Global
RPKI. This document attempts to outline a few of them. RPKI. This document attempts to outline a few of them.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 32 skipping to change at page 1, line 32
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 11, 2019. This Internet-Draft will expire on November 1, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 13 skipping to change at page 2, line 13
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 2 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 2
3. What is 'Local' . . . . . . . . . . . . . . . . . . . . . . . 2 3. What is 'Local' . . . . . . . . . . . . . . . . . . . . . . . 2
4. Example Uses . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Example Uses . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Some Approaches . . . . . . . . . . . . . . . . . . . . . . . 3 5. Some Approaches . . . . . . . . . . . . . . . . . . . . . . . 3
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
9.1. Normative References . . . . . . . . . . . . . . . . . . 5 9.1. Normative References . . . . . . . . . . . . . . . . . . 5
9.2. Informative References . . . . . . . . . . . . . . . . . 5 9.2. Informative References . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
Today RPKI-based Origin Validation, [RFC6811], relies on widespread Today RPKI-based Origin Validation, [RFC6811], relies on widespread
deployment of the Global Resource Public Key Infrastructure (RPKI), deployment of the Global Resource Public Key Infrastructure (RPKI),
[RFC6480]. In the future, RPKI-based Path Validation, [RFC6480]. In the future, RPKI-based Path Validation, [RFC8205],
[I-D.ietf-sidr-bgpsec-overview], will be even more reliant on the will be even more reliant on the Global RPKI.
Global RPKI.
But there are critical circumstances in which a local, clearly- But there are critical circumstances in which a local, clearly-
scoped, administrative and/or routing domain will want to augment scoped, administrative and/or routing domain will want to augment
and/or modify their internal view of the Global RPKI. and/or modify their internal view of the Global RPKI.
This document attempts to lay out a few of those use cases. It is 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. not intended to be authoritative, complete, or to become a standard.
It is informative laying out a few critical examples to help frame It is informative laying out a few critical examples to help frame
the issues. the issues.
skipping to change at page 3, line 21 skipping to change at page 3, line 21
For the purposes of this exploration, we refer to this localized view For the purposes of this exploration, we refer to this localized view
as a 'Local Trust Anchor', mostly for historical reasons, but also as a 'Local Trust Anchor', mostly for historical reasons, but also
because implementation would likely require the local distribution of because implementation would likely require the local distribution of
one or more specialized trust anchors, [RFC6481]. one or more specialized trust anchors, [RFC6481].
4. Example Uses 4. Example Uses
We explore this space using three examples. We explore this space using three examples.
Carol, a resource holder (LIR, PI holder, ...), operates outside of Carol, a resource holder (Local Internet Registry (LIR), Provider
the country in which her RIR is based. Someone convinces the RIR's Independent address space (PI) holder, ...), operates outside of the
local court to force the RIR to remove or modify some or all of country in which her Regional Internet Registry (RIR) is based.
Carol's certificates, ROAs, etc. or the resources they represent, and Someone convinces the RIR's local court to force the RIR to remove or
the operational community wants to retain the ability to route to modify some or all of Carol's certificates, ROAs, etc. or the
Carol's network(s). There is need for some channel through which resources they represent, and the operational community wants to
operators can permit Carol to be believed and exchange local trust, retain the ability to route to Carol's network(s). There is need for
command, and data collections necessary to propagate patches local to some channel through which operators can permit Carol to be believed
all their RPKI views. 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 Bob has a multi-AS network under his administration and some of those
ASs use private ([RFC1918]) or 'borrowed' address space which is not ASs use private ([RFC1918]) or 'borrowed' address space which is not
announced on the global Internet (not to condone borrowing), and he announced on the global Internet (not to condone borrowing), and he
wishes to certify them for use in his internal routing. wishes to certify them for use in his internal routing.
Alice is responsible for the trusted routing for a large Alice is responsible for the trusted routing for a large
organization, commercial or geo-political, in which management organization, commercial or geo-political, in which management
requests routing engineering to redirect their competitors' prefixes requests routing engineering to redirect their competitors' prefixes
to socially acceptable data. Alice is responsible for making the CA to socially acceptable data. Alice is responsible for making the
hierarchy have validated certificates for those redirected resources Certificate Authority (CA) hierarchy have validated certificates for
as well as the rest of the Internet. those redirected resources as well as the rest of the Internet.
5. Some Approaches 5. Some Approaches
In these examples, it is ultimately the ROAs, not the certificates, In these examples, it is ultimately the ROAs, not the certificates,
which one wants to modify or replace. But one probably can not which one wants to modify or replace. But one probably can not
simply create new ROAs as one does not have the private keys needed simply create new ROAs as one does not have the private keys needed
to sign them. Hence it is likely that one has to also do something to sign them. Hence it is likely that one has to also do something
about the [RFC6480] certificates. about the [RFC6480] certificates.
The goal is to modify, create, and/or replace ROAs and GhostBuster The goal is to modify, create, and/or replace ROAs and GhostBuster
skipping to change at page 4, line 38 skipping to change at page 4, line 38
to merge modification 'recipes'. to merge modification 'recipes'.
Simplified Local Internet Number Resource Management with the RPKI Simplified Local Internet Number Resource Management with the RPKI
(SLURM), [RFC8416], addresses many, but not all, of these issues and (SLURM), [RFC8416], addresses many, but not all, of these issues and
approaches. This document was originally a gating requirements approaches. This document was originally a gating requirements
document for SLURM and other approaches. document for SLURM and other approaches.
6. Security Considerations 6. Security Considerations
Though the above use cases are all constrained to local contexts, Though the above use cases are all constrained to local contexts,
they violate the model of a single global PKI, albeit to meet real they violate the model of a single Global RPKI, albeit to meet real
operational needs. Hence they MUST be implemented to assure the operational needs. Hence the result must be able to be validated as
local constraint. if the changed data were part of the validatable Global RPKI while
including the local context, perhaps with the addition of trust
anchors or authenticatable patching of trust.
Authentication of modification 'recipes' will be needed. Modification 'recipes' may lack authentication. E.g., if
modifications to the tree are passed around a la SLURM files, see
[RFC8416], what was object security becomes, at best, transport
security, or authentication by other trust domains such as PGP.
7. IANA Considerations 7. IANA Considerations
This document has no IANA Considerations. This document has no IANA Considerations.
8. Acknowledgments 8. Acknowledgments
The author thanks Chris Morrow, Karen Seo, Rob Austein, and Steve The author thanks Chris Morrow, Karen Seo, Rob Austein, and Steve
Kent for comments and suggestions. Kent for comments and suggestions.
skipping to change at page 5, line 39 skipping to change at page 5, line 48
DOI 10.17487/RFC6811, January 2013, DOI 10.17487/RFC6811, January 2013,
<http://www.rfc-editor.org/info/rfc6811>. <http://www.rfc-editor.org/info/rfc6811>.
[RFC8416] Ma, D., Mandelberg, D., and T. Bruijnzeels, "Simplified [RFC8416] Ma, D., Mandelberg, D., and T. Bruijnzeels, "Simplified
Local Internet Number Resource Management with the RPKI Local Internet Number Resource Management with the RPKI
(SLURM)", RFC 8416, DOI 10.17487/RFC8416, August 2018, (SLURM)", RFC 8416, DOI 10.17487/RFC8416, August 2018,
<https://www.rfc-editor.org/info/rfc8416>. <https://www.rfc-editor.org/info/rfc8416>.
9.2. Informative References 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., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<http://www.rfc-editor.org/info/rfc1918>. <http://www.rfc-editor.org/info/rfc1918>.
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
Specification", RFC 8205, DOI 10.17487/RFC8205, September
2017, <https://www.rfc-editor.org/info/rfc8205>.
Author's Address Author's Address
Randy Bush Randy Bush
Internet Initiative Japan Internet Initiative Japan
5147 Crystal Springs 5147 Crystal Springs
Bainbridge Island, Washington 98110 Bainbridge Island, Washington 98110
US US
Email: randy@psg.com Email: randy@psg.com
 End of changes. 11 change blocks. 
30 lines changed or deleted 34 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/