idnits 2.17.1 draft-manderson-sidr-usecases-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- == There are 126 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 26, 2009) is 5286 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3852' is defined on line 806, but no explicit reference was found in the text == Unused Reference: 'RFC4055' is defined on line 809, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 815, but no explicit reference was found in the text == Unused Reference: 'RFC4893' is defined on line 818, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-08 == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-17 == Outdated reference: A later version (-12) exists of draft-ietf-sidr-roa-format-05 == Outdated reference: A later version (-10) exists of draft-ietf-sidr-roa-validation-03 ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) ** Obsolete normative reference: RFC 4893 (Obsoleted by RFC 6793) Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Inter-Domain Routing T. Manderson 3 Internet-Draft ICANN 4 Intended status: Informational K. Sriram 5 Expires: April 29, 2010 NIST 6 R. White 7 Cisco 8 October 26, 2009 10 Use Cases and interpretation of RPKI objects for issuers and relying 11 parties 12 draft-manderson-sidr-usecases-01 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 29, 2010. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 This document provides use cases directions, and interpretations for 51 organisations and relying parties when creating or encountering RPKI 52 object scenarios in the public RPKI in relation to the Internet 53 routing system. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 59 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 60 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 6 61 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.1. General interpretation of RPKI object semantics . . . . . 6 63 3. Origination use cases . . . . . . . . . . . . . . . . . . . . 7 64 3.1. Single announcement . . . . . . . . . . . . . . . . . . . 7 65 3.2. Aggregate with a more specific . . . . . . . . . . . . . . 7 66 3.3. Aggregate with more specific from different ASN . . . . . 7 67 3.4. Sub-allocation to multi-homed customer . . . . . . . . . . 8 68 3.5. Restriction of new allocation . . . . . . . . . . . . . . 8 69 3.6. Restriction of new ASN . . . . . . . . . . . . . . . . . . 9 70 3.7. Restriction of part of allocation . . . . . . . . . . . . 9 71 3.8. Restriction of prefix length . . . . . . . . . . . . . . . 10 72 3.9. Restriction of sub-allocation prefix length . . . . . . . 10 73 3.10. Permitted Aggregation and origination by an upstream . . . 11 74 3.11. Rogue Aggregation and origination by an upstream . . . . . 12 75 4. Adjacency use cases . . . . . . . . . . . . . . . . . . . . . 13 76 4.1. Multi-homed . . . . . . . . . . . . . . . . . . . . . . . 13 77 4.2. Restricting peers . . . . . . . . . . . . . . . . . . . . 13 78 5. Partial Deployment use cases . . . . . . . . . . . . . . . . . 14 79 5.1. Parent does not do RPKI . . . . . . . . . . . . . . . . . 14 80 5.2. Only some children participate . . . . . . . . . . . . . . 15 81 5.3. Grandchild allocations . . . . . . . . . . . . . . . . . . 15 82 6. Transfer use cases . . . . . . . . . . . . . . . . . . . . . . 16 83 6.1. Transfer of in-use prefix and autonomous system number . . 16 84 6.2. Transfer of in-use prefix . . . . . . . . . . . . . . . . 16 85 6.3. Transfer of un-used prefix . . . . . . . . . . . . . . . . 16 86 7. Relying Party use cases . . . . . . . . . . . . . . . . . . . 16 87 7.1. Use Cases Related to ROA Expiry or receipt of a CRL 88 covering a ROA . . . . . . . . . . . . . . . . . . . . . . 16 89 7.1.1. ROA of Parent Prefix is Revoked . . . . . . . . . . . 16 90 7.1.2. ROA of Prefix Revoked . . . . . . . . . . . . . . . . 17 91 7.1.3. ROA of Grandparent Prefix Revoked while that of 92 Parent Prefix Prevails . . . . . . . . . . . . . . . . 17 93 7.1.4. ROA of Prefix Revoked while that of Parent Prefix 94 Prevails . . . . . . . . . . . . . . . . . . . . . . . 17 95 7.1.5. Expiry of ROA of Parent Prefix . . . . . . . . . . . . 18 96 7.1.6. Expiry of ROA of Prefix . . . . . . . . . . . . . . . 18 97 7.1.7. Expiry of ROA of Grandparent Prefix while ROA of 98 Parent Prefix Prevails . . . . . . . . . . . . . . . . 18 99 7.1.8. Expiry of ROA of Prefix while ROA of Parent Prefix 100 Prevails . . . . . . . . . . . . . . . . . . . . . . . 18 101 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 102 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 103 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 104 11. Normative References . . . . . . . . . . . . . . . . . . . . . 19 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 107 1. Introduction 109 This document provides suggested use cases, direction and 110 interpretations for organisations and relying parties when creating 111 or encountering RPKI object scenarios in the public RPKI in relation 112 to the Internet routing system. 114 1.1. Terminology 116 It is assumed that the reader is familiar with the terms and concepts 117 described in "Internet X.509 Public Key Infrastructure Certificate 118 and Certificate Revocation List (CRL) Profile" [RFC5280], "A Profile 119 for X.509 PKIX Resource Certificates" [I-D.ietf-sidr-res-certs] 120 "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779], "A 121 Profile for Route Origin Authorizations (ROAs)" 122 [I-D.ietf-sidr-roa-format], "A Profile for Bogon Origin 123 Authorizations (BOAs)" [I-D.ietf-sidr-bogons], "Validation of Route 124 Origination in BGP using the Resource Certificate PKI" 125 [I-D.ietf-sidr-roa-validation], 127 1.2. Definitions 129 The following definitions are in use in this document. 131 Autonomous System (AS) Number (ASN) - An officially registered number 132 reprsenting a common, clearly defined routing policy for use in 133 Internet routing systems. 135 Prefix - A network address and the prefix length. 137 Route - A tuple of prefix and Autonomous System Number announced to 138 Internet routing systems. 140 Origin AS - The Autonomous System, designated by number, which 141 originates a route. 143 Aggregate - The result of where multiple specific prefixes are 144 aggregated into one covering route. 146 More specific - A route that has a longer prefix than a covering 147 aggregate. 149 Multi-homed - An Autonomous System that has active connections to 150 more than one other Autonomous System 152 Resource - An Internet (IP) addresses or Autonomous System Number. 154 Sub-allocation - Where a holder of a resource further allocates a 155 portion of the resource to another entity or organisation. 157 Allocation - The set of resources allocated to an entity or 158 organisation. 160 Transit Provider - An Autonomous System that provides access to other 161 networks through itself. 163 Upstream - See "Transit Provider". 165 Grandchild - A Sub-allocation that has resulted from one or more 166 previous Sub-allocations. 168 Parent - An allocation from which the subject prefix was sub- 169 allocated. 171 Grandparent - The allocation from which the prefix is a grandchild. 173 1.3. Requirements Language 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in RFC 2119. 179 2. Overview 181 2.1. General interpretation of RPKI object semantics 183 It is important that the interpretation of relying parties, or 184 relying party routing software, that implements a level of routing 185 decision, when a routing update ("route") is received in light of the 186 existence or non-existence of a corresponding RPKI object a 'make 187 before break' stance is taken. This means that the relying party 188 should do all possible steps to ensure a route is valid, before 189 attempting to declare it otherwise. For all of the cases in this 190 document it is assumed that RPKI objects validate (or otherwise) in 191 accordance with [I-D.ietf-sidr-res-certs], [I-D.ietf-sidr-arch], 192 [I-D.ietf-sidr-roa-validation], and [I-D.ietf-sidr-bogons] unless 193 otherwise stated. 195 While many of the examples provided here demonstrate organisations 196 with their own autonomous system numbers, it should be recognised 197 that a prefix holder not necessarily be the holder of an autonomous 198 system number, but simply use the autonomous system number for the 199 purposes of origination. 201 3. Origination use cases 203 3.1. Single announcement 205 An organisation (Org A with ASN 64496) has been allocated the prefix 206 192.168.2.0/24, it wishes to announce the /24 prefix from ASN 64496 207 to the Internet routing system such that relying parties interpret 208 the route as valid. 210 The resulting valid announcement (and organisation) would be: 212 +----------------------------------------------+ 213 | Prefix | Origin AS | Organisation | 214 +----------------------------------------------+ 215 | 192.168.2.0/24 | AS64496 | Org A | 216 +----------------------------------------------+ 218 The issuing party would create the following RPKI objects: TBC 220 3.2. Aggregate with a more specific 222 An organisation (Org A with ASN 64496) has been allocated the prefix 223 10.1.0.0/16, it wishes to announce the more specific prefix 224 10.1.0.0/20 from ASN 64496 as well as the aggregate route to the 225 Internet routing system such that relying parties interpret the 226 routes as valid. 228 The resulting valid announcements (and organisation) would be: 230 +----------------------------------------------+ 231 | Prefix | Origin AS | Organisation | 232 +----------------------------------------------+ 233 | 10.1.0.0/16 | AS64496 | Org A | 234 | 10.1.0.0/20 | AS64496 | Org A | 235 +----------------------------------------------+ 237 The issuing party would create the following RPKI objects: TBC 239 3.3. Aggregate with more specific from different ASN 241 An organisation (Org A with ASN 64496 and ASN 64499) has been 242 allocated the prefix 10.1.0.0/16, it wishes to announce the more 243 specific prefix 10.1.0.0/20 from ASN 64499 as well as the aggregate 244 route from ASN 64496 to the Internet routing system such that relying 245 parties interpret the routes as valid. 247 The resulting valid announcements (and organisation) would be: 249 +---------------------------------------------+ 250 | Prefix | Origin AS |Organisation | 251 +---------------------------------------------+ 252 | 10.1.0.0/16 | AS64496 | Org A | 253 | 10.1.0.0/20 | AS64499 | Org A | 254 +---------------------------------------------+ 256 The issuing party would create the following RPKI objects: TBC 258 3.4. Sub-allocation to multi-homed customer 260 An organisation (Org A with ASN 64496) has been allocated the prefix 261 10.1.0.0/16, it wishes to announce the more specific prefix 262 10.1.0.0/20 from ASN 64496. It has further delegated 10.1.16.0/20 to 263 a customer (Org B with ASN 64511) who is multi-homed and will 264 originate the route prefix route from ASN 64511. ASN 64496 will also 265 announce the aggregate route to the Internet routing system such that 266 relying parties interpret the routes as valid. 268 The resulting valid announcements (and organisation) would be: 270 +---------------------------------------------+ 271 | Prefix | Origin AS |Organisation | 272 +---------------------------------------------+ 273 | 10.1.0.0/16 | AS64496 | Org A | 274 | 10.1.0.0/20 | AS64496 | Org A | 275 | 10.1.16.0/20 | AS64511 | Org B | 276 +---------------------------------------------+ 278 The issuing parties would create the following RPKI objects: TBC 280 3.5. Restriction of new allocation 282 An organisation has recently been allocated the prefix 10.1.0.0/16. 283 Its network deployment is not yet ready to announce the prefix and 284 wishes to restrict all possible announcements of 10.1.0.0/16 and more 285 specifics in routing using RPKI. 287 The following announcements would be considered invalid: 289 +---------------------------------------------+ 290 | Prefix | Origin AS |Organisation | 291 +---------------------------------------------+ 292 | 10.1.0.0/16 | ANY AS | ANY | 293 | 10.1.0.0/20 | ANY AS | ANY | 294 | 10.1.17.0/24 | ANY AS | ANY | 295 +---------------------------------------------+ 297 The issuing party would create the following RPKI objects: TBC 299 3.6. Restriction of new ASN 301 An organisation has recently been allocated an additional 4 byte ASN 302 65551. Its network deployment is not yet ready to use this ASN and 303 wishes to restrict all possible uses of ASN 65551 using RPKI. 305 The following announcements would be considered invalid: 307 +---------------------------------------------+ 308 | Prefix | Origin AS |Organisation | 309 +---------------------------------------------+ 310 | ANY | AS65551 | ANY | 311 +---------------------------------------------+ 313 The issuing party would create the following RPKI objects: TBC 315 3.7. Restriction of part of allocation 317 An organisation (Org A with ASN 64496) has been allocated the prefix 318 10.1.0.0/16. Its network topology permits the announcement of 319 10.1.0.0/17 and the /16 aggregate however it wishes to restrict any 320 possible announcement of 10.1.128.0/17 or more specifics of that /17 321 using RPKI. 323 The resulting valid announcements would be: 325 +---------------------------------------------+ 326 | Prefix | Origin AS |Organisation | 327 +---------------------------------------------+ 328 | 10.1.0.0/16 | AS64496 | Org A | 329 | 10.1.0.0/17 | AS64496 | Org A | 330 +---------------------------------------------+ 332 The following announcements would be considered invalid: 334 +---------------------------------------------+ 335 | Prefix | Origin AS |Organisation | 336 +---------------------------------------------+ 337 | 10.1.128.0/17 | ANY AS | ANY | 338 | 10.1.128.0/24 | ANY AS | ANY | 339 +---------------------------------------------+ 341 The issuing party would create the following RPKI objects: TBC 343 3.8. Restriction of prefix length 345 An organization (Org A with ASN 64496) has been allocated the prefix 346 10.1.0.0/16, it wishes to announce the aggregate and any or all more 347 specific prefixes up to and including a maximum length of /20, but 348 never any more specific than a /20. 350 Examples of the resulting valid announcements (and organisation) 351 would be: 353 +---------------------------------------------+ 354 | Prefix | Origin AS |Organisation | 355 +---------------------------------------------+ 356 | 10.1.0.0/16 | AS64496 | Org A | 357 | 10.1.0.0/17 | AS64496 | Org A | 358 | ... | AS64496 | Org A | 359 | 10.1.128.0/20 | AS64496 | Org A | 360 +---------------------------------------------+ 362 The following announcements would be considered invalid: 364 +---------------------------------------------+ 365 | Prefix | Origin AS |Organisation | 366 +---------------------------------------------+ 367 | 10.1.0.0/21 | ANY AS | ANY | 368 | 10.1.0.0/22 | ANY AS | ANY | 369 | ... | ANY AS | ANY | 370 | 10.1.128.0/24 | ANY AS | ANY | 371 +---------------------------------------------+ 373 The issuing party would create the following RPKI objects: TBC 375 3.9. Restriction of sub-allocation prefix length 377 An organization (Org A with ASN 64496) has been allocated the prefix 378 10.1.0.0/16, it sub-allocates several /20 prefixes to its multi-homed 379 customers Org B with ASN 65551, and Org C with ASN 64499. It wishes 380 to restrict those customers from advertising any corresponding routes 381 more specific than a /22. 383 The resulting valid announcements would be: 385 +---------------------------------------------+ 386 | Prefix | Origin AS |Organisation | 387 +---------------------------------------------+ 388 | 10.1.0.0/16 | AS64496 | Org A | 389 | 10.1.0.0/20 | AS65551 | Org B | 390 | 10.1.128.0/20 | AS64499 | Org C | 391 | 10.1.4.0/22 | AS65551 | Org B 392 +---------------------------------------------+ 394 The following example announcements (and organisation) would be 395 considered invalid: 397 +---------------------------------------------+ 398 | Prefix | Origin AS |Organisation | 399 +---------------------------------------------+ 400 | 10.1.0.0/24 | AS65551 | Org B | 401 | 10.1.128.0/24 | AS64499 | Org C | 402 | ..... | ... | ... | 403 | 10.1.0.0/23 | ANY AS | ANY | 404 +---------------------------------------------+ 406 The issuing party would create the following RPKI objects: TBC 408 3.10. Permitted Aggregation and origination by an upstream 410 Consider four organisations with the following resources which were 411 acquired independently from any transit provider. 413 +-------------------------------------------------+ 414 | Organisation | ASN | Prefix | 415 +-------------------------------------------------+ 416 | Org A | AS64496 | 10.1.0.0/24 | 417 | Org B | AS65551 | 10.1.3.0/24 | 418 | Org C | AS64499 | 10.1.1.0/24 | 419 | Org D | AS64512 | 10.1.2.0/24 | 420 +-------------------------------------------------+ 422 Thes organisations share a common upstream provider Transit A (ASN 423 64497) that originates an aggregate of these prefixes with the 424 permission of all four organisations. 426 The resulting valid announcements (and organisation) would be: 428 +----------------------------------------------+ 429 | Prefix | Origin AS | Organisation | 430 +----------------------------------------------+ 431 | 10.1.0.0/24 | AS64496 | Org A | 432 | 10.1.3.0/24 | AS65551 | Org B | 433 | 10.1.1.0/24 | AS64499 | Org C | 434 | 10.1.2.0/24 | AS64512 | Org D | 435 | 10.1.0.0/22 | AS64497 | Transit A | 436 +----------------------------------------------+ 438 The issuing parties would create the following RPKI objects: TBC 440 3.11. Rogue Aggregation and origination by an upstream 442 Consider four organisations with the following resources which were 443 acquired independently from any transit provider. 445 +-------------------------------------------------+ 446 | Organisation | ASN | Prefix | 447 +-------------------------------------------------+ 448 | Org A | AS64496 | 10.1.0.0/24 | 449 | Org B | AS65551 | 10.1.3.0/24 | 450 | Org C | AS64499 | 10.1.1.0/24 | 451 | Org D | AS64512 | 10.1.2.0/24 | 452 +-------------------------------------------------+ 454 These organisations share a common upstream provider Transit A (ASN 455 64497) that originates an aggregate of these prefixes where possible. 456 Org B (ASN 65551, 10.1.3.0/24) does not wish for its prefix to be 457 aggregated by any upstream 459 The resulting valid announcements (and organisation) would be: 461 +----------------------------------------------+ 462 | Prefix | Origin AS | Organisation | 463 +----------------------------------------------+ 464 | 10.1.0.0/24 | AS64496 | Org A | 465 | 10.1.3.0/24 | AS65551 | Org B | 466 | 10.1.1.0/24 | AS64499 | Org C | 467 | 10.1.2.0/24 | AS64512 | Org D | 468 | 10.1.0.0/23 | AS64497 | Transit A | 469 +----------------------------------------------+ 471 The following announcement would be invalid: 473 +----------------------------------------------+ 474 | Prefix | Origin AS | Organisation | 475 +----------------------------------------------+ 476 | 10.1.0.0/22 | AS64497 | Transit A | 477 +----------------------------------------------+ 479 The issuing parties would create the following RPKI objects: TBC 481 4. Adjacency use cases 483 Issues regarding validation of adjacency, or path validation, are 484 currently out of scope of the SIDR-WG charter. The use cases is this 485 section are listed here as a reminder that the work goes beyond 486 origination and at the stage when origination has been addressed by 487 the WG, a re-charter to encompass adjacency will allow consideration 488 of these use cases. 490 4.1. Multi-homed 492 An organisation (Org A with ASN 64496) has been allocated the prefix 493 10.1.0.0/16. Its upstreams transit providers are Transit A with ASN 494 65551 and Transit B ASN 64499. The organisation announces the /16 495 aggregate. It permits that ASN 65551 and ASN 64499 may further pass 496 on the aggregate route to their peers or upstreams. 498 The following announcements and paths would be considered valid: 500 +---------------------------------------------------------+ 501 | Prefix | Origin AS | Path | 502 +---------------------------------------------------------+ 503 | 10.1.0.0/16 | AS64496 | AS64499 AS64496 | 504 | 10.1.0.0/16 | AS64496 | AS65551 AS64496 | 505 +---------------------------------------------------------+ 507 The issuing parties would create the following RPKI objects: TBC 509 4.2. Restricting peers 511 An organisation (Org A with ASN 64496) has been allocated the prefix 512 10.1.0.0/16. Its two upstreams are Transit A with ASN 65551 and 513 Transit B with ASN 64499. The organisation (ASN 64496) peers with a 514 third AS, Peer A with ASN 64511. Org A announces the more specific 515 10.1.0.0/24 and the /16 aggregate. It wishes that only ASNs 65551 516 and 64499 may announce the aggregate and more specifics to their 517 upstreams. ASN 64511, the peer, may not further announce (pass on, 518 or leak) any routes for 10.1.0.0/16 and 10.1.0.0/24. 520 The following announcements and paths would be considered valid: 522 +---------------------------------------------------------+ 523 | Prefix | Origin AS | Path | 524 +---------------------------------------------------------+ 525 | 10.1.0.0/16 | AS64496 | AS64499 AS64496 | 526 | 10.1.0.0/24 | AS64496 | AS64499 AS64496 | 527 | 10.1.0.0/16 | AS64496 | AS65551 AS64496 | 528 | 10.1.0.0/24 | AS64496 | AS65551 AS64496 | 529 | 10.1.0.0/16 | AS64496 | Any_AS AS64499 AS64496 | 530 | 10.1.0.0/24 | AS64496 | Any_AS AS64499 AS64496 | 531 | 10.1.0.0/16 | AS64496 | Any_AS AS65551 AS64496 | 532 | 10.1.0.0/24 | AS64496 | Any_AS AS65551 AS64496 | 533 | 10.1.0.0/16 | AS64496 | AS64511 AS64496 | 534 | 10.1.0.0/24 | AS64496 | AS64511 AS64496 | 535 +---------------------------------------------------------+ 537 The following announcements and paths would be considered invalid: 539 +---------------------------------------------------------+ 540 | Prefix | Origin AS | Path | 541 +---------------------------------------------------------+ 542 | 10.1.0.0/16 | AS64496 | Any_AS AS64511 AS64496 | 543 | 10.1.0.0/24 | AS64496 | Any_AS AS64511 AS64496 | 544 +---------------------------------------------------------+ 546 The issuing parties would create the following RPKI objects: TBC 548 5. Partial Deployment use cases 550 5.1. Parent does not do RPKI 552 An organisation (Org A with ASN 64511) is multi-homed has been 553 assigned the prefix 10.1.0.0/20 from its upstream (Transit A with ASN 554 64496) Org A wishes to announce the prefix 10.1.0.0/20 from ASN 64511 555 to its other upstream(s). Org A also wishes to create RPKI 556 statements about the resource, however Transit A (ASN 64496) which 557 announces the aggregate 10.1.0.0/16 has not yet adopted RPKI. 559 The resulting valid announcements (and organisation with RPKI 560 adoption) would be: 562 +----------------------------------------------------+ 563 | Prefix | Origin AS |Organisation | RPKI | 564 +----------------------------------------------------+ 565 | 10.1.0.0/20 | AS64511 | Org A | Yes | 566 | 10.1.0.0/16 | AS64496 | Transit A | No | 567 +----------------------------------------------------+ 569 The issuing parties would create the following RPKI objects: TBC 571 5.2. Only some children participate 573 An organisation (Org A with ASN 64496) has been allocated the prefix 574 10.1.0.0/16 and participates in RPKI, it wishes to announce the more 575 specific prefix 10.1.0.0/20 from ASN 64496. It has further delegated 576 10.1.16.0/20 and 10.1.32.0/20 to customers Org B with ASN 64511 and 577 and Org C with ASN 65551 (respectively) who are multi-homed. Org B 578 (ASN 64511) does not participate in RPKI. Org C (ASN 65551) 579 participates in RPKI. 581 The resulting valid announcements (and organisation with RPKI 582 adoption) would be: 584 +----------------------------------------------------+ 585 | Prefix | Origin AS |Organisation | RPKI | 586 +----------------------------------------------------+ 587 | 10.1.0.0/16 | AS64496 | Org A | Yes | 588 | 10.1.0.0/20 | AS64496 | Org A | Yes | 589 | 10.1.16.0/20 | AS64511 | Org B | No | 590 | 10.1.32.0/20 | AS65551 | Org C | YES | 591 +----------------------------------------------------+ 593 The issuing parties would create the following RPKI objects: TBC 595 5.3. Grandchild allocations 597 Consider the previous example with an extension by where Org B, who 598 does not participate in RPKI, further allocates 10.1.17.0/24 to Org X 599 with ASN 64512. 601 The resulting valid announcements (and organisation with RPKI 602 adoption) would be: 604 +----------------------------------------------------+ 605 | Prefix | Origin AS |Organisation | RPKI | 606 +----------------------------------------------------+ 607 | 10.1.0.0/16 | AS64496 | Org A | Yes | 608 | 10.1.0.0/20 | AS64496 | Org A | Yes | 609 | 10.1.16.0/20 | AS64511 | Org B | No | 610 | 10.1.32.0/20 | AS65551 | Org C | YES | 611 | 10.1.17.0/24 | AS64512 | Org X | No | 612 +----------------------------------------------------+ 614 The issuing parties would create the following RPKI objects: TBC 616 6. Transfer use cases 618 6.1. Transfer of in-use prefix and autonomous system number 620 Organisation A holds the resource 10.1.0.0/20 and is currently is use 621 and originated from AS64496 with valid RPKI objects in place. 622 Organisation B has acquired these resources and desires an RPKI 623 transfer on a particular date and time without adversely affecting 624 the operational use of the resource. 626 The following RPKI objects would be created/revoked: TBC 628 6.2. Transfer of in-use prefix 630 Organisation A holds the resource 10.1.0.0/8 and it is currently is 631 use and originated from AS64496 with valid RPKI objects in place. 632 Organisation B has acquired this resource and desires an RPKI 633 transfer on a particular date and time with the additional change of 634 originating the prefix from AS65551. 636 The following RPKI objects would be created/revoked: TBC 638 6.3. Transfer of un-used prefix 640 Organisation A holds the resource 10.1.0.0/8 (with RPKI objects). 641 Organisation B has acquired an unused portion of the resource 642 (10.1.4.0/24) and desires an RPKI transfer on a particular date and 643 time. 645 The following RPKI objects would be created/revoked: TBC 647 7. Relying Party use cases 649 7.1. Use Cases Related to ROA Expiry or receipt of a CRL covering a ROA 651 Note: In the cases which follow the terms "expired ROA" or "revoked 652 ROA" are shorthand, and describe the appropriate revocation or expiry 653 of EE or Resource Certificates which result in the RPKI invalidation 654 of a ROA. 656 7.1.1. ROA of Parent Prefix is Revoked 658 A revocation certificate list (CRL) is received which reveals that 659 the ROA containing the prefix 10.1.0.0/16; maxLength 24 with ASN64496 660 is revoked. Further, a prefix route exists in the Internet routing 661 system for 10.1.4.0/24 originated from ASN64496. 663 Note: Parent prefix here simply means a less specific prefix. 665 The Relying Party interpretation would be: TBC 667 7.1.2. ROA of Prefix Revoked 669 A CRL is received which reveals that the ROA containing the prefix 670 10.1.4.0/24; maxLength 24 with ASN64496 is revoked. Further, a 671 prefix route exists in the Internet routing system for 10.1.4.0/24 672 originated from ASN64496. 674 The Relying Party interpretation would be: TBC 676 A Counter Example: If there was a valid ROA containing the (less 677 specific) prefix 10.1.0.0/20; maxLength 24 with ASN64496. 679 The Relying Party interpretation would be: TBC 681 7.1.3. ROA of Grandparent Prefix Revoked while that of Parent Prefix 682 Prevails 684 A CRL is received which reveals that the ROA containing the prefix 685 10.1.0.0/16; maxLength 24 with ASN64496 is revoked. Further, a 686 prefix route exists in the Internet routing system for 10.1.4.0/24 687 originated from ASN64496. Additionally, the current ROA list has a 688 valid ROA containing the prefix 10.1.0.0/20; maxLength 24 with 689 ASN64496. 691 The Relying Party interpretation would be: TBC 693 (Clarification: ROA for less specific grandparent prefix 10.1.0.0/16 694 was withdrawn) 696 The Relying Party interpretation would be: TBC 698 7.1.4. ROA of Prefix Revoked while that of Parent Prefix Prevails 700 A CRL is received which reveals that the ROA containing the prefix 701 10.1.4.0/24; maxLength 24 with ASN64496 is revoked. Further, a 702 prefix route exists in the Internet routing system for 10.1.4.0/24 703 originated from ASN64496. Additionally, the current ROA list has a 704 valid ROA containing the prefix 10.1.0.0/20; maxLength 24 with 705 ASN64496. 707 The Relying Party interpretation would be: TBC 709 (Clarification: Perhaps the revocation of ROA for prefix 10.1.4.0/24 710 was initiated just to eliminate redundancy) 712 7.1.5. Expiry of ROA of Parent Prefix 714 A scan of the ROA list reveals that the ROA containing the prefix 715 10.1.0.0/16; maxLength 24 with ASN64496 has expired. Further, a 716 prefix route exists in the Internet routing system for 10.1.4.0/24 717 originated from ASN64496. 719 The Relying Party interpretation would be: TBC 721 7.1.6. Expiry of ROA of Prefix 723 A scan of the ROA list reveals that the ROA containing the prefix 724 10.1.4.0/24; maxLength 24 with ASN64496 has expired. Further, a 725 prefix route exists in the Internet routing system for 10.1.4.0/24 726 originated from ASN64496. 728 The Relying Party interpretation would be: TBC 730 7.1.7. Expiry of ROA of Grandparent Prefix while ROA of Parent Prefix 731 Prevails 733 A scan of the ROA list reveals that the ROA containing the prefix 734 10.1.0.0/16; maxLength 24 with ASN64496 has expired. Further, a 735 prefix route exists in the Internet routing system for 10.1.4.0/24 736 originated from ASN64496. Additionally, the current ROA list has a 737 valid ROA containing the prefix 10.1.0.0/20; maxLength 24 with 738 ASN64496. 740 The Relying Party interpretation would be: TBC 742 (Clarification: ROA for less specific grandparent prefix 10.1.0.0/16 743 expired.) 745 7.1.8. Expiry of ROA of Prefix while ROA of Parent Prefix Prevails 747 A scan of the ROA list reveals that the ROA containing the prefix 748 10.1.4.0/24; maxLength 24 with ASN64496 has expired. Further, a 749 prefix route exists in the Internet routing system for 10.1.4.0/24 750 originated from ASN64496. Additionally, the current ROA list has a 751 valid ROA containing the prefix 10.1.0.0/20; maxLength 24 with 752 ASN64496. 754 The Relying Party interpretation would be: TBC 756 (Clarification: Perhaps the expiry of the ROA for prefix 10.1.4.0/24 757 was meant to eliminate redundancy.) 759 8. Acknowledgements 761 The authors are indebted to both Sandy Murphy and Sam Weiler for 762 their guidance. Further, the authors would like to thank Curtis 763 Villamizar and Danny McPherson for technical insight. 765 9. IANA Considerations 767 This memo includes no request to IANA. 769 10. Security Considerations 771 This memo requires no security considerations 773 11. Normative References 775 [I-D.ietf-sidr-arch] 776 Lepinski, M. and S. Kent, "An Infrastructure to Support 777 Secure Internet Routing", draft-ietf-sidr-arch-08 (work in 778 progress), July 2009. 780 [I-D.ietf-sidr-bogons] 781 Manderson, T., "A Profile for Bogon Origin Attestations 782 (BOAs)", draft-ietf-sidr-bogons-03 (work in progress), 783 May 2009. 785 [I-D.ietf-sidr-res-certs] 786 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 787 X.509 PKIX Resource Certificates", 788 draft-ietf-sidr-res-certs-17 (work in progress), 789 September 2009. 791 [I-D.ietf-sidr-roa-format] 792 Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 793 Origin Authorizations (ROAs)", 794 draft-ietf-sidr-roa-format-05 (work in progress), 795 July 2009. 797 [I-D.ietf-sidr-roa-validation] 798 Huston, G. and G. Michaelson, "Validation of Route 799 Origination in BGP using the Resource Certificate PKI and 800 ROAs", draft-ietf-sidr-roa-validation-03 (work in 801 progress), August 2009. 803 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 804 Addresses and AS Identifiers", RFC 3779, June 2004. 806 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 807 RFC 3852, July 2004. 809 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 810 Algorithms and Identifiers for RSA Cryptography for use in 811 the Internet X.509 Public Key Infrastructure Certificate 812 and Certificate Revocation List (CRL) Profile", RFC 4055, 813 June 2005. 815 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 816 Protocol 4 (BGP-4)", RFC 4271, January 2006. 818 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 819 Number Space", RFC 4893, May 2007. 821 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 822 Housley, R., and W. Polk, "Internet X.509 Public Key 823 Infrastructure Certificate and Certificate Revocation List 824 (CRL) Profile", RFC 5280, May 2008. 826 Authors' Addresses 828 Terry Manderson 829 ICANN 831 Email: terry.manderson@icann.org 833 Kotikalapudi Sriram 834 NIST 836 Email: ksriram@nist.gov 838 Russ White 839 Cisco 841 Email: russ@cisco.com