Resource Transfer in the Resource Public Key Infrastructure

To paraphrase the Introduction of , 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 extensions in the Resource Public Key Infrastructure (RPKI), see . 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.

+------------+ | 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.

+------------+ | Swing | | Point | | IR | +------------+ 4 ^ ^ | ^ 4 +----------+ | | +----------+ | | | | v | | | +------------+ | | +------------+ | Selling | 2 | | 3 | Buying | | IR | | | | IR | | | | | | | +---------+--+ | | +--+---------+ | | | | 1 | | | | v | | v .---------. | | .---------. |Resources|-----+ +--->|Resources| `---------' `---------' Fig 2. Steps in a Simple Transfer

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): The seller creates a certificate describing the subset of the seller’s resources which are to be transferred. The seller tells the swing point that it wishes to transfer the resources described by the certificate to the buyer. The swing point issues a new expanded certificate to the buyer describing the buyer’s old holdings plus the new resources. 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.

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. This protocol has yet to be described.

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 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.

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?

+------------+ | 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.

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.

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 Section 3) and uses an APNIC-provided publication point. 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.

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 , the time window of exposure of this over-claiming can be relatively large.

Ghu only knows.

Thanks to Steve Kent for comments.

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.