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]