Internet Engineering Task Force G. Rada Internet-Draft N. Fiumarelli Intended status: Informational LACNIC Expires: January 25, 2015 August 18, 2014 ROA Creation Recommendations for Resource Public Key Infrastructure draft-sidr-roa-creation-recommendations-00 Abstract This document describes the different criterias over ROA's creation, a possible classification of organizations and an argument about the most recommended criteria for each case. 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 January 25, 2015. Copyright Notice Copyright (c) 2014 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 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. Rada & Fiumarelli Expires January 25, 2015 [Page 1] Internet-Draft ROA Recommendations for RPKI August 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. Classification of Organizations . . . . . . . . . . . . . . . 2 2.1. Business Model . . . . . . . . . . . . . . . . . . . . . 3 2.2. Frequency of BGP updates . . . . . . . . . . . . . . . . 3 2.3. Customers Quantity . . . . . . . . . . . . . . . . . . . 3 2.4. RPKI Aprehension Level . . . . . . . . . . . . . . . . . 3 2.5. ASN Origin . . . . . . . . . . . . . . . . . . . . . . . 3 2.6. Providers Quantity . . . . . . . . . . . . . . . . . . . 3 3. Creation Criterias . . . . . . . . . . . . . . . . . . . . . 3 3.1. Creation Dedication . . . . . . . . . . . . . . . . . . . 4 3.2. Maintenance Dedication . . . . . . . . . . . . . . . . . 4 3.3. Security Level . . . . . . . . . . . . . . . . . . . . . 4 4. Criteria 1 . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Criteria 2 . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Criteria 3 . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. Resume Table . . . . . . . . . . . . . . . . . . . . . . . . 5 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction In the context of Resource Public Key Infrastructure (RPKI) the concept of ROA (rfc roa-xx) consists in a set of IP blocks / maximum length for an ASN. This leads to the routes advertised to validate these prefixes to * the maximum length allowed by the configuration of the ROA. In recent years, the use of RPKI has increased significantly, this, almost forcing the ISPs to ensure their advertisements. 1.1. 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 [RFC2119]. 2. Classification of Organizations Rada & Fiumarelli Expires January 25, 2015 [Page 2] Internet-Draft ROA Recommendations for RPKI August 2014 2.1. Business Model ISP End User 2.2. Frequency of BGP updates I frequently change my BGP announcements I rarely change my BGP announcements 2.3. Customers Quantity I have many BGP-speaking clients I have a few BGP-speaking clients I have no bgp-speaking clients 2.4. RPKI Aprehension Level I know a lot about RPKI I have a medium knowledge in RPKI I have no knowledge in RPKI 2.5. ASN Origin I have my own ASN I do not own ASN 2.6. Providers Quantity I have only one provider I have many providers 3. Creation Criterias We will consider some different criterias to create the prefix and the maximum length included in the ROAs. These different ways to create generate various benefits and contraindications classified according to the following: Rada & Fiumarelli Expires January 25, 2015 [Page 3] Internet-Draft ROA Recommendations for RPKI August 2014 3.1. Creation Dedication Medium Complexity: The criteria will have a high complexity if the scan before the creation of the ROA implies aggregation tasks, many consultations and careful research on the structure of BGP announcements. Low Complexity: The criteria will have a low complexity if the process of analyse the creation does not require extensive work and research to identify which prefixes should be included in the ROA 3.2. Maintenance Dedication High maintenance dedication Low maintenance dedication 3.3. Security Level High Security Medium Security 4. Criteria 1 Criterion 1: For every advertise in the routing table, ip blocks within the same ASN are grouped to create a ROA, the maximum length corresponds to the length of the prefix, as it is being advertised. Creation dedication: Low. The Low-cost of creation is because the creation of the ROA is as simple as reflect (copy) the information in the routing table. Identify the network, the ASN and its source and include that information in the ROA. Cost of maintenance: High. Whenever there are changes in the BGP advertisements is necessary to update the information ROAs. When you copy exactly the information that is in the routing table whenever it changes, you must update ROAs. Security level: High. It reflect exactly what is being advertised and place the Max Prefix length = length, this authorize no other more specific ads for the same AS. 5. Criteria 2 Criterion 2: For each network assigned to our organization, identify which ASNs announce at least a subset of this network, ip blocks within the same ASN are grouped to create a ROA. The maximum length corresponds to the highest prefix length of announced subnets. Cost of creation: Medium. The cost of creation is medium because the creation of the ROA includes a preliminary analysis, identify of all our networks, identify all ASNs source and verify which is the Rada & Fiumarelli Expires January 25, 2015 [Page 4] Internet-Draft ROA Recommendations for RPKI August 2014 maximum of the lengths with which networks are advertised regularly. Cost of maintenance: Low. By including all networks assigned to our organization in the roa, there is no need to modify the ROAs every time you start to advertise networks that already have been assigned. Security level: Medium. Unlike the previous case, here we are allowing a larger set of networks for been announced. If there is a hijack over my ASN, and a kidnap of my networks is realized, in some places the abducted route would be preferred rather than the valid route. 6. Criteria 3 Criterion 3: For each network assigned to our organization we identify which ASNs announce at least a subset of my networks, the ip-blocks with the same ASN are grouped to create a ROA for each and the maximum length corresponds to 24 in the case of grouped IPv4 and 48 in the case of IPv6. Cost of creation: Low. The Low cost is because the creation of the ROA it's' reduced to simply identify the assigned networks and which ASN's announce their. Cost of maintenance: Low. By including all networks assigned to our organization in the roa, there is no need to modify the ROAs every time you start to advertise networks that had already assigned, Also it is not necessary to edit the ROA if you decide to make more specific announcements. Security level: Medium. Similar to criterion 2 we are allowing a larger set of networks for been announced. If there is a hijack over my ASN, and a kidnap of my networks is realized, in some places the abducted route would be preferred rather than the valid route. 7. Resume Table Here are the recommendations made in accordance with the criteria and organization's classification previously submitted. For each case one of the following values will be assigned: Ideal: The best option to apply Recommended: If you choose to implement this approach it is a valid and practical option. Not recommended: Do not apply this criterion for this type of organization. Unknown: We can not recommend or not the use of this criterion by lack of information Figure 1 shows the general scheme of a single RDAP Redirection Service serving three different RIRs standalone RDAPs while providing a seamless query interface to clients. Rada & Fiumarelli Expires January 25, 2015 [Page 5] Internet-Draft ROA Recommendations for RPKI August 2014 _____________________________________________________________________ | | | | | | | CLASSIFICATION | CASE | C1 | C2 | C3 | | | | | | | |......................|.......................|......|......|......| | | ISP | R | U | U | | Business Model |.......................|......|......|......| | | End User | NR | I | R | |......................|.......................|......|......|......| | | Frequently | NR | R | I | | Frequency of BGP |.......................|......|......|......| | | Rarely | R | R | U | |......................|.......................|......|......|......| | | High | R | NR | U | | Customers Quantity |.......................|......|......|......| | | Medium | NR | R | R | | |.......................|......|......|......| | | Low | NR | R | R | |......................|.......................|......|......|......| | | High | I | NR NR | | |.......................|......|......|......| |RPKI Aprehension Level| Medium | NR | I | R | | |.......................|......|......|......| | | Low | NR | R | R | |......................|.......................|......|......|......| | | Own ASN | U | R | R | | ASN Origin |..................... |......|......|......| | | Third party ASN | R | U | U | |...................'..|.......................|......|......|......| | | Only one provider | U | R | I | | Providers Quantity |.......................|......|......|......| | | Multiple providers | R | U | U | |......................|.......................|......|......|......| Resume Table Figure 1 8. Security Considerations No security considerations are described in this informational 9. Acknowledgments The authors acknowledge the work of Alejandro Acosta for their help with the format and ordering of sections in the draft Rada & Fiumarelli Expires January 25, 2015 [Page 6] Internet-Draft ROA Recommendations for RPKI August 2014 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012. [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 Gerardo Rada LACNIC Rambla Mexico 6125 Montevideo 11400 Uruguay Phone: +598-2604-2222 Email: gerardo@lacnic.net Nicolas Fiumarelli LACNIC Rambla Mexico 6125 Montevideo 11400 Uruguay Phone: +598-2604-2222 Email: nfiumarelli@lacnic.net Rada & Fiumarelli Expires January 25, 2015 [Page 7]