draft-ietf-sidr-lta-use-cases-02.txt   draft-ietf-sidr-lta-use-cases-03.txt 
Network Working Group R. Bush Network Working Group R. Bush
Internet-Draft Internet Initiative Japan Internet-Draft Internet Initiative Japan
Intended status: Informational December 30, 2014 Intended status: Informational June 24, 2015
Expires: July 3, 2015 Expires: December 26, 2015
RPKI Local Trust Anchor Use Cases RPKI Local Trust Anchor Use Cases
draft-ietf-sidr-lta-use-cases-02 draft-ietf-sidr-lta-use-cases-03
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 July 3, 2015. This Internet-Draft will expire on December 26, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 17 skipping to change at page 2, line 17
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. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
9.1. Normative References . . . . . . . . . . . . . . . . . . 4 9.1. Normative References . . . . . . . . . . . . . . . . . . 4
9.2. Informative References . . . . . . . . . . . . . . . . . 4 9.2. Informative References . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
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,
[I-D.lepinski-bgpsec-overview], will be even more reliant on the [I-D.lepinski-bgpsec-overview], will be even more reliant on the
Global RPKI. Global RPKI.
But there are critical circumstances in which a local, well-scoped, But there are critical circumstances in which a local, clearly-
administrative and/or routing domain will need to augment and/or scoped, administrative and/or routing domain will want to augment
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 merely tries to lay out a few critical examples to help scope the It merely tries to lay out a few critical examples to help frame the
issues. issues.
2. Suggested Reading 2. Suggested Reading
It is assumed that the reader understands the RPKI, see [RFC6480], It is assumed that the reader understands the RPKI, see [RFC6480],
the RPKI Repository Structure, see [RFC6481], Route Origin the RPKI Repository Structure, see [RFC6481], Route Origin
Authorizations (ROAs), see [RFC6482], and GhostBusters Records, see Authorizations (ROAs), see [RFC6482], and GhostBusters Records, see
[RFC6493]. [RFC6493].
3. What is 'Local' 3. What is 'Local'
The RPKI is a distributed database containing certificates, CRLs, The RPKI is a distributed database containing certificates, CRLs,
manifests, ROAs, and GhostBusters Records as described in [RFC6481]. manifests, ROAs, and GhostBusters Records as described in [RFC6481].
Policies and considerations for RPKI object generation and Policies and considerations for RPKI object generation and
maintenance are discussed elsewhere. maintenance are discussed elsewhere.
Like the DNS, the Global RPKI presents a single global view, although Like the DNS, the Global RPKI tries to present a single global view,
only a loosely consistent view, depending on timing, updating, although only a loosely consistent view, depending on timing,
fetching, etc. There is no 'fix' for this, it is not broken, it is updating, fetching, etc. There is no 'fix' for this, it is not
the nature of distributed data with distributed caches. broken, it is the nature of distributed data with distributed caches.
There are critical uses of the RPKI where a local administrative and/ There are critical uses of the RPKI where a local administrative and/
or routing domain, e.g. an end-user site, a particular ISP or content or routing domain, e.g. an end-user site, a particular ISP or content
provider, an organization, a geo-political region, ... may wish to provider, an organization, a geo-political region, ... may wish to
have a specialized view of the RPKI. have a specialized view of the RPKI.
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 be the local distribution of one because implementation would likely require the local distribution of
or more specialized trust anchors, [RFC6481]. one or more specialized trust anchors, [RFC6481].
4. Example Uses 4. Example Uses
Carol, a RIPE resource holder (LIR, PI holder, ...), statistically We explore this space using three examples.
likely not to actually be in the Netherlands, is a victim of the
"Dutch Court Attack," i.e. someone convinces a Dutch court to force Carol, a RIPE resource holder (LIR, PI holder, ...), operates outside
the RIPE/NCC to remove or modify some or all of Carol's certificates, of the Netherlands. Someone convinces a Dutch court to force the
RIPE/NCC to remove or modify some or all of Carol's certificates,
ROAs, etc. or the resources they represent, and the operational ROAs, etc. or the resources they represent, and the operational
community wants to retain the ability to route to Carol's network(s). community wants to retain the ability to route to Carol's network(s).
There is need for some channel through which operators can exchange There is need for some channel through which operators can exchange
local trust, command, and data collections necessary to propagate local trust, command, and data collections necessary to propagate
patches local to all their caches. 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 ASs use private ([RFC1918]) or 'borrowed' address space which is not
otherwise unrouted in the global Internet (US military space is announced on the global Internet, and he wishes to certify them for
popular), and he wishes to certify them for use in his internal use in his internal routing.
routing.
Alice runs the root trust for a large organization, commercial or Alice is responsible for the trusted routing for a large
geo-political, where upper management requests routing engineering to organization, commercial or geo-political, in which management
redirect their competitors' prefixes to socially acceptable data, and requests routing engineering to redirect their competitors' prefixes
Alice is responsible for making the CA hierarchy have validated to socially acceptable data, and Alice is responsible for making the
certificates for those redirected resources as well as the rest of CA hierarchy have validated certificates for those redirected
the Internet. resources as well as the rest of the Internet.
5. Notes 5. Notes
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. But one can't just hack new ROAs as one which one wants to modify or replace. But one probably can not
does not have the private keys needed to sign them. Hence one has to simply create new ROAs as one does not have the private keys needed
first hack the 3779 certificates. to sign them. Hence it is likely that one has to also do something
about the [RFC6480] certificates.
But we should not lose sight of the goal that it is the ROAs and The goal is to modify, create, and/or replace ROAs and GhostBuster
GhostBuster Records which need re-issuing under the new 3779 Records which are needed to present the localized view of the RPKI
certificates. data.
Further, since we're not the NSA, GCHQ, ..., we can not assume that One wants to reproduce only as much of the Global RPKI as needed.
we can reissue down from the root trust anchor at the IANA or from Replicating more than is needed would amplify tracking and
the RIRs' certificates. So we have to create a new trust anchor maintenance.
which, for ease of use, will contain the new/hacked certificates and
ROAs as well as the unmodified remainder of the Global RPKI.
And, because Alice, Bob, and Carol want to be able to archive, One can not reissue down from the root trust anchor at the IANA or
reproduce, and send to friends the data necessary to recreate their from the RIRs' certificates because one do not have the private keys
hacks, there will need to be a formally defined set of data which is required. So one has to create a new trust anchor which, for ease of
input to a well-defind process to take an existing Global RPKI tree use, will contain the new/modified certificates and ROAs as well as
and produce the desired modified re-anchored tree. the unmodified remainder of the Global RPKI.
Because Alice, Bob, and Carol want to be able to archive, reproduce,
and send to other operators the data necessary to reproduce their
modified view of the global RPKI, there will need to be a formally
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 modification
'recipes' should be mergable.
6. Security Considerations 6. Security Considerations
These use cases are all about violating global security, albeit These use cases are all about violating global security, albeit
within a constrained local context. within a constrained local context.
Authentication of modification 'recipes' will be needed.
7. IANA Considerations 7. IANA Considerations
This document has no IANA Considerations. This document has no IANA Considerations.
8. Acknowledgments 8. Acknowledgments
The author wishes to thank Rob Austein, Steve Kent, and Karen Seo. The author wishes to thank Rob Austein, Steve Kent, and Karen Seo.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, February 2012.
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for
Resource Certificate Repository Structure", RFC 6481, Resource Certificate Repository Structure", RFC 6481,
February 2012. February 2012.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)", RFC 6482, February 2012. Origin Authorizations (ROAs)", RFC 6482, February 2012.
[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI)
Ghostbusters Record", RFC 6493, February 2012. Ghostbusters Record", RFC 6493, February 2012.
skipping to change at page 5, line 14 skipping to change at page 5, line 30
[I-D.lepinski-bgpsec-overview] [I-D.lepinski-bgpsec-overview]
Lepinski, M. and S. Turner, "An Overview of BGPSEC", Lepinski, M. and S. Turner, "An Overview of BGPSEC",
draft-lepinski-bgpsec-overview-00 (work in progress), draft-lepinski-bgpsec-overview-00 (work in progress),
March 2011. March 2011.
[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, February 1996. BCP 5, RFC 1918, February 1996.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, February 2012.
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. 20 change blocks. 
50 lines changed or deleted 62 lines changed or added

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