idnits 2.17.1 draft-ymbk-sidrops-transfer-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 4, 2019) is 1635 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Austein 3 Internet-Draft Arrcus 4 Intended status: Standards Track R. Bush 5 Expires: May 7, 2020 Arrcus & Internet Initiative Japan 6 G. Huston 7 G. Michaelson 8 Asia Pacific Network Information Centre 9 November 4, 2019 11 Resource Transfer in the Resource Public Key Infrastructure 12 draft-ymbk-sidrops-transfer-00 14 Abstract 16 Transfer within the RPKI of actual address space and/or autonomous 17 system number resources between two Internet registries (ISPs, RIRs, 18 NIRs, etc.) is reasonably achievable for most useful operational 19 needs. In this paper, we describe, at a high level, how this may be 20 accomplished. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 7, 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction and Terms . . . . . . . . . . . . . . . . . . . 2 57 2. A Simplistic Case . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Steps in Simple Case . . . . . . . . . . . . . . . . . . 4 59 2.2. The Torn Euro Protocol . . . . . . . . . . . . . . . . . 4 60 3. A More Complex Case . . . . . . . . . . . . . . . . . . . . . 5 61 3.1. The Indirect Buyer . . . . . . . . . . . . . . . . . . . 6 62 3.2. The Difference Between Buyer and Seller Chain . . . . . . 8 63 4. Transfer in the Absence of a Common Ancestor . . . . . . . . 8 64 5. Transfer in process: Resources Change Forced from Above . . . 9 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 70 9.2. Informative References . . . . . . . . . . . . . . . . . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 73 1. Introduction and Terms 75 To paraphrase the Introduction of [RFC6480], the "Resource Public Key 76 Infrastructure (RPKI) represents the allocation hierarchy of IP 77 address space and Autonomous System (AS) numbers; and is a 78 distributed repository system for storing and disseminating the data 79 objects that comprise the RPKI, as well as other signed objects 80 necessary for improved routing security." 82 An Internet Registry (IR) is the IANA, a Regional Internet Registry 83 (RIR), a National Internet Registry (NIR), a Local Internet Registry 84 (LIR), a Internet Service Provider (ISP), or an end site which may 85 hold IP resources and is the subject of one or more certificates 86 using [RFC3779] extensions in the Resource Public Key Infrastructure 87 (RPKI), see [RFC6480]. 89 It is increasingly necessary to transfer resources between resource- 90 holding entities in the RPKI, to do so without violating contracts, 91 policies, etc., and while maintaining operational reliability and 92 administrative accuracy with minimal administrative overhead. 94 +------------+ 95 | Swing | 96 | Point | 97 | IR | 98 +------------+ 99 ^ ^ 100 +-------+ +-------+ 101 | | 102 +------------+ +------------+ 103 | Selling | | Buying | 104 | IR | | IR | 105 | | | | 106 +------------+ +------------+ 107 Fig 1. The Simplest Example of 108 Seller, Buyer, and Swing Point 110 Seller and Buyer are used to describe the end parties to a transfer, 111 the selling IR transferring the resource(s) to the buying IR. For 112 the purposes of this document, the terms seller and buyer are used, 113 although layer nine considerations may require less commercial formal 114 roles. 116 Transfer is the sale and corresponding purchase of literal address 117 space or autonomous system numbers between two parties. The seller 118 relinquishing some amount of resource and the buyer being allocated a 119 similar amount but not the same literal address space, is not a 120 transfer, and is not further considered here. 122 A Swing Point is the IR at the lowest point in the RPKI hierarchy 123 which the seller and buyer have as a common parent and which has 124 agreed to be used as the agent of transfer. 126 While there is no automated method for the RPKI to assist the parties 127 to a transaction in determining that all business and policy aspects 128 of a transaction are satisfied, these layer eight and nine issues can 129 be resolved using normal business practices and therefore not 130 addressed in this document. 132 2. A Simplistic Case 133 +------------+ 134 | Swing | 135 | Point | 136 | IR | 137 +------------+ 138 4 ^ ^ | ^ 4 139 +----------+ | | +----------+ 140 | | | | 141 v | | | 142 +------------+ | | +------------+ 143 | Selling | 2 | | 3 | Buying | 144 | IR | | | | IR | 145 | | | | | | 146 +---------+--+ | | +--+---------+ 147 | | | | 148 1 | | | | 149 v | | v 150 .---------. | | .---------. 151 |Resources|-----+ +--->|Resources| 152 `---------' `---------' 153 Fig 2. Steps in a Simple Transfer 155 2.1. Steps in Simple Case 157 As a formal business relationship between all parties to a transfer 158 provides a level of trust which allows simple transactions, we first 159 consider the simple case where the seller and the buyer are both 160 directly known to the swing point, see Figure 1. 162 The transfer is done in the following steps (see Figure 2): 164 1. The seller creates a certificate describing the subset of the 165 seller's resources which are to be transferred. 166 2. The seller tells the swing point that it wishes to transfer the 167 resources described by the certificate to the buyer. 168 3. The swing point issues a new expanded certificate to the buyer 169 describing the buyer's old holdings plus the new resources. 170 4. When the seller and the buyer are comfortable that both the 171 technical aspects (customers swung, routing done, etc.) and the 172 business aspects of the transfer have been accomplished, they 173 inform the swing point which then issues a new certificate to the 174 seller, having removed the transferred resources. 176 2.2. The Torn Euro Protocol 178 Due to issues of cancellation, reneging, and fraud, step 4 above, 179 where the seller and the buyer tell the swing point that the deal is 180 done, needs to be formal in some fashion. For this purpose, we 181 envision a yet to be described torn Euro protocol, where the buyer 182 and the seller each hold one half of a virtual torn Euro note, and 183 the swing point believes the transaction to be complete when it has 184 received both halves and they match. 186 This protocol has yet to be described. 188 3. A More Complex Case 190 What happens when the seller is not a direct customer of the swing 191 point as in Figure ?. 193 +------------+ 194 | Swing | 195 | Point | 196 | IR | 197 +------------+ 198 ^ ^ 199 +-------+ +-------+ 200 | | 201 +------------+ +------------+ 202 |Intermediate| | Buying | 203 | IR | | IR | 204 | | | | 205 +----.-------+ +------------+ 206 ^ 207 +-------+ 208 | 209 +------------+ 210 | Selling | 211 | IR | 212 | | 213 +------------+ 214 Figure 3. The Case of The Indirect Seller 216 The swing point needs to be assured that it is contractually able to 217 move the resource given its relationship to the Other IR. As RFC 218 3779 extensions do not codify business issues such as PI/PA, and 219 rights to resell, this has to be handled out of band; there is no way 220 to automate it. This is part of today's IR address space management 221 process and will continue to be handled manually. 223 Therefore the process is the same as for the simple case, except 224 that, before issuing the expanded certificate to the buyer in step 3, 225 the swing point must assure itself that policy and contractual issues 226 have been addressed. The swing point might be well-advised to 227 contact the intermediate IR and gain its consent, possibly with the 228 assistance of the seller. The bottom line is that the swing point 229 does own/control the resource being transferred, and therefore has 230 the prerogative to act based on its perception of the liabilities it 231 is incurring. 233 This freedom allowing the seller to be indirectly related to the 234 swing point can accommodate more levels of indirection. It is the 235 swing point's obligation to perform diligence on the iterative 236 financial, contractual, and policy obligations of the relationships 237 down to the seller. Unfortunately, the RPKI can not automate this. 239 All certificates below the swing point down to and including the 240 seller will need to be reissued with the appropriate reduction of 241 resources. All certificated below the swing point down to and 242 including the buyer will need to be [re-]issued to include the 243 addition of the resource(s) being transferred to the buyer. 245 3.1. The Indirect Buyer 247 The case where the buyer is not directly known to the swing point is 248 more difficult. Among other issues, the buyer may not be an existing 249 resource holder at all, i.e. there may be no path down from the IANA 250 root to the buyer. In this case, the buyer must explore the graph 251 and choose an IR with which to contract a relationship. This can be 252 both a business issue and a policy issue, e.g. can a buyer in Asia 253 choose a parent which is, directly or indirectly, an ARIN customer? 255 The case where the buyer contracts directly to become a customer of 256 the swing point has been explored above. What if the buyer becomes a 257 grandchild of the swing point, as in Figure 4? 258 +------------+ 259 | Swing | 260 | Point | 261 | IR | 262 +------------+ 263 ^ ^ 264 +-------+ +-------+ 265 | | 266 +------------+ +------------+ 267 | Selling | |Intermediate| 268 | IR | | IR | 269 | | | | 270 +------------+ +------------+ 271 ^ 272 +-------+ 273 | 274 +------------+ 275 | Buying | 276 | IR | 277 | | 278 +------------+ 279 Figure 4. The Case of The Indirect Buyer 281 Somewhat analogously to the case of the indirect seller, the swing 282 point has to iteratively verify that the IRs between it and the buyer 283 are all willing to contractually and technically accept the 284 resource(s) to be allocated to the buyer. But, in the case of the 285 indirect buyer, the iterative conditions are much stronger. In the 286 indirect seller case, the swing point has contractual control of the 287 chain between it and the seller. In the case of the indirect buyer, 288 all intermediate IRs between the swing point and the buyer must give 289 business and technical consent to the transfer. The swing point can 290 not directly or transitively force its child to issue a resource 291 certificate to the buyer. 293 Things may not be as bad as they appear at first blush. The buyer is 294 actually contracting with its parent, and part of that contract will 295 presumably be that the parent agrees to issue the resource 296 certificate to the buyer when it receives the resource from it's 297 parent. And this presumably applies to the buyer's parent's 298 relationship to a grandparent and so forth. On the other hand, the 299 swing point has no mechanical way to test the willingness of the IRs 300 on the buyer's indirect chain. But the swing point will need to know 301 when the buyer is happy that it has received the resources. 303 3.2. The Difference Between Buyer and Seller Chain 305 Essentially, the difference between an indirect buyer chain and an 306 indirect seller chain is that the swing point has the logical, though 307 maybe not contractual, prerogative to pull address space from the 308 seller's chain, but does not have the power to push it down the 309 buyer's chain. All IRs on the buyer's chain must agree to certify 310 downward toward the buyer. 312 4. Transfer in the Absence of a Common Ancestor 314 For political reasons, the current RPKI structure has no single root 315 trust anchor. There are a number of trust anchors, e.g. the five 316 RIRs which do not descend from the IANA. This creates considerable 317 complexity and some risk for resource transfers between entities 318 without a common ancestor. 320 To work around this problem, each RIR certifies a subsidiary 321 Certification Authority for each other RIR to which it transfers 322 resources, see Figure 5, and issues the transferred resources to that 323 subsidiary CA. 325 +------+ 326 | RIPE | 327 +------+ 328 | 329 | 330 +-----------+-------+-------+-----------+ 331 | | | | | 332 | | | | | 333 v v | v v 334 +-------+ +-------+ | +-------+ +-------+ 335 | APNIC | |AfriNIC| | | ARIN | |LACNIC | 336 +-------+ +-------+ | +-------+ +-------+ 337 v 338 +-----------+ 339 | Members | 340 +-----------+ 342 Figure 5: The RIRs each certify proxy CAs 343 for all of the other RIRs. 345 But, to use the example of Figure 5, the APNIC CA to which RIPE 346 issues resources is, in fact, run by APNIC under APNIC's Business 347 Certificate PKI (see [RFC6492] Section 3) and uses an APNIC-provided 348 publication point. 350 Thus APNIC has under its control, among other things, four CAs, one 351 with resources from each of the other CAs. And similarly for each of 352 the other RIRs. 354 So the swing point for a transfer from an APNIC member to a RIPE 355 member is the APNIC CA. And an APNIC member holding resources 356 originated by APNIC as well as resources transferred in from another 357 RIR, e.g. RIPE, actually holds two resource certificates. 359 This could probably be made more complicated and brittle, but it 360 would require serious effort. 362 5. Transfer in process: Resources Change Forced from Above 364 Even though both seller and buyer have agreed to a transfer, the 365 seller might try to not relinquish the resource, hoping to sell it 366 more than once. Therefore it may become necessary to force closure 367 for a non-compliant seller. In this case, a resource holding would 368 be changed, shrunk, by force from above. 370 A 'normal' (i.e. what the RPKI design anticipated) resource shrinkage 371 is initiated by the leaf resource holder and propagates upward toward 372 the root of the tree. At no point in this process does a holder 373 claim more than their parent believes they have. 375 When a resource is forcibly removed from 'above', the shrinkage 376 propagates downward. Until the ultimate holder relinquishes the 377 resource, at some point in the path down the tree a child holds more 378 resources than its parent believes it does. As the protocol model is 379 bottom initiated polling, see [RFC6492], the time window of exposure 380 of this over-claiming can be relatively large. 382 6. Security Considerations 384 Ghu only knows. 386 7. Acknowledgements 388 Thanks to Steve Kent for comments. 390 8. IANA Considerations 392 Nothing is required of the IANA; though it would make some things a 393 lot simpler if the IANA was the root TA/CA of the entire tree. 395 9. References 397 9.1. Normative References 399 [RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A 400 Protocol for Provisioning Resource Certificates", 401 RFC 6492, DOI 10.17487/RFC6492, February 2012, 402 . 404 9.2. Informative References 406 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 407 Addresses and AS Identifiers", RFC 3779, 408 DOI 10.17487/RFC3779, June 2004, 409 . 411 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 412 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 413 February 2012, . 415 Authors' Addresses 417 Rob Austein 418 Arrcus, Inc 420 Email: sra@hactrn.net 422 Randy Bush 423 Arrcus & Internet Initiative Japan 424 5147 Crystal Springs 425 Bainbridge Island, WA 98110 426 US 428 Email: randy@psg.com 430 Geoff Huston 431 Asia Pacific Network Information Centre 432 6 Cordelia St 433 South Brisbane, QLD 4101 434 AU 436 Email: gih@apnic.net 437 George Michaelson 438 Asia Pacific Network Information Centre 439 6 Cordelia St 440 South Brisbane, QLD 4101 441 AU 443 Email: ggm@apnic.net