idnits 2.17.00 (12 Aug 2021) /tmp/idnits6909/draft-ietf-sidr-usecases-01.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 : ---------------------------------------------------------------------------- == There are 127 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 (December 22, 2010) is 4167 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3852' is defined on line 1038, but no explicit reference was found in the text == Unused Reference: 'RFC4055' is defined on line 1041, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 1047, but no explicit reference was found in the text == Unused Reference: 'RFC4893' is defined on line 1050, but no explicit reference was found in the text == Outdated reference: draft-ietf-idr-deprecate-as-sets has been published as RFC 6472 == Outdated reference: draft-ietf-sidr-arch has been published as RFC 6480 == Outdated reference: draft-ietf-sidr-res-certs has been published as RFC 6487 == Outdated reference: draft-ietf-sidr-roa-format has been published as RFC 6482 == Outdated reference: draft-ietf-sidr-roa-validation has been published as RFC 6483 ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) ** Obsolete normative reference: RFC 4893 (Obsoleted by RFC 6793) Summary: 2 errors (**), 0 flaws (~~), 12 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: June 25, 2011 US NIST 6 R. White 7 Cisco 8 December 22, 2010 10 Use Cases and interpretation of RPKI objects for issuers and relying 11 parties 12 draft-ietf-sidr-usecases-01 14 Abstract 16 This document provides use cases, directions, and interpretations for 17 organizations and relying parties when creating or encountering RPKI 18 object scenarios in the public RPKI in relation to the Internet 19 routing system. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on June 25, 2011. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 59 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 2.1. General interpretation of RPKI object semantics . . . . . 6 61 3. Origination Use Cases . . . . . . . . . . . . . . . . . . . . 6 62 3.1. Single Announcement . . . . . . . . . . . . . . . . . . . 6 63 3.2. Aggregate with a More Specific . . . . . . . . . . . . . . 6 64 3.3. Aggregate with a More Specific from a Different ASN . . . 7 65 3.4. Sub-allocation to a Multi-homed Customer . . . . . . . . . 7 66 3.5. Restriction of a New Allocation . . . . . . . . . . . . . 8 67 3.6. Restriction of New ASN . . . . . . . . . . . . . . . . . . 8 68 3.7. Restriction of a Part of an Allocation . . . . . . . . . . 9 69 3.8. Restriction of Prefix Length . . . . . . . . . . . . . . . 9 70 3.9. Restriction of Sub-allocation Prefix Length . . . . . . . 10 71 3.10. Aggregation and Origination by an Upstream . . . . . . . . 10 72 3.11. Rogue Aggregation and Origination by an Upstream . . . . . 11 73 4. Adjacency Use Cases . . . . . . . . . . . . . . . . . . . . . 12 74 4.1. Multi-homed . . . . . . . . . . . . . . . . . . . . . . . 12 75 4.2. Restricting Peers . . . . . . . . . . . . . . . . . . . . 13 76 5. Partial Deployment Use Cases . . . . . . . . . . . . . . . . . 13 77 5.1. Parent does not do RPKI . . . . . . . . . . . . . . . . . 13 78 5.2. Only Some Children Participate in RPKI . . . . . . . . . . 14 79 5.3. Grandchild Does Not Participate in RPKI . . . . . . . . . 14 80 6. Transfer Use Cases . . . . . . . . . . . . . . . . . . . . . . 15 81 6.1. Transfer of in-use prefix and autonomous system number . . 15 82 6.2. Transfer of in-use prefix . . . . . . . . . . . . . . . . 15 83 6.3. Transfer of un-used prefix . . . . . . . . . . . . . . . . 15 84 7. Relying Party Use Cases . . . . . . . . . . . . . . . . . . . 16 85 7.1. ROA Expiry or receipt of a CRL covering a ROA . . . . . . 16 86 7.1.1. ROA of Parent Prefix is Revoked . . . . . . . . . . . 16 87 7.1.2. ROA of Prefix Revoked . . . . . . . . . . . . . . . . 16 88 7.1.3. ROA of Grandparent Prefix Revoked while that of 89 Parent Prefix Prevails . . . . . . . . . . . . . . . . 16 90 7.1.4. ROA of Prefix Revoked while that of Parent Prefix 91 Prevails . . . . . . . . . . . . . . . . . . . . . . . 17 92 7.1.5. Expiry of ROA of Parent Prefix . . . . . . . . . . . . 17 93 7.1.6. Expiry of ROA of Prefix . . . . . . . . . . . . . . . 17 94 7.1.7. Expiry of ROA of Grandparent Prefix while ROA of 95 Parent Prefix Prevails . . . . . . . . . . . . . . . . 17 97 7.1.8. Expiry of ROA of Prefix while ROA of Parent Prefix 98 Prevails . . . . . . . . . . . . . . . . . . . . . . . 18 99 7.2. Prefix, Origin Validation use cases . . . . . . . . . . . 18 100 7.2.1. Covering ROA Prefix, maxLength Satisfied, and AS 101 Match . . . . . . . . . . . . . . . . . . . . . . . . 18 102 7.2.2. Covering ROA Prefix, maxLength Exceeded, and AS 103 Match . . . . . . . . . . . . . . . . . . . . . . . . 18 104 7.2.3. Covering ROA Prefix, maxLength Satisfied, and AS 105 Mismatch: . . . . . . . . . . . . . . . . . . . . . . 19 106 7.2.4. Covering ROA Prefix, maxLength Exceeded, and AS 107 Mismatch . . . . . . . . . . . . . . . . . . . . . . . 19 108 7.2.5. Covering ROA Prefix Not Found . . . . . . . . . . . . 19 109 7.2.6. Covering ROA Prefix Not Found but ROAs Exist for a 110 Covering Set of More Specifics . . . . . . . . . . . . 20 111 7.2.7. AS_SET in Update and Covering ROA Prefix Not Found . . 20 112 7.2.8. Singleton AS in AS_SET (in the Update), Covering 113 ROA Prefix, and AS Match . . . . . . . . . . . . . . . 20 114 7.2.9. Singleton AS in AS_SET (in the Update), Covering 115 ROA Prefix, and AS Mismatch . . . . . . . . . . . . . 21 116 7.2.10. Multiple ASs in AS_SET (in the Update) and 117 Covering ROA Prefix . . . . . . . . . . . . . . . . . 21 118 7.2.11. Update has an AS_SET as Origin and ROAs Exist for 119 a Covering Set of More Specifics . . . . . . . . . . . 21 120 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 121 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 122 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 123 11. Normative References . . . . . . . . . . . . . . . . . . . . . 22 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 126 1. Introduction 128 This document provides suggested use cases, directions, and 129 interpretations for organizations and relying parties when creating 130 or encountering RPKI object scenarios in the public RPKI in relation 131 to the Internet routing system. 133 1.1. Terminology 135 It is assumed that the reader is familiar with the terms and concepts 136 described in "Internet X.509 Public Key Infrastructure Certificate 137 and Certificate Revocation List (CRL) Profile" [RFC5280], "A Profile 138 for X.509 PKIX Resource Certificates" [I-D.ietf-sidr-res-certs] 139 "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779], "A 140 Profile for Route Origin Authorizations (ROAs)" 141 [I-D.ietf-sidr-roa-format], "Validation of Route Origination in BGP 142 using the Resource Certificate PKI and ROAs" 143 [I-D.ietf-sidr-roa-validation], and BGP Prefix Origin Validation" 144 [I-D.pmohapat-sidr-pfx-validate]. 146 1.2. Definitions 148 The following definitions are in use in this document. 150 Autonomous System - A network under a single technical administration 151 that presents a consistent picture of what destinations are reachable 152 through it. 154 Autonomous System Number (ASN) - An officially registered number 155 representing an autonomous system. 157 Prefix - A network address and an integer that specifies the length 158 of a mask to be applied to the address to represent a set of 159 numerically adjacent addresses. 161 Route - A prefix and a sequence of one or more autonomous system 162 numbers. 164 Origin AS - The Autonomous System, designated by an ASN, which 165 originates a route. Seen as the "First" ASN in a route. 167 Specific route - A route that has a longer prefix than an aggregate. 169 Aggregate route - A more general route in the presence of a specific 170 route. 172 Covering Aggregate - A route that covers one or more specific routes. 174 Multi-homed Autonomous System - An Autonomous System that is 175 connected, and announces routes, to two or more Autonomous Systems. 177 Multi-homed prefix or subnet - A prefix (i.e., subnet) that is 178 originated via two or more Autonomous Systems to which the subnet is 179 connected. 181 Resource - Internet (IP) addresses or Autonomous System Number. 183 Allocation - The set of resources provided to an entity or 184 organization for its use. 186 Sub-allocation - The set of a resources subordinate to an allocation 187 assigned to another entity or organization. 189 Transit Provider - An Autonomous System that carries traffic that 190 neither originates nor is the destination of that traffic. 192 Upstream - See "Transit Provider". 194 Child - A Sub-allocation that has resulted from an Allocation. 196 Parent - An allocation from which the subject prefix is a Child. 198 Grandchild - A Sub-allocation from one or more previous Sub- 199 allocations. 201 Grandparent - The allocation from which the prefix is a Grandchild. 203 Update prefix - The prefix seen in a routing update. 205 ROA prefix - The prefix described in a ROA. 207 Covering Prefix - The ROA Prefix is an exact match or a less specific 208 when compared to the update prefix. 210 No relevant ROA - No ROA exists that has a covering prefix for the 211 update prefix. 213 No other relevant ROA - No other ROA (besides any that is(are) 214 already cited) that has a covering prefix for the update prefix. 216 1.3. Requirements Language 218 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 219 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 220 document are to be interpreted as described in RFC 2119. 222 2. Overview 224 2.1. General interpretation of RPKI object semantics 226 It is important that in the interpretation of relying parties (RP), 227 or relying party routing software, that a 'make before break' stance 228 is applied. This means that a RP should implement a routing decision 229 process where a routing update ("route") is assumed to be intended 230 unless proven otherwise by the existence of a valid RPKI object. For 231 all of the cases in this document it is assumed that RPKI objects 232 validate (or otherwise) in accordance with [I-D.ietf-sidr-res-certs], 233 [I-D.ietf-sidr-arch], [I-D.ietf-sidr-roa-validation] unless otherwise 234 stated. 236 While many of the examples provided here illustrate organizations 237 using their own autonomous system numbers to originate routes, it 238 should be recognised that a prefix holder need not necessarily be the 239 holder of the autonomous system number used for the route 240 origination. 242 3. Origination Use Cases 244 This section deals with the various use cases where an organization 245 has Internet resources and will announce routes to the Internet. It 246 is based on operational observations of the existing routing system. 248 3.1. Single Announcement 250 An organization (Org A with ASN 64496) has been allocated the prefix 251 192.168.2.0/24. It wishes to announce the /24 prefix from ASN 64496 252 such that relying parties interpret the route as intended. 254 The desired announcement (and organization) would be: 256 +----------------------------------------------+ 257 | Prefix | Origin AS | Organization | 258 +----------------------------------------------+ 259 | 192.168.2.0/24 | AS64496 | Org A | 260 +----------------------------------------------+ 262 The issuing party would create the following RPKI objects: TBC 264 3.2. Aggregate with a More Specific 266 An organization (Org A with ASN 64496) has been allocated the prefix 267 10.1.0.0/16. It wishes to announce the more specific prefix 268 10.1.0.0/20 from ASN 64496 as well as the aggregate route such that 269 relying parties interpret the routes as intended. 271 The desired announcements (and organization) would be: 273 +----------------------------------------------+ 274 | Prefix | Origin AS | Organization | 275 +----------------------------------------------+ 276 | 10.1.0.0/16 | AS64496 | Org A | 277 | 10.1.0.0/20 | AS64496 | Org A | 278 +----------------------------------------------+ 280 The issuing party would create the following RPKI objects: TBC 282 3.3. Aggregate with a More Specific from a Different ASN 284 An organization (Org A with ASN 64496 and ASN 64499) has been 285 allocated the prefix 10.1.0.0/16. It wishes to announce the more 286 specific prefix 10.1.0.0/20 from ASN 64499 as well as the aggregate 287 route from ASN 64496 such that relying parties interpret the routes 288 as intended. 290 The desired announcements (and organization) would be: 292 +---------------------------------------------+ 293 | Prefix | Origin AS |Organization | 294 +---------------------------------------------+ 295 | 10.1.0.0/16 | AS64496 | Org A | 296 | 10.1.0.0/20 | AS64499 | Org A | 297 +---------------------------------------------+ 299 The issuing party would create the following RPKI objects: TBC 301 3.4. Sub-allocation to a Multi-homed Customer 303 An organization (Org A with ASN 64496) has been allocated the prefix 304 10.1.0.0/16, it wishes to announce the more specific prefix 305 10.1.0.0/20 from ASN 64496. It has further delegated 10.1.16.0/20 to 306 a customer (Org B with ASN 64511) who is multi-homed and will 307 originate the prefix route from ASN 64511. ASN 64496 will also 308 announce the aggregate route such that relying parties interpret the 309 routes as intended. 311 The desirable announcements (and organization) would be: 313 +---------------------------------------------+ 314 | Prefix | Origin AS |Organization | 315 +---------------------------------------------+ 316 | 10.1.0.0/16 | AS64496 | Org A | 317 | 10.1.0.0/20 | AS64496 | Org A | 318 | 10.1.16.0/20 | AS64511 | Org B | 319 +---------------------------------------------+ 321 The issuing parties would create the following RPKI objects: TBC 323 3.5. Restriction of a New Allocation 325 An organization has recently been allocated the prefix 10.1.0.0/16. 326 Its network deployment is not yet ready to announce the prefix and 327 wishes to restrict all possible announcements of 10.1.0.0/16 and more 328 specifics in routing using RPKI. 330 The following announcements would be considered undesirable: 332 +---------------------------------------------+ 333 | Prefix | Origin AS |Organization | 334 +---------------------------------------------+ 335 | 10.1.0.0/16 | ANY AS | ANY | 336 | 10.1.0.0/20 | ANY AS | ANY | 337 | 10.1.17.0/24 | ANY AS | ANY | 338 +---------------------------------------------+ 340 The issuing party would create the following RPKI objects: TBC 342 3.6. Restriction of New ASN 344 An organization has recently been allocated an additional 4 byte ASN 345 65535. Its network deployment is not yet ready to use this ASN and 346 wishes to restrict all possible uses of ASN 65535 using RPKI. 348 The following announcements would be considered undesirable: 350 +---------------------------------------------+ 351 | Prefix | Origin AS |Organization | 352 +---------------------------------------------+ 353 | ANY | AS65535 | ANY | 354 +---------------------------------------------+ 356 The issuing party would create the following RPKI objects: TBC 358 3.7. Restriction of a Part of an Allocation 360 An organization (Org A with ASN 64496) has been allocated the prefix 361 10.1.0.0/16. Its network topology permits the announcement of 362 10.1.0.0/17 and the /16 aggregate. However it wishes to restrict any 363 possible announcement of 10.1.128.0/17 or more specifics of that /17 364 using RPKI. 366 The desired announcements would be: 368 +---------------------------------------------+ 369 | Prefix | Origin AS |Organization | 370 +---------------------------------------------+ 371 | 10.1.0.0/16 | AS64496 | Org A | 372 | 10.1.0.0/17 | AS64496 | Org A | 373 +---------------------------------------------+ 375 The following announcements would be considered undesirable: 377 +---------------------------------------------+ 378 | Prefix | Origin AS |Organization | 379 +---------------------------------------------+ 380 | 10.1.128.0/17 | ANY AS | ANY | 381 | 10.1.128.0/24 | ANY AS | ANY | 382 +---------------------------------------------+ 384 The issuing party would create the following RPKI objects: TBC 386 3.8. Restriction of Prefix Length 388 An organization (Org A with ASN 64496) has been allocated the prefix 389 10.1.0.0/16, it wishes to announce the aggregate and any or all more 390 specific prefixes up to and including a maximum length of /20, but 391 never any more specific than a /20. 393 Examples of the desired announcements (and organization) would be: 395 +---------------------------------------------+ 396 | Prefix | Origin AS |Organization | 397 +---------------------------------------------+ 398 | 10.1.0.0/16 | AS64496 | Org A | 399 | 10.1.0.0/17 | AS64496 | Org A | 400 | ... | AS64496 | Org A | 401 | 10.1.128.0/20 | AS64496 | Org A | 402 +---------------------------------------------+ 404 The following announcements would be considered undesirable: 406 +---------------------------------------------+ 407 | Prefix | Origin AS |Organization | 408 +---------------------------------------------+ 409 | 10.1.0.0/21 | ANY AS | ANY | 410 | 10.1.0.0/22 | ANY AS | ANY | 411 | ... | ANY AS | ANY | 412 | 10.1.128.0/24 | ANY AS | ANY | 413 +---------------------------------------------+ 415 The issuing party would create the following RPKI objects: TBC 417 3.9. Restriction of Sub-allocation Prefix Length 419 An organization (Org A with ASN 64496) has been allocated the prefix 420 10.1.0.0/16, it sub-allocates several /20 prefixes to its multi-homed 421 customers Org B with ASN 65535, and Org C with ASN 64499. It wishes 422 to restrict those customers from advertising any corresponding routes 423 more specific than a /22. 425 The desired announcements would be: 427 +---------------------------------------------+ 428 | Prefix | Origin AS |Organization | 429 +---------------------------------------------+ 430 | 10.1.0.0/16 | AS64496 | Org A | 431 | 10.1.0.0/20 | AS65535 | Org B | 432 | 10.1.128.0/20 | AS64499 | Org C | 433 | 10.1.4.0/22 | AS65535 | Org B 434 +---------------------------------------------+ 436 The following example announcements (and organization) would be 437 considered undesirable: 439 +---------------------------------------------+ 440 | Prefix | Origin AS |Organization | 441 +---------------------------------------------+ 442 | 10.1.0.0/24 | AS65535 | Org B | 443 | 10.1.128.0/24 | AS64499 | Org C | 444 | ..... | ... | ... | 445 | 10.1.0.0/23 | ANY AS | ANY | 446 +---------------------------------------------+ 448 The issuing party would create the following RPKI objects: TBC 450 3.10. Aggregation and Origination by an Upstream 452 Consider four organizations with the following resources, which were 453 acquired independently from any transit provider. . 455 +-------------------------------------------------+ 456 | Organization | ASN | Prefix | 457 +-------------------------------------------------+ 458 | Org A | AS64496 | 10.1.0.0/24 | 459 | Org B | AS65535 | 10.1.3.0/24 | 460 | Org C | AS64499 | 10.1.1.0/24 | 461 | Org D | AS64512 | 10.1.2.0/24 | 462 +-------------------------------------------------+ 464 These organizations share a common upstream provider Transit A (ASN 465 64497) that originates an aggregate of these prefixes with the 466 permission of all four organizations. 468 The desired announcements (and organization) would be: 470 +----------------------------------------------+ 471 | Prefix | Origin AS | Organization | 472 +----------------------------------------------+ 473 | 10.1.0.0/24 | AS64496 | Org A | 474 | 10.1.3.0/24 | AS65535 | Org B | 475 | 10.1.1.0/24 | AS64499 | Org C | 476 | 10.1.2.0/24 | AS64512 | Org D | 477 | 10.1.0.0/22 | AS64497 | Transit A | 478 +----------------------------------------------+ 480 The issuing parties would create the following RPKI objects: TBC 482 3.11. Rogue Aggregation and Origination by an Upstream 484 Consider four organizations with the following resources which were 485 acquired independently from any transit provider. 487 +-------------------------------------------------+ 488 | Organization | ASN | Prefix | 489 +-------------------------------------------------+ 490 | Org A | AS64496 | 10.1.0.0/24 | 491 | Org B | AS65535 | 10.1.3.0/24 | 492 | Org C | AS64499 | 10.1.1.0/24 | 493 | Org D | AS64512 | 10.1.2.0/24 | 494 +-------------------------------------------------+ 496 These organizations share a common upstream provider Transit A (ASN 497 64497) that originates an aggregate of these prefixes where possible. 498 In this situation organization B (ASN 65535, 10.1.3.0/24) does not 499 wish for its prefix to be aggregated by the upstream 501 The desired announcements (and organization) would be: 503 +----------------------------------------------+ 504 | Prefix | Origin AS | Organization | 505 +----------------------------------------------+ 506 | 10.1.0.0/24 | AS64496 | Org A | 507 | 10.1.3.0/24 | AS65535 | Org B | 508 | 10.1.1.0/24 | AS64499 | Org C | 509 | 10.1.2.0/24 | AS64512 | Org D | 510 | 10.1.0.0/23 | AS64497 | Transit A | 511 +----------------------------------------------+ 513 The following announcement would be undesirable: 515 +----------------------------------------------+ 516 | Prefix | Origin AS | Organization | 517 +----------------------------------------------+ 518 | 10.1.0.0/22 | AS64497 | Transit A | 519 +----------------------------------------------+ 521 The issuing parties would create the following RPKI objects: TBC 523 4. Adjacency Use Cases 525 Issues regarding validation of adjacency, or path validation, are 526 currently out of scope of the SIDR-WG charter. The use cases in this 527 section are listed here as a reminder that the work goes beyond 528 origination and at the stage when origination has been addressed by 529 the WG, a re-charter to encompass adjacency will allow consideration 530 of these use cases. 532 4.1. Multi-homed 534 An organization (Org A with ASN 64496) has been allocated the prefix 535 10.1.0.0/16. Its upstream transit providers are Transit A with ASN 536 65535 and Transit B with ASN 64499. The organization announces the 537 /16 aggregate. It permits that ASN 65535 and ASN 64499 may further 538 pass on the aggregate route to their peers or upstreams. 540 The following announcements and paths would be desired: 542 +---------------------------------------------------------+ 543 | Prefix | Origin AS | Path | 544 +---------------------------------------------------------+ 545 | 10.1.0.0/16 | AS64496 | AS64499 AS64496 | 546 | 10.1.0.0/16 | AS64496 | AS65535 AS64496 | 547 +---------------------------------------------------------+ 549 The issuing parties would create the following RPKI objects: TBC 551 4.2. Restricting Peers 553 An organization (Org A with ASN 64496) has been allocated the prefix 554 10.1.0.0/16. Its two upstreams are Transit X with ASN 65535 and 555 Transit Y with ASN 64499. The organization (ASN 64496) peers with a 556 third AS, Peer Z with ASN 64511. Org A announces the more specific 557 10.1.0.0/24 and the /16 aggregate. It wishes that only ASNs 65535 558 and 64499 may announce the aggregate and more specifics to their 559 upstreams. ASN 64511, the peer, may not further announce (pass on, 560 or leak) any routes for 10.1.0.0/16 and 10.1.0.0/24. 562 The following announcements and paths would be desired: 564 +---------------------------------------------------------+ 565 | Prefix | Origin AS | Path | 566 +---------------------------------------------------------+ 567 | 10.1.0.0/16 | AS64496 | AS64499 AS64496 | 568 | 10.1.0.0/24 | AS64496 | AS64499 AS64496 | 569 | 10.1.0.0/16 | AS64496 | AS65535 AS64496 | 570 | 10.1.0.0/24 | AS64496 | AS65535 AS64496 | 571 | 10.1.0.0/16 | AS64496 | Any_AS AS64499 AS64496 | 572 | 10.1.0.0/24 | AS64496 | Any_AS AS64499 AS64496 | 573 | 10.1.0.0/16 | AS64496 | Any_AS AS65535 AS64496 | 574 | 10.1.0.0/24 | AS64496 | Any_AS AS65535 AS64496 | 575 | 10.1.0.0/16 | AS64496 | AS64511 AS64496 | 576 | 10.1.0.0/24 | AS64496 | AS64511 AS64496 | 577 +---------------------------------------------------------+ 579 The following announcements and paths would be considered 580 undesirable: 582 +---------------------------------------------------------+ 583 | Prefix | Origin AS | Path | 584 +---------------------------------------------------------+ 585 | 10.1.0.0/16 | AS64496 | Any_AS AS64511 AS64496 | 586 | 10.1.0.0/24 | AS64496 | Any_AS AS64511 AS64496 | 587 +---------------------------------------------------------+ 589 The issuing parties would create the following RPKI objects: TBC 591 5. Partial Deployment Use Cases 593 5.1. Parent does not do RPKI 595 An organization (Org A with ASN 64511) is multi-homed has been 596 assigned the prefix 10.1.0.0/20 from its upstream (Transit X with ASN 597 64496). Org A wishes to announce the prefix 10.1.0.0/20 from ASN 598 64511 to its other upstream(s). Org A also wishes to create RPKI 599 statements about the resource, however Transit X (ASN 64496) which 600 announces the aggregate 10.1.0.0/16 has not yet adopted RPKI. 602 The desired announcements (and organization with RPKI adoption) would 603 be: 605 +----------------------------------------------------+ 606 | Prefix | Origin AS |Organization | RPKI | 607 +----------------------------------------------------+ 608 | 10.1.0.0/20 | AS64511 | Org A | Yes | 609 | 10.1.0.0/16 | AS64496 | Transit X | No | 610 +----------------------------------------------------+ 612 The issuing parties would create the following RPKI objects: TBC 614 5.2. Only Some Children Participate in RPKI 616 An organization (Org A with ASN 64496) has been allocated the prefix 617 10.1.0.0/16 and participates in RPKI, it wishes to announce the more 618 specific prefix 10.1.0.0/20 from ASN 64496. It has further delegated 619 10.1.16.0/20 and 10.1.32.0/20 to customers Org B with ASN 64511 and 620 and Org C with ASN 65535 (respectively) who are multi-homed. Org B 621 (ASN 64511) does not participate in RPKI. Org C (ASN 65535) 622 participates in RPKI. 624 The desired announcements (and organization with RPKI adoption) would 625 be: 627 +----------------------------------------------------+ 628 | Prefix | Origin AS |Organization | RPKI | 629 +----------------------------------------------------+ 630 | 10.1.0.0/16 | AS64496 | Org A | Yes | 631 | 10.1.0.0/20 | AS64496 | Org A | Yes | 632 | 10.1.16.0/20 | AS64511 | Org B | No | 633 | 10.1.32.0/20 | AS65535 | Org C | YES | 634 +----------------------------------------------------+ 636 The issuing parties would create the following RPKI objects: TBC 638 5.3. Grandchild Does Not Participate in RPKI 640 Consider the previous example with an extension by where Org B, who 641 does not participate in RPKI, further allocates 10.1.17.0/24 to Org X 642 with ASN 64512. Org X does not participate in RPKI. 644 The desired announcements (and organization with RPKI adoption) would 645 be: 647 +----------------------------------------------------+ 648 | Prefix | Origin AS |Organization | RPKI | 649 +----------------------------------------------------+ 650 | 10.1.0.0/16 | AS64496 | Org A | Yes | 651 | 10.1.0.0/20 | AS64496 | Org A | Yes | 652 | 10.1.16.0/20 | AS64511 | Org B | No | 653 | 10.1.32.0/20 | AS65535 | Org C | YES | 654 | 10.1.17.0/24 | AS64512 | Org X | No | 655 +----------------------------------------------------+ 657 The issuing parties would create the following RPKI objects: TBC 659 6. Transfer Use Cases 661 6.1. Transfer of in-use prefix and autonomous system number 663 Organization A holds the resource 10.1.0.0/20 and it is currently in 664 use and originated from AS64496 with valid RPKI objects in place. 665 Organization B has acquired both the prefix and ASN and desires an 666 RPKI transfer on a particular date and time without adversely 667 affecting the operational use of the resource. 669 The following RPKI objects would be created/revoked: TBC 671 6.2. Transfer of in-use prefix 673 Organization A holds the resource 10.1.0.0/8 and it is currently in 674 use and originated from AS64496 with valid RPKI objects in place. 675 Organization B has acquired the address and desires an RPKI transfer 676 on a particular date and time. This prefix will be originated by 677 AS65535 as a result of this transfer. 679 The following RPKI objects would be created/revoked: TBC 681 6.3. Transfer of un-used prefix 683 Organization A holds the resource 10.1.0.0/8 and AS65535 (with RPKI 684 objects). Organization B has acquired an unused portion 685 (10.1.4.0/24) of the prefix and desires an RPKI transfer on a 686 particular date and time. Organization B will originate a route 687 10.1.4.0/24 from AS64496 689 The following RPKI objects would be created/revoked: TBC 691 7. Relying Party Use Cases 693 7.1. ROA Expiry or receipt of a CRL covering a ROA 695 In the cases which follow, the terms "expired ROA" or "revoked ROA" 696 are shorthand, and describe the appropriate expiry or revocation of 697 the EE or Resource Certificates that causes a relying party to 698 consider the corresponding ROA to be viewed as expired or revoked. 700 7.1.1. ROA of Parent Prefix is Revoked 702 A certificate revocation list (CRL) is received which reveals that 703 the ROA containing the prefix 10.1.0.0/16; maxLength 24 with ASN64496 704 is revoked. Further, a prefix route exists in the Internet routing 705 system for 10.1.4.0/24 originated from ASN64496. 707 The Relying Party interpretation would be: TBC 709 7.1.2. ROA of Prefix Revoked 711 A CRL is received which reveals that the ROA containing the prefix 712 10.1.4.0/24; maxLength 24 with ASN64496 is revoked. Further, a 713 prefix route exists in the Internet routing system for 10.1.4.0/24 714 originated from ASN64496. 716 The Relying Party interpretation would be: TBC 718 A counter example: If there was simultaneously a valid ROA containing 719 the (less specific) prefix 10.1.0.0/20; maxLength 24 with ASN64496. 720 (see Section 7.1.4) 722 The Relying Party interpretation would be: TBC 724 7.1.3. ROA of Grandparent Prefix Revoked while that of Parent Prefix 725 Prevails 727 A CRL is received which reveals that the ROA containing the prefix 728 10.1.0.0/16; maxLength 24 with ASN64496 is revoked. Further, a 729 prefix route exists in the Internet routing system for 10.1.4.0/24 730 originated from ASN64496. Additionally, the current ROA list has a 731 valid ROA containing the prefix 10.1.0.0/20; maxLength 24 with 732 ASN64496. 734 The Relying Party interpretation would be: TBC 736 (Clarification: ROA for less specific grandparent prefix 10.1.0.0/16 737 was revoked or withdrawn) 738 The Relying Party interpretation would be: TBC 740 7.1.4. ROA of Prefix Revoked while that of Parent Prefix Prevails 742 A CRL is received which reveals that the ROA containing the prefix 743 10.1.4.0/24; maxLength 24 with ASN64496 is revoked. Further, a 744 prefix route exists in the Internet routing system for 10.1.4.0/24 745 originated from ASN64496. Additionally, the current ROA list has a 746 valid ROA containing the prefix 10.1.0.0/20; maxLength 24 with 747 ASN64496. 749 The Relying Party interpretation would be: TBC 751 (Clarification: Perhaps the revocation of ROA for prefix 10.1.4.0/24 752 was initiated just to eliminate redundancy.) 754 7.1.5. Expiry of ROA of Parent Prefix 756 A scan of the ROA list reveals that the ROA containing the prefix 757 10.1.0.0/16; maxLength 24 with ASN64496 has expired. Further, a 758 prefix route exists in the Internet routing system for 10.1.4.0/24 759 originated from ASN64496. 761 The Relying Party interpretation would be: TBC 763 7.1.6. Expiry of ROA of Prefix 765 A scan of the ROA list reveals that the ROA containing the prefix 766 10.1.4.0/24; maxLength 24 with ASN64496 has expired. Further, a 767 prefix route exists in the Internet routing system for 10.1.4.0/24 768 originated from ASN64496. 770 The Relying Party interpretation would be: TBC 772 7.1.7. Expiry of ROA of Grandparent Prefix while ROA of Parent Prefix 773 Prevails 775 A scan of the ROA list reveals that the ROA containing the prefix 776 10.1.0.0/16; maxLength 24 with ASN64496 has expired. Further, a 777 prefix route exists in the Internet routing system for 10.1.4.0/24 778 originated from ASN64496. Additionally, the current ROA list has a 779 valid ROA containing the prefix 10.1.0.0/20; maxLength 24 with 780 ASN64496. 782 The Relying Party interpretation would be: TBC 784 (Clarification: ROA for less specific grandparent prefix 10.1.0.0/16 785 has expired.) 787 7.1.8. Expiry of ROA of Prefix while ROA of Parent Prefix Prevails 789 A scan of the ROA list reveals that the ROA containing the prefix 790 10.1.4.0/24; maxLength 24 with ASN64496 has expired. Further, a 791 prefix route exists in the Internet routing system for 10.1.4.0/24 792 originated from ASN64496. Additionally, the current ROA list has a 793 valid ROA containing the prefix 10.1.0.0/20; maxLength 24 with 794 ASN64496. 796 The Relying Party interpretation would be: TBC 798 (Clarification: Perhaps the expiry of the ROA for prefix 10.1.4.0/24 799 was meant to eliminate redundancy.) 801 7.2. Prefix, Origin Validation use cases 803 These use cases try to systematically enumerate the situations a 804 relying party may encounter while receiving a BGP update and making 805 use of ROA information to interpret the validity of the prefix-origin 806 information in the update. We enumerate the situations or scenarios 807 but do not make a final recommendation on any RPKI interpretation. 808 For work on development of prefix-origin validation algorithms, see 809 [I-D.ietf-sidr-roa-validation] and [I-D.pmohapat-sidr-pfx-validate]. 810 Also see [I-D.ietf-idr-deprecate-as-sets] for work-in-progress in the 811 IDR WG to deprecate AS_SETs in BGP updates (especially in the context 812 of RPKI-based validation). 814 7.2.1. Covering ROA Prefix, maxLength Satisfied, and AS Match 816 ROA: {10.1.0.0/16, maxLength = 20, AS64496} 818 Update has {10.1.0.0/17, Origin = AS64496} 820 Recommended RPKI prefix-origin validation interpretation: TBC 822 Comment: This is a straight forward prefix-origin validation use 823 case; it follows from the primary intention of creation of ROA by a 824 resource owner. 826 7.2.2. Covering ROA Prefix, maxLength Exceeded, and AS Match 828 ROA: {10.1.0.0/16, maxLength = 20, AS64496} 830 Update has {10.1.0.0/22, Origin = AS64496} 832 No other relevant ROA 834 Recommended RPKI prefix-origin validation interpretation: TBC 835 Comment: In this case the maxLength specified in the ROA is exceeded 836 by the update prefix. 838 7.2.3. Covering ROA Prefix, maxLength Satisfied, and AS Mismatch: 840 ROA: {10.1.0.0/16, maxLength = 24, AS64496} 842 Update has {10.1.88.0/24, Origin = AS65535} 844 No other relevant ROA 846 Recommended RPKI prefix-origin validation interpretation: TBC 848 Comment: In this case an AS other than the one specified in the ROA 849 is originating an update. This may be a prefix or subprefix hijack 850 situation. 852 7.2.4. Covering ROA Prefix, maxLength Exceeded, and AS Mismatch 854 ROA: {10.1.0.0/16, maxLength = 22, AS64496} 856 Update has {10.1.88.0/24, Origin = AS65535} 858 No other relevant ROA 860 Recommended RPKI prefix-origin validation interpretation: TBC 862 Comment: In this case the maxLength specified in the ROA is exceeded 863 by the update prefix, and also an AS other than the one specified in 864 the ROA is originating the update. This may be a subprefix hijack 865 situation. 867 7.2.5. Covering ROA Prefix Not Found 869 Update has {240.1.1.0/24, Origin = AS65535} 871 No relevant ROA 873 Recommended RPKI prefix-origin validation interpretation: TBC 875 Comment: In this case there is no relevant ROA that has a covering 876 prefix for the update prefix. It could be a case of prefix or 877 subprefix hijack situation, but this announcement does not contradict 878 any existing ROA. During partial deployment, there would be some 879 legitimate prefix-origin announcements for which ROAs may not have 880 been issued yet. 882 7.2.6. Covering ROA Prefix Not Found but ROAs Exist for a Covering Set 883 of More Specifics 885 ROA: {10.1.0.0/18, maxLength = 20, AS64496} 887 ROA: {10.1.64.0/18, maxLength = 20, AS64496} 889 ROA: {10.1.128.0/18, maxLength = 20, AS64496} 891 ROA: {10.1.192.0/18, maxLength = 20, AS64496} 893 Update has {10.1.0.0/16, Origin = AS64496} 895 No relevant ROA 897 Recommended RPKI prefix-origin validation interpretation: TBC 899 Comment: In this case the update prefix is an aggregate, and it turns 900 out that there exit ROAs for more specifics which, if combined, can 901 help support validation of the announced prefix-origin pair. But it 902 is very hard in general to breakup an announced prefix into 903 constituent more specifics and check for ROA coverage for those more 904 specifics. 906 7.2.7. AS_SET in Update and Covering ROA Prefix Not Found 908 Update has {10.1.0.0/16, Origin = [AS64496, AS64497, AS64498, 909 AS64497]} 911 No relevant ROA 913 Recommended RPKI prefix-origin validation interpretation: TBC 915 Comment: An extremely small percentage (~0.1%) of eBGP updates are 916 seen to have an AS_SET in them as origin; this is known as proxy 917 aggregation. In this case, update with the AS_SET does not conflict 918 with any ROA. 920 7.2.8. Singleton AS in AS_SET (in the Update), Covering ROA Prefix, and 921 AS Match 923 Update has {10.1.0.0/24, Origin = [AS64496]} (Note: AS_SET with 924 singleton AS appears in origin AS position.) 926 ROA: {10.1.0.0/22, maxLength = 24, AS64496} 928 Recommended RPKI prefix-origin validation interpretation: TBC 929 Comment: In the spirit of [I-D.ietf-idr-deprecate-as-sets], possibly 930 any update with an AS_SET in it should not be considered valid (by 931 ROA-based validation). But does a scenario as described in the 932 example here need be treated differently? 934 7.2.9. Singleton AS in AS_SET (in the Update), Covering ROA Prefix, and 935 AS Mismatch 937 Update has {10.1.0.0/24, Origin = [AS64496]} 939 (Note: AS_SET with singleton AS appears in origin AS position.) 941 ROA: {10.1.0.0/22, maxLength = 24, AS65535} No other relevant ROA. 943 Recommended RPKI prefix-origin validation interpretation: TBC 945 Comment: In this case, update with the AS_SET does conflict with a 946 ROA and there is no other relevant ROA. 948 7.2.10. Multiple ASs in AS_SET (in the Update) and Covering ROA Prefix 950 Update has {10.1.0.0/22, Origin = [AS64496, AS64497, AS64498, 951 AS64497]} 953 ROA: {10.1.0.0/22, maxLength = 24, AS65535} No other relevant ROA. 955 Recommended RPKI prefix-origin validation interpretation: TBC 957 Comment: In this case, update with the AS_SET conflicts with a ROA 958 and there is no other relevant ROA. 960 7.2.11. Update has an AS_SET as Origin and ROAs Exist for a Covering 961 Set of More Specifics 963 ROA: {10.1.0.0/18, maxLength = 20, AS64496} ROA: {10.1.64.0/18, 964 maxLength = 20, AS64497} ROA: {10.1.128.0/18, maxLength = 20, 965 AS64498} ROA: {10.1.192.0/18, maxLength = 20, AS64499} 967 Update has {10.1.0.0/16, Origin = [AS64496, AS64497, AS64498, 968 AS64497]} 970 No (directly) relevant ROA 972 Recommended RPKI prefix-origin validation interpretation: TBC 974 Comment: In this case the aggregate of the prefixes in the ROAs is a 975 covering prefix for the update prefix. The ASs in each of the 976 contributing ROAs together form a set that matches the AS_SET in the 977 update. But it is very hard in general to breakup an announced 978 prefix into constituent more specifics and check for ROA coverage for 979 those more specifics. In any case, it may be noted once again that 980 in the spirit of [I-D.ietf-idr-deprecate-as-sets], possibly any 981 update with an AS_SET in it should not be considered valid (by ROA- 982 based validation). 984 8. Acknowledgements 986 The authors are indebted to both Sandy Murphy and Sam Weiler for 987 their guidance. Further, the authors would like to thank Curtis 988 Villamizar, Steve Kent, and Danny McPherson for their technical 989 insight and review. 991 9. IANA Considerations 993 This memo includes no request to IANA. 995 10. Security Considerations 997 This memo requires no security considerations 999 11. Normative References 1001 [I-D.ietf-idr-deprecate-as-sets] 1002 Kumari, W., "Deprecation of BGP AS_SET, AS_CONFED_SET.", 1003 draft-ietf-idr-deprecate-as-sets-00 (work in progress), 1004 November 2010. 1006 [I-D.ietf-sidr-arch] 1007 Lepinski, M. and S. Kent, "An Infrastructure to Support 1008 Secure Internet Routing", draft-ietf-sidr-arch-11 (work in 1009 progress), September 2010. 1011 [I-D.ietf-sidr-res-certs] 1012 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 1013 X.509 PKIX Resource Certificates", 1014 draft-ietf-sidr-res-certs-21 (work in progress), 1015 December 2010. 1017 [I-D.ietf-sidr-roa-format] 1018 Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 1019 Origin Authorizations (ROAs)", 1020 draft-ietf-sidr-roa-format-09 (work in progress), 1021 November 2010. 1023 [I-D.ietf-sidr-roa-validation] 1024 Huston, G. and G. Michaelson, "Validation of Route 1025 Origination using the Resource Certificate PKI and ROAs", 1026 draft-ietf-sidr-roa-validation-10 (work in progress), 1027 November 2010. 1029 [I-D.pmohapat-sidr-pfx-validate] 1030 Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 1031 Austein, "BGP Prefix Origin Validation", 1032 draft-pmohapat-sidr-pfx-validate-07 (work in progress), 1033 April 2010. 1035 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 1036 Addresses and AS Identifiers", RFC 3779, June 2004. 1038 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 1039 RFC 3852, July 2004. 1041 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 1042 Algorithms and Identifiers for RSA Cryptography for use in 1043 the Internet X.509 Public Key Infrastructure Certificate 1044 and Certificate Revocation List (CRL) Profile", RFC 4055, 1045 June 2005. 1047 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1048 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1050 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 1051 Number Space", RFC 4893, May 2007. 1053 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1054 Housley, R., and W. Polk, "Internet X.509 Public Key 1055 Infrastructure Certificate and Certificate Revocation List 1056 (CRL) Profile", RFC 5280, May 2008. 1058 Authors' Addresses 1060 Terry Manderson 1061 ICANN 1063 Email: terry.manderson@icann.org 1064 Kotikalapudi Sriram 1065 US NIST 1067 Email: ksriram@nist.gov 1069 Russ White 1070 Cisco 1072 Email: russ@cisco.com