randy/draft-transfer
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

smash over from svn

Browse source
This commit is contained in:
Randy Bush 2016-12-14 10:36:58 +09:00
commit d4b4d65779
2 changed files with 490 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

19
Makefile Executable file
View file

@ -0,0 +1,19 @@
#
# Makefile for I-D's and RFCs
# $Id: Makefile,v 1.1.1.1 2002-11-11 05:11:48 randy Exp $
#
# Your nroff document is called foo.txt. Change below as appropiate.
NAME=draft-ymbk-sidr-transfer
DEST=psg.com:public_html
RSY=rsync --rsh ssh -v -a -l -H -p -t -x --delete
all: $(NAME).xml
xml2rfc $(NAME).xml --html --text
rsy:
$(RSY) $(NAME).html $(DEST)
$(RSY) $(NAME).txt $(DEST)
clean:
rm -f *.html *.txt

471
draft-ymbk-sidr-transfer.xml Normal file
View file

@ -0,0 +1,471 @@
<?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>