Typically, LACNIC events include RPKI (Public Resource Key Infrastructure) and IRR (Internet Routing Registry) tutorials in which we review the theory and technical aspects of best practices related to traffic exchange and peering routing security. In addition, the LACNIC 39 event held in Mérida also included a consultation session on secure routing and tools, where a series of questions were raised which we have consolidated in this document.
Who should create the ROA, the organization to which the IP address block has been delegated or the organization to which the autonomous system has been delegated?
Route Origin Attestations (ROAs) are digitally signed objects that describe a link between a set of prefixes (IPv4 or IPv6) and the autonomous system authorized to originate them in BGP announcements (in RPKI, this is known as ‘origin validation’ of a route or prefix). Therefore, the ROA must be created by the holder of the address block (the organization to which LACNIC has delegated the use of the prefix) and can be associated with any autonomous system, regardless of whether it is held by the same organization or by a third party.
(Free access, no subscription required)
What is the maximum length that should be used when creating an ROA?
When creating ROAs, we must take into account the maximum length of the prefixes we are advertising in BGP. As a general rule, we should only create ROAs that cover our advertisements. It is essential that the maximum length specified in an ROA is not shorter than that of a published prefix, because, for example, if the ROA allows /22 prefixes but we announce a /24, that announcement will not be allowed by the ROA and therefore both will be invalidated.
In certain cases, if we know we are going to deaggregate blocks from a larger block, we could use this maximum length to avoid having to create an ROA for each advertised prefix. However, this practice is generally not recommended, as it would enable potential origin spoofing attacks. For more information, see RFC 9319.
What is the maximum length that should be used when creating an ROA?
When creating ROAs, we must take into account the maximum length of the prefixes we are advertising in BGP. As a general rule, we should only create ROAs that cover our advertisements. It is essential that the maximum length specified in an ROA is not shorter than that of a published prefix, because, for example, if the ROA allows /22 prefixes but we announce a /24, that announcement will not be allowed by the ROA and therefore both will be invalidated.
In certain cases, if we know we are going to deaggregate blocks from a larger block, we could use this maximum length to avoid having to create an ROA for each advertised prefix. However, this practice is generally not recommended, as it would enable potential origin spoofing attacks. For more information, see RFC 9319.
How do we create or define our ROAs if we have more than one provider?
For prefixes delegated by LACNIC, two different cases are possible: when an Autonomous System Number (ASN) is available and when an ASN is not available.
If theadvertisements originate from our own ASN:
In this case, the ROAs must be generated with our own ASN as the origin autonomous system. It is important to consider how we are publishing BGP advertisements and to properly generate the ROAs so that the authorized prefix lengths match our advertisements.
If the advertisements originate from our Internet access providers’ ASNs:
If the prefixes originate from the autonomous system of one or more providers, we must generate an ROA with each prefix and each of their origin autonomous systems. RPKI validation will determine that a BGP advertisement is valid if it is covered by at least one ROA; in other words, it doesn’t matter if there are contradicting ROAs provided that there is at least one ROA that corresponds to the BGP advertisement.
Can I create my own ROAs if my resources are a sub-assignment?
After the approval of policy LAC-2020-10, the holders of sub-assigned resources may create their own ROAs. Prior to this, they relied on the ISP that sub-assigned the addresses to create the ROA for the organization receiving the resources.
Is the creation of ROAs part of MANRS best operational practices?
The creation of ROAs is indeed part of MANRS, the Mutually Agreed Standards for Routing Security. These standards specify actions that end entities, Internet service providers, Internet exchange points, content providers, and cloud service providers should implement in their infrastructure.
Specifically, two of these actions —filtering and global validation— call for routing information to be made available on a global scale to facilitate validation of the routes advertised to the Internet and to use filtering to prevent the propagation of incorrect routing information. This is achieved by generating our ROAs and recording our routing information in databases such as the IRRs.
What are the main objects in LACNIC’s IRR? Which are generated automatically?
The current version of LACNIC’s IRR supports the following objects: AUT-NUM, ROUTE, ROUTE6, AS-SET, MNTNER, and PERSON. All these objects are automatically generated based on the whois information or the information registered in RPKI, except for AS-SET which must be generated by the user who holds the resources.
Invitation to LACNIC 40 – LACNOG 2023
To learn more about these topics, we invite you to the tutorials that will be held at the LACNIC 40- LACNOG 2023 event to be held in the city of Fortaleza, Brazil, on Monday 2 October. These include the tutorials Use of RPKI and IRR for Network Operation, Delegated RPKI (aimed primarily at members of NIC Brasil), and Resource Management/MiLACNIC, a tutorial designed for members who manage RPKI in hosted mode. You can also participate in the Secure Routing and Automation Lab, where these topics will be addressed from a practical point of view.
If you are interested in these topics, you can participate both remotely and in person. Click here to register!
