Secure Inter-Domain Routing T. Manderson
Internet-Draft ICANN
Intended status: Informational K. Sriram
Expires: December 17, 2009 NIST
R. White
Cisco
June 15, 2009
Use Cases and interpretation of RPKI objects for issuers and relying
parties
draft-manderson-sidr-usecases-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 17, 2009.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Manderson, et al. Expires December 17, 2009 [Page 1]
Internet-Draft RPKI Use Case and interpretations June 2009
Abstract
This document provides use cases directions, and interpretations for
organisations and relying parties when creating or encountering RPKI
object scenarios in the public RPKI in relation to public internet
routing.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. General interpretation of RPKI object semantics . . . . . . 3
3. Origination use cases . . . . . . . . . . . . . . . . . . . . . 3
3.1. Single announcement . . . . . . . . . . . . . . . . . . . . 4
3.2. Aggregate with a more specific . . . . . . . . . . . . . . 4
3.3. Aggregate with more specific from different ASN . . . . . . 4
3.4. Sub-allocation to multi-homed customer . . . . . . . . . . 4
3.5. Restriction of new allocation . . . . . . . . . . . . . . . 4
3.6. Restriction of new ASN . . . . . . . . . . . . . . . . . . 4
3.7. Restriction of part of allocation . . . . . . . . . . . . . 5
3.8. Restriction of prefix length . . . . . . . . . . . . . . . 5
3.9. Restriction of sub-alloction prefix length . . . . . . . . 5
4. Adjacency use cases . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Multi-homed . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Restricting peers . . . . . . . . . . . . . . . . . . . . . 5
4.3. Restricting customers . . . . . . . . . . . . . . . . . . . 6
5. Partial Deployment use cases . . . . . . . . . . . . . . . . . 6
5.1. Parent does not do RPKI . . . . . . . . . . . . . . . . . . 6
5.2. Only some children participate . . . . . . . . . . . . . . 6
6. Relying Party use cases . . . . . . . . . . . . . . . . . . . . 6
6.1. Validation of updates using ROAs . . . . . . . . . . . . . 6
6.2. Response to Expiry/Revocation of Certificates . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
10. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Manderson, et al. Expires December 17, 2009 [Page 2]
Internet-Draft RPKI Use Case and interpretations June 2009
1. Introduction
This document provides suggested use cases, direction and
interpretations for organisations and relying parties when creating
or encountering RPKI object scenarios in the public RPKI in relation
to public internet routing.
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], "A Profile for Bogon Origin
Authorizations (BOAs)" [I-D.ietf-sidr-bogons], "Validation of Route
Origination in BGP using the Resource Certificate PKI"
[I-D.ietf-sidr-roa-validation],
1.2. 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.
2. Overview
2.1. General interpretation of RPKI object semantics
It is important that the interpretation of relying parties, or
relying party routing software, that implements a level of routing
decision, when a routing update ("route") is received in light of the
existence or non-existence of an RPKI object corresponding to the
routing update a 'make before break' stance is taken. This means
that the relying party should do all possible steps to ensure a route
is valid, before attempting to declare it otherwise. For all of the
cases in this document it is assumed that RPKI objects validate in
accordance with [I-D.ietf-sidr-res-certs], [I-D.ietf-sidr-arch],
[I-D.ietf-sidr-roa-validation], and [I-D.ietf-sidr-bogons] unless
otherwise stated.
3. Origination use cases
Manderson, et al. Expires December 17, 2009 [Page 3]
Internet-Draft RPKI Use Case and interpretations June 2009
3.1. Single announcement
An organisation (ASN 64496) has been allocated the prefix
192.168.2.0/24, it wishes to announce the /24 prefix from ASN 64496
to the public internet such that relying parties interpret the route
as valid.
3.2. Aggregate with a more specific
An organisation (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 to the
public internet such that relying parties interpret the routes as
valid.
3.3. Aggregate with more specific from different ASN
An organisation (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 64499 as well as the aggregate route from ASN
64496 to the public internet such that relying parties interpret the
routes as valid.
3.4. Sub-allocation to multi-homed customer
An organisation (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 who is multi-homed and will originate the route prefix
route from ASN 64511. ASN 64496 will also announce the aggregate
route to the public internet such that relying parties interpret the
routes as valid.
3.5. Restriction of new allocation
An organisation 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 in
routing using RPKI.
3.6. Restriction of new ASN
An organisation has recently been allocated an additional 4 byte ASN
65551. Its network deployment is not yet ready to use this ASN and
wishes to restrict all possible uses of ASN 65551 using RPKI.
Manderson, et al. Expires December 17, 2009 [Page 4]
Internet-Draft RPKI Use Case and interpretations June 2009
3.7. Restriction of part of allocation
An organisation (ASN 64496) has been allocated the prefix
10.1.0.0/16. Its network topology permits the announcement of
10.1.0.0/17 but restricts any possible announcement of 10.1.128.0/17
using RPKI.
3.8. Restriction of prefix length
An organization (ASN 64496) has been allocated the prefix
10.1.0.0/16, it wishes to announce the aggregate and all more
specific prefixes up to and including a maximum length of /20, but
never more specific than that.
3.9. Restriction of sub-alloction prefix length
An organization (ASN 64496) has been allocated the prefix
10.1.0.0/16, it sub-allocates /20 prefixes to its multi-homed
customers. It wishes to restrict those customers from advertising
any corresponding routes more specific than a /22.
4. Adjacency use cases
Issues of validation of adjacency, or path validation, are currently
out of scope of the SIDR-WG charter. The use cases is this section
are listed here as a reminder that the work goes beyond origination
and at the stage when orginiation has been addressed by the WG, a
recharter to encompass adjacency will allow consideration of these
use cases.
4.1. Multi-homed
An organisation (ASN 64496) has been allocated the prefix
10.1.0.0/16. Its upstreams are ASN 65551 and ASN 64499. The
organisation announces the /16 aggregate. It permits that ASNs 65551
and 64499 may announce the aggregate to their upstreams.
4.2. Restricting peers
An organisation (ASN 64496) has been allocated the prefix
10.1.0.0/16. Its two upstreams are ASN 65551 and ASN 64499. The
organistion (ASN 64496) peers with a third AS, ASN 64511. The
organisation announces the more specific 10.1.0.0/24 and the /16
aggregate. It wishes that only ASNs 65551 and 64499 may announce the
aggregate and more specifics to their upstreams. ASN 64511, the
peer, may not further announce (or leak) any routes for 10.1.0.0/16
and 10.1.0.0/24.
Manderson, et al. Expires December 17, 2009 [Page 5]
Internet-Draft RPKI Use Case and interpretations June 2009
4.3. Restricting customers
An organisation (ASN 64496) has a customer (ASN 64511) that has been
allocated 10.1.0.0/16 from an RIR. The organisation wishes not to be
used as transit for ASN 64511.
5. Partial Deployment use cases
5.1. Parent does not do RPKI
An organisation (ASN 64511) is multi-homed has been assigned the
prefix 10.1.0.0/20 from an upstream (ASN 64496), it wishes to
announce the prefix 10.1.0.0/20 from ASN 64511 to its other
upstream(s). It also wishes to create RPKI statements about the
resource, however ASN 64496 has not yet adopted RPKI.
5.2. Only some children participate
An An organisation (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
and 10.1.32.0/20 to customers ASN 64511 and 65551 (respectively) who
are multi-homed. ASN 64511 does not participate in RPKI. ASN 65551
participates in RPKI.
6. Relying Party use cases
6.1. Validation of updates using ROAs
TBC
6.2. Response to Expiry/Revocation of Certificates
TBC
7. Acknowledgements
The authors are indebted to both Sandy Murphy and Sam Weiler for
their guidance.
8. IANA Considerations
This memo includes no request to IANA.
Manderson, et al. Expires December 17, 2009 [Page 6]
Internet-Draft RPKI Use Case and interpretations June 2009
9. Security Considerations
This memo requires no security considerations
10. Normative References
[I-D.ietf-sidr-arch]
Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", draft-ietf-sidr-arch-06 (work in
progress), March 2009.
[I-D.ietf-sidr-bogons]
Manderson, T., "A Profile for Bogon Origin Attestations
(BOAs)", draft-ietf-sidr-bogons-03 (work in progress),
May 2009.
[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-16 (work in progress),
February 2009.
[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-04 (work in progress),
November 2008.
[I-D.ietf-sidr-roa-validation]
Huston, G. and G. Michaelson, "Validation of Route
Origination in BGP using the Resource Certificate PKI",
draft-ietf-sidr-roa-validation-01 (work in progress),
October 2008.
[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.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Manderson, et al. Expires December 17, 2009 [Page 7]
Internet-Draft RPKI Use Case and interpretations June 2009
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.
Authors' Addresses
Terry Manderson
ICANN
Email: terry.manderson@icann.org
Kotikalapudi Sriram
NIST
Email: ksriram@nist.gov
Russ White
Cisco
Email: russ@cisco.com
Manderson, et al. Expires December 17, 2009 [Page 8]