471 lines
20 KiB
XML
471 lines
20 KiB
XML
<?xml version="1.0"?>
|
||
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
|
||
<?rfc comments="yes"?>
|
||
<?rfc compact="yes"?>
|
||
<?rfc inline="yes"?>
|
||
<?rfc sortrefs="yes"?>
|
||
<?rfc subcompact="yes"?>
|
||
<?rfc symrefs="yes"?>
|
||
<?rfc toc="yes"?>
|
||
<?rfc tocdepth="3"?>
|
||
<?rfc tocindent="yes"?>
|
||
<?rfc tocompact="yes"?>
|
||
|
||
<rfc category="std" docName="draft-ymbk-sidr-transfer-02" ipr="trust200902">
|
||
|
||
<front>
|
||
|
||
<title abbrev="Resource Transfer in the RPKI">
|
||
Resource Transfer in the Resource Public Key Infrastructure</title>
|
||
|
||
<author initials="R." surname="Austein" fullname="Rob Austein">
|
||
<organization abbrev="Dragon Research Labs">Dragon Research Lab</organization>
|
||
<address>
|
||
<postal>
|
||
<street>40 Gavin Circle</street>
|
||
<city>Reading</city>
|
||
<region>MA</region>
|
||
<code>01867</code>
|
||
<country>USA</country>
|
||
</postal>
|
||
<email>sra@hactrn.net</email>
|
||
</address>
|
||
</author>
|
||
|
||
<author fullname="Randy Bush" initials="R." surname="Bush">
|
||
<organization abbrev="IIJ Lab / Dragon Research Lab">IIJ / Dragon Research Labs</organization>
|
||
<address>
|
||
<postal>
|
||
<street>5147 Crystal Springs</street>
|
||
<city>Bainbridge Island</city>
|
||
<region>Washington</region>
|
||
<code>98110</code>
|
||
<country>US</country>
|
||
</postal>
|
||
<email>randy@psg.com</email>
|
||
</address>
|
||
</author>
|
||
|
||
<author fullname="Geoff Huston" initials="G." surname="Huston">
|
||
<organization>Asia Pacific Network Information Centre</organization>
|
||
<address>
|
||
<postal>
|
||
<street>6 Cordelia St</street>
|
||
<city>South Brisbane</city>
|
||
<region>QLD</region>
|
||
<code>4101</code>
|
||
<country>AU</country>
|
||
</postal>
|
||
<email>gih@apnic.net</email>
|
||
</address>
|
||
</author>
|
||
|
||
<author fullname="George Michaelson" initials="G." surname="Michaelson">
|
||
<organization>Asia Pacific Network Information Centre</organization>
|
||
<address>
|
||
<postal>
|
||
<street>6 Cordelia St</street>
|
||
<city>South Brisbane</city>
|
||
<region>QLD</region>
|
||
<code>4101</code>
|
||
<country>AU</country>
|
||
</postal>
|
||
<email>ggm@apnic.net</email>
|
||
</address>
|
||
</author>
|
||
|
||
<date month="July" year="2015" />
|
||
|
||
<abstract>
|
||
<t>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.</t>
|
||
</abstract>
|
||
|
||
<!--
|
||
<note title="Requirements Language">
|
||
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to
|
||
be interpreted as described in <xref target="RFC2119">RFC
|
||
2119</xref> only when they appear in all upper case. They may also
|
||
appear in lower or mixed case as English words, without normative
|
||
meaning.</t>
|
||
</note>
|
||
-->
|
||
|
||
</front>
|
||
|
||
<middle>
|
||
|
||
<section anchor="intro" title="Introduction and Terms">
|
||
<t>To paraphrase the Introduction of <xref target="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."</t>
|
||
<t>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 <xref target="RFC3779"/> extensions in the
|
||
Resource Public Key Infrastructure (RPKI), see
|
||
<xref target="RFC6480"/>.</t>
|
||
<t>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.</t>
|
||
<figure>
|
||
<artwork>
|
||
+------------+
|
||
| Swing |
|
||
| Point |
|
||
| IR |
|
||
+------------+
|
||
^ ^
|
||
+-------+ +-------+
|
||
| |
|
||
+------------+ +------------+
|
||
| Selling | | Buying |
|
||
| IR | | IR |
|
||
| | | |
|
||
+------------+ +------------+
|
||
Fig 1. The Simplest Example of
|
||
Seller, Buyer, and Swing Point
|
||
</artwork>
|
||
</figure>
|
||
<t>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.</t>
|
||
<t>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.</t>
|
||
<t>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.</t>
|
||
<t>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.</t>
|
||
</section>
|
||
|
||
<section anchor="simple" title="A Simplistic Case">
|
||
|
||
<figure>
|
||
<artwork>
|
||
+------------+
|
||
| Swing |
|
||
| Point |
|
||
| IR |
|
||
+------------+
|
||
4 ^ ^ | ^ 4
|
||
+----------+ | | +----------+
|
||
| | | |
|
||
v | | |
|
||
+------------+ | | +------------+
|
||
| Selling | 2 | | 3 | Buying |
|
||
| IR | | | | IR |
|
||
| | | | | |
|
||
+---------+--+ | | +--+---------+
|
||
| | | |
|
||
1 | | | |
|
||
v | | v
|
||
.---------. | | .---------.
|
||
|Resources|-----+ +--->|Resources|
|
||
`---------' `---------'
|
||
Fig 2. Steps in a Simple Transfer
|
||
</artwork>
|
||
</figure>
|
||
|
||
<section anchor="steps" title="Steps in Simple Case">
|
||
<t>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.</t>
|
||
<t>The transfer is done in the following steps (see Figure 2):
|
||
<list style="numbers">
|
||
<t>The seller creates a certificate describing the subset of the
|
||
seller’s resources which are to be transferred.</t>
|
||
<t>The seller tells the swing point that it wishes to transfer the
|
||
resources described by the certificate to the buyer.</t>
|
||
<t>The swing point issues a new expanded certificate to the buyer
|
||
describing the buyer’s old holdings plus the new resources.</t>
|
||
<t>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.</t>
|
||
</list>
|
||
</t>
|
||
</section>
|
||
|
||
<section anchor="euro" title="The Torn Euro Protocol">
|
||
|
||
<t>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 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.</t>
|
||
|
||
<t>This protocol has yet to be described.</t>
|
||
|
||
</section>
|
||
|
||
</section>
|
||
|
||
<section anchor="complex" title="A More Complex Case">
|
||
|
||
<t> What happens when the seller is not a direct customer of the
|
||
swing point as in Figure ?.</t>
|
||
<figure>
|
||
<artwork>
|
||
+------------+
|
||
| Swing |
|
||
| Point |
|
||
| IR |
|
||
+------------+
|
||
^ ^
|
||
+-------+ +-------+
|
||
| |
|
||
+------------+ +------------+
|
||
|Intermediate| | Buying |
|
||
| IR | | IR |
|
||
| | | |
|
||
+----.-------+ +------------+
|
||
^
|
||
+-------+
|
||
|
|
||
+------------+
|
||
| Selling |
|
||
| IR |
|
||
| |
|
||
+------------+
|
||
Figure 3. The Case of The Indirect Seller
|
||
</artwork>
|
||
</figure>
|
||
<t>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.</t>
|
||
<t>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 does own/control the resource being transferred, and
|
||
therefore has the prerogative to act based on its perception of
|
||
the liabilities it is incurring. </t>
|
||
<t>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.</t>
|
||
<t>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.</t>
|
||
|
||
<section anchor="indirectbuyer" title="The Indirect Buyer">
|
||
|
||
<t>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?</t>
|
||
<t>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?</t>
|
||
<figure>
|
||
<artwork>
|
||
+------------+
|
||
| Swing |
|
||
| Point |
|
||
| IR |
|
||
+------------+
|
||
^ ^
|
||
+-------+ +-------+
|
||
| |
|
||
+------------+ +------------+
|
||
| Selling | |Intermediate|
|
||
| IR | | IR |
|
||
| | | |
|
||
+------------+ +------------+
|
||
^
|
||
+-------+
|
||
|
|
||
+------------+
|
||
| Buying |
|
||
| IR |
|
||
| |
|
||
+------------+
|
||
Figure 4. The Case of The Indirect Buyer
|
||
</artwork>
|
||
</figure>
|
||
<t>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.</t>
|
||
<t>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.</t>
|
||
|
||
</section>
|
||
|
||
<section anchor="diff" title="The Difference Between Buyer and Seller Chain">
|
||
<t>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.</t>
|
||
</section>
|
||
|
||
</section>
|
||
|
||
<section anchor="noswing" title="Transfer in the Absence of a Common Ancestor">
|
||
<t>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.</t>
|
||
|
||
<t>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.</t>
|
||
|
||
<figure>
|
||
<artwork>
|
||
+------+
|
||
| 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.
|
||
</artwork>
|
||
</figure>
|
||
|
||
<t>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 <xref target="RFC6492"/> Section 3) and uses
|
||
an APNIC-provided publication point.</t>
|
||
|
||
<t>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.</t>
|
||
|
||
<t>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.</t>
|
||
|
||
<t>This could probably be made more complicated and brittle, but it
|
||
would require serious effort.</t>
|
||
|
||
</section>
|
||
|
||
<section anchor="inprocess" title="Transfer in process: Resources Change Forced from Above">
|
||
|
||
<t>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.</t>
|
||
|
||
<t>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.</t>
|
||
|
||
<t>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 <xref target="RFC6492"></xref>, the time window of exposure of
|
||
this over-claiming can be relatively large.</t>
|
||
|
||
</section>
|
||
|
||
<section anchor="Security" title="Security Considerations">
|
||
<t>Ghu only knows.</t>
|
||
</section>
|
||
|
||
<section anchor="Acknowledgements" title="Acknowledgements">
|
||
<t>Thanks to Steve Kent for comments.</t>
|
||
</section>
|
||
|
||
<section anchor="IANA" title="IANA Considerations">
|
||
<t>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.</t>
|
||
</section>
|
||
|
||
</middle>
|
||
|
||
<back>
|
||
|
||
<references title="Normative References">
|
||
<!--
|
||
<?rfc include="reference.RFC.2119"?>
|
||
-->
|
||
<?rfc include="reference.RFC.6492"?>
|
||
</references>
|
||
<references title="Informative References">
|
||
<?rfc include="reference.RFC.3779"?>
|
||
<?rfc include="reference.RFC.6480"?>
|
||
</references>
|
||
|
||
</back>
|
||
|
||
</rfc>
|