Internet DRAFT - draft-sidr-roa-creation-recommendations
draft-sidr-roa-creation-recommendations
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]
