Secure Inter-Domain Routing T. Manderson
Internet-Draft ICANN
Intended status: Informational K. Sriram
Expires: December 24, 2011 US NIST
R. White
Cisco
June 22, 2011
Use Cases and Interpretation of RPKI Objects for Issuers and Relying
Parties
draft-ietf-sidr-usecases-02
Abstract
This document provides use cases, directions, and interpretations for
organizations and relying parties when creating or encountering RPKI
object scenarios in the public RPKI 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 December 24, 2011.
Copyright Notice
Copyright (c) 2011 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
to this document. Code Components extracted from this document must
Manderson, et al. Expires December 24, 2011 [Page 1]
Internet-Draft RPKI Use Case and Interpretations June 2011
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. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. General interpretation of RPKI object semantics . . . . . 6
3. Origination Use Cases . . . . . . . . . . . . . . . . . . . . 6
3.1. Single Announcement . . . . . . . . . . . . . . . . . . . 6
3.2. Aggregate with a More Specific . . . . . . . . . . . . . . 7
3.3. Aggregate with a More Specific from a Different ASN . . . 7
3.4. Sub-allocation to a Multi-homed Customer . . . . . . . . . 8
3.5. Restriction of a New Allocation . . . . . . . . . . . . . 9
3.6. Restriction of New ASN . . . . . . . . . . . . . . . . . . 10
3.7. Restriction of a Part of an Allocation . . . . . . . . . . 10
3.8. Restriction of Prefix Length . . . . . . . . . . . . . . . 11
3.9. Restriction of Sub-allocation Prefix Length . . . . . . . 12
3.10. Aggregation and Origination by an Upstream . . . . . . . . 13
3.11. Rogue Aggregation and Origination by an Upstream . . . . . 15
4. Adjacency or Path Validation Use Cases . . . . . . . . . . . . 16
5. Partial Deployment Use Cases . . . . . . . . . . . . . . . . . 16
5.1. Parent does not do RPKI . . . . . . . . . . . . . . . . . 16
5.2. Only Some Children Participate in RPKI . . . . . . . . . . 17
5.3. Grandchild Does Not Participate in RPKI . . . . . . . . . 18
6. Transfer Use Cases . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Transfer of in-use prefix and autonomous system number . . 19
6.2. Transfer of in-use prefix . . . . . . . . . . . . . . . . 20
6.3. Transfer of un-used prefix . . . . . . . . . . . . . . . . 21
7. Relying Party Use Cases . . . . . . . . . . . . . . . . . . . 21
7.1. Prefix-Origin Validation use cases . . . . . . . . . . . . 21
7.1.1. Covering ROA Prefix, maxLength Satisfied, and AS
Match . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1.2. Covering ROA Prefix, maxLength Exceeded, and AS
Match . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1.3. Covering ROA Prefix, maxLength Satisfied, and AS
Mismatch: . . . . . . . . . . . . . . . . . . . . . . 22
7.1.4. Covering ROA Prefix, maxLength Exceeded, and AS
Mismatch . . . . . . . . . . . . . . . . . . . . . . . 23
7.1.5. Covering ROA Prefix Not Found . . . . . . . . . . . . 23
7.1.6. Covering ROA Prefix Not Found but ROAs Exist for a
Covering Set of More Specifics . . . . . . . . . . . . 23
7.1.7. AS_SET in Update and Covering ROA Prefix Not Found . . 24
Manderson, et al. Expires December 24, 2011 [Page 2]
Internet-Draft RPKI Use Case and Interpretations June 2011
7.1.8. Singleton AS in AS_SET (in the Update), Covering
ROA Prefix, and AS Match . . . . . . . . . . . . . . . 24
7.1.9. Singleton AS in AS_SET (in the Update), Covering
ROA Prefix, and AS Mismatch . . . . . . . . . . . . . 25
7.1.10. Multiple ASs in AS_SET (in the Update) and
Covering ROA Prefix . . . . . . . . . . . . . . . . . 25
7.1.11. Update has an AS_SET as Origin and ROAs Exist for
a Covering Set of More Specifics . . . . . . . . . . . 25
7.2. ROA Expiry or receipt of a CRL covering a ROA . . . . . . 26
7.2.1. ROA of Parent Prefix is Revoked . . . . . . . . . . . 26
7.2.2. ROA of Prefix Revoked while Parent Has Covering
ROA with Different ASN . . . . . . . . . . . . . . . . 26
7.2.3. ROA of Prefix Revoked while that of Parent Prefix
Prevails . . . . . . . . . . . . . . . . . . . . . . . 27
7.2.4. ROA of Grandparent Prefix Revoked while that of
Parent Prefix Prevails . . . . . . . . . . . . . . . . 27
7.2.5. Expiry of ROA of Parent Prefix . . . . . . . . . . . . 27
7.2.6. Expiry of ROA of Prefix while Parent Has Covering
ROA with Different ASN . . . . . . . . . . . . . . . . 27
7.2.7. Expiry of ROA of Prefix while that of Parent
Prefix Prevails . . . . . . . . . . . . . . . . . . . 28
7.2.8. Expiry of ROA of Grandparent Prefix while that of
Parent Prefix Prevails . . . . . . . . . . . . . . . . 28
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.1. Normative References . . . . . . . . . . . . . . . . . . . 29
11.2. Informative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Manderson, et al. Expires December 24, 2011 [Page 3]
Internet-Draft RPKI Use Case and Interpretations June 2011
1. Introduction
This document provides suggested use cases, directions, and
interpretations for organizations and relying parties when creating
or encountering RPKI object scenarios in the public RPKI 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" [I-D.ietf-sidr-res-certs]
"X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779], "A
Profile for Route Origin Authorizations (ROAs)"
[I-D.ietf-sidr-roa-format], "Validation of Route Origination in BGP
using the Resource Certificate PKI and ROAs"
[I-D.ietf-sidr-roa-validation], and BGP Prefix Origin Validation"
[I-D.ietf-sidr-pfx-validate].
1.2. Definitions
The following definitions are in use in this document.
Autonomous System - A network under a single technical administration
that presents a consistent picture of what destinations are reachable
through it.
Autonomous System Number (ASN) - An officially registered number
representing an autonomous system.
Prefix - A network address and an integer that specifies the length
of a mask to be applied to the address to represent a set of
numerically adjacent addresses.
Route - A prefix and a sequence of one or more autonomous system
numbers.
Origin AS - The Autonomous System, designated by an ASN, which
originates a route. Seen as the "First" ASN in a route.
Specific route - A route that has a longer prefix than an aggregate.
Aggregate route - A more general route in the presence of a specific
route.
Covering Aggregate - A route that covers one or more specific routes.
Manderson, et al. Expires December 24, 2011 [Page 4]
Internet-Draft RPKI Use Case and Interpretations June 2011
Multi-homed Autonomous System - An Autonomous System that is
connected, and announces routes, to two or more Autonomous Systems.
Multi-homed prefix or subnet - A prefix (i.e., subnet) that is
originated via two or more Autonomous Systems to which the subnet is
connected.
Resource - Internet (IP) addresses or Autonomous System Number.
Allocation - The set of resources provided to an entity or
organization for its use.
Sub-allocation - The set of a resources subordinate to an allocation
assigned to another entity or organization.
Transit Provider - An Autonomous System that carries traffic that
neither originates nor is the destination of that traffic.
Upstream - See "Transit Provider".
Child - A Sub-allocation that has resulted from an Allocation.
Parent - An allocation from which the subject prefix is a Child.
Grandchild - A Sub-allocation from one or more previous Sub-
allocations.
Grandparent - The allocation from which the prefix is a Grandchild.
Update prefix - The prefix seen in a routing update.
ROA prefix - The prefix described in a ROA.
Covering Prefix - The ROA Prefix is an exact match or a less specific
when compared to the update prefix.
No relevant ROA - No ROA exists that has a covering prefix for the
update prefix.
No other relevant ROA - No other ROA (besides any that is(are)
already cited) that has a covering prefix for the update prefix.
1.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Manderson, et al. Expires December 24, 2011 [Page 5]
Internet-Draft RPKI Use Case and Interpretations June 2011
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' stance
is applied. This means that a RP should implement a routing decision
process where a routing update ("route") is assumed to be intended
unless proven otherwise by the existence of a valid RPKI object. For
all of the cases in this document it is assumed that RPKI objects
validate (or otherwise) in accordance with [I-D.ietf-sidr-res-certs],
[I-D.ietf-sidr-arch], [I-D.ietf-sidr-roa-validation] unless otherwise
stated.
While many of the examples provided here illustrate organizations
using their own autonomous system numbers to originate routes, it
should be recognised 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.
3.1. Single Announcement
An organization (Org A with ASN 64496) has been allocated the prefix
192.168.2.0/24. It wishes to announce the /24 prefix from ASN 64496
such that relying parties interpret the route as intended.
The desired announcement (and organization) would be:
+----------------------------------------------+
| Prefix | Origin AS | Organization |
+----------------------------------------------+
| 192.168.2.0/24 | AS64496 | Org A |
+----------------------------------------------+
The issuing party should create a ROA containing the following:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 192.168.2.0/24 | 24 |
+----------------------------------------------+
Manderson, et al. Expires December 24, 2011 [Page 6]
Internet-Draft RPKI Use Case and Interpretations June 2011
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 |
+----------------------------------------------+
3.3. Aggregate with a More Specific from a Different ASN
An organization (Org A with ASN 64496 and ASN 64499) 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 64499 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 | AS64499 | Org A |
+---------------------------------------------+
The issuing party should create ROAs containing the following:
Manderson, et al. Expires December 24, 2011 [Page 7]
Internet-Draft RPKI Use Case and Interpretations June 2011
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 16 |
+----------------------------------------------+
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64499 | 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 desirable 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 |
| 10.1.16.0/20 | AS64511 | Org B |
+---------------------------------------------+
The issuing party should create ROAs containing the following:
Manderson, et al. Expires December 24, 2011 [Page 8]
Internet-Draft RPKI Use Case and Interpretations June 2011
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:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 0 | 10.1.0.0/16 | 32 |
+----------------------------------------------+
This is known as an AS0-ROA [I-D.ietf-sidr-roa-validation]
Manderson, et al. Expires December 24, 2011 [Page 9]
Internet-Draft RPKI Use Case and Interpretations June 2011
3.6. Restriction of New ASN
An organization has recently been allocated an additional ASN 65535.
Its network deployment is not yet ready to use this ASN and wishes to
restrict all possible uses of ASN 65535 using RPKI.
The following announcements would be considered undesirable:
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| ANY | AS65535 | 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 and the /16 aggregate. However it 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/16 | AS64496 | Org A |
| 10.1.0.0/17 | AS64496 | 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:
Manderson, et al. Expires December 24, 2011 [Page 10]
Internet-Draft RPKI Use Case and Interpretations June 2011
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 16 |
+----------------------------------------------+
| | 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:
+---------------------------------------------+
| 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:
Manderson, et al. Expires December 24, 2011 [Page 11]
Internet-Draft RPKI Use Case and Interpretations June 2011
+----------------------------------------------+
| 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 65535, 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 | AS65535 | Org B |
| 10.1.128.0/20 | AS64499 | Org C |
| 10.1.4.0/22 | AS65535 | Org B
+---------------------------------------------+
The following example announcements (and organization) would be
considered undesirable:
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/24 | AS65535 | 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:
Manderson, et al. Expires December 24, 2011 [Page 12]
Internet-Draft RPKI Use Case and Interpretations June 2011
For Org A.
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 16 |
+----------------------------------------------+
For Org B.
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 65535 | 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 | AS65535 | 10.1.3.0/24 |
| Org C | AS64499 | 10.1.1.0/24 |
| Org D | AS64512 | 10.1.2.0/24 |
+-------------------------------------------------+
These organizations share a common upstream provider Transit A (ASN
64497) that originates an aggregate of these prefixes with the
permission of all four organizations.
The desired announcements (and organization) would be:
Manderson, et al. Expires December 24, 2011 [Page 13]
Internet-Draft RPKI Use Case and Interpretations June 2011
+----------------------------------------------+
| Prefix | Origin AS | Organization |
+----------------------------------------------+
| 10.1.0.0/24 | AS64496 | Org A |
| 10.1.3.0/24 | AS65535 | Org B |
| 10.1.1.0/24 | AS64499 | Org C |
| 10.1.2.0/24 | AS64512 | Org D |
| 10.1.0.0/22 | AS64497 | Transit A |
+----------------------------------------------+
It is currently not possible for an upstream to make a valid
aggregate annoucement of indepentant 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 |
+----------------------------------------------+
| 65535 | 10.1.3.0/24 | 24 |
+----------------------------------------------+
Org C.
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64499 | 10.1.1.0/24 | 24 |
+----------------------------------------------+
Org D.
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64512 | 10.1.2.0/24 | 24 |
+----------------------------------------------+
Manderson, et al. Expires December 24, 2011 [Page 14]
Internet-Draft RPKI Use Case and Interpretations June 2011
3.11. Rogue 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 | AS65535 | 10.1.3.0/24 |
| Org C | AS64499 | 10.1.1.0/24 |
| Org D | AS64512 | 10.1.2.0/24 |
+-------------------------------------------------+
These organizations share a common upstream provider Transit A (ASN
64497) that originates an aggregate of these prefixes where possible.
In this situation organization B (ASN 65535, 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 | AS65535 | Org B |
| 10.1.1.0/24 | AS64499 | Org C |
| 10.1.2.0/24 | AS64512 | Org D |
| 10.1.0.0/23 | AS64497 | Transit A |
+----------------------------------------------+
The following announcement would be undesirable:
+----------------------------------------------+
| Prefix | Origin AS | Organization |
+----------------------------------------------+
| 10.1.0.0/22 | AS64497 | Transit A |
+----------------------------------------------+
It is currently not possible for an upstream to make a valid
aggregate annoucement of indepentant prefixes. However the issuing
parties should create ROAs containing the following:
Manderson, et al. Expires December 24, 2011 [Page 15]
Internet-Draft RPKI Use Case and Interpretations June 2011
Org A.
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/24 | 24 |
+----------------------------------------------+
Org B.
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 65535 | 10.1.3.0/24 | 24 |
+----------------------------------------------+
Org C.
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64499 | 10.1.1.0/24 | 24 |
+----------------------------------------------+
Org D.
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64512 | 10.1.2.0/24 | 24 |
+----------------------------------------------+
4. Adjacency or Path Validation Use Cases
The SIDR WG was recently re-chartered (April 2011) to address AS path
validation. 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 do RPKI
An organization (Org A with ASN 64511) is multi-homed 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
Manderson, et al. Expires December 24, 2011 [Page 16]
Internet-Draft RPKI Use Case and Interpretations June 2011
announces the aggregate 10.1.0.0/16 has not yet adopted RPKI.
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 do
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
and Org C with ASN 65535 (respectively) who are multi-homed. Org B
(ASN 64511) does not participate in RPKI. Org C (ASN 65535)
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 | AS65535 | Org C | YES |
+----------------------------------------------------+
The issuing parties should create ROAs containing the following:
Manderson, et al. Expires December 24, 2011 [Page 17]
Internet-Draft RPKI Use Case and Interpretations June 2011
Org A.
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 20 |
+----------------------------------------------+
Org A issues for Org B.
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64511 | 10.1.16.0/20 | 20 |
+----------------------------------------------+
Org C.
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 65535 | 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 64512. 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 | AS65535 | Org C | YES |
| 10.1.17.0/24 | AS64512 | Org X | No |
+----------------------------------------------------+
The issuing parties should create ROAs containing the following:
Manderson, et al. Expires December 24, 2011 [Page 18]
Internet-Draft RPKI Use Case and Interpretations June 2011
Org A.
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 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 |
+----------------------------------------------+
| 64512 | 10.1.17.0/24 | 24 |
+----------------------------------------------+
Org C.
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 65535 | 10.1.32.0/20 | 20 |
+----------------------------------------------+
6. Transfer Use Cases
For transfer use cases, based on the preceding sections it would be
easy to deduce what existing ROAs would need to be maintained or
revoked and what new ROAs would need to be created. 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.
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
affecting the operational use of the resource.
Manderson, et al. Expires December 24, 2011 [Page 19]
Internet-Draft RPKI Use Case and Interpretations June 2011
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/8 and it is currently in
use and originated from AS64496 with valid RPKI objects in place.
Organization B has acquired the address and desires an RPKI transfer
on a particular date and time. This prefix will be originated by
AS65535 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/8 | 8 |
+----------------------------------------------+
For Org. B, add the following ROA when the
resource certificate for 10.1.0.0/8 is issued to
them (Org. B):
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 65535 | 10.1.0.0/8 | 8 |
+----------------------------------------------+
Manderson, et al. Expires December 24, 2011 [Page 20]
Internet-Draft RPKI Use Case and Interpretations June 2011
6.3. Transfer of un-used prefix
Organization A holds the resource 10.1.0.0/8 and AS65535 (with RPKI
objects). Organization B has acquired an unused portion
(10.1.4.0/24) of the prefix 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/revoked:
For Org. A, leave the following ROA unchanged:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 65535 | 10.1.0.0/8 | 8 |
+----------------------------------------------+
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 Organisation 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
information in the update. We enumerate the situations or scenarios
Manderson, et al. Expires December 24, 2011 [Page 21]
Internet-Draft RPKI Use Case and Interpretations June 2011
and include a recommendation for the expected outcome of prefix-
origin validation. For description of prefix-origin validation
algorithms, see [I-D.ietf-sidr-roa-validation] and
[I-D.ietf-sidr-pfx-validate]. We use the terms Valid, Invalid, and
Unknown as defined in [I-D.ietf-sidr-roa-validation]. Also see
[I-D.ietf-idr-deprecate-as-sets] for work-in-progress in the IDR WG
to deprecate AS_SETs in BGP updates. The use cases described here
can be potentailly 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}
Update has {10.1.0.0/17, Origin = AS64496}
Recommended RPKI prefix-origin validation interpretation: Update is
Valid.
Comment: This is a straight forward prefix-origin validation use
case; it follows from the primary intention of creation of ROA by a
resource owner.
7.1.2. Covering ROA Prefix, maxLength Exceeded, and AS Match
ROA: {10.1.0.0/16, maxLength = 20, AS64496}
Update has {10.1.0.0/22, Origin = AS64496}
No other relevant ROA
Recommended RPKI prefix-origin validation interpretation: Update is
Invalid.
Comment: In this case the maxLength specified in the ROA is exceeded
by the update prefix.
7.1.3. Covering ROA Prefix, maxLength Satisfied, and AS Mismatch:
ROA: {10.1.0.0/16, maxLength = 24, AS64496}
Update has {10.1.88.0/24, Origin = AS65535}
No other relevant ROA
Recommended RPKI prefix-origin validation interpretation: Update is
Invalid.
Manderson, et al. Expires December 24, 2011 [Page 22]
Internet-Draft RPKI Use Case and Interpretations June 2011
Comment: In this case an AS other than the one specified in the ROA
is originating an update. 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}
Update has {10.1.88.0/24, Origin = AS65535}
No other relevant ROA
Recommended RPKI prefix-origin validation interpretation: Update is
Invalid.
Comment: In this case the maxLength specified in the ROA is exceeded
by the update prefix, and also an AS other than the one specified in
the ROA is originating the update. This may be a subprefix hijack
situation.
7.1.5. Covering ROA Prefix Not Found
Update has {240.1.1.0/24, Origin = AS65535}
No relevant ROA
Recommended RPKI prefix-origin validation interpretation: Update's
validation status is Unknown.
Comment: In this case there is no relevant ROA that has a covering
prefix for the update 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 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}
Update has {10.1.0.0/16, Origin = AS64496}
Manderson, et al. Expires December 24, 2011 [Page 23]
Internet-Draft RPKI Use Case and Interpretations June 2011
No (directly) relevant ROA
Recommended RPKI prefix-origin validation interpretation: Update's
validation status is Unknown.
Comment: In this case the update prefix is an aggregate, and it turns
out that there exit ROAs for more specifics which, 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.7. AS_SET in Update and Covering ROA Prefix Not Found
Update has {10.1.0.0/16, Origin = [AS64496, AS64497, AS64498,
AS64497]}
No relevant ROA
Recommended RPKI prefix-origin validation interpretation: Update's
validation status is Unknown.
Comment: An extremely small percentage (~0.1%) of eBGP updates are
seen to have an AS_SET in them as origin; this is known as proxy
aggregation. In this case, update with the AS_SET does not conflict
with any ROA.
7.1.8. Singleton AS in AS_SET (in the Update), Covering ROA Prefix, and
AS Match
Update has {10.1.0.0/24, Origin = [AS64496]} (Note: AS_SET with
singleton AS appears in origin AS position.)
ROA: {10.1.0.0/22, maxLength = 24, AS64496}
Recommended RPKI prefix-origin validation interpretation: Update is
Invalid.
Comment: In the spirit of [I-D.ietf-idr-deprecate-as-sets], any
update with an AS_SET in it should not be considered valid (by ROA-
based validation). If the update contains an AS_SET and a covering
ROA exists, then no attempt should be made to match the ASN in the
update with that in the covering ROA and the update should get an
Invalid status.
Manderson, et al. Expires December 24, 2011 [Page 24]
Internet-Draft RPKI Use Case and Interpretations June 2011
7.1.9. Singleton AS in AS_SET (in the Update), Covering ROA Prefix, and
AS Mismatch
Update has {10.1.0.0/24, Origin = [AS64496]}
(Note: AS_SET with singleton AS appears in origin AS position.)
ROA: {10.1.0.0/22, maxLength = 24, AS65535}
Recommended RPKI prefix-origin validation interpretation: Update is
Invalid.
Comment: When there is at least one covering ROA, then the update
with an AS_SET should get an Invalid status regardless of whether
there is AS match or mismatch.
7.1.10. Multiple ASs in AS_SET (in the Update) and Covering ROA Prefix
Update has {10.1.0.0/22, Origin = [AS64496, AS64497, AS64498,
AS64497]}
ROA: {10.1.0.0/22, maxLength = 24, AS65535}
No other relevant ROA.
Recommended RPKI prefix-origin validation interpretation: Update is
Invalid.
Comment: When there is at least one covering ROA, then the update
with an AS_SET should get an Invalid status.
7.1.11. Update has an AS_SET as Origin 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}
Update has {10.1.0.0/16, Origin = [AS64496, AS64497, AS64498,
AS64497]}
No (directly) relevant ROA
Recommended RPKI prefix-origin validation interpretation: Update's
Manderson, et al. Expires December 24, 2011 [Page 25]
Internet-Draft RPKI Use Case and Interpretations June 2011
validation status is Unknown.
Comment: In this case the aggregate of the prefixes in the ROAs is a
covering prefix for the update prefix. The ASs in each of the
contributing ROAs together form a set that matches the AS_SET in the
update. 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 [I-D.ietf-idr-deprecate-as-sets], any update with an
AS_SET in it should not be considered valid (by ROA-based
validation). In fact, the update in consideration would have
received an Invalid staus if there were at least one covering ROA.
7.2. ROA Expiry or receipt of a CRL covering 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
appropriate expiry or revocation of the EE or Resource Certificate(s)
that causes a relying party to consider the corresponding ROA to have
expired or revoked.
7.2.1. ROA of Parent Prefix is Revoked
A certificate revocation list (CRL) is received which reveals that
the ROA containing the prefix 10.1.0.0/22; maxLength 24 with ASN64496
is revoked. Further, a prefix route exists in the Internet routing
system for 10.1.4.0/24 originated from ASN64496. In absence of the
revoked ROA, no covering ROA exists for 10.1.4.0/24.
The Relying Party interpretation would be: Route validation status is
Unknown
7.2.2. ROA of Prefix Revoked while Parent Has Covering ROA with
Different ASN
A CRL is received which reveals that the ROA containing the prefix
10.1.4.0/24; maxLength 24 with ASN64496 is revoked. Further, a
prefix route exists in the Internet routing system for 10.1.4.0/24
originated from ASN64496. A covering ROA exists for a parent prefix
10.1.4.0/22; maxlength 24 with ASN65535. No other covering ROA
exists for the 10.1.4.0/24 prefix.
The Relying Party interpretation would be: Route is Invalid.
Manderson, et al. Expires December 24, 2011 [Page 26]
Internet-Draft RPKI Use Case and Interpretations June 2011
7.2.3. ROA of Prefix Revoked while that of Parent Prefix Prevails
A CRL is received which reveals that the ROA containing the prefix
10.1.4.0/24; maxLength 24 with ASN64496 is revoked. Further, a
prefix route exists in the Internet routing system for 10.1.4.0/24
originated from ASN64496. Additionally, the current ROA list has a
valid ROA containing the parent prefix 10.1.0.0/22; maxLength 24 with
ASN64496.
The Relying Party interpretation would be: Route is Valid.
(Clarification: Perhaps the revocation of ROA for prefix 10.1.4.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 containing the prefix
10.1.0.0/20; maxLength 24 with ASN64496 is revoked. Further, a
prefix route exists in the Internet routing system for 10.1.4.0/24
originated from ASN64496. Additionally, the current ROA list has a
valid ROA containing the prefix 10.1.0.0/22; maxLength 24 with
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 containing the prefix
10.1.0.0/22; maxLength 24 with ASN64496 has expired. Further, a
prefix route exists in the Internet routing system for 10.1.4.0/24
originated from ASN64496. In absence of the expired ROA, no covering
ROA exists for 10.1.4.0/24.
The Relying Party interpretation would be: Route validation status is
Unknown
7.2.6. Expiry of ROA of Prefix while Parent Has Covering ROA with
Different ASN
A scan of the ROA list reveals that the ROA containing the prefix
10.1.4.0/24; maxLength 24 with ASN64496 has expired. Further, a
prefix route exists in the Internet routing system for 10.1.4.0/24
originated from ASN64496. A valid covering ROA exists for a parent
prefix 10.1.4.0/22; maxlength 24 with ASN65535. No other covering
Manderson, et al. Expires December 24, 2011 [Page 27]
Internet-Draft RPKI Use Case and Interpretations June 2011
ROA exists for the prefix.
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 containing the prefix
10.1.4.0/24; maxLength 24 with ASN64496 has expired. Further, a
prefix route exists in the Internet routing system for 10.1.4.0/24
originated from ASN64496. Additionally, the current ROA list has a
valid ROA containing the parent prefix 10.1.0.0/22; maxLength 24 with
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 containing the prefix
10.1.0.0/20; maxLength 24 with ASN64496 is revoked. Further, a
prefix route exists in the Internet routing system for 10.1.4.0/24
originated from ASN64496. Additionally, the current ROA list has a
valid ROA containing the prefix 10.1.0.0/22; maxLength 24 with
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 Curtis
Villamizar, Steve Kent, and Danny McPherson for their technical
insight and review.
9. IANA Considerations
This memo includes no request to IANA.
10. Security Considerations
This memo requires no security considerations
11. References
Manderson, et al. Expires December 24, 2011 [Page 28]
Internet-Draft RPKI Use Case and Interpretations June 2011
11.1. Normative References
[I-D.ietf-idr-deprecate-as-sets]
Kumari, W. and K. Sriram, "Deprecation of the use of BGP
AS_SET, AS_CONFED_SET.",
draft-ietf-idr-deprecate-as-sets-04 (work in progress),
May 2011.
[I-D.ietf-sidr-arch]
Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", draft-ietf-sidr-arch-13 (work in
progress), May 2011.
[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-01 (work in progress),
February 2011.
[I-D.ietf-sidr-res-certs]
Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates",
draft-ietf-sidr-res-certs-22 (work in progress), May 2011.
[I-D.ietf-sidr-roa-format]
Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)",
draft-ietf-sidr-roa-format-12 (work in progress),
May 2011.
[I-D.ietf-sidr-roa-validation]
Huston, G. and G. Michaelson, "Validation of Route
Origination using the Resource Certificate PKI and ROAs",
draft-ietf-sidr-roa-validation-10 (work in progress),
November 2010.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3852, July 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.
Manderson, et al. Expires December 24, 2011 [Page 29]
Internet-Draft RPKI Use Case and Interpretations June 2011
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 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.
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>.
Authors' Addresses
Terry Manderson
ICANN
Email: terry.manderson@icann.org
Kotikalapudi Sriram
US NIST
Email: ksriram@nist.gov
Russ White
Cisco
Email: russ@cisco.com
Manderson, et al. Expires December 24, 2011 [Page 30]
