idnits 2.17.1 draft-ietf-sidr-usecases-06.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 146 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 date (January 14, 2013) is 4091 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'AS64496' is mentioned on line 1174, but not defined == Missing Reference: 'AS64497' is mentioned on line 1174, but not defined == Missing Reference: 'AS64498' is mentioned on line 1174, but not defined == Missing Reference: 'AS64499' is mentioned on line 1174, but not defined == Unused Reference: 'RFC4055' is defined on line 1357, but no explicit reference was found in the text == Unused Reference: 'RFC4893' is defined on line 1367, but no explicit reference was found in the text == Unused Reference: 'RFC5652' is defined on line 1375, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4893 (Obsoleted by RFC 6793) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). 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: July 18, 2013 US NIST 6 R. White 7 Verisign 8 January 14, 2013 10 Use Cases and Interpretation of RPKI Objects for Issuers and Relying 11 Parties 12 draft-ietf-sidr-usecases-06 14 Abstract 16 This document describes a number of use cases together with 17 directions and interpretations for organizations and relying parties 18 when creating or encountering Resource Public Key Infrastructure 19 (RPKI)object scenarios in the public RPKI. All of the above are 20 discussed here in relation to the Internet routing system. 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 http://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 July 18, 2013. 39 Copyright Notice 41 Copyright (c) 2013 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.2. Documentation Prefixes . . . . . . . . . . . . . . . . . . 4 59 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 2.1. General interpretation of RPKI object semantics . . . . . 6 62 3. Origination Use Cases . . . . . . . . . . . . . . . . . . . . 7 63 3.1. Single Announcement . . . . . . . . . . . . . . . . . . . 7 64 3.2. Aggregate with a More Specific . . . . . . . . . . . . . . 8 65 3.3. Aggregate with a More Specific from a Different ASN . . . 9 66 3.4. Sub-allocation to a Multi-homed Customer . . . . . . . . . 9 67 3.5. Restriction of a New Allocation . . . . . . . . . . . . . 10 68 3.6. Restriction of New ASN . . . . . . . . . . . . . . . . . . 11 69 3.7. Restriction of a Part of an Allocation . . . . . . . . . . 11 70 3.8. Restriction of Prefix Length . . . . . . . . . . . . . . . 12 71 3.9. Restriction of Sub-allocation Prefix Length . . . . . . . 13 72 3.10. Aggregation and Origination by an Upstream . . . . . . . . 14 73 3.11. Rogue Aggregation and Origination by an Upstream . . . . . 16 74 4. Adjacency or Path Validation Use Cases . . . . . . . . . . . . 17 75 5. Partial Deployment Use Cases . . . . . . . . . . . . . . . . . 17 76 5.1. Parent Does Not Participate in RPKI . . . . . . . . . . . 17 77 5.2. Only Some Children Participate in RPKI . . . . . . . . . . 18 78 5.3. Grandchild Does Not Participate in RPKI . . . . . . . . . 19 79 6. Transfer Use Cases . . . . . . . . . . . . . . . . . . . . . . 20 80 6.1. Transfer of in-use prefix and autonomous system number . . 20 81 6.2. Transfer of in-use prefix . . . . . . . . . . . . . . . . 21 82 6.3. Transfer of unused prefix . . . . . . . . . . . . . . . . 22 83 7. Relying Party Use Cases . . . . . . . . . . . . . . . . . . . 22 84 7.1. Prefix-Origin Validation Use Cases . . . . . . . . . . . . 22 85 7.1.1. Covering ROA Prefix, maxLength Satisfied, and AS 86 Match . . . . . . . . . . . . . . . . . . . . . . . . 23 87 7.1.2. Covering ROA Prefix, maxLength Exceeded, and AS 88 Match . . . . . . . . . . . . . . . . . . . . . . . . 23 89 7.1.3. Covering ROA Prefix, maxLength Satisfied, and AS 90 Mismatch . . . . . . . . . . . . . . . . . . . . . . . 23 91 7.1.4. Covering ROA Prefix, maxLength Exceeded, and AS 92 Mismatch . . . . . . . . . . . . . . . . . . . . . . . 24 93 7.1.5. Covering ROA Prefix Not Found . . . . . . . . . . . . 24 94 7.1.6. Covering ROA Prefix and the ROA is an AS0 ROA . . . . 24 95 7.1.7. Covering ROA Prefix Not Found but ROAs Exist for a 96 Covering Set of More Specifics . . . . . . . . . . . . 25 97 7.1.8. AS_SET in Route and Covering ROA Prefix Not Found . . 25 98 7.1.9. Singleton AS in AS_SET (in the Route), Covering 99 ROA Prefix, and AS Match . . . . . . . . . . . . . . . 26 100 7.1.10. Singleton AS in AS_SET (in the Route), Covering 101 ROA Prefix, and AS Mismatch . . . . . . . . . . . . . 26 102 7.1.11. Multiple ASs in AS_SET (in the Route) and Covering 103 ROA Prefix . . . . . . . . . . . . . . . . . . . . . . 26 104 7.1.12. Multiple ASs in AS_SET (in the Route) and ROAs 105 Exist for a Covering Set of More Specifics . . . . . . 27 106 7.2. ROA Expiry or Receipt of a CRL Revoking a ROA . . . . . . 27 107 7.2.1. ROA of Parent Prefix is Revoked . . . . . . . . . . . 27 108 7.2.2. ROA of Prefix Revoked while Parent Prefix Has 109 Covering ROA Prefix with Different ASN . . . . . . . . 28 110 7.2.3. ROA of Prefix Revoked while that of Parent Prefix 111 Prevails . . . . . . . . . . . . . . . . . . . . . . . 28 112 7.2.4. ROA of Grandparent Prefix Revoked while that of 113 Parent Prefix Prevails . . . . . . . . . . . . . . . . 28 114 7.2.5. Expiry of ROA of Parent Prefix . . . . . . . . . . . . 28 115 7.2.6. Expiry of ROA of Prefix while Parent Prefix Has 116 Covering ROA with Different ASN . . . . . . . . . . . 29 117 7.2.7. Expiry of ROA of Prefix while that of Parent 118 Prefix Prevails . . . . . . . . . . . . . . . . . . . 29 119 7.2.8. Expiry of ROA of Grandparent Prefix while that of 120 Parent Prefix Prevails . . . . . . . . . . . . . . . . 29 121 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 122 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 123 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 124 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 125 11.1. Normative References . . . . . . . . . . . . . . . . . . . 30 126 11.2. Informative References . . . . . . . . . . . . . . . . . . 30 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 129 1. Introduction 131 This document describes a number of use cases together with 132 directions and interpretations for organizations and relying parties 133 when creating or encountering Resource Public Key Infrastructure 134 (RPKI)object scenarios in the public RPKI. All of the above are 135 discussed here in relation to the Internet routing system. 137 1.1. Terminology 139 It is assumed that the reader is familiar with the terms and concepts 140 described in "Internet X.509 Public Key Infrastructure Certificate 141 and Certificate Revocation List (CRL) Profile" [RFC5280], "A Profile 142 for X.509 PKIX Resource Certificates" [RFC6487], "X.509 Extensions 143 for IP Addresses and AS Identifiers" [RFC3779], "A Profile for Route 144 Origin Authorizations (ROAs)" [RFC6482], "Validation of Route 145 Origination Using the Resource Certificate Public Key Infrastructure 146 (PKI) and Route Origin Authorizations (ROAs)" [RFC6483], and "BGP 147 Prefix Origin Validation" [I-D.ietf-sidr-pfx-validate]. 149 1.2. Documentation Prefixes 151 The documentation prefixes recommended in [RFC5737] are insufficient 152 for use as example prefixes in this document. Therefore, this 153 document uses RFC1918 [RFC1918] address space for constructing 154 example prefixes. 156 1.3. Definitions 158 For all of the use cases in this document it is assumed that RPKI 159 objects (e.g., resource certificates, ROAs) validate in accordance 160 with [RFC6487] and [RFC6480]. In other words, we assume that 161 corrupted RPKI objects, if any, have been detected and eliminated. 163 The following definitions are in use in this document. Some of these 164 definitions are reused or adapted from [I-D.ietf-sidr-pfx-validate] 165 with authors' permission. 167 Resource: An IP address prefix (simply called prefix or subnet) or an 168 Autonomous System Number (ASN). 170 Allocation: A set of resources provided to an entity or organization 171 for its use. 173 Sub-allocation: A set of resources subordinate to an allocation 174 assigned to another entity or organization. 176 Prefix: A prefix consists of a pair (IP address, prefix length), 177 interpreted as is customary (see [RFC4632]). 179 Route: Data derived from a received BGP update, as defined in 180 [RFC4271], Section 1.1. The Route includes one Prefix and an 181 AS_PATH, among other things. 183 ROA: Route Origin Authorization(ROA) is an RPKI object signed by a 184 prefix holder authorizing origination of said prefix from an origin 185 AS specified in said ROA. 187 AS0 ROA: A ROA with ASN value 0 (zero) in the AS ID field. AS0 ROA 188 is an attestation by a prefix holder that the prefix described in the 189 ROA, and any more specific prefix, should not be used in a routing 190 context [RFC6483]. 192 ROA prefix: The Prefix from a ROA. 194 ROA ASN: The origin ASN from a ROA. 196 MaxLength: The maximum length up to which more specific prefixes of a 197 ROA prefix may be originated from the corresponding ROA ASN. The 198 maxLength is specified in the ROA. 200 Route prefix: A prefix derived from a route. 202 Route origin ASN: The origin AS number derived from a route. The 203 origin AS number is: 205 o the rightmost AS in the final segment of the AS_PATH attribute in 206 the route if that segment is of type AS_SEQUENCE, or 208 o the BGP speaker's own AS number if that segment is of type 209 AS_CONFED_SEQUENCE or AS_CONFED_SET or if the AS_PATH is empty, or 211 o the distinguished value "NONE" if the final segment of the AS_PATH 212 attribute is of any other type. 214 Covering ROA prefix: A ROA prefix that is an exact match or a less 215 specific when compared to the route prefix under consideration. In 216 other words, the route prefix is said to have a covering ROA prefix 217 when there exists a ROA such that the ROA prefix length is less than 218 or equal to the route prefix length and the ROA prefix address 219 matches the route prefix address for all bits specified by the ROA 220 prefix length. 222 Covering ROA: If a ROA contains a covering ROA prefix for a route 223 prefix under consideration, then the ROA is said to be a covering ROA 224 for the route prefix. 226 No covering ROA: No covering ROA exists for a route prefix under 227 consideration. 229 No other covering ROA: No other covering ROA exists (besides what is 230 (are) already cited) for a route prefix under consideration. 232 Multi-homed prefix or subnet: A prefix (i.e., subnet) for which a 233 route is originated through two or more Autonomous Systems. 235 Matched: A route's {prefix, origin AS} pair is said to be matched by 236 a ROA when the route prefix has a covering ROA and in addition, the 237 route prefix length is less than or equal to the maxLength in said 238 covering ROA and the route origin ASN is equal to the ASN in said 239 covering ROA. 241 Given these definitions, any given BGP route will be found to have 242 one of the following "validation states": 244 o NotFound: The route prefix has no covering ROA. 246 o Valid: The route's {prefix, origin AS} pair is matched by at least 247 one ROA. 249 o Invalid: The route prefix has at least one covering ROA and the 250 route's {prefix, origin AS} pair is not matched by any ROA. 252 It is to be noted that that no ROA can have the value "NONE" as its 253 ROA ASN. Thus a route whose origin ASN is "NONE" cannot be matched 254 by any ROA. Similarly, no valid route can have an origin ASN of zero 255 [I-D.ietf-idr-as0]. Thus no route can be matched by a ROA whose ASN 256 is zero (i.e., an AS0 ROA) [RFC6483]. 258 2. Overview 260 2.1. General interpretation of RPKI object semantics 262 It is important that in the interpretation of relying parties (RP), 263 or relying party routing software, that a 'make before break' 264 operational policy is applied. This means in part that a RP should 265 implement a routing decision process where a route is assumed to be 266 intended (i.e., considered unsuspicious) unless proven otherwise by 267 the existence of a valid RPKI object that explicitly invalidates the 268 route (see Section 7.1 for examples). Also, especially in cases when 269 a prefix is newly acquired by allocation/suballocation or due to 270 prefix-ownership transfer, a ROA should be registered in RPKI prior 271 to advertisement of the prefix in BGP. This is highly recommended 272 for the following reasons. Observe that in the transfer case 273 (considering a prefix transfer from Org-A to Org-B), even though 274 Org-A's resource cert would be revoked before issuing a resource cert 275 to Org-B, there may be some latency before all relying parties 276 discard the previously received ROA of Org-A for that prefix. The 277 latency may be due to CRL propagation delay in the RPKI system or due 278 to periodic polling by RPs, etc. Also, observe that in the 279 suballocation case (from parent Org-A to child Org-B), there may be 280 an existing ROA registered by Org-A (with their own origin ASN) for a 281 covering aggregate prefix relative to the prefix in consideration. 282 If the new prefix owner (Org-B) has not already registered their own 283 ROA (i.e., ROA with their origin ASN), then the presence of a 284 different covering ROA (i.e., one with a different origin ASN) 285 belonging to Org-A would result in invalid assessment for the route 286 advertised by the new owner (Org-B). Thus in both cases (transfer or 287 suballocation), it is prudent for the new owner (Org-B) to ensure 288 that its route for the prefix will be valid by proactively issuing a 289 ROA before advertising the route. The ROA should be issued with 290 sufficient lead time taking into consideration the RPKI propagation 291 delays. 293 As stated earlier in Section 1.3, for all of the use cases in this 294 document it is assumed that RPKI objects (e.g., resource 295 certificates, ROAs) validate in accordance with [RFC6487] and 296 [RFC6480]. In other words, we assume that corrupted RPKI objects, if 297 any, have been detected and eliminated. 299 While many of the examples provided here illustrate organizations 300 using their own autonomous system numbers to originate routes, it 301 should be recognized that a prefix holder need not necessarily be the 302 holder of the autonomous system number used for the route 303 origination. 305 3. Origination Use Cases 307 This section deals with the various use cases where an organization 308 has Internet resources and will announce routes to the Internet. It 309 is based on operational observations of the existing routing system. 310 In the following use cases, the phrase "relying parties interpret the 311 route as intended" is generally meant to indicate that "relying 312 parties interpret an announced route as having a valid origination 313 AS." 315 3.1. Single Announcement 317 An organization (Org A with ASN 64496) has been allocated the prefix 318 10.1.2.0/24. It wishes to announce the /24 prefix from ASN 64496 319 such that relying parties interpret the route as intended. 321 The desired announcement (and organization) would be: 323 +----------------------------------------------+ 324 | Prefix | Origin AS | Organization | 325 +----------------------------------------------+ 326 | 10.1.2.0/24 | AS64496 | Org A | 327 +----------------------------------------------+ 329 The issuing party should create a ROA containing the following: 331 +----------------------------------------------+ 332 | asID | address | maxLength | 333 +----------------------------------------------+ 334 | 64496 | 10.1.2.0/24 | 24 | 335 +----------------------------------------------+ 337 3.2. Aggregate with a More Specific 339 An organization (Org A with ASN 64496) has been allocated the prefix 340 10.1.0.0/16. It wishes to announce the more specific prefix 341 10.1.0.0/20 from ASN 64496 as well as the aggregate route such that 342 relying parties interpret the routes as intended. 344 The desired announcements (and organization) would be: 346 +----------------------------------------------+ 347 | Prefix | Origin AS | Organization | 348 +----------------------------------------------+ 349 | 10.1.0.0/16 | AS64496 | Org A | 350 | 10.1.0.0/20 | AS64496 | Org A | 351 +----------------------------------------------+ 353 The issuing party should create a ROA containing the following: 355 +----------------------------------------------+ 356 | asID | address | maxLength | 357 +----------------------------------------------+ 358 | 64496 | 10.1.0.0/16 | 16 | 359 | |-----------------------------------+ 360 | | 10.1.0.0/20 | 20 | 361 +----------------------------------------------+ 363 3.3. Aggregate with a More Specific from a Different ASN 365 An organization (Org A with ASN 64496 and ASN 64511) has been 366 allocated the prefix 10.1.0.0/16. It wishes to announce the more 367 specific prefix 10.1.0.0/20 from ASN 64511 as well as the aggregate 368 route from ASN 64496 such that relying parties interpret the routes 369 as intended. 371 The desired announcements (and organization) would be: 373 +---------------------------------------------+ 374 | Prefix | Origin AS |Organization | 375 +---------------------------------------------+ 376 | 10.1.0.0/16 | AS64496 | Org A | 377 | 10.1.0.0/20 | AS64511 | Org A | 378 +---------------------------------------------+ 380 The issuing party should create ROAs containing the following: 382 +----------------------------------------------+ 383 | asID | address | maxLength | 384 +----------------------------------------------+ 385 | 64496 | 10.1.0.0/16 | 16 | 386 +----------------------------------------------+ 388 +----------------------------------------------+ 389 | asID | address | maxLength | 390 +----------------------------------------------+ 391 | 64511 | 10.1.0.0/20 | 20 | 392 +----------------------------------------------+ 394 3.4. Sub-allocation to a Multi-homed Customer 396 An organization (Org A with ASN 64496) has been allocated the prefix 397 10.1.0.0/16; it wishes to announce the more specific prefix 398 10.1.0.0/20 from ASN 64496. It has further delegated 10.1.16.0/20 to 399 a customer (Org B with ASN 64511) who is multi-homed and will 400 originate the prefix route from ASN 64511. ASN 64496 will also 401 announce the aggregate route such that relying parties interpret the 402 routes as intended. 404 The desired announcements (and organization) would be: 406 +---------------------------------------------+ 407 | Prefix | Origin AS |Organization | 408 +---------------------------------------------+ 409 | 10.1.0.0/16 | AS64496 | Org A | 410 | 10.1.0.0/20 | AS64496 | Org A | 411 | 10.1.16.0/20 | AS64511 | Org B | 412 +---------------------------------------------+ 414 The issuing party should create ROAs containing the following: 416 Org A. 417 +----------------------------------------------+ 418 | asID | address | maxLength | 419 +----------------------------------------------+ 420 | 64496 | 10.1.0.0/16 | 16 | 421 | |-----------------------------------+ 422 | | 10.1.0.0/20 | 20 | 423 +----------------------------------------------+ 425 Org B. 426 +----------------------------------------------+ 427 | asID | address | maxLength | 428 +----------------------------------------------+ 429 | 64511 | 10.1.16.0/20 | 20 | 430 +----------------------------------------------+ 432 3.5. Restriction of a New Allocation 434 An organization has recently been allocated the prefix 10.1.0.0/16. 435 Its network deployment is not yet ready to announce the prefix and 436 wishes to restrict all possible announcements of 10.1.0.0/16 and more 437 specifics in routing using RPKI. 439 The following announcements would be considered undesirable: 441 +---------------------------------------------+ 442 | Prefix | Origin AS |Organization | 443 +---------------------------------------------+ 444 | 10.1.0.0/16 | ANY AS | ANY | 445 | 10.1.0.0/20 | ANY AS | ANY | 446 | 10.1.17.0/24 | ANY AS | ANY | 447 +---------------------------------------------+ 449 The issuing party should create a ROA containing the following: 451 +----------------------------------------------+ 452 | asID | address | maxLength | 453 +----------------------------------------------+ 454 | 0 | 10.1.0.0/16 | 32 | 455 +----------------------------------------------+ 457 This is known as an AS0 ROA [RFC6483]. Also, please see the 458 definition and related comments in Section 1.3. 460 3.6. Restriction of New ASN 462 An organization has recently been allocated an additional ASN 64511. 463 Its network deployment is not yet ready to use this ASN and wishes to 464 restrict all possible uses of ASN 64511 using RPKI. 466 The following announcements would be considered undesirable: 468 +---------------------------------------------+ 469 | Prefix | Origin AS |Organization | 470 +---------------------------------------------+ 471 | ANY | AS64511 | ANY | 472 +---------------------------------------------+ 474 It is currently not possible to restrict use of Autonomous System 475 Numbers 477 3.7. Restriction of a Part of an Allocation 479 An organization (Org A with ASN 64496) has been allocated the prefix 480 10.1.0.0/16. Its network topology permits the announcement of 481 10.1.0.0/17. Org A wishes to restrict any possible announcement of 482 10.1.128.0/17 or more specifics of that /17 using RPKI. 484 The desired announcements would be: 486 +---------------------------------------------+ 487 | Prefix | Origin AS |Organization | 488 +---------------------------------------------+ 489 | 10.1.0.0/17 | AS64496 | Org A | 490 +---------------------------------------------+ 492 The following announcements would be considered undesirable: 494 +---------------------------------------------+ 495 | Prefix | Origin AS |Organization | 496 +---------------------------------------------+ 497 | 10.1.128.0/17 | ANY AS | ANY | 498 | 10.1.128.0/24 | ANY AS | ANY | 499 +---------------------------------------------+ 501 The issuing party should create ROAs containing the following: 503 +----------------------------------------------+ 504 | asID | address | maxLength | 505 +----------------------------------------------+ 506 | 64496 | 10.1.0.0/17 | 17 | 507 +----------------------------------------------+ 509 +----------------------------------------------+ 510 | asID | address | maxLength | 511 +----------------------------------------------+ 512 | 0 | 10.1.128.0/17 | 32 | 513 +----------------------------------------------+ 515 3.8. Restriction of Prefix Length 517 An organization (Org A with ASN 64496) has been allocated the prefix 518 10.1.0.0/16; it wishes to announce the aggregate and any or all more 519 specific prefixes up to and including a maximum length of /20, but 520 never any more specific than a /20. 522 Examples of the desired announcements (and organization) would be: 524 +---------------------------------------------+ 525 | Prefix | Origin AS |Organization | 526 +---------------------------------------------+ 527 | 10.1.0.0/16 | AS64496 | Org A | 528 | 10.1.0.0/17 | AS64496 | Org A | 529 | ... | AS64496 | Org A | 530 | 10.1.128.0/20 | AS64496 | Org A | 531 +---------------------------------------------+ 533 The following announcements would be considered undesirable: 535 +---------------------------------------------+ 536 | Prefix | Origin AS |Organization | 537 +---------------------------------------------+ 538 | 10.1.0.0/21 | ANY AS | ANY | 539 | 10.1.0.0/22 | ANY AS | ANY | 540 | ... | ANY AS | ANY | 541 | 10.1.128.0/24 | ANY AS | ANY | 542 +---------------------------------------------+ 544 The issuing party should create a ROA containing the following: 546 +----------------------------------------------+ 547 | asID | address | maxLength | 548 +----------------------------------------------+ 549 | 64496 | 10.1.0.0/16 | 20 | 550 +----------------------------------------------+ 552 3.9. Restriction of Sub-allocation Prefix Length 554 An organization (Org A with ASN 64496) has been allocated the prefix 555 10.1.0.0/16; it sub-allocates several /20 prefixes to its multi-homed 556 customers Org B with ASN 64501, and Org C with ASN 64499. It wishes 557 to restrict those customers from advertising any corresponding routes 558 more specific than a /22. 560 The desired announcements would be: 562 +---------------------------------------------+ 563 | Prefix | Origin AS |Organization | 564 +---------------------------------------------+ 565 | 10.1.0.0/16 | AS64496 | Org A | 566 | 10.1.0.0/20 | AS64501 | Org B | 567 | 10.1.128.0/20 | AS64499 | Org C | 568 | 10.1.4.0/22 | AS64501 | Org B 569 +---------------------------------------------+ 571 The following example announcements (and organization) would be 572 considered undesirable: 574 +---------------------------------------------+ 575 | Prefix | Origin AS |Organization | 576 +---------------------------------------------+ 577 | 10.1.0.0/24 | AS64501 | Org B | 578 | 10.1.128.0/24 | AS64499 | Org C | 579 | ..... | ... | ... | 580 | 10.1.0.0/23 | ANY AS | ANY | 581 +---------------------------------------------+ 583 The issuing party (Org A) should create ROAs containing the 584 following: 586 For Org A: 587 +----------------------------------------------+ 588 | asID | address | maxLength | 589 +----------------------------------------------+ 590 | 64496 | 10.1.0.0/16 | 16 | 591 +----------------------------------------------+ 593 For Org B: 594 +----------------------------------------------+ 595 | asID | address | maxLength | 596 +----------------------------------------------+ 597 | 64501 | 10.1.0.0/20 | 22 | 598 +----------------------------------------------+ 600 For Org C: 601 +----------------------------------------------+ 602 | asID | address | maxLength | 603 +----------------------------------------------+ 604 | 64499 | 10.1.128.0/20 | 22 | 605 +----------------------------------------------+ 607 3.10. Aggregation and Origination by an Upstream 609 Consider four organizations with the following resources, which were 610 acquired independently from any transit provider. 612 +-------------------------------------------------+ 613 | Organization | ASN | Prefix | 614 +-------------------------------------------------+ 615 | Org A | AS64496 | 10.1.0.0/24 | 616 | Org B | AS64505 | 10.1.3.0/24 | 617 | Org C | AS64499 | 10.1.1.0/24 | 618 | Org D | AS64511 | 10.1.2.0/24 | 619 +-------------------------------------------------+ 621 These organizations share a common upstream provider Transit X (ASN 622 64497) that originates an aggregate of these prefixes with the 623 permission of all four organizations. 625 The desired announcements (and organization) would be: 627 +----------------------------------------------+ 628 | Prefix | Origin AS | Organization | 629 +----------------------------------------------+ 630 | 10.1.0.0/24 | AS64496 | Org A | 631 | 10.1.3.0/24 | AS64505 | Org B | 632 | 10.1.1.0/24 | AS64499 | Org C | 633 | 10.1.2.0/24 | AS64511 | Org D | 634 | 10.1.0.0/22 | AS64497 | Transit X | 635 +----------------------------------------------+ 637 It is currently not possible for an upstream to make a valid 638 aggregate announcement of independent prefixes. However the issuing 639 parties should create ROAs containing the following: 641 Org A: 642 +----------------------------------------------+ 643 | asID | address | maxLength | 644 +----------------------------------------------+ 645 | 64496 | 10.1.0.0/24 | 24 | 646 +----------------------------------------------+ 648 Org B: 649 +----------------------------------------------+ 650 | asID | address | maxLength | 651 +----------------------------------------------+ 652 | 64505 | 10.1.3.0/24 | 24 | 653 +----------------------------------------------+ 655 Org C: 656 +----------------------------------------------+ 657 | asID | address | maxLength | 658 +----------------------------------------------+ 659 | 64499 | 10.1.1.0/24 | 24 | 660 +----------------------------------------------+ 662 Org D: 663 +----------------------------------------------+ 664 | asID | address | maxLength | 665 +----------------------------------------------+ 666 | 64511 | 10.1.2.0/24 | 24 | 667 +----------------------------------------------+ 669 3.11. Rogue Aggregation and Origination by an Upstream 671 Consider four organizations with the following resources that were 672 acquired independently from any transit provider. 674 +-------------------------------------------------+ 675 | Organization | ASN | Prefix | 676 +-------------------------------------------------+ 677 | Org A | AS64496 | 10.1.0.0/24 | 678 | Org B | AS64503 | 10.1.3.0/24 | 679 | Org C | AS64499 | 10.1.1.0/24 | 680 | Org D | AS64511 | 10.1.2.0/24 | 681 +-------------------------------------------------+ 683 These organizations share a common upstream provider Transit X (ASN 684 64497) that originates an aggregate of these prefixes where possible. 685 In this situation organization B (ASN 64503, 10.1.3.0/24) does not 686 wish for its prefix to be aggregated by the upstream provider. 688 The desired announcements (and organization) would be: 690 +----------------------------------------------+ 691 | Prefix | Origin AS | Organization | 692 +----------------------------------------------+ 693 | 10.1.0.0/24 | AS64496 | Org A | 694 | 10.1.3.0/24 | AS64503 | Org B | 695 | 10.1.1.0/24 | AS64499 | Org C | 696 | 10.1.2.0/24 | AS64511 | Org D | 697 | 10.1.0.0/23 | AS64497 | Transit X | 698 +----------------------------------------------+ 700 The following announcement would be undesirable: 702 +----------------------------------------------+ 703 | Prefix | Origin AS | Organization | 704 +----------------------------------------------+ 705 | 10.1.0.0/22 | AS64497 | Transit X | 706 +----------------------------------------------+ 708 It is currently not possible for an upstream to make a valid 709 aggregate announcement of independent prefixes. However the issuing 710 parties should create ROAs containing the following: 712 Org A: 713 +----------------------------------------------+ 714 | asID | address | maxLength | 715 +----------------------------------------------+ 716 | 64496 | 10.1.0.0/24 | 24 | 717 +----------------------------------------------+ 719 Org B: 720 +----------------------------------------------+ 721 | asID | address | maxLength | 722 +----------------------------------------------+ 723 | 64503 | 10.1.3.0/24 | 24 | 724 +----------------------------------------------+ 726 Org C: 727 +----------------------------------------------+ 728 | asID | address | maxLength | 729 +----------------------------------------------+ 730 | 64499 | 10.1.1.0/24 | 24 | 731 +----------------------------------------------+ 733 Org D: 734 +----------------------------------------------+ 735 | asID | address | maxLength | 736 +----------------------------------------------+ 737 | 64511 | 10.1.2.0/24 | 24 | 738 +----------------------------------------------+ 740 4. Adjacency or Path Validation Use Cases 742 Use cases pertaining to adjacency or path validation are beyond the 743 scope of this document and would be addressed in a separate document. 745 5. Partial Deployment Use Cases 747 5.1. Parent Does Not Participate in RPKI 749 An organization (Org A with ASN 64511) is multi-homed and has been 750 assigned the prefix 10.1.0.0/20 from its upstream (Transit X with ASN 751 64496). Org A wishes to announce the prefix 10.1.0.0/20 from ASN 752 64511 to its other upstream(s). Org A also wishes to create RPKI 753 statements about the resource; however Transit X (ASN 64496) which 754 announces the aggregate 10.1.0.0/16 has not yet adopted RPKI. 756 The desired announcements (and organization with RPKI adoption) would 757 be: 759 +----------------------------------------------------+ 760 | Prefix | Origin AS |Organization | RPKI | 761 +----------------------------------------------------+ 762 | 10.1.0.0/20 | AS64511 | Org A | Yes | 763 | 10.1.0.0/16 | AS64496 | Transit X | No | 764 +----------------------------------------------------+ 766 RPKI is strictly hierarchical; therefore if Transit X does not 767 participate in RPKI, Org A is unable to validly issue RPKI objects. 769 5.2. Only Some Children Participate in RPKI 771 An organization (Org A with ASN 64496) has been allocated the prefix 772 10.1.0.0/16 and participates in RPKI; it wishes to announce the more 773 specific prefix 10.1.0.0/20 from ASN 64496. It has further delegated 774 10.1.16.0/20 and 10.1.32.0/20 to customers Org B with ASN 64511 and 775 Org C with ASN 64502 (respectively) who are multi-homed. Org B (ASN 776 64511) does not participate in RPKI. Org C (ASN 64502) participates 777 in RPKI. 779 The desired announcements (and organization with RPKI adoption) would 780 be: 782 +----------------------------------------------------+ 783 | Prefix | Origin AS |Organization | RPKI | 784 +----------------------------------------------------+ 785 | 10.1.0.0/16 | AS64496 | Org A | Yes | 786 | 10.1.0.0/20 | AS64496 | Org A | Yes | 787 | 10.1.16.0/20 | AS64511 | Org B | No | 788 | 10.1.32.0/20 | AS64502 | Org C | Yes | 789 +----------------------------------------------------+ 791 The issuing parties should create ROAs containing the following: 793 Org A: 794 +----------------------------------------------+ 795 | asID | address | maxLength | 796 +----------------------------------------------+ 797 | 64496 | 10.1.0.0/16 | 16 | 798 +----------------------------------------------+ 799 | | 10.1.0.0/20 | 20 | 800 +----------------------------------------------+ 802 Org A issues for Org B: 803 +----------------------------------------------+ 804 | asID | address | maxLength | 805 +----------------------------------------------+ 806 | 64511 | 10.1.16.0/20 | 20 | 807 +----------------------------------------------+ 809 Org C: 810 +----------------------------------------------+ 811 | asID | address | maxLength | 812 +----------------------------------------------+ 813 | 64502 | 10.1.32.0/20 | 20 | 814 +----------------------------------------------+ 816 5.3. Grandchild Does Not Participate in RPKI 818 Consider the previous example with an extension by where Org B, who 819 does not participate in RPKI, further allocates 10.1.17.0/24 to Org X 820 with ASN 64505. Org X does not participate in RPKI. 822 The desired announcements (and organization with RPKI adoption) would 823 be: 825 +----------------------------------------------------+ 826 | Prefix | Origin AS |Organization | RPKI | 827 +----------------------------------------------------+ 828 | 10.1.0.0/16 | AS64496 | Org A | Yes | 829 | 10.1.0.0/20 | AS64496 | Org A | Yes | 830 | 10.1.16.0/20 | AS64511 | Org B | No | 831 | 10.1.32.0/20 | AS64502 | Org C | Yes | 832 | 10.1.17.0/24 | AS64505 | Org X | No | 833 +----------------------------------------------------+ 835 The issuing parties should create ROAs containing the following: 837 Org A: 838 +----------------------------------------------+ 839 | asID | address | maxLength | 840 +----------------------------------------------+ 841 | 64496 | 10.1.0.0/16 | 16 | 842 +----------------------------------------------+ 843 | | 10.1.0.0/20 | 20 | 844 +----------------------------------------------+ 846 Org A issues for Org B: 847 +----------------------------------------------+ 848 | asID | address | maxLength | 849 +----------------------------------------------+ 850 | 64511 | 10.1.16.0/20 | 20 | 851 +----------------------------------------------+ 853 Org A issues for Org B's customer Org X: 854 +----------------------------------------------+ 855 | asID | address | maxLength | 856 +----------------------------------------------+ 857 | 64505 | 10.1.17.0/24 | 24 | 858 +----------------------------------------------+ 860 Org C: 861 +----------------------------------------------+ 862 | asID | address | maxLength | 863 +----------------------------------------------+ 864 | 64502 | 10.1.32.0/20 | 20 | 865 +----------------------------------------------+ 867 6. Transfer Use Cases 869 For transfer use cases, based on the preceding sections, it should be 870 easy to deduce what new ROAs need to be created and what existing 871 ones need to be maintained (or revoked). The resource transfer and 872 timing of revocation/creation of the ROAs need to be performed based 873 on the make-before-break principle and using suitable RIR procedures 874 (see Section 2.1). 876 6.1. Transfer of in-use prefix and autonomous system number 878 Organization A holds the resource 10.1.0.0/20 and it is currently in 879 use and originated from AS64496 with valid RPKI objects in place. 880 Organization B has acquired both the prefix and ASN and desires an 881 RPKI transfer on a particular date and time without adversely 882 affecting the operational use of the resource. 884 The following RPKI objects would be created/revoked: 886 For Org. A, revoke the following ROA: 887 +----------------------------------------------+ 888 | asID | address | maxLength | 889 +----------------------------------------------+ 890 | 64496 | 10.1.0.0/20 | 20 | 891 +----------------------------------------------+ 893 For Org. B, add the following ROA: 894 +----------------------------------------------+ 895 | asID | address | maxLength | 896 +----------------------------------------------+ 897 | 64496 | 10.1.0.0/20 | 20 | 898 +----------------------------------------------+ 900 6.2. Transfer of in-use prefix 902 Organization A holds the resource 10.1.0.0/16 and it is currently in 903 use and originated from AS64496 with valid RPKI objects in place. 904 Organization A has agreed to transfer the entire /16 address block to 905 Organization B and will no longer originate the prefix or more 906 specifics of it. Consequently, Organization B desires an RPKI 907 transfer of this resource on a particular date and time. This prefix 908 will be originated by AS64511 as a result of this transfer. 910 The following RPKI objects would be created/revoked: 912 For Org. A, revoke the following ROA: 913 +----------------------------------------------+ 914 | asID | address | maxLength | 915 +----------------------------------------------+ 916 | 64496 | 10.1.0.0/16 | 16 | 917 +----------------------------------------------+ 919 For Org. B, add the following ROA when the 920 resource certificate for 10.1.0.0/16 is issued to 921 them (Org. B): 922 +----------------------------------------------+ 923 | asID | address | maxLength | 924 +----------------------------------------------+ 925 | 64511 | 10.1.0.0/16 | 16 | 926 +----------------------------------------------+ 928 6.3. Transfer of unused prefix 930 Organization A holds the resources 10.1.0.0/16 and AS64507 (with RPKI 931 objects). Organization A currently announces 10.1.0.0/16 from 932 AS64507. Organization B has acquired an unused portion (10.1.4.0/24) 933 of the prefix from Organization A, and desires an RPKI transfer on a 934 particular date and time. Organization B will originate a route 935 10.1.4.0/24 from AS64496 937 The following RPKI objects would be created/sustained: 939 For Org. A, leave the following ROA unchanged: 940 +----------------------------------------------+ 941 | asID | address | maxLength | 942 +----------------------------------------------+ 943 | 64507 | 10.1.0.0/16 | 16 | 944 +----------------------------------------------+ 946 For Org. B, add the following ROA when the 947 resource certificate for 10.1.4.0/24 is issued 948 to them (Org. B): 949 +----------------------------------------------+ 950 | asID | address | maxLength | 951 +----------------------------------------------+ 952 | 64496 | 10.1.4.0/24 | 24 | 953 +----------------------------------------------+ 955 Organization A may optionally provide ROA coverage for Organization B 956 by creating the following ROA preceding the RPKI transfer. The ROA 957 itself is then naturally revoked when 10.1.4.0/24 is transferred to 958 Organization B's resource certificate. 960 Org. A adds the following ROA: 961 +----------------------------------------------+ 962 | asID | address | maxLength | 963 +----------------------------------------------+ 964 | 64496 | 10.1.4.0/24 | 24 | 965 +----------------------------------------------+ 967 7. Relying Party Use Cases 969 7.1. Prefix-Origin Validation Use Cases 971 These use cases try to systematically enumerate the situations a 972 relying party may encounter while receiving a BGP update and making 973 use of ROA information to interpret the validity of the prefix-origin 974 information in the routes derived from the update. We enumerate the 975 situations or scenarios and include a recommendation for the expected 976 outcome of prefix-origin validation. For a description of prefix- 977 origin validation algorithms, see [RFC6483] and 978 [I-D.ietf-sidr-pfx-validate]. We use the terms Valid, Invalid, and 979 NotFound as defined in [I-D.ietf-sidr-pfx-validate] and summarized 980 earlier in Section 1.3. Also see [RFC6472] for work-in-progress in 981 the IDR WG to deprecate AS_SETs in BGP updates. The use cases 982 described here can be potentially used as test cases for testing and 983 evaluation of prefix-origin validation in router implementations; see 984 for example [BRITE]. 986 7.1.1. Covering ROA Prefix, maxLength Satisfied, and AS Match 988 ROA: {10.1.0.0/16, maxLength = 20, AS64496} 990 Route has {10.1.0.0/17, Origin = AS64496} 992 Recommended RPKI prefix-origin validation interpretation: Route is 993 Valid. 995 Comment: The route prefix has a covering ROA prefix, and the route 996 origin ASN matches the ROA ASN. This is a straightforward prefix- 997 origin validation use case; it follows from the primary intention of 998 creation of ROA by a prefix holder. 1000 7.1.2. Covering ROA Prefix, maxLength Exceeded, and AS Match 1002 ROA: {10.1.0.0/16, maxLength = 20, AS64496} 1004 Route has {10.1.0.0/22, Origin = AS64496} 1006 No other covering ROA 1008 Recommended RPKI prefix-origin validation interpretation: Route is 1009 Invalid. 1011 Comment: In this case the maxLength specified in the ROA is exceeded 1012 by the route prefix. 1014 7.1.3. Covering ROA Prefix, maxLength Satisfied, and AS Mismatch 1016 ROA: {10.1.0.0/16, maxLength = 24, AS64496} 1018 Route has {10.1.88.0/24, Origin = AS64511} 1020 No other covering ROA 1021 Recommended RPKI prefix-origin validation interpretation: Route is 1022 Invalid. 1024 Comment: In this case an AS other than the one specified in the ROA 1025 is originating the route. This may be a prefix or subprefix hijack 1026 situation. 1028 7.1.4. Covering ROA Prefix, maxLength Exceeded, and AS Mismatch 1030 ROA: {10.1.0.0/16, maxLength = 22, AS64496} 1032 Route has {10.1.88.0/24, Origin = AS64511} 1034 No other covering ROA 1036 Recommended RPKI prefix-origin validation interpretation: Route is 1037 Invalid. 1039 Comment: In this case the maxLength specified in the ROA is exceeded 1040 by the route prefix, and also an AS other than the one specified in 1041 the ROA is originating the route. This may be a subprefix hijack 1042 situation. 1044 7.1.5. Covering ROA Prefix Not Found 1046 Route has {10.1.3.0/24, Origin = AS64511} 1048 No covering ROA 1050 Recommended RPKI prefix-origin validation interpretation: Route's 1051 validation status is NotFound. 1053 Comment: In this case there is no covering ROA for the route prefix. 1054 It could be a case of prefix or subprefix hijack situation, but this 1055 announcement does not contradict any existing ROA. During partial 1056 deployment, there would be some legitimate prefix-origin 1057 announcements for which ROAs may not have been issued yet. 1059 7.1.6. Covering ROA Prefix and the ROA is an AS0 ROA 1061 ROA: {10.1.0.0/16, maxLength = 32, AS0} 1063 Route has {10.1.5.0/24, Origin = AS64511} 1065 Recommended RPKI prefix-origin validation interpretation: Route's 1066 validation status is Invalid. 1068 Comment: An AS0 ROA implies by definition that the prefix listed in 1069 it and all of the more specifics of that prefix should not be used in 1070 a routing context [RFC6483][I-D.ietf-idr-as0]. Also, please see 1071 related comments in Section 1.3. 1073 7.1.7. Covering ROA Prefix Not Found but ROAs Exist for a Covering Set 1074 of More Specifics 1076 ROA: {10.1.0.0/18, maxLength = 20, AS64496} 1078 ROA: {10.1.64.0/18, maxLength = 20, AS64496} 1080 ROA: {10.1.128.0/18, maxLength = 20, AS64496} 1082 ROA: {10.1.192.0/18, maxLength = 20, AS64496} 1084 Route has {10.1.0.0/16, Origin = AS64496} 1086 No covering ROA 1088 Recommended RPKI prefix-origin validation interpretation: Route's 1089 validation status is NotFound. 1091 Comment: In this case the route prefix is an aggregate (/16), and it 1092 turns out that there exist ROAs for more specifics (/18s) that, if 1093 combined, can help support validation of the announced prefix-origin 1094 pair. But it is very hard in general to breakup an announced prefix 1095 into constituent more specifics and check for ROA coverage for those 1096 more specifics, and hence this type of accommodation is not 1097 recommended. 1099 7.1.8. AS_SET in Route and Covering ROA Prefix Not Found 1101 Route has {10.1.0.0/16, AS_SET [AS64496, AS64497, AS64498, AS64499] 1102 appears in the right most position in the AS_PATH} 1104 No covering ROA 1106 Recommended RPKI prefix-origin validation interpretation: Route's 1107 validation status is NotFound. 1109 Comment: An extremely small percentage (~0.1%) of eBGP updates are 1110 seen to have an AS_SET in them; this is known as proxy aggregation. 1111 In this case, the route with the AS_SET does not conflict with any 1112 ROA (i.e., the route prefix has no covering ROA prefix). Therefore, 1113 the route gets NotFound validation status. 1115 7.1.9. Singleton AS in AS_SET (in the Route), Covering ROA Prefix, and 1116 AS Match 1118 Route has {10.1.0.0/24, AS_SET [AS64496] appears in the right most 1119 position in the AS_PATH} 1121 ROA: {10.1.0.0/22, maxLength = 24, AS64496} 1123 Recommended RPKI prefix-origin validation interpretation: Route is 1124 Invalid. 1126 Comment: In the spirit of [RFC6472], any route with an AS_SET in it 1127 should not be considered valid (by ROA-based validation). If the 1128 route contains an AS_SET and a covering ROA prefix exists for the 1129 route prefix, then the route should get an Invalid status. (Note: AS 1130 match or mismatch consideration does not apply.) 1132 7.1.10. Singleton AS in AS_SET (in the Route), Covering ROA Prefix, and 1133 AS Mismatch 1135 Route has {10.1.0.0/24, AS_SET [AS64496] appears in the right most 1136 position in the AS_PATH} 1138 ROA: {10.1.0.0/22, maxLength = 24, AS64511} 1140 Recommended RPKI prefix-origin validation interpretation: Route is 1141 Invalid. 1143 Comment: If the route contains an AS_SET and a covering ROA prefix 1144 exists for the route prefix, then the route should get an Invalid 1145 status. (Note: AS match or mismatch consideration does not apply.) 1147 7.1.11. Multiple ASs in AS_SET (in the Route) and Covering ROA Prefix 1149 Route has {10.1.0.0/22, AS_SET [AS64496, AS64497, AS64498, AS64499] 1150 appears in the right most position in the AS_PATH} 1152 ROA: {10.1.0.0/22, maxLength = 24, AS64509} 1154 No other covering ROA. 1156 Recommended RPKI prefix-origin validation interpretation: Route is 1157 Invalid. 1159 Comment: If the route contains an AS_SET and a covering ROA prefix 1160 exists for the route prefix, then the route should get an Invalid 1161 status. 1163 7.1.12. Multiple ASs in AS_SET (in the Route) and ROAs Exist for a 1164 Covering Set of More Specifics 1166 ROA: {10.1.0.0/18, maxLength = 20, AS64496} 1168 ROA: {10.1.64.0/18, maxLength = 20, AS64497} 1170 ROA: {10.1.128.0/18, maxLength = 20, AS64498} 1172 ROA: {10.1.192.0/18, maxLength = 20, AS64499} 1174 Route has {10.1.0.0/16, AS_SET [AS64496, AS64497, AS64498, AS64499] 1175 appears in the right most position in the AS_PATH} 1177 No covering ROA 1179 Recommended RPKI prefix-origin validation interpretation: Route's 1180 validation status is NotFound. 1182 Comment: In this case the aggregate of the prefixes in the ROAs is a 1183 covering prefix (i.e., exact match or less specific) relative to the 1184 route prefix. The ASs in each of the contributing ROAs together form 1185 a set that matches the AS_SET in the route. But it is very hard in 1186 general to breakup an announced prefix into constituent more 1187 specifics and check for ROA coverage for those more specifics. In 1188 any case, it may be noted once again that in the spirit of [RFC6472], 1189 any route with an AS_SET in it should not be considered valid (by 1190 ROA-based validation). In fact, the route under consideration would 1191 have received an Invalid status if the route prefix had at least one 1192 covering ROA prefix. 1194 7.2. ROA Expiry or Receipt of a CRL Revoking a ROA 1196 Here we enumerate use cases corresponding to router actions when RPKI 1197 objects expire or are revoked. In the cases which follow, the terms 1198 "expired ROA" or "revoked ROA" are shorthand, and describe the expiry 1199 or revocation of the End Entity (EE) or Resource Certificate that 1200 causes a relying party to consider the corresponding ROA to have 1201 expired or revoked, respectively. 1203 7.2.1. ROA of Parent Prefix is Revoked 1205 A certificate revocation list (CRL) is received which reveals that 1206 the ROA {10.1.0.0/22, maxLength = 24, ASN64496} is revoked. Further, 1207 a route exists in the Internet routing system for 10.1.3.0/24 1208 originated from ASN64496. In absence of said revoked ROA, no 1209 covering ROA prefix exists for the route prefix (i.e., 10.1.3.0/24). 1211 The Relying Party interpretation would be: Route's validation status 1212 is NotFound 1214 7.2.2. ROA of Prefix Revoked while Parent Prefix Has Covering ROA 1215 Prefix with Different ASN 1217 A CRL is received which reveals that the ROA {10.1.3.0/24, maxLength 1218 = 24, ASN64496} is revoked. Further, a route exists in the Internet 1219 routing system for 10.1.3.0/24 originated from ASN64496. 1220 Additionally, a valid ROA exists for a parent prefix 10.1.0.0/22 and 1221 said ROA is {10.1.0.0/22, maxLength = 24, ASN64511}. No other 1222 covering ROA exists for the 10.1.3.0/24 prefix. 1224 The Relying Party interpretation would be: Route is Invalid. 1226 7.2.3. ROA of Prefix Revoked while that of Parent Prefix Prevails 1228 A CRL is received which reveals that the ROA {10.1.3.0/24; maxLength 1229 = 24, ASN64496} is revoked. Further, a route exists in the Internet 1230 routing system for 10.1.3.0/24 originated from ASN64496. 1231 Additionally, a valid ROA exists for a parent prefix 10.1.0.0/22 and 1232 said ROA is {10.1.0.0/22, maxLength = 24, ASN64496}. 1234 The Relying Party interpretation would be: Route is Valid. 1236 (Clarification: Perhaps the revocation of ROA for prefix 10.1.3.0/24 1237 was initiated just to eliminate redundancy.) 1239 7.2.4. ROA of Grandparent Prefix Revoked while that of Parent Prefix 1240 Prevails 1242 A CRL is received which reveals that the ROA {10.1.0.0/20; maxLength 1243 = 24, ASN64496} is revoked. Further, a route exists in the Internet 1244 routing system for 10.1.3.0/24 originated from ASN64496. 1245 Additionally, a valid ROA exists for a parent prefix 10.1.0.0/22 and 1246 said ROA is {10.1.0.0/22, maxLength = 24, ASN64496}. 1248 The Relying Party interpretation would be: Route is Valid. 1250 (Clarification: ROA for less specific grandparent prefix 10.1.0.0/20 1251 was revoked or withdrawn.) 1253 7.2.5. Expiry of ROA of Parent Prefix 1255 A scan of the ROA list reveals that the ROA {10.1.0.0/22, maxLength = 1256 24, ASN64496} has expired. Further, a route exists in the Internet 1257 routing system for 10.1.3.0/24 originated from ASN64496. In absence 1258 of said expired ROA, no covering ROA prefix exists for the route 1259 prefix (i.e., 10.1.3.0/24). 1261 The Relying Party interpretation would be: Route's validation status 1262 is NotFound 1264 7.2.6. Expiry of ROA of Prefix while Parent Prefix Has Covering ROA 1265 with Different ASN 1267 A scan of the ROA list reveals that the ROA {10.1.3.0/24, maxLength = 1268 24, ASN64496} has expired. Further, a route exists in the Internet 1269 routing system for 10.1.3.0/24 originated from ASN64496. 1270 Additionally, a valid ROA exists for a parent prefix 10.1.0.0/22 and 1271 said ROA is {10.1.0.0/22, maxLength = 24, ASN64511}. No other 1272 covering ROA exists for the prefix (i.e., 10.1.3.0/24). 1274 The Relying Party interpretation would be: Route is Invalid. 1276 7.2.7. Expiry of ROA of Prefix while that of Parent Prefix Prevails 1278 A scan of the ROA list reveals that the ROA {10.1.3.0/24; maxLength = 1279 24, ASN64496} has expired. Further, a route exists in the Internet 1280 routing system for 10.1.3.0/24 originated from ASN64496. 1281 Additionally, a valid ROA exists for a parent prefix 10.1.0.0/22 and 1282 said ROA is {10.1.0.0/22, maxLength = 24, ASN64496}. 1284 The Relying Party interpretation would be: Route is Valid. 1286 7.2.8. Expiry of ROA of Grandparent Prefix while that of Parent Prefix 1287 Prevails 1289 A scan of the ROA list reveals that the ROA {10.1.0.0/20; maxLength = 1290 24, ASN64496} has expired. Further, a route exists in the Internet 1291 routing system for 10.1.3.0/24 originated from ASN64496. 1292 Additionally, a valid ROA exists for a parent prefix 10.1.0.0/22 and 1293 said ROA is {10.1.0.0/22, maxLength = 24, ASN64496}. 1295 The Relying Party interpretation would be: Route is Valid. 1297 8. Acknowledgements 1299 The authors are indebted to both Sandy Murphy and Sam Weiler for 1300 their guidance. Further, the authors would like to thank Steve Kent, 1301 Warren Kumari, Randy Bush, Curtis Villamizar, and Danny McPherson for 1302 their technical insight and review. The authors also wish to thank 1303 Elwyn Davies, Stephen Farrel, Barry Leiba, Stewart Bryant, Alexey 1304 Melnikov, and Russ Housley for their review and comments during the 1305 IESG review process. 1307 9. IANA Considerations 1309 This memo includes no request to IANA. 1311 10. Security Considerations 1313 This memo requires no security considerations 1315 11. References 1317 11.1. Normative References 1319 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1320 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1322 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 1323 Secure Internet Routing", RFC 6480, February 2012. 1325 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 1326 Origin Authorizations (ROAs)", RFC 6482, February 2012. 1328 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 1329 X.509 PKIX Resource Certificates", RFC 6487, 1330 February 2012. 1332 11.2. Informative References 1334 [BRITE] "BRITE: BGPSEC/RPKI Interoperability Test and Evaluation", 1335 Developed by the National Institute of Standards and 1336 Technology (NIST), Gaithersburg, Maryland, 1337 . 1339 [I-D.ietf-idr-as0] 1340 Kumari, W., Bush, R., Schiller, H., and K. Patel, 1341 "Codification of AS 0 processing.", draft-ietf-idr-as0-06 1342 (work in progress), August 2012. 1344 [I-D.ietf-sidr-pfx-validate] 1345 Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 1346 Austein, "BGP Prefix Origin Validation", 1347 draft-ietf-sidr-pfx-validate-10 (work in progress), 1348 October 2012. 1350 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1351 E. Lear, "Address Allocation for Private Internets", 1352 BCP 5, RFC 1918, February 1996. 1354 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 1355 Addresses and AS Identifiers", RFC 3779, June 2004. 1357 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 1358 Algorithms and Identifiers for RSA Cryptography for use in 1359 the Internet X.509 Public Key Infrastructure Certificate 1360 and Certificate Revocation List (CRL) Profile", RFC 4055, 1361 June 2005. 1363 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 1364 (CIDR): The Internet Address Assignment and Aggregation 1365 Plan", BCP 122, RFC 4632, August 2006. 1367 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 1368 Number Space", RFC 4893, May 2007. 1370 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1371 Housley, R., and W. Polk, "Internet X.509 Public Key 1372 Infrastructure Certificate and Certificate Revocation List 1373 (CRL) Profile", RFC 5280, May 2008. 1375 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1376 RFC 5652, September 2009. 1378 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 1379 Reserved for Documentation", RFC 5737, January 2010. 1381 [RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using 1382 AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472, 1383 December 2011. 1385 [RFC6483] Huston, G. and G. Michaelson, "Validation of Route 1386 Origination Using the Resource Certificate Public Key 1387 Infrastructure (PKI) and Route Origin Authorizations 1388 (ROAs)", RFC 6483, February 2012. 1390 Authors' Addresses 1392 Terry Manderson 1393 ICANN 1395 Email: terry.manderson@icann.org 1396 Kotikalapudi Sriram 1397 US NIST 1399 Email: ksriram@nist.gov 1401 Russ White 1402 Verisign 1404 Email: russ@riw.us