RFC 6907
Use Cases and Interpretations of Resource Public Key Infrastructure (RPKI) Objects for Issuers and Relying Parties
Part 1 of 6 🎀
Okay so this is RFC 6907, and the title is Use Cases and Interpretations of Resource Public Key Infrastructure (RPKI) Objects for Issuers and Relying Parties 🦋 It came out in March 2013 and it's Informational, which means it's published for info, not as an Internet Standard 📚 The authors are T. Manderson (ICANN), K. Sriram (US NIST), and R. White (Verisign). It's an IETF product with ISSN 2070-1721. The header doesn't list anything it obsoletes or updates, so there's nothing to flag there ✨
Abstract ✨
ngl this is the vibe check: the doc goes through a bunch of use cases, plus directions and interpretations for organizations and relying parties when they make or run into RPKI object scenarios in the public RPKI 💅 Everything gets talked about in terms of the Internet routing system 🌐
Status of This Memo 🫶
This one is not an Internet Standards Track spec. It's published just for informational purposes 🌸
This is a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community 💖 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 if you want the deets 🔥
Info about the current status, any errata, and how to give feedback lives at http://www.rfc-editor.org/info/rfc6907 🍓
Copyright Notice 🌈
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved 💜
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, bestie, because they spell out your rights and restrictions for this document 🙈 Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🎀
Table of Contents 🦋
1. Introduction ....................................................4
1.1. Terminology ................................................4
1.2. Documentation Prefixes .....................................4
1.3. Definitions ................................................4
2. Overview ........................................................6
2.1. General Interpretation of RPKI Object Semantics ............6
3. Origination Use Cases ...........................................7
3.1. Single Announcement ........................................8
3.2. Aggregate with a More Specific .............................8
3.3. Aggregate with a More Specific from a Different ASN ........9
3.4. Sub-Allocation to a Multi-Homed Customer ...................9
3.5. Restriction of a New Allocation ...........................10
3.6. Restriction of New ASN ....................................11
3.7. Restriction of a Part of an Allocation ....................11
3.8. Restriction of Prefix Length ..............................12
3.9. Restriction of Sub-Allocation Prefix Length ...............13
3.10. Aggregation and Origination by an Upstream Provider ......15
3.11. Rogue Aggregation and Origination by an Upstream
Provider .................................................16
4. Adjacency or Path Validation Use Cases .........................17
5. Partial Deployment Use Cases ...................................18
5.1. Parent Does Not Participate in RPKI .......................18
5.2. Only Some Children Participate in RPKI ....................18
5.3. Grandchild Does Not Participate in RPKI ...................19
6. Transfer Use Cases .............................................20
6.1. Transfer of In-Use Prefix and Autonomous System Number ....20
6.2. Transfer of In-Use Prefix .................................21
6.3. Transfer of Unused Prefix .................................22
7. Relying Party Use Cases ........................................22
7.1. Prefix-Origin Validation Use Cases ........................22
7.1.1. Covering ROA Prefix, maxLength Satisfied,
and AS Match .......................................23
7.1.2. Covering ROA Prefix, maxLength Exceeded,
and AS Match .......................................23
7.1.3. Covering ROA Prefix, maxLength Satisfied,
and AS Mismatch ....................................23
7.1.4. Covering ROA Prefix, maxLength Exceeded,
and AS Mismatch ....................................24
7.1.5. Covering ROA Prefix Not Found ......................24
7.1.6. Covering ROA Prefix and the ROA Is an AS 0 ROA .....24
7.1.7. Covering ROA Prefix Not Found but ROAs
Exist for a Covering Set of More Specifics .........25
7.1.8. AS_SET in Route and Covering ROA Prefix Not Found ..25
7.1.9. Singleton AS in AS_SET (in the Route),
Covering ROA Prefix, and AS Match ..................26
7.1.10. Singleton AS in AS_SET (in the Route),
Covering ROA Prefix, and AS Mismatch ..............26
7.1.11. Multiple ASs in AS_SET (in the Route) and
Covering ROA Prefix ...............................26
7.1.12. Multiple ASs in AS_SET (in the Route) and
ROAs Exist for a Covering Set of More Specifics ...27
7.2. ROA Expiry or Receipt of a CRL Revoking a ROA .............27
7.2.1. ROA of Parent Prefix Is Revoked ....................27
7.2.2. ROA of Prefix Revoked while Parent Prefix
Has Covering ROA Prefix with Different ASN .........28
7.2.3. ROA of Prefix Revoked while That of Parent
Prefix Prevails ....................................28
7.2.4. ROA of Grandparent Prefix Revoked while
That of Parent Prefix Prevails .....................28
7.2.5. Expiry of ROA of Parent Prefix .....................29
7.2.6. Expiry of ROA of Prefix while Parent Prefix
Has Covering ROA with Different ASN ................29
7.2.7. Expiry of ROA of Prefix while That of
Parent Prefix Prevails .............................29
7.2.8. Expiry of ROA of Grandparent Prefix while
That of Parent Prefix Prevails .....................29
8. Acknowledgements ...............................................30
9. Security Considerations ........................................30
10. References ....................................................30
10.1. Normative References .....................................30
10.2. Informative References ...................................301. Introduction 💖
This section is the intro and it says the same thing as the abstract: the doc covers a bunch of use cases with directions and interpretations for organizations and relying parties when they create or encounter RPKI object scenarios in the public RPKI, all in relation to the Internet routing system 🌐✨
1.1. Terminology 🌸
It's assumed you already know the terms and concepts from these docs: "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC5280], "A Profile for X.509 PKIX Resource Certificates" [RFC6487], "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779], "A Profile for Route Origin Authorizations (ROAs)" [RFC6482], "Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)" [RFC6483], and "BGP Prefix Origin Validation" [RFC6811] 🧚
1.2. Documentation Prefixes 🧚
So the documentation prefixes recommended in [RFC5737] aren't enough to use as example prefixes in this doc 🙈 That's why this doc uses RFC 1918 [RFC1918] address space to build its example prefixes 🍓
1.3. Definitions 💖
okay so, for every single use case in this doc, we're assuming RPKI objects (like resource certificates and ROAs) validate under [RFC6487] and [RFC6480]. in other words, if any corrupted RPKI objects exist, we're assuming they've already been spotted and eliminated 🫶
the definitions below are used throughout the doc. some are reused or adapted from [RFC6811], and the authors gave their permission for that ✨
Resource: an IP address prefix (aka a prefix or subnet) or an Autonomous System Number (ASN) 🌸
Allocation: a set of resources given to an entity or organization for its own use 🎀
Sub-allocation: a set of resources that sits under an allocation and is assigned to another entity or organization 🦋
Prefix: a pair of (IP address, prefix length), read the way it's customarily read (see [RFC4632]) 💅
Route: data derived from a received BGP update, as defined in [RFC4271], Section 1.1. the route includes one prefix and an AS_PATH, among other things 🧚
ROA: a Route Origin Authorization (ROA) is an RPKI object signed by a prefix holder. it authorizes origination of that prefix from an origin AS specified in the ROA 🔥
AS 0 ROA: a ROA with ASN value 0 (zero) in the AS ID field. an AS 0 ROA is a prefix holder's attestation that the prefix described in the ROA, and any more specific prefix, should not be used in a routing context [RFC6483] 💀
ROA prefix: the prefix from a ROA 🍓
ROA ASN: the origin ASN from a ROA 🌈
maxLength: the maximum length up to which more specific prefixes of a ROA prefix may be originated from the corresponding ROA ASN. the maxLength is specified in the ROA 💜
Route prefix: a prefix derived from a route 🦋
Route origin ASN: the origin AS number derived from a route. the origin AS number is:
- the rightmost AS in the final segment of the
AS_PATHattribute in the route if that segment is of typeAS_SEQUENCE, or - the BGP speaker's own AS number if that segment is of type
AS_CONFED_SEQUENCEorAS_CONFED_SET, or if theAS_PATHis empty, or - the distinguished value
NONEif the final segment of theAS_PATHattribute is of any other type.
Covering ROA prefix: a ROA prefix that is an exact match or a less specific one compared to the route prefix under consideration. put another way, the route prefix has a covering ROA prefix when there's a ROA where the ROA prefix length is less than or equal to the route prefix length, and the ROA prefix address matches the route prefix address for all bits specified by the ROA prefix length ✨
Covering ROA: if a ROA contains a covering ROA prefix for a route prefix under consideration, then that ROA is said to be a covering ROA for the route prefix 🎀
No covering ROA: no covering ROA exists for a route prefix under consideration 🙈
No other covering ROA: no other covering ROA exists (besides what's already cited) for a route prefix under consideration 🙈
Multi-homed prefix or subnet: a prefix (aka subnet) for which a route is originated through two or more autonomous systems 🌸
Matched: a route's {prefix, origin AS} pair is said to be matched by a ROA when the route prefix has a covering ROA, and additionally, the route prefix length is less than or equal to the maxLength in that covering ROA, and the route origin ASN is equal to the ASN in that covering ROA 👑
okay so, given these definitions, any BGP route will end up with one of the following "validation states" 😭
NotFound: the route prefix has no covering ROA.Valid: the route's {prefix, origin AS} pair is matched by at least one ROA.Invalid: the route prefix has at least one covering ROA, and the route's {prefix, origin AS} pair is not matched by any ROA.
it's worth noting that no ROA can have the value NONE as its ROA ASN. so a route whose origin ASN is NONE can't be matched by any ROA. similarly, no valid route can have an origin ASN of zero [AS0-PROC]. so no route can be matched by a ROA whose ASN is zero (aka an AS 0 ROA) [RFC6483] 🫶
2. Overview ✨
2.1. General Interpretation of RPKI Object Semantics 🌸
for relying parties (RPs), or relying party routing software, it's really important to apply a 'make before break' operational policy. in part, that means an RP should implement a routing decision process where a route is assumed to be intended (aka considered unsuspicious) unless it's proven otherwise by a valid RPKI object that explicitly invalidates the route (see Section 7.1 for examples) 💅
also, especially when a prefix is newly acquired by allocation/sub-allocation or through a prefix-ownership transfer, a ROA should be registered in RPKI before the prefix is advertised in BGP. this is highly recommended, for these reasons 😭
in the transfer case (a prefix moving from Org A to Org B), even though Org A's resource cert would be revoked before a resource cert gets issued to Org B, there may be some latency before all relying parties discard the ROA Org A had previously received for that prefix. that latency could come from CRL propagation delay in the RPKI system, or from periodic polling by RPs, etc. 🦋
also, in the sub-allocation case (from parent Org A to child Org B), there may already be a ROA registered by Org A (with their own origin ASN) for a covering aggregate prefix relative to the prefix in question. if the new prefix owner (Org B) hasn't already registered their own ROA (aka a ROA with their origin ASN), then the presence of that different covering ROA (one with a different origin ASN), belonging to Org A, would result in an invalid assessment for the route advertised by the new owner (Org B) 💀
so in both cases (transfer or sub-allocation), it's prudent for the new owner (Org B) to make sure its route for the prefix will be valid by proactively issuing a ROA before advertising the route. the ROA should be issued with enough lead time, taking the RPKI propagation delays into account 🧚
as stated earlier in Section 1.3, for all of the use cases in this document, it's assumed that RPKI objects (e.g., resource certificates, ROAs) validate under [RFC6487] and [RFC6480]. in other words, if any corrupted RPKI objects exist, we're assuming they've been detected and eliminated 🫶
a lot of the examples here show organizations using their own autonomous system numbers to originate routes. but it should be recognized that a prefix holder doesn't necessarily have to be the holder of the autonomous system number used for the route origination 👑
3. Origination Use Cases 🎀
this section covers the different use cases where an organization has Internet resources and will announce routes to the Internet. it's based on operational observations of the existing routing system. in the following use cases, the phrase "relying parties interpret the route as intended" is generally meant to indicate that "relying parties interpret an announced route as having a valid origination AS" 💖
3.1. Single Announcement 🦋
an organization (Org A with ASN 64496) has been allocated the prefix 10.1.2.0/24. it wants to announce the /24 prefix from ASN 64496 so that relying parties interpret the route as intended ✨
the desired announcement (and organization) would be:
+----------------------------------------------+
| Prefix | Origin AS | Organization |
+----------------------------------------------+
| 10.1.2.0/24 | AS 64496 | Org A |
+----------------------------------------------+the issuing party should create a ROA containing the following:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.2.0/24 | 24 |
+----------------------------------------------+3.2. Aggregate with a More Specific 🌈
an organization (Org A with ASN 64496) has been allocated the prefix 10.1.0.0/16. it wants to announce the more specific prefix 10.1.0.0/20 from ASN 64496, as well as the aggregate route, so that relying parties interpret the routes as intended 🍓
the desired announcements (and organization) would be:
+----------------------------------------------+
| Prefix | Origin AS | Organization |
+----------------------------------------------+
| 10.1.0.0/16 | AS 64496 | Org A |
| 10.1.0.0/20 | AS 64496 | Org A |
+----------------------------------------------+the issuing party should create a ROA containing the following:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 16 |
| |-----------------------------------+
| | 10.1.0.0/20 | 20 |
+----------------------------------------------+3.3. Aggregate with a More Specific from a Different ASN 👑
an organization (Org A with ASN 64496 and ASN 64511) has been allocated the prefix 10.1.0.0/16. it wants to announce the more specific prefix 10.1.0.0/20 from ASN 64511, as well as the aggregate route from ASN 64496, so that relying parties interpret the routes as intended 🔥
the desired announcements (and organization) would be:
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/16 | AS 64496 | Org A |
| 10.1.0.0/20 | AS 64511 | Org A |
+---------------------------------------------+the issuing party should create ROAs containing the following:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 16 |
+----------------------------------------------+ +----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64511 | 10.1.0.0/20 | 20 |
+----------------------------------------------+3.4. Sub-Allocation to a Multi-Homed Customer
okay so bestie 🎀 Org A (ASN 64496) got the prefix 10.1.0.0/16 and wants to announce the more specific 10.1.0.0/20 from ASN 64496. they also handed 10.1.16.0/20 to a customer, Org B (ASN 64511), who is multi-homed and will originate that route from ASN 64511. ASN 64496 is also announcing the aggregate route so that relying parties read everything the way it was meant to be read ✨
The desired announcements (and organizations) would be:
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/16 | AS 64496 | Org A |
| 10.1.0.0/20 | AS 64496 | Org A |
| 10.1.16.0/20 | AS 64511 | Org B |
+---------------------------------------------+The issuing party should create ROAs containing the following:
Org A:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 16 |
| |-----------------------------------+
| | 10.1.0.0/20 | 20 |
+----------------------------------------------+Org B:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64511 | 10.1.16.0/20 | 20 |
+----------------------------------------------+3.5. Restriction of a New Allocation
so an organization just got 10.1.0.0/16 🌸 but the network isn't ready to announce it yet, and they want to block every possible announcement of 10.1.0.0/16 and anything more specific from showing up in routing via RPKI. main character energy, honestly 💅
these announcements would be considered undesirable:
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/16 | ANY AS | ANY |
| 10.1.0.0/20 | ANY AS | ANY |
| 10.1.17.0/24 | ANY AS | ANY |
+---------------------------------------------+The issuing party should create a ROA containing the following:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 0 | 10.1.0.0/16 | 32 |
+----------------------------------------------+This is known as an AS 0 ROA [RFC6483]. Also, please see the definition and related comments in Section 1.3. 🦋
3.6. Restriction of New ASN
okay this one's giving "new toy, not allowed to play with it yet" 🧚 an organization just got an extra ASN, 64511, but their network isn't ready to use it. so they want to shut down every possible use of ASN 64511 using RPKI.
the following announcement would be considered undesirable:
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| ANY | AS 64511 | ANY |
+---------------------------------------------+ngl it is currently not possible to restrict use of autonomous system numbers. 💀
3.7. Restriction of a Part of an Allocation
Org A (ASN 64496) got 10.1.0.0/16 🎀 and their topology only lets them announce 10.1.0.0/17. so they want to restrict any possible announcement of 10.1.128.0/17, or anything more specific than that /17, using RPKI. boundaries bestie, iconic 👑
the desired announcement (and organization) would be:
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/17 | AS 64496 | Org A |
+---------------------------------------------+The following announcements would be considered undesirable:
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.128.0/17 | ANY AS | ANY |
| 10.1.128.0/24 | ANY AS | ANY |
+---------------------------------------------+The issuing party should create ROAs containing the following:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/17 | 17 |
+----------------------------------------------++----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 0 | 10.1.128.0/17 | 32 |
+----------------------------------------------+3.8. Restriction of Prefix Length
Org A (ASN 64496) has 10.1.0.0/16 🌈 and they want to announce the aggregate, plus any or all of the more specifics up to and including a max length of /20. but nothing more specific than a /20, periodt ✨
examples of the desired announcements (and organization) would be:
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/16 | AS 64496 | Org A |
| 10.1.0.0/17 | AS 64496 | Org A |
| ... | AS 64496 | Org A |
| 10.1.128.0/20 | AS 64496 | Org A |
+---------------------------------------------+The following announcements would be considered undesirable:
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/21 | ANY AS | ANY |
| 10.1.0.0/22 | ANY AS | ANY |
| ... | ANY AS | ANY |
| 10.1.128.0/24 | ANY AS | ANY |
+---------------------------------------------+The issuing party should create a ROA containing the following:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 20 |
+----------------------------------------------+3.9. Restriction of Sub-Allocation Prefix Length
Org A (ASN 64496) got 10.1.0.0/16 and then sub-allocated several /20s to its multi-homed customers: Org B (ASN 64501) and Org C (ASN 64499). 🫶 Org A wants to stop those customers from advertising any matching routes more specific than a /22. boss move, honestly.
The desired announcements (and organizations) would be:
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/16 | AS 64496 | Org A |
| 10.1.0.0/20 | AS 64501 | Org B |
| 10.1.128.0/20 | AS 64499 | Org C |
| 10.1.4.0/22 | AS 64501 | Org B |
+---------------------------------------------+The following example announcements (and organizations) would be considered undesirable:
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/24 | AS 64501 | Org B |
| 10.1.128.0/24 | AS 64499 | Org C |
| ..... | ... | ... |
| 10.1.0.0/23 | ANY AS | ANY |
+---------------------------------------------+The issuing party (Org A) should create ROAs containing the following:
For Org A:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 16 |
+----------------------------------------------+For Org B:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64501 | 10.1.0.0/20 | 22 |
+----------------------------------------------+For Org C:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64499 | 10.1.128.0/20 | 22 |
+----------------------------------------------+3.10. Aggregation and Origination by an Upstream Provider
okay so here's the setup 🧚 four organizations, each with their own resources, acquired independently from any transit provider. no shared vibes, just four separate ASNs and prefixes.
+-------------------------------------------------+
| Organization | ASN | Prefix |
+-------------------------------------------------+
| Org A | AS 64496 | 10.1.0.0/24 |
| Org B | AS 64505 | 10.1.3.0/24 |
| Org C | AS 64499 | 10.1.1.0/24 |
| Org D | AS 64511 | 10.1.2.0/24 |
+-------------------------------------------------+These organizations share a common upstream provider, Transit X (ASN 64497), which originates an aggregate of these prefixes with the permission of all four organizations. 🌸
The desired announcements (and organizations) would be:
+----------------------------------------------+
| Prefix | Origin AS | Organization |
+----------------------------------------------+
| 10.1.0.0/24 | AS 64496 | Org A |
| 10.1.3.0/24 | AS 64505 | Org B |
| 10.1.1.0/24 | AS 64499 | Org C |
| 10.1.2.0/24 | AS 64511 | Org D |
| 10.1.0.0/22 | AS 64497 | Transit X |
+----------------------------------------------+It is currently not possible for an upstream provider to make a valid aggregate announcement of independent prefixes. 😭 However, the issuing parties should create ROAs containing the following:
Org A:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/24 | 24 |
+----------------------------------------------+Org B:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64505 | 10.1.3.0/24 | 24 |
+----------------------------------------------+Org C:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64499 | 10.1.1.0/24 | 24 |
+----------------------------------------------+Org D:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64511 | 10.1.2.0/24 | 24 |
+----------------------------------------------+3.11. Rogue Aggregation and Origination by an Upstream Provider 🦋
okay so picture this: four orgs, each one got its resources independently, not through any transit provider 👀
+-------------------------------------------------+
| Organization | ASN | Prefix |
+-------------------------------------------------+
| Org A | AS 64496 | 10.1.0.0/24 |
| Org B | AS 64503 | 10.1.3.0/24 |
| Org C | AS 64499 | 10.1.1.0/24 |
| Org D | AS 64511 | 10.1.2.0/24 |
+-------------------------------------------------+All four share an upstream, Transit X (ASN 64497), who likes to originate an aggregate of these prefixes wherever it can. But Org B (ASN 64503, 10.1.3.0/24) is like "absolutely not, don't aggregate my prefix" 🙅♀️
The announcements we want to see are:
+----------------------------------------------+
| Prefix | Origin AS | Organization |
+----------------------------------------------+
| 10.1.0.0/24 | AS 64496 | Org A |
| 10.1.3.0/24 | AS 64503 | Org B |
| 10.1.1.0/24 | AS 64499 | Org C |
| 10.1.2.0/24 | AS 64511 | Org D |
| 10.1.0.0/23 | AS 64497 | Transit X |
+----------------------------------------------+And this one is a big nope 🙈
+----------------------------------------------+
| Prefix | Origin AS | Organization |
+----------------------------------------------+
| 10.1.0.0/22 | AS 64497 | Transit X |
+----------------------------------------------+Here's the tea: it is currently not possible for an upstream provider to make a valid aggregate announcement of independent prefixes. So instead, the issuing parties should create ROAs containing the following 💅
Org A:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/24 | 24 |
+----------------------------------------------+Org B:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64503 | 10.1.3.0/24 | 24 |
+----------------------------------------------+Org C:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64499 | 10.1.1.0/24 | 24 |
+----------------------------------------------+Org D:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64511 | 10.1.2.0/24 | 24 |
+----------------------------------------------+4. Adjacency or Path Validation Use Cases 🧚
Use cases about adjacency or path validation are beyond the scope of this document. They'll be covered in a separate document, so stay tuned 👀
5. Partial Deployment Use Cases 🌈
5.1. Parent Does Not Participate in RPKI 💀
Okay, so an organization (Org A with ASN 64511) is multi-homed and got the prefix 10.1.0.0/20 from its upstream, Transit X (ASN 64496). Org A wants to announce 10.1.0.0/20 from ASN 64511 to its other upstream(s). Org A also wants to make RPKI statements about the resource, but the problem is Transit X (ASN 64496), which announces the aggregate 10.1.0.0/16, hasn't adopted RPKI yet 😭
The desired announcements (and the organization with RPKI adoption) would be:
+----------------------------------------------------+
| Prefix | Origin AS |Organization | RPKI |
+----------------------------------------------------+
| 10.1.0.0/20 | AS 64511 | Org A | Yes |
| 10.1.0.0/16 | AS 64496 | Transit X | No |
+----------------------------------------------------+RPKI is strictly hierarchical, so if Transit X doesn't participate in RPKI, Org A is unable to validly issue RPKI objects. Real talk, that's a bummer 💔
5.2. Only Some Children Participate in RPKI 🎀
So an organization (Org A with ASN 64496) has been allocated the prefix 10.1.0.0/16 and participates in RPKI. They want to announce the more specific prefix 10.1.0.0/20 from ASN 64496. They've also delegated 10.1.16.0/20 and 10.1.32.0/20 to customers Org B (ASN 64511) and Org C (ASN 64502), respectively, and both of those customers are multi-homed. The thing is, Org B (ASN 64511) doesn't participate in RPKI, but Org C (ASN 64502) does 🦋
The desired announcements (and organizations with RPKI adoption) would be:
+----------------------------------------------------+
| Prefix | Origin AS |Organization | RPKI |
+----------------------------------------------------+
| 10.1.0.0/16 | AS 64496 | Org A | Yes |
| 10.1.0.0/20 | AS 64496 | Org A | Yes |
| 10.1.16.0/20 | AS 64511 | Org B | No |
| 10.1.32.0/20 | AS 64502 | Org C | Yes |
+----------------------------------------------------+The issuing parties should create ROAs containing the following:
Org A:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 16 |
+----------------------------------------------+
| | 10.1.0.0/20 | 20 |
+----------------------------------------------+Org A issues for Org B:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64511 | 10.1.16.0/20 | 20 |
+----------------------------------------------+Org C:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64502 | 10.1.32.0/20 | 20 |
+----------------------------------------------+5.3. Grandchild Does Not Participate in RPKI 🫶
Let's keep going with the previous example, but now Org B (who doesn't participate in RPKI) goes and allocates 10.1.17.0/24 to Org X with ASN 64505. Org X doesn't participate in RPKI either. Chaotic, but here we are 😭
The desired announcements (and organizations with RPKI adoption) would be:
+----------------------------------------------------+
| Prefix | Origin AS |Organization | RPKI |
+----------------------------------------------------+
| 10.1.0.0/16 | AS 64496 | Org A | Yes |
| 10.1.0.0/20 | AS 64496 | Org A | Yes |
| 10.1.16.0/20 | AS 64511 | Org B | No |
| 10.1.32.0/20 | AS 64502 | Org C | Yes |
| 10.1.17.0/24 | AS 64505 | Org X | No |
+----------------------------------------------------+The issuing parties should create ROAs containing the following:
Org A:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 16 |
+----------------------------------------------+
| | 10.1.0.0/20 | 20 |
+----------------------------------------------+Org A issues for Org B:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64511 | 10.1.16.0/20 | 20 |
+----------------------------------------------+Org A issues for Org B's customer Org X:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64505 | 10.1.17.0/24 | 24 |
+----------------------------------------------+Org C:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64502 | 10.1.32.0/20 | 20 |
+----------------------------------------------+6. Transfer Use Cases ✨
For transfer use cases, based on the sections before this one, it should be easy to figure out which new ROAs need to be created and which existing ROAs need to be kept (or revoked). The resource transfer and the timing of ROA revocation and creation need to happen using the make-before-break principle, plus the right Regional Internet Registry (RIR) procedures (see Section 2.1). Basically, the new stuff goes up before the old stuff comes down 🧚
6.1. Transfer of In-Use Prefix and Autonomous System Number 👑
Org A holds the resource 10.1.0.0/20. It's currently in use and originated from AS 64496 with valid RPKI objects in place. Org B has acquired both the prefix and the ASN, and they want an RPKI transfer on a particular date and time without messing up the operational use of the resource 💖
The following RPKI objects would be created/revoked:
For Org A, revoke the following ROA:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/20 | 20 |
+----------------------------------------------+For Org B, add the following ROA:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/20 | 20 |
+----------------------------------------------+6.2. Transfer of In-Use Prefix 🌸
Org A holds the resource 10.1.0.0/16. It's currently in use and originated from AS 64496 with valid RPKI objects in place. Org A has agreed to transfer the entire /16 address block to Org B, and they won't originate the prefix or any more specifics of it anymore. So Org B wants an RPKI transfer of this resource on a particular date and time. After the transfer, this prefix will be originated by AS 64511 🦋
The following RPKI objects would be created/revoked:
For Org A, revoke the following ROA:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 16 |
+----------------------------------------------+For Org B, add the following ROA when the resource certificate for 10.1.0.0/16 is issued to them (Org B):
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64511 | 10.1.0.0/16 | 16 |
+----------------------------------------------+6.3. Transfer of Unused Prefix ✨
okay so Org A holds the resources 10.1.0.0/16 and AS 64507 (with RPKI objects) 🎀. Org A is currently announcing 10.1.0.0/16 from AS 64507. Org B grabbed an unused little piece, 10.1.4.0/24, from Org A and wants an RPKI transfer at a specific date and time 💅. Org B is going to originate the route 10.1.4.0/24 from AS 64496 🦋.
Here's the RPKI objects that would be created/sustained 🌸:
For Org A, leave the following ROA unchanged:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64507 | 10.1.0.0/16 | 16 |
+----------------------------------------------+For Org B, add the following ROA when the resource certificate for 10.1.4.0/24 is issued to them (Org B) 🧚:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.4.0/24 | 24 |
+----------------------------------------------+Org A may optionally provide ROA coverage for Org B by creating the following ROA before the RPKI transfer. Then the ROA itself is naturally revoked when 10.1.4.0/24 is transferred to Org B's resource certificate ✨. It's giving neat handoff 🫶.
Org A adds the following ROA:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.4.0/24 | 24 |
+----------------------------------------------+7. Relying Party Use Cases 🌈
7.1. Prefix-Origin Validation Use Cases 🔥
okay this section is the big one bestie 😭. These use cases try to systematically list every situation a relying party might run into while it's receiving a BGP update and using ROA info to figure out whether the prefix-origin info in the routes from that update is valid 💜. For each one we list the situation and a recommended expected outcome for prefix-origin validation. For how prefix-origin validation algorithms actually work, check [RFC6483] and [RFC6811] 📚. We use the terms Valid, Invalid, and NotFound the way [RFC6811] defines them, and they're summarized earlier in Section 1.3. Also look at [RFC6472] for the recommendation to deprecate AS_SETs in BGP updates 🙈. These use cases can be used as test cases for testing and evaluating prefix-origin validation in router implementations too. See, for example, [BRITE] 💅.
7.1.1. Covering ROA Prefix, maxLength Satisfied, and AS Match
ROA: {10.1.0.0/16, maxLength = 20, AS 64496}
Route has {10.1.0.0/17, Origin = AS 64496}
Recommended RPKI prefix-origin validation interpretation: Route is Valid. ✨
Comment: The route prefix has a covering ROA prefix, and the route origin ASN matches the ROA ASN. This is a totally straightforward prefix-origin validation case, and it's exactly what the prefix holder was going for when they made the ROA 🎀.
7.1.2. Covering ROA Prefix, maxLength Exceeded, and AS Match
ROA: {10.1.0.0/16, maxLength = 20, AS 64496}
Route has {10.1.0.0/22, Origin = AS 64496}
No other covering ROA
Recommended RPKI prefix-origin validation interpretation: Route is Invalid. 💀
Comment: Here the route prefix goes past the maxLength the ROA allows. Not it 🙅♀️.
7.1.3. Covering ROA Prefix, maxLength Satisfied, and AS Mismatch
ROA: {10.1.0.0/16, maxLength = 24, AS 64496}
Route has {10.1.88.0/24, Origin = AS 64511}
No other covering ROA
Recommended RPKI prefix-origin validation interpretation: Route is Invalid. 🚨
Comment: Here some AS other than the one in the ROA is originating the route. This might be a prefix or subprefix hijack situation 👀.
7.1.4. Covering ROA Prefix, maxLength Exceeded, and AS Mismatch
ROA: {10.1.0.0/16, maxLength = 22, AS 64496}
Route has {10.1.88.0/24, Origin = AS 64511}
No other covering ROA
Recommended RPKI prefix-origin validation interpretation: Route is Invalid. 😭
Comment: Double whammy here 😭. The maxLength in the ROA gets exceeded by the route prefix, AND an AS other than the one in the ROA is originating the route. This might be a subprefix hijack situation.
7.1.5. Covering ROA Prefix Not Found
Route has {10.1.3.0/24, Origin = AS 64511}
No covering ROA
Recommended RPKI prefix-origin validation interpretation: Route's validation status is NotFound. 🤷♀️
Comment: In this case there's no covering ROA for the route prefix. It could be a prefix or subprefix hijack situation, but this announcement doesn't contradict any existing ROA. During partial deployment there'd be legit prefix-origin announcements that just don't have ROAs issued yet, so NotFound is kind of the honest answer 🌸.
7.1.6. Covering ROA Prefix and the ROA Is an AS 0 ROA
ROA: {10.1.0.0/16, maxLength = 32, AS 0}
Route has {10.1.5.0/24, Origin = AS 64511}
Recommended RPKI prefix-origin validation interpretation: Route's validation status is Invalid. 🚫
Comment: An AS 0 ROA means, by definition, that the prefix listed in it and all of its more specifics shouldn't be used in a routing context [RFC6483] [AS0-PROC]. Also, check out the related comments in Section 1.3 💖.
7.1.7. Covering ROA Prefix Not Found but ROAs Exist for a Covering Set of More Specifics
ROA: {10.1.0.0/18, maxLength = 20, AS 64496}
ROA: {10.1.64.0/18, maxLength = 20, AS 64496}
ROA: {10.1.128.0/18, maxLength = 20, AS 64496}
ROA: {10.1.192.0/18, maxLength = 20, AS 64496}
Route has {10.1.0.0/16, Origin = AS 64496}
No covering ROA
Recommended RPKI prefix-origin validation interpretation: Route's validation status is NotFound. 🧩
Comment: The route prefix here is an aggregate (/16), and it turns out there are ROAs for the more specifics (/18s) that, if you combine them, could help support validation of the announced prefix-origin pair. But it's super hard in general to break an announced prefix up into its more specifics and check for ROA coverage on each one, so this kind of accommodation is not recommended 🙈.
7.1.8. AS_SET in Route and Covering ROA Prefix Not Found
Route has {10.1.0.0/16, AS_SET [AS 64496, AS 64497, AS 64498, AS 64499] appears in the rightmost position in the AS_PATH}
No covering ROA
Recommended RPKI prefix-origin validation interpretation: Route's validation status is NotFound. 🫠
Comment: Only a tiny slice (~0.1%) of external BGP (eBGP) updates have an AS_SET in them, and that's known as proxy aggregation 🍓. In this case the route with the AS_SET doesn't conflict with any ROA, since the route prefix has no covering ROA prefix. So the route gets NotFound validation status.
7.1.9. Singleton AS in AS_SET (in the Route), Covering ROA Prefix, and AS Match
Route has {10.1.0.0/24, AS_SET [AS 64496] appears in the rightmost position in the AS_PATH}
ROA: {10.1.0.0/22, maxLength = 24, AS 64496}
Recommended RPKI prefix-origin validation interpretation: Route is Invalid. 🛑
Comment: In the spirit of [RFC6472], any route with an AS_SET in it should not be considered valid (by ROA-based validation). If the route has an AS_SET and a covering ROA prefix exists for the route prefix, the route should get an Invalid status. (Note: AS match or mismatch consideration does not apply.) 💅
7.1.10. Singleton AS in AS_SET (in the Route), Covering ROA Prefix, and AS Mismatch
Route has {10.1.0.0/24, AS_SET [AS 64496] appears in the rightmost position in the AS_PATH}
ROA: {10.1.0.0/22, maxLength = 24, AS 64511}
Recommended RPKI prefix-origin validation interpretation: Route is Invalid. 🚫
Comment: If the route has an AS_SET and a covering ROA prefix exists for the route prefix, the route should get an Invalid status. (Note: AS match or mismatch consideration does not apply.) 🙅♀️
7.1.11. Multiple ASs in AS_SET (in the Route) and Covering ROA Prefix
Route has {10.1.0.0/22, AS_SET [AS 64496, AS 64497, AS 64498, AS 64499] appears in the rightmost position in the AS_PATH}
ROA: {10.1.0.0/22, maxLength = 24, AS 64509}
No other covering ROA
Recommended RPKI prefix-origin validation interpretation: Route is Invalid. 💀
Comment: If the route has an AS_SET and a covering ROA prefix exists for the route prefix, the route should get an Invalid status. It's giving no notes 📝.
7.1.12. Multiple ASs in AS_SET (in the Route) and ROAs Exist for a Covering Set of More Specifics
ROA: {10.1.0.0/18, maxLength = 20, AS 64496}
ROA: {10.1.64.0/18, maxLength = 20, AS 64497}
ROA: {10.1.128.0/18, maxLength = 20, AS 64498}
ROA: {10.1.192.0/18, maxLength = 20, AS 64499}
Route has {10.1.0.0/16, AS_SET [AS 64496, AS 64497, AS 64498, AS 64499] appears in the rightmost position in the AS_PATH}
No covering ROA
Recommended RPKI prefix-origin validation interpretation: Route's validation status is NotFound. 🧐
Comment: In this case the aggregate of the prefixes in the ROAs is a covering prefix (exact match or less specific) relative to the route prefix. The ASs in each of the contributing ROAs together form a set that matches the AS_SET in the route. But again, it's super hard in general to break an announced prefix into its more specifics and check ROA coverage for each. And in the spirit of [RFC6472], any route with an AS_SET in it should not be considered valid (by ROA-based validation). Honestly, the route here would have gotten an Invalid status if the route prefix had at least one covering ROA prefix 😭.
7.2. ROA Expiry or Receipt of a CRL Revoking a ROA 🥀
Here we list the use cases for what routers do when RPKI objects expire or get revoked 🕰️. In the cases that follow, "expired ROA" and "revoked ROA" are shorthand. They describe the expiry or revocation of the End Entity (EE) or resource certificate that makes a relying party consider the matching ROA to have expired or been revoked, respectively 💜.
7.2.1. ROA of Parent Prefix Is Revoked
A certificate revocation list (CRL) comes in and reveals that the ROA {10.1.0.0/22, maxLength = 24, ASN 64496} is revoked. Also, a route exists in the Internet routing system for 10.1.3.0/24 originated from ASN 64496. Without that revoked ROA, no covering ROA prefix exists for the route prefix (i.e., 10.1.3.0/24) 😬.
The Relying Party interpretation would be: Route's validation status is NotFound. 🌫️
7.2.2. ROA of Prefix Revoked while Parent Prefix Has Covering ROA Prefix with Different ASN
A CRL comes in and reveals that the ROA {10.1.3.0/24, maxLength = 24, ASN 64496} is revoked. Also, a route exists in the Internet routing system for 10.1.3.0/24 originated from ASN 64496. On top of that, a valid ROA exists for a parent prefix 10.1.0.0/22, and that ROA is {10.1.0.0/22, maxLength = 24, ASN 64511}. No other covering ROA exists for the 10.1.3.0/24 prefix 🧵.
The Relying Party interpretation would be: Route is Invalid. 🚨
7.2.3. ROA of Prefix Revoked while That of Parent Prefix Prevails ✨
okay so a CRL drops and it reveals that the ROA {10.1.3.0/24, maxLength = 24, ASN 64496} is revoked 💀. But there's still a route in the Internet routing system for 10.1.3.0/24 coming from ASN 64496 🛣️. And a valid ROA exists for the parent prefix 10.1.0.0/22, which is {10.1.0.0/22, maxLength = 24, ASN 64496} 🫶.
The Relying Party interpretation would be: Route is Valid 💅
(Clarification: Perhaps the revocation of the ROA for prefix 10.1.3.0/24 was initiated just to eliminate redundancy.) 🌸
7.2.4. ROA of Grandparent Prefix Revoked while That of Parent Prefix Prevails 🦋
so this one is giving the same vibe but with a grandparent 👵. A CRL reveals that the ROA {10.1.0.0/20, maxLength = 24, ASN 64496} is revoked. There's a route in the Internet routing system for 10.1.3.0/24 originated from ASN 64496, and a valid ROA exists for the parent prefix 10.1.0.0/22, which is {10.1.0.0/22, maxLength = 24, ASN 64496} ✨.
The Relying Party interpretation would be: Route is Valid 🎀
(Clarification: The ROA for less specific grandparent prefix 10.1.0.0/20 was revoked or withdrawn.) 🧚
7.2.5. Expiry of ROA of Parent Prefix 🥀
a scan of the ROA list shows that the ROA {10.1.0.0/22, maxLength = 24, ASN 64496} has expired 😭. There's a route in the Internet routing system for 10.1.3.0/24 originated from ASN 64496. Without that expired ROA, there's no covering ROA prefix left for the route prefix (aka 10.1.3.0/24) 🙈.
The Relying Party interpretation would be: Route's validation status is NotFound 🍓
7.2.6. Expiry of ROA of Prefix while Parent Prefix Has Covering ROA with Different ASN 🚫
ugh, okay, a scan of the ROA list reveals that the ROA {10.1.3.0/24, maxLength = 24, ASN 64496} has expired 😩. A route exists in the Internet routing system for 10.1.3.0/24 originated from ASN 64496. Now, a valid ROA exists for the parent prefix 10.1.0.0/22, but this one is {10.1.0.0/22, maxLength = 24, ASN 64511}, a different ASN 👀. No other covering ROA exists for the prefix (aka 10.1.3.0/24), so yeah, that's the drama.
The Relying Party interpretation would be: Route is Invalid 💀
7.2.7. Expiry of ROA of Prefix while That of Parent Prefix Prevails 🌈
same kind of scan, same kind of expired ROA: {10.1.3.0/24, maxLength = 24, ASN 64496} is expired 🥲. The route for 10.1.3.0/24 from ASN 64496 is still out there. But the parent prefix 10.1.0.0/22 has a valid ROA, {10.1.0.0/22, maxLength = 24, ASN 64496}, and it's the same ASN, so the parent carries it 🙌.
The Relying Party interpretation would be: Route is Valid 👑
7.2.8. Expiry of ROA of Grandparent Prefix while That of Parent Prefix Prevails 🍑
last one in this bunch 🫡. A scan of the ROA list reveals that the ROA {10.1.0.0/20, maxLength = 24, ASN 64496} has expired. A route exists in the Internet routing system for 10.1.3.0/24 originated from ASN 64496. The parent prefix 10.1.0.0/22 still has a valid ROA, {10.1.0.0/22, maxLength = 24, ASN 64496}, so the route stays valid 💖.
The Relying Party interpretation would be: Route is Valid ✨
8. Acknowledgements 🫶
the authors are obsessed with Sandy Murphy and Sam Weiler for their guidance 💜. They also want to thank Steve Kent, Warren Kumari, Randy Bush, Curtis Villamizar, and Danny McPherson for their technical insight and review 🧠. And a big shoutout to Elwyn Davies, Stephen Farrell, Barry Leiba, Stewart Bryant, Alexey Melnikov, and Russ Housley for their review and comments during the IESG review process 📣.
9. Security Considerations 🔒
this memo requires no security considerations 🙌. Nothing extra to worry about here, bestie 🍓.
10. References 📚
10.1. Normative References
- [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
- [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
- [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012.
- [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, February 2012.
10.2. Informative References
- [AS0-PROC] Kumari, W., Bush, R., Schiller, H., and K. Patel, "Codification of AS 0 processing", Work in Progress, August 2012.
- [BRITE] NIST, "BRITE - BGPSEC / RPKI Interoperability Test & Evaluation", Developed by the National Institute of Standards and Technology (NIST), Gaithersburg, Maryland, 2011,
http://brite.antd.nist.gov/statics/about. - [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
- [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
- [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
- [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
- [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks Reserved for Documentation", RFC 5737, January 2010.
- [RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472, December 2011.
- [RFC6483] Huston, G. and G. Michaelson, "Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)", RFC 6483, February 2012.
- [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, January 2013.
Authors' Addresses 🎀
Terry Manderson ICANN
EMail: terry.manderson@icann.org
Kotikalapudi Sriram US NIST
EMail: ksriram@nist.gov
Russ White Verisign
EMail: russ@riw.us
📦 where this page comes from
- ietf: rfc6907 2013-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms