Internet DRAFT - draft-ietf-sidr-usecases
draft-ietf-sidr-usecases
Secure Inter-Domain Routing T. Manderson
Internet-Draft ICANN
Intended status: Informational K. Sriram
Expires: July 18, 2013 US NIST
R. White
Verisign
January 14, 2013
Use Cases and Interpretation of RPKI Objects for Issuers and Relying
Parties
draft-ietf-sidr-usecases-06
Abstract
This document describes a number of use cases together with
directions and interpretations for organizations and relying parties
when creating or encountering Resource Public Key Infrastructure
(RPKI)object scenarios in the public RPKI. All of the above are
discussed here in relation to the Internet routing system.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 18, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Manderson, et al. Expires July 18, 2013 [Page 1]
Internet-Draft RPKI Use Case and Interpretations January 2013
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided 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 . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . 14
3.11. Rogue Aggregation and Origination by an Upstream . . . . . 16
4. Adjacency or Path Validation Use Cases . . . . . . . . . . . . 17
5. Partial Deployment Use Cases . . . . . . . . . . . . . . . . . 17
5.1. Parent Does Not Participate in RPKI . . . . . . . . . . . 17
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 AS0 ROA . . . . 24
7.1.7. Covering ROA Prefix Not Found but ROAs Exist for a
Manderson, et al. Expires July 18, 2013 [Page 2]
Internet-Draft RPKI Use Case and Interpretations January 2013
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 . . . . . . . . . . . . 28
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 . . . . . . . . . . . . . . . . . . . . . . . 29
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
11.1. Normative References . . . . . . . . . . . . . . . . . . . 30
11.2. Informative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
Manderson, et al. Expires July 18, 2013 [Page 3]
Internet-Draft RPKI Use Case and Interpretations January 2013
1. Introduction
This document describes a number of use cases together with
directions and interpretations for organizations and relying parties
when creating or encountering Resource Public Key Infrastructure
(RPKI)object scenarios in the public RPKI. All of the above are
discussed here in relation to the Internet routing system.
1.1. Terminology
It is assumed that the reader is familiar with the terms and concepts
described in "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" [I-D.ietf-sidr-pfx-validate].
1.2. Documentation Prefixes
The documentation prefixes recommended in [RFC5737] are insufficient
for use as example prefixes in this document. Therefore, this
document uses RFC1918 [RFC1918] address space for constructing
example prefixes.
1.3. Definitions
For all of the use cases in this document it is assumed that RPKI
objects (e.g., resource certificates, ROAs) validate in accordance
with [RFC6487] and [RFC6480]. In other words, we assume that
corrupted RPKI objects, if any, have been detected and eliminated.
The following definitions are in use in this document. Some of these
definitions are reused or adapted from [I-D.ietf-sidr-pfx-validate]
with authors' permission.
Resource: An IP address prefix (simply called prefix or subnet) or an
Autonomous System Number (ASN).
Allocation: A set of resources provided to an entity or organization
for its use.
Sub-allocation: A set of resources subordinate to an allocation
assigned to another entity or organization.
Prefix: A prefix consists of a pair (IP address, prefix length),
Manderson, et al. Expires July 18, 2013 [Page 4]
Internet-Draft RPKI Use Case and Interpretations January 2013
interpreted as is customary (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: Route Origin Authorization(ROA) is an RPKI object signed by a
prefix holder authorizing origination of said prefix from an origin
AS specified in said ROA.
AS0 ROA: A ROA with ASN value 0 (zero) in the AS ID field. AS0 ROA
is an attestation by a prefix holder 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:
o the rightmost AS in the final segment of the AS_PATH attribute in
the route if that segment is of type AS_SEQUENCE, or
o the BGP speaker's own AS number if that segment is of type
AS_CONFED_SEQUENCE or AS_CONFED_SET or if the AS_PATH is empty, or
o the distinguished value "NONE" if the final segment of the AS_PATH
attribute is of any other type.
Covering ROA prefix: A ROA prefix that is an exact match or a less
specific when compared to the route prefix under consideration. In
other words, the route prefix is said to have a covering ROA prefix
when there exists a ROA such that 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 the ROA is said to be a covering ROA
for the route prefix.
Manderson, et al. Expires July 18, 2013 [Page 5]
Internet-Draft RPKI Use Case and Interpretations January 2013
No covering ROA: No covering ROA exists for a route prefix under
consideration.
No other covering ROA: No other covering ROA exists (besides what is
(are) already cited) for a route prefix under consideration.
Multi-homed prefix or subnet: A prefix (i.e., 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 in addition, the
route prefix length is less than or equal to the maxLength in said
covering ROA and the route origin ASN is equal to the ASN in said
covering ROA.
Given these definitions, any given BGP route will be found to have
one of the following "validation states":
o NotFound: The route prefix has no covering ROA.
o Valid: The route's {prefix, origin AS} pair is matched by at least
one ROA.
o 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 is to be noted that that no ROA can have the value "NONE" as its
ROA ASN. Thus a route whose origin ASN is "NONE" cannot be matched
by any ROA. Similarly, no valid route can have an origin ASN of zero
[I-D.ietf-idr-as0]. Thus no route can be matched by a ROA whose ASN
is zero (i.e., an AS0 ROA) [RFC6483].
2. Overview
2.1. General interpretation of RPKI object semantics
It is important that in the interpretation of relying parties (RP),
or relying party routing software, that a 'make before break'
operational policy is applied. This means in part that a RP should
implement a routing decision process where a route is assumed to be
intended (i.e., considered unsuspicious) unless proven otherwise by
the existence of a valid RPKI object that explicitly invalidates the
route (see Section 7.1 for examples). Also, especially in cases when
a prefix is newly acquired by allocation/suballocation or due to
prefix-ownership transfer, a ROA should be registered in RPKI prior
to advertisement of the prefix in BGP. This is highly recommended
for the following reasons. Observe that in the transfer case
Manderson, et al. Expires July 18, 2013 [Page 6]
Internet-Draft RPKI Use Case and Interpretations January 2013
(considering a prefix transfer from Org-A to Org-B), even though
Org-A's resource cert would be revoked before issuing a resource cert
to Org-B, there may be some latency before all relying parties
discard the previously received ROA of Org-A for that prefix. The
latency may be due to CRL propagation delay in the RPKI system or due
to periodic polling by RPs, etc. Also, observe that in the
suballocation case (from parent Org-A to child Org-B), there may be
an existing ROA registered by Org-A (with their own origin ASN) for a
covering aggregate prefix relative to the prefix in consideration.
If the new prefix owner (Org-B) has not already registered their own
ROA (i.e., ROA with their origin ASN), then the presence of a
different covering ROA (i.e., one with a different origin ASN)
belonging to Org-A would result in invalid assessment for the route
advertised by the new owner (Org-B). Thus in both cases (transfer or
suballocation), it is prudent for the new owner (Org-B) to ensure
that its route for the prefix will be valid by proactively issuing a
ROA before advertising the route. The ROA should be issued with
sufficient lead time taking into consideration the RPKI propagation
delays.
As stated earlier in Section 1.3, for all of the use cases in this
document it is assumed that RPKI objects (e.g., resource
certificates, ROAs) validate in accordance with [RFC6487] and
[RFC6480]. In other words, we assume that corrupted RPKI objects, if
any, have been detected and eliminated.
While many of the examples provided here illustrate organizations
using their own autonomous system numbers to originate routes, it
should be recognized that a prefix holder need not necessarily be the
holder of the autonomous system number used for the route
origination.
3. Origination Use Cases
This section deals with the various use cases where an organization
has Internet resources and will announce routes to the Internet. It
is 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 wishes to announce the /24 prefix from ASN 64496
such that relying parties interpret the route as intended.
Manderson, et al. Expires July 18, 2013 [Page 7]
Internet-Draft RPKI Use Case and Interpretations January 2013
The desired announcement (and organization) would be:
+----------------------------------------------+
| Prefix | Origin AS | Organization |
+----------------------------------------------+
| 10.1.2.0/24 | AS64496 | 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 wishes to announce the more specific prefix
10.1.0.0/20 from ASN 64496 as well as the aggregate route such that
relying parties interpret the routes as intended.
The desired announcements (and organization) would be:
+----------------------------------------------+
| Prefix | Origin AS | Organization |
+----------------------------------------------+
| 10.1.0.0/16 | AS64496 | Org A |
| 10.1.0.0/20 | AS64496 | 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 |
+----------------------------------------------+
Manderson, et al. Expires July 18, 2013 [Page 8]
Internet-Draft RPKI Use Case and Interpretations January 2013
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 wishes to announce the more
specific prefix 10.1.0.0/20 from ASN 64511 as well as the aggregate
route from ASN 64496 such that relying parties interpret the routes
as intended.
The desired announcements (and organization) would be:
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/16 | AS64496 | Org A |
| 10.1.0.0/20 | AS64511 | 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
An organization (Org A with ASN 64496) has been allocated the prefix
10.1.0.0/16; it wishes to announce the more specific prefix
10.1.0.0/20 from ASN 64496. It has further delegated 10.1.16.0/20 to
a customer (Org B with ASN 64511) who is multi-homed and will
originate the prefix route from ASN 64511. ASN 64496 will also
announce the aggregate route such that relying parties interpret the
routes as intended.
The desired announcements (and organization) would be:
Manderson, et al. Expires July 18, 2013 [Page 9]
Internet-Draft RPKI Use Case and Interpretations January 2013
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/16 | AS64496 | Org A |
| 10.1.0.0/20 | AS64496 | Org A |
| 10.1.16.0/20 | AS64511 | 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
An organization has recently been allocated the prefix 10.1.0.0/16.
Its network deployment is not yet ready to announce the prefix and
wishes to restrict all possible announcements of 10.1.0.0/16 and more
specifics in routing using RPKI.
The following 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:
Manderson, et al. Expires July 18, 2013 [Page 10]
Internet-Draft RPKI Use Case and Interpretations January 2013
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 0 | 10.1.0.0/16 | 32 |
+----------------------------------------------+
This is known as an AS0 ROA [RFC6483]. Also, please see the
definition and related comments in Section 1.3.
3.6. Restriction of New ASN
An organization has recently been allocated an additional ASN 64511.
Its network deployment is not yet ready to use this ASN and wishes to
restrict all possible uses of ASN 64511 using RPKI.
The following announcements would be considered undesirable:
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| ANY | AS64511 | ANY |
+---------------------------------------------+
It is currently not possible to restrict use of Autonomous System
Numbers
3.7. Restriction of a Part of an Allocation
An organization (Org A with ASN 64496) has been allocated the prefix
10.1.0.0/16. Its network topology permits the announcement of
10.1.0.0/17. Org A wishes to restrict any possible announcement of
10.1.128.0/17 or more specifics of that /17 using RPKI.
The desired announcements would be:
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/17 | AS64496 | Org A |
+---------------------------------------------+
The following announcements would be considered undesirable:
Manderson, et al. Expires July 18, 2013 [Page 11]
Internet-Draft RPKI Use Case and Interpretations January 2013
+---------------------------------------------+
| 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
An organization (Org A with ASN 64496) has been allocated the prefix
10.1.0.0/16; it wishes to announce the aggregate and any or all more
specific prefixes up to and including a maximum length of /20, but
never any more specific than a /20.
Examples of the desired announcements (and organization) would be:
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/16 | AS64496 | Org A |
| 10.1.0.0/17 | AS64496 | Org A |
| ... | AS64496 | Org A |
| 10.1.128.0/20 | AS64496 | Org A |
+---------------------------------------------+
The following announcements would be considered undesirable:
Manderson, et al. Expires July 18, 2013 [Page 12]
Internet-Draft RPKI Use Case and Interpretations January 2013
+---------------------------------------------+
| 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
An organization (Org A with ASN 64496) has been allocated the prefix
10.1.0.0/16; it sub-allocates several /20 prefixes to its multi-homed
customers Org B with ASN 64501, and Org C with ASN 64499. It wishes
to restrict those customers from advertising any corresponding routes
more specific than a /22.
The desired announcements would be:
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/16 | AS64496 | Org A |
| 10.1.0.0/20 | AS64501 | Org B |
| 10.1.128.0/20 | AS64499 | Org C |
| 10.1.4.0/22 | AS64501 | Org B
+---------------------------------------------+
The following example announcements (and organization) would be
considered undesirable:
Manderson, et al. Expires July 18, 2013 [Page 13]
Internet-Draft RPKI Use Case and Interpretations January 2013
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/24 | AS64501 | Org B |
| 10.1.128.0/24 | AS64499 | 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
Consider four organizations with the following resources, which were
acquired independently from any transit provider.
+-------------------------------------------------+
| Organization | ASN | Prefix |
+-------------------------------------------------+
| Org A | AS64496 | 10.1.0.0/24 |
| Org B | AS64505 | 10.1.3.0/24 |
| Org C | AS64499 | 10.1.1.0/24 |
| Org D | AS64511 | 10.1.2.0/24 |
Manderson, et al. Expires July 18, 2013 [Page 14]
Internet-Draft RPKI Use Case and Interpretations January 2013
+-------------------------------------------------+
These organizations share a common upstream provider Transit X (ASN
64497) that originates an aggregate of these prefixes with the
permission of all four organizations.
The desired announcements (and organization) would be:
+----------------------------------------------+
| Prefix | Origin AS | Organization |
+----------------------------------------------+
| 10.1.0.0/24 | AS64496 | Org A |
| 10.1.3.0/24 | AS64505 | Org B |
| 10.1.1.0/24 | AS64499 | Org C |
| 10.1.2.0/24 | AS64511 | Org D |
| 10.1.0.0/22 | AS64497 | Transit X |
+----------------------------------------------+
It is currently not possible for an upstream 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 |
+----------------------------------------------+
Manderson, et al. Expires July 18, 2013 [Page 15]
Internet-Draft RPKI Use Case and Interpretations January 2013
| 64511 | 10.1.2.0/24 | 24 |
+----------------------------------------------+
3.11. Rogue Aggregation and Origination by an Upstream
Consider four organizations with the following resources that were
acquired independently from any transit provider.
+-------------------------------------------------+
| Organization | ASN | Prefix |
+-------------------------------------------------+
| Org A | AS64496 | 10.1.0.0/24 |
| Org B | AS64503 | 10.1.3.0/24 |
| Org C | AS64499 | 10.1.1.0/24 |
| Org D | AS64511 | 10.1.2.0/24 |
+-------------------------------------------------+
These organizations share a common upstream provider Transit X (ASN
64497) that originates an aggregate of these prefixes where possible.
In this situation organization B (ASN 64503, 10.1.3.0/24) does not
wish for its prefix to be aggregated by the upstream provider.
The desired announcements (and organization) would be:
+----------------------------------------------+
| Prefix | Origin AS | Organization |
+----------------------------------------------+
| 10.1.0.0/24 | AS64496 | Org A |
| 10.1.3.0/24 | AS64503 | Org B |
| 10.1.1.0/24 | AS64499 | Org C |
| 10.1.2.0/24 | AS64511 | Org D |
| 10.1.0.0/23 | AS64497 | Transit X |
+----------------------------------------------+
The following announcement would be undesirable:
+----------------------------------------------+
| Prefix | Origin AS | Organization |
+----------------------------------------------+
| 10.1.0.0/22 | AS64497 | Transit X |
+----------------------------------------------+
It is currently not possible for an upstream to make a valid
aggregate announcement of independent prefixes. However the issuing
parties should create ROAs containing the following:
Manderson, et al. Expires July 18, 2013 [Page 16]
Internet-Draft RPKI Use Case and Interpretations January 2013
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 pertaining to adjacency or path validation are beyond the
scope of this document and would be addressed in a separate document.
5. Partial Deployment Use Cases
5.1. Parent Does Not Participate in RPKI
An organization (Org A with ASN 64511) is multi-homed and has been
assigned the prefix 10.1.0.0/20 from its upstream (Transit X with ASN
64496). Org A wishes to announce the prefix 10.1.0.0/20 from ASN
64511 to its other upstream(s). Org A also wishes to create RPKI
statements about the resource; however Transit X (ASN 64496) which
announces the aggregate 10.1.0.0/16 has not yet adopted RPKI.
Manderson, et al. Expires July 18, 2013 [Page 17]
Internet-Draft RPKI Use Case and Interpretations January 2013
The desired announcements (and organization with RPKI adoption) would
be:
+----------------------------------------------------+
| Prefix | Origin AS |Organization | RPKI |
+----------------------------------------------------+
| 10.1.0.0/20 | AS64511 | Org A | Yes |
| 10.1.0.0/16 | AS64496 | Transit X | No |
+----------------------------------------------------+
RPKI is strictly hierarchical; therefore if Transit X does not
participate in RPKI, Org A is unable to validly issue RPKI objects.
5.2. Only Some Children Participate in RPKI
An organization (Org A with ASN 64496) has been allocated the prefix
10.1.0.0/16 and participates in RPKI; it wishes to announce the more
specific prefix 10.1.0.0/20 from ASN 64496. It has further delegated
10.1.16.0/20 and 10.1.32.0/20 to customers Org B with ASN 64511 and
Org C with ASN 64502 (respectively) who are multi-homed. Org B (ASN
64511) does not participate in RPKI. Org C (ASN 64502) participates
in RPKI.
The desired announcements (and organization with RPKI adoption) would
be:
+----------------------------------------------------+
| Prefix | Origin AS |Organization | RPKI |
+----------------------------------------------------+
| 10.1.0.0/16 | AS64496 | Org A | Yes |
| 10.1.0.0/20 | AS64496 | Org A | Yes |
| 10.1.16.0/20 | AS64511 | Org B | No |
| 10.1.32.0/20 | AS64502 | Org C | Yes |
+----------------------------------------------------+
The issuing parties should create ROAs containing the following:
Manderson, et al. Expires July 18, 2013 [Page 18]
Internet-Draft RPKI Use Case and Interpretations January 2013
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
Consider the previous example with an extension by where Org B, who
does not participate in RPKI, further allocates 10.1.17.0/24 to Org X
with ASN 64505. Org X does not participate in RPKI.
The desired announcements (and organization with RPKI adoption) would
be:
+----------------------------------------------------+
| Prefix | Origin AS |Organization | RPKI |
+----------------------------------------------------+
| 10.1.0.0/16 | AS64496 | Org A | Yes |
| 10.1.0.0/20 | AS64496 | Org A | Yes |
| 10.1.16.0/20 | AS64511 | Org B | No |
| 10.1.32.0/20 | AS64502 | Org C | Yes |
| 10.1.17.0/24 | AS64505 | Org X | No |
+----------------------------------------------------+
The issuing parties should create ROAs containing the following:
Manderson, et al. Expires July 18, 2013 [Page 19]
Internet-Draft RPKI Use Case and Interpretations January 2013
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 preceding sections, it should be
easy to deduce what new ROAs need to be created and what existing
ones need to be maintained (or revoked). The resource transfer and
timing of revocation/creation of the ROAs need to be performed based
on the make-before-break principle and using suitable RIR procedures
(see Section 2.1).
6.1. Transfer of in-use prefix and autonomous system number
Organization A holds the resource 10.1.0.0/20 and it is currently in
use and originated from AS64496 with valid RPKI objects in place.
Organization B has acquired both the prefix and ASN and desires an
RPKI transfer on a particular date and time without adversely
Manderson, et al. Expires July 18, 2013 [Page 20]
Internet-Draft RPKI Use Case and Interpretations January 2013
affecting 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
Organization A holds the resource 10.1.0.0/16 and it is currently in
use and originated from AS64496 with valid RPKI objects in place.
Organization A has agreed to transfer the entire /16 address block to
Organization B and will no longer originate the prefix or more
specifics of it. Consequently, Organization B desires an RPKI
transfer of this resource on a particular date and time. This prefix
will be originated by AS64511 as a result of this transfer.
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 |
+----------------------------------------------+
Manderson, et al. Expires July 18, 2013 [Page 21]
Internet-Draft RPKI Use Case and Interpretations January 2013
6.3. Transfer of unused prefix
Organization A holds the resources 10.1.0.0/16 and AS64507 (with RPKI
objects). Organization A currently announces 10.1.0.0/16 from
AS64507. Organization B has acquired an unused portion (10.1.4.0/24)
of the prefix from Organization A, and desires an RPKI transfer on a
particular date and time. Organization B will originate a route
10.1.4.0/24 from AS64496
The following RPKI objects 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 |
+----------------------------------------------+
Organization A may optionally provide ROA coverage for Organization B
by creating the following ROA preceding the RPKI transfer. The ROA
itself is then naturally revoked when 10.1.4.0/24 is transferred to
Organization B's resource certificate.
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
These use cases try to systematically enumerate the situations a
relying party may encounter while receiving a BGP update and making
use of ROA information to interpret the validity of the prefix-origin
Manderson, et al. Expires July 18, 2013 [Page 22]
Internet-Draft RPKI Use Case and Interpretations January 2013
information in the routes derived from the update. We enumerate the
situations or scenarios and include a recommendation for the expected
outcome of prefix-origin validation. For a description of prefix-
origin validation algorithms, see [RFC6483] and
[I-D.ietf-sidr-pfx-validate]. We use the terms Valid, Invalid, and
NotFound as defined in [I-D.ietf-sidr-pfx-validate] and summarized
earlier in Section 1.3. Also see [RFC6472] for work-in-progress in
the IDR WG to deprecate AS_SETs in BGP updates. The use cases
described here can be potentially used as test cases for testing and
evaluation of prefix-origin validation in router implementations; see
for example [BRITE].
7.1.1. Covering ROA Prefix, maxLength Satisfied, and AS Match
ROA: {10.1.0.0/16, maxLength = 20, AS64496}
Route has {10.1.0.0/17, Origin = AS64496}
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 straightforward prefix-
origin validation use case; it follows from the primary intention of
creation of ROA by a prefix holder.
7.1.2. Covering ROA Prefix, maxLength Exceeded, and AS Match
ROA: {10.1.0.0/16, maxLength = 20, AS64496}
Route has {10.1.0.0/22, Origin = AS64496}
No other covering ROA
Recommended RPKI prefix-origin validation interpretation: Route is
Invalid.
Comment: In this case the maxLength specified in the ROA is exceeded
by the route prefix.
7.1.3. Covering ROA Prefix, maxLength Satisfied, and AS Mismatch
ROA: {10.1.0.0/16, maxLength = 24, AS64496}
Route has {10.1.88.0/24, Origin = AS64511}
No other covering ROA
Manderson, et al. Expires July 18, 2013 [Page 23]
Internet-Draft RPKI Use Case and Interpretations January 2013
Recommended RPKI prefix-origin validation interpretation: Route is
Invalid.
Comment: In this case an AS other than the one specified in the ROA
is originating the route. This may 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, AS64496}
Route has {10.1.88.0/24, Origin = AS64511}
No other covering ROA
Recommended RPKI prefix-origin validation interpretation: Route is
Invalid.
Comment: In this case the maxLength specified in the ROA is exceeded
by the route prefix, and also an AS other than the one specified in
the ROA is originating the route. This may be a subprefix hijack
situation.
7.1.5. Covering ROA Prefix Not Found
Route has {10.1.3.0/24, Origin = AS64511}
No covering ROA
Recommended RPKI prefix-origin validation interpretation: Route's
validation status is NotFound.
Comment: In this case there is no covering ROA for the route prefix.
It could be a case of prefix or subprefix hijack situation, but this
announcement does not contradict any existing ROA. During partial
deployment, there would be some legitimate prefix-origin
announcements for which ROAs may not have been issued yet.
7.1.6. Covering ROA Prefix and the ROA is an AS0 ROA
ROA: {10.1.0.0/16, maxLength = 32, AS0}
Route has {10.1.5.0/24, Origin = AS64511}
Recommended RPKI prefix-origin validation interpretation: Route's
validation status is Invalid.
Comment: An AS0 ROA implies by definition that the prefix listed in
Manderson, et al. Expires July 18, 2013 [Page 24]
Internet-Draft RPKI Use Case and Interpretations January 2013
it and all of the more specifics of that prefix should not be used in
a routing context [RFC6483][I-D.ietf-idr-as0]. Also, please see
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, AS64496}
ROA: {10.1.64.0/18, maxLength = 20, AS64496}
ROA: {10.1.128.0/18, maxLength = 20, AS64496}
ROA: {10.1.192.0/18, maxLength = 20, AS64496}
Route has {10.1.0.0/16, Origin = AS64496}
No covering ROA
Recommended RPKI prefix-origin validation interpretation: Route's
validation status is NotFound.
Comment: In this case the route prefix is an aggregate (/16), and it
turns out that there exist ROAs for more specifics (/18s) that, if
combined, can help support validation of the announced prefix-origin
pair. But it is very hard in general to breakup an announced prefix
into constituent more specifics and check for ROA coverage for those
more specifics, and hence this type 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 [AS64496, AS64497, AS64498, AS64499]
appears in the right most position in the AS_PATH}
No covering ROA
Recommended RPKI prefix-origin validation interpretation: Route's
validation status is NotFound.
Comment: An extremely small percentage (~0.1%) of eBGP updates are
seen to have an AS_SET in them; this is known as proxy aggregation.
In this case, the route with the AS_SET does not conflict with any
ROA (i.e., the route prefix has no covering ROA prefix). Therefore,
the route gets NotFound validation status.
Manderson, et al. Expires July 18, 2013 [Page 25]
Internet-Draft RPKI Use Case and Interpretations January 2013
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 [AS64496] appears in the right most
position in the AS_PATH}
ROA: {10.1.0.0/22, maxLength = 24, AS64496}
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 contains an AS_SET and a covering ROA prefix exists for the
route prefix, then 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 [AS64496] appears in the right most
position in the AS_PATH}
ROA: {10.1.0.0/22, maxLength = 24, AS64511}
Recommended RPKI prefix-origin validation interpretation: Route is
Invalid.
Comment: If the route contains an AS_SET and a covering ROA prefix
exists for the route prefix, then 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 [AS64496, AS64497, AS64498, AS64499]
appears in the right most position in the AS_PATH}
ROA: {10.1.0.0/22, maxLength = 24, AS64509}
No other covering ROA.
Recommended RPKI prefix-origin validation interpretation: Route is
Invalid.
Comment: If the route contains an AS_SET and a covering ROA prefix
exists for the route prefix, then the route should get an Invalid
status.
Manderson, et al. Expires July 18, 2013 [Page 26]
Internet-Draft RPKI Use Case and Interpretations January 2013
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, AS64496}
ROA: {10.1.64.0/18, maxLength = 20, AS64497}
ROA: {10.1.128.0/18, maxLength = 20, AS64498}
ROA: {10.1.192.0/18, maxLength = 20, AS64499}
Route has {10.1.0.0/16, AS_SET [AS64496, AS64497, AS64498, AS64499]
appears in the right most 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 (i.e., 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 it is very hard in
general to breakup an announced prefix into constituent more
specifics and check for ROA coverage for those more specifics. In
any case, it may be noted once again that in the spirit of [RFC6472],
any route with an AS_SET in it should not be considered valid (by
ROA-based validation). In fact, the route under consideration would
have received 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 enumerate use cases corresponding to router actions when RPKI
objects expire or are revoked. In the cases which follow, the terms
"expired ROA" or "revoked ROA" are shorthand, and describe the expiry
or revocation of the End Entity (EE) or Resource Certificate that
causes a relying party to consider the corresponding ROA to have
expired or revoked, respectively.
7.2.1. ROA of Parent Prefix is Revoked
A certificate revocation list (CRL) is received which reveals that
the ROA {10.1.0.0/22, maxLength = 24, ASN64496} is revoked. Further,
a route exists in the Internet routing system for 10.1.3.0/24
originated from ASN64496. In absence of said revoked ROA, no
covering ROA prefix exists for the route prefix (i.e., 10.1.3.0/24).
Manderson, et al. Expires July 18, 2013 [Page 27]
Internet-Draft RPKI Use Case and Interpretations January 2013
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 is received which reveals that the ROA {10.1.3.0/24, maxLength
= 24, ASN64496} is revoked. Further, a route exists in the Internet
routing system for 10.1.3.0/24 originated from ASN64496.
Additionally, a valid ROA exists for a parent prefix 10.1.0.0/22 and
said ROA is {10.1.0.0/22, maxLength = 24, ASN64511}. 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
A CRL is received which reveals that the ROA {10.1.3.0/24; maxLength
= 24, ASN64496} is revoked. Further, a route exists in the Internet
routing system for 10.1.3.0/24 originated from ASN64496.
Additionally, a valid ROA exists for a parent prefix 10.1.0.0/22 and
said ROA is {10.1.0.0/22, maxLength = 24, ASN64496}.
The Relying Party interpretation would be: Route is Valid.
(Clarification: Perhaps the revocation of 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
A CRL is received which reveals that the ROA {10.1.0.0/20; maxLength
= 24, ASN64496} is revoked. Further, a route exists in the Internet
routing system for 10.1.3.0/24 originated from ASN64496.
Additionally, a valid ROA exists for a parent prefix 10.1.0.0/22 and
said ROA is {10.1.0.0/22, maxLength = 24, ASN64496}.
The Relying Party interpretation would be: Route is Valid.
(Clarification: 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 reveals that the ROA {10.1.0.0/22, maxLength =
24, ASN64496} has expired. Further, a route exists in the Internet
routing system for 10.1.3.0/24 originated from ASN64496. In absence
of said expired ROA, no covering ROA prefix exists for the route
Manderson, et al. Expires July 18, 2013 [Page 28]
Internet-Draft RPKI Use Case and Interpretations January 2013
prefix (i.e., 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
A scan of the ROA list reveals that the ROA {10.1.3.0/24, maxLength =
24, ASN64496} has expired. Further, a route exists in the Internet
routing system for 10.1.3.0/24 originated from ASN64496.
Additionally, a valid ROA exists for a parent prefix 10.1.0.0/22 and
said ROA is {10.1.0.0/22, maxLength = 24, ASN64511}. No other
covering ROA exists for the prefix (i.e., 10.1.3.0/24).
The Relying Party interpretation would be: Route is Invalid.
7.2.7. Expiry of ROA of Prefix while that of Parent Prefix Prevails
A scan of the ROA list reveals that the ROA {10.1.3.0/24; maxLength =
24, ASN64496} has expired. Further, a route exists in the Internet
routing system for 10.1.3.0/24 originated from ASN64496.
Additionally, a valid ROA exists for a parent prefix 10.1.0.0/22 and
said ROA is {10.1.0.0/22, maxLength = 24, ASN64496}.
The Relying Party interpretation would be: Route is Valid.
7.2.8. Expiry of ROA of Grandparent Prefix while that of Parent Prefix
Prevails
A scan of the ROA list reveals that the ROA {10.1.0.0/20; maxLength =
24, ASN64496} has expired. Further, a route exists in the Internet
routing system for 10.1.3.0/24 originated from ASN64496.
Additionally, a valid ROA exists for a parent prefix 10.1.0.0/22 and
said ROA is {10.1.0.0/22, maxLength = 24, ASN64496}.
The Relying Party interpretation would be: Route is Valid.
8. Acknowledgements
The authors are indebted to both Sandy Murphy and Sam Weiler for
their guidance. Further, the authors would like to thank Steve Kent,
Warren Kumari, Randy Bush, Curtis Villamizar, and Danny McPherson for
their technical insight and review. The authors also wish to thank
Elwyn Davies, Stephen Farrel, Barry Leiba, Stewart Bryant, Alexey
Melnikov, and Russ Housley for their review and comments during the
IESG review process.
Manderson, et al. Expires July 18, 2013 [Page 29]
Internet-Draft RPKI Use Case and Interpretations January 2013
9. IANA Considerations
This memo includes no request to IANA.
10. Security Considerations
This memo requires no security considerations
11. References
11.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.
11.2. Informative References
[BRITE] "BRITE: BGPSEC/RPKI Interoperability Test and Evaluation",
Developed by the National Institute of Standards and
Technology (NIST), Gaithersburg, Maryland,
<http://brite.antd.nist.gov/statics/about>.
[I-D.ietf-idr-as0]
Kumari, W., Bush, R., Schiller, H., and K. Patel,
"Codification of AS 0 processing.", draft-ietf-idr-as0-06
(work in progress), August 2012.
[I-D.ietf-sidr-pfx-validate]
Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation",
draft-ietf-sidr-pfx-validate-10 (work in progress),
October 2012.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
Manderson, et al. Expires July 18, 2013 [Page 30]
Internet-Draft RPKI Use Case and Interpretations January 2013
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
Algorithms and Identifiers for RSA Cryptography for use in
the Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", RFC 4055,
June 2005.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, August 2006.
[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS
Number Space", RFC 4893, May 2007.
[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.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, September 2009.
[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.
Authors' Addresses
Terry Manderson
ICANN
Email: terry.manderson@icann.org
Manderson, et al. Expires July 18, 2013 [Page 31]
Internet-Draft RPKI Use Case and Interpretations January 2013
Kotikalapudi Sriram
US NIST
Email: ksriram@nist.gov
Russ White
Verisign
Email: russ@riw.us
Manderson, et al. Expires July 18, 2013 [Page 32]
