Internet DRAFT - draft-ymbk-sidrops-transfer
draft-ymbk-sidrops-transfer
Network Working Group R. Austein
Internet-Draft Arrcus
Intended status: Standards Track R. Bush
Expires: May 7, 2020 Arrcus & Internet Initiative Japan
G. Huston
G. Michaelson
Asia Pacific Network Information Centre
November 4, 2019
Resource Transfer in the Resource Public Key Infrastructure
draft-ymbk-sidrops-transfer-00
Abstract
Transfer within the RPKI of actual address space and/or autonomous
system number resources between two Internet registries (ISPs, RIRs,
NIRs, etc.) is reasonably achievable for most useful operational
needs. In this paper, we describe, at a high level, how this may be
accomplished.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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 May 7, 2020.
Copyright Notice
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
Austein, et al. Expires May 7, 2020 [Page 1]
Internet-Draft Resource Transfer in the RPKI November 2019
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
described in the Simplified BSD License.
Table of Contents
1. Introduction and Terms . . . . . . . . . . . . . . . . . . . 2
2. A Simplistic Case . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Steps in Simple Case . . . . . . . . . . . . . . . . . . 4
2.2. The Torn Euro Protocol . . . . . . . . . . . . . . . . . 4
3. A More Complex Case . . . . . . . . . . . . . . . . . . . . . 5
3.1. The Indirect Buyer . . . . . . . . . . . . . . . . . . . 6
3.2. The Difference Between Buyer and Seller Chain . . . . . . 8
4. Transfer in the Absence of a Common Ancestor . . . . . . . . 8
5. Transfer in process: Resources Change Forced from Above . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction and Terms
To paraphrase the Introduction of [RFC6480], the "Resource Public Key
Infrastructure (RPKI) represents the allocation hierarchy of IP
address space and Autonomous System (AS) numbers; and is a
distributed repository system for storing and disseminating the data
objects that comprise the RPKI, as well as other signed objects
necessary for improved routing security."
An Internet Registry (IR) is the IANA, a Regional Internet Registry
(RIR), a National Internet Registry (NIR), a Local Internet Registry
(LIR), a Internet Service Provider (ISP), or an end site which may
hold IP resources and is the subject of one or more certificates
using [RFC3779] extensions in the Resource Public Key Infrastructure
(RPKI), see [RFC6480].
It is increasingly necessary to transfer resources between resource-
holding entities in the RPKI, to do so without violating contracts,
policies, etc., and while maintaining operational reliability and
administrative accuracy with minimal administrative overhead.
Austein, et al. Expires May 7, 2020 [Page 2]
Internet-Draft Resource Transfer in the RPKI November 2019
+------------+
| Swing |
| Point |
| IR |
+------------+
^ ^
+-------+ +-------+
| |
+------------+ +------------+
| Selling | | Buying |
| IR | | IR |
| | | |
+------------+ +------------+
Fig 1. The Simplest Example of
Seller, Buyer, and Swing Point
Seller and Buyer are used to describe the end parties to a transfer,
the selling IR transferring the resource(s) to the buying IR. For
the purposes of this document, the terms seller and buyer are used,
although layer nine considerations may require less commercial formal
roles.
Transfer is the sale and corresponding purchase of literal address
space or autonomous system numbers between two parties. The seller
relinquishing some amount of resource and the buyer being allocated a
similar amount but not the same literal address space, is not a
transfer, and is not further considered here.
A Swing Point is the IR at the lowest point in the RPKI hierarchy
which the seller and buyer have as a common parent and which has
agreed to be used as the agent of transfer.
While there is no automated method for the RPKI to assist the parties
to a transaction in determining that all business and policy aspects
of a transaction are satisfied, these layer eight and nine issues can
be resolved using normal business practices and therefore not
addressed in this document.
2. A Simplistic Case
Austein, et al. Expires May 7, 2020 [Page 3]
Internet-Draft Resource Transfer in the RPKI November 2019
+------------+
| Swing |
| Point |
| IR |
+------------+
4 ^ ^ | ^ 4
+----------+ | | +----------+
| | | |
v | | |
+------------+ | | +------------+
| Selling | 2 | | 3 | Buying |
| IR | | | | IR |
| | | | | |
+---------+--+ | | +--+---------+
| | | |
1 | | | |
v | | v
.---------. | | .---------.
|Resources|-----+ +--->|Resources|
`---------' `---------'
Fig 2. Steps in a Simple Transfer
2.1. Steps in Simple Case
As a formal business relationship between all parties to a transfer
provides a level of trust which allows simple transactions, we first
consider the simple case where the seller and the buyer are both
directly known to the swing point, see Figure 1.
The transfer is done in the following steps (see Figure 2):
1. The seller creates a certificate describing the subset of the
seller's resources which are to be transferred.
2. The seller tells the swing point that it wishes to transfer the
resources described by the certificate to the buyer.
3. The swing point issues a new expanded certificate to the buyer
describing the buyer's old holdings plus the new resources.
4. When the seller and the buyer are comfortable that both the
technical aspects (customers swung, routing done, etc.) and the
business aspects of the transfer have been accomplished, they
inform the swing point which then issues a new certificate to the
seller, having removed the transferred resources.
2.2. The Torn Euro Protocol
Due to issues of cancellation, reneging, and fraud, step 4 above,
where the seller and the buyer tell the swing point that the deal is
done, needs to be formal in some fashion. For this purpose, we
Austein, et al. Expires May 7, 2020 [Page 4]
Internet-Draft Resource Transfer in the RPKI November 2019
envision a yet to be described torn Euro protocol, where the buyer
and the seller each hold one half of a virtual torn Euro note, and
the swing point believes the transaction to be complete when it has
received both halves and they match.
This protocol has yet to be described.
3. A More Complex Case
What happens when the seller is not a direct customer of the swing
point as in Figure ?.
+------------+
| Swing |
| Point |
| IR |
+------------+
^ ^
+-------+ +-------+
| |
+------------+ +------------+
|Intermediate| | Buying |
| IR | | IR |
| | | |
+----.-------+ +------------+
^
+-------+
|
+------------+
| Selling |
| IR |
| |
+------------+
Figure 3. The Case of The Indirect Seller
The swing point needs to be assured that it is contractually able to
move the resource given its relationship to the Other IR. As RFC
3779 extensions do not codify business issues such as PI/PA, and
rights to resell, this has to be handled out of band; there is no way
to automate it. This is part of today's IR address space management
process and will continue to be handled manually.
Therefore the process is the same as for the simple case, except
that, before issuing the expanded certificate to the buyer in step 3,
the swing point must assure itself that policy and contractual issues
have been addressed. The swing point might be well-advised to
contact the intermediate IR and gain its consent, possibly with the
assistance of the seller. The bottom line is that the swing point
Austein, et al. Expires May 7, 2020 [Page 5]
Internet-Draft Resource Transfer in the RPKI November 2019
does own/control the resource being transferred, and therefore has
the prerogative to act based on its perception of the liabilities it
is incurring.
This freedom allowing the seller to be indirectly related to the
swing point can accommodate more levels of indirection. It is the
swing point's obligation to perform diligence on the iterative
financial, contractual, and policy obligations of the relationships
down to the seller. Unfortunately, the RPKI can not automate this.
All certificates below the swing point down to and including the
seller will need to be reissued with the appropriate reduction of
resources. All certificated below the swing point down to and
including the buyer will need to be [re-]issued to include the
addition of the resource(s) being transferred to the buyer.
3.1. The Indirect Buyer
The case where the buyer is not directly known to the swing point is
more difficult. Among other issues, the buyer may not be an existing
resource holder at all, i.e. there may be no path down from the IANA
root to the buyer. In this case, the buyer must explore the graph
and choose an IR with which to contract a relationship. This can be
both a business issue and a policy issue, e.g. can a buyer in Asia
choose a parent which is, directly or indirectly, an ARIN customer?
The case where the buyer contracts directly to become a customer of
the swing point has been explored above. What if the buyer becomes a
grandchild of the swing point, as in Figure 4?
Austein, et al. Expires May 7, 2020 [Page 6]
Internet-Draft Resource Transfer in the RPKI November 2019
+------------+
| Swing |
| Point |
| IR |
+------------+
^ ^
+-------+ +-------+
| |
+------------+ +------------+
| Selling | |Intermediate|
| IR | | IR |
| | | |
+------------+ +------------+
^
+-------+
|
+------------+
| Buying |
| IR |
| |
+------------+
Figure 4. The Case of The Indirect Buyer
Somewhat analogously to the case of the indirect seller, the swing
point has to iteratively verify that the IRs between it and the buyer
are all willing to contractually and technically accept the
resource(s) to be allocated to the buyer. But, in the case of the
indirect buyer, the iterative conditions are much stronger. In the
indirect seller case, the swing point has contractual control of the
chain between it and the seller. In the case of the indirect buyer,
all intermediate IRs between the swing point and the buyer must give
business and technical consent to the transfer. The swing point can
not directly or transitively force its child to issue a resource
certificate to the buyer.
Things may not be as bad as they appear at first blush. The buyer is
actually contracting with its parent, and part of that contract will
presumably be that the parent agrees to issue the resource
certificate to the buyer when it receives the resource from it's
parent. And this presumably applies to the buyer's parent's
relationship to a grandparent and so forth. On the other hand, the
swing point has no mechanical way to test the willingness of the IRs
on the buyer's indirect chain. But the swing point will need to know
when the buyer is happy that it has received the resources.
Austein, et al. Expires May 7, 2020 [Page 7]
Internet-Draft Resource Transfer in the RPKI November 2019
3.2. The Difference Between Buyer and Seller Chain
Essentially, the difference between an indirect buyer chain and an
indirect seller chain is that the swing point has the logical, though
maybe not contractual, prerogative to pull address space from the
seller's chain, but does not have the power to push it down the
buyer's chain. All IRs on the buyer's chain must agree to certify
downward toward the buyer.
4. Transfer in the Absence of a Common Ancestor
For political reasons, the current RPKI structure has no single root
trust anchor. There are a number of trust anchors, e.g. the five
RIRs which do not descend from the IANA. This creates considerable
complexity and some risk for resource transfers between entities
without a common ancestor.
To work around this problem, each RIR certifies a subsidiary
Certification Authority for each other RIR to which it transfers
resources, see Figure 5, and issues the transferred resources to that
subsidiary CA.
+------+
| RIPE |
+------+
|
|
+-----------+-------+-------+-----------+
| | | | |
| | | | |
v v | v v
+-------+ +-------+ | +-------+ +-------+
| APNIC | |AfriNIC| | | ARIN | |LACNIC |
+-------+ +-------+ | +-------+ +-------+
v
+-----------+
| Members |
+-----------+
Figure 5: The RIRs each certify proxy CAs
for all of the other RIRs.
But, to use the example of Figure 5, the APNIC CA to which RIPE
issues resources is, in fact, run by APNIC under APNIC's Business
Certificate PKI (see [RFC6492] Section 3) and uses an APNIC-provided
publication point.
Austein, et al. Expires May 7, 2020 [Page 8]
Internet-Draft Resource Transfer in the RPKI November 2019
Thus APNIC has under its control, among other things, four CAs, one
with resources from each of the other CAs. And similarly for each of
the other RIRs.
So the swing point for a transfer from an APNIC member to a RIPE
member is the APNIC CA. And an APNIC member holding resources
originated by APNIC as well as resources transferred in from another
RIR, e.g. RIPE, actually holds two resource certificates.
This could probably be made more complicated and brittle, but it
would require serious effort.
5. Transfer in process: Resources Change Forced from Above
Even though both seller and buyer have agreed to a transfer, the
seller might try to not relinquish the resource, hoping to sell it
more than once. Therefore it may become necessary to force closure
for a non-compliant seller. In this case, a resource holding would
be changed, shrunk, by force from above.
A 'normal' (i.e. what the RPKI design anticipated) resource shrinkage
is initiated by the leaf resource holder and propagates upward toward
the root of the tree. At no point in this process does a holder
claim more than their parent believes they have.
When a resource is forcibly removed from 'above', the shrinkage
propagates downward. Until the ultimate holder relinquishes the
resource, at some point in the path down the tree a child holds more
resources than its parent believes it does. As the protocol model is
bottom initiated polling, see [RFC6492], the time window of exposure
of this over-claiming can be relatively large.
6. Security Considerations
Ghu only knows.
7. Acknowledgements
Thanks to Steve Kent for comments.
8. IANA Considerations
Nothing is required of the IANA; though it would make some things a
lot simpler if the IANA was the root TA/CA of the entire tree.
Austein, et al. Expires May 7, 2020 [Page 9]
Internet-Draft Resource Transfer in the RPKI November 2019
9. References
9.1. Normative References
[RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A
Protocol for Provisioning Resource Certificates",
RFC 6492, DOI 10.17487/RFC6492, February 2012,
<http://www.rfc-editor.org/info/rfc6492>.
9.2. Informative References
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779,
DOI 10.17487/RFC3779, June 2004,
<http://www.rfc-editor.org/info/rfc3779>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <http://www.rfc-editor.org/info/rfc6480>.
Authors' Addresses
Rob Austein
Arrcus, Inc
Email: sra@hactrn.net
Randy Bush
Arrcus & Internet Initiative Japan
5147 Crystal Springs
Bainbridge Island, WA 98110
US
Email: randy@psg.com
Geoff Huston
Asia Pacific Network Information Centre
6 Cordelia St
South Brisbane, QLD 4101
AU
Email: gih@apnic.net
Austein, et al. Expires May 7, 2020 [Page 10]
Internet-Draft Resource Transfer in the RPKI November 2019
George Michaelson
Asia Pacific Network Information Centre
6 Cordelia St
South Brisbane, QLD 4101
AU
Email: ggm@apnic.net
Austein, et al. Expires May 7, 2020 [Page 11]
