Internet DRAFT - draft-ymbk-sidr-transfer

draft-ymbk-sidr-transfer







Network Working Group                                         R. Austein
Internet-Draft                                      Dragon Research Labs
Intended status: Standards Track                                 R. Bush
Expires: January 21, 2016                  IIJ Lab / Dragon Research Lab
                                                               G. Huston
                                                           G. Michaelson
                                 Asia Pacific Network Information Centre
                                                           July 20, 2015


      Resource Transfer in the Resource Public Key Infrastructure
                      draft-ymbk-sidr-transfer-01

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 http://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 January 21, 2016.

Copyright Notice

   Copyright (c) 2015 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
   (http://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 January 21, 2016                [Page 1]

Internet-Draft        Resource Transfer in the RPKI            July 2015


   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 January 21, 2016                [Page 2]

Internet-Draft        Resource Transfer in the RPKI            July 2015


                           +------------+
                           |   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 January 21, 2016                [Page 3]

Internet-Draft        Resource Transfer in the RPKI            July 2015


                                +------------+
                                |   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 January 21, 2016                [Page 4]

Internet-Draft        Resource Transfer in the RPKI            July 2015


   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 January 21, 2016                [Page 5]

Internet-Draft        Resource Transfer in the RPKI            July 2015


   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 January 21, 2016                [Page 6]

Internet-Draft        Resource Transfer in the RPKI            July 2015


                   +------------+
                   |   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 January 21, 2016                [Page 7]

Internet-Draft        Resource Transfer in the RPKI            July 2015


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 January 21, 2016                [Page 8]

Internet-Draft        Resource Transfer in the RPKI            July 2015


   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 January 21, 2016                [Page 9]

Internet-Draft        Resource Transfer in the RPKI            July 2015


9.  References

9.1.  Normative References

   [RFC6492]  Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A
              Protocol for Provisioning Resource Certificates", RFC
              6492, February 2012.

9.2.  Informative References

   [RFC3779]  Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
              Addresses and AS Identifiers", RFC 3779, June 2004.

   [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
              Secure Internet Routing", RFC 6480, February 2012.

Authors' Addresses

   Rob Austein
   Dragon Research Lab
   40 Gavin Circle
   Reading, MA  01867
   USA

   Email: sra@hactrn.net


   Randy Bush
   IIJ / Dragon Research Labs
   5147 Crystal Springs
   Bainbridge Island, Washington  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 January 21, 2016               [Page 10]

Internet-Draft        Resource Transfer in the RPKI            July 2015


   George Michaelson
   Asia Pacific Network Information Centre
   6 Cordelia St
   South Brisbane, QLD  4101
   AU

   Email: ggm@apnic.net












































Austein, et al.         Expires January 21, 2016               [Page 11]