use minimal ROAs whenever possible. A minimal ROA contains only those IP prefixes that are actually originated by an AS in BGP and no other IP prefixes. See Section 3
for an example.
In general, operators SHOULD
avoid using the maxLength attribute in their ROAs, since its inclusion will usually make the ROA non-minimal.
One such exception may be when all more specific prefixes permitted by the maxLength value are actually announced by the AS in the ROA. Another exception is where: (a) the maxLength value is substantially larger compared to the specified prefix length in the ROA, and (b) a large number of more specific prefixes in that range are announced by the AS in the ROA. In practice, this case should occur rarely (if at all). Operator discretion is necessary in this case.
This practice requires no changes to the RPKI specifications and need not increase the number of signed ROAs in the RPKI because ROAs already support lists of IP prefixes [RFC 6482
]. See [GSG17
] for further discussion of why this practice will have minimal impact on the performance of the RPKI ecosystem.
Operators that implement these recommendations and have existing ROAs published in the RPKI system MUST
perform a review of such objects, especially where they make use of the maxLength attribute, to ensure that the set of included prefixes is "minimal" with respect to the current BGP origination and routing policies. Published ROAs MUST
be replaced as necessary. Such an exercise MUST
be repeated whenever the operator makes changes to either policy.
Operational requirements may require that a route for an IP prefix be originated on an ad hoc basis, with little or no prior warning. An example of such a situation arises when an operator wishes to make use of DDoS mitigation services that use BGP to redirect traffic via a "scrubbing center".
In order to ensure that such ad hoc routing changes are effective, a ROA validating the new route should exist. However, a difficulty arises due to the fact that newly created objects in the RPKI are made visible to relying parties considerably more slowly than routing updates in BGP.
Ideally, it would not be necessary to pre-create the ROA, which validates the ad hoc route, and instead create it "on the fly" as required. However, this is practical only if the latency imposed by the propagation of RPKI data is guaranteed to be within acceptable limits in the circumstances. For time-critical interventions such as responding to a DDoS attack, this is unlikely to be the case.
Thus, the ROA in question will usually need to be created well in advance of the routing intervention, but such a ROA will be non-minimal, since it includes an IP prefix that is sometimes (but not always) originated in BGP.
In this case, the ROA SHOULD
- the set of IP prefixes that are always originated in BGP, and
- the set of IP prefixes that are sometimes, but not always, originated in BGP.
The ROA SHOULD NOT
include any IP prefixes that the operator knows will not be originated in BGP. In general, the ROA SHOULD NOT
make use of the maxLength attribute unless doing so has no impact on the set of included prefixes.
The running example is now extended to illustrate one situation where it is not possible to issue a minimal ROA.
Consider the following scenario prior to the deployment of RPKI. Suppose AS 64496 announced 192.168.0.0/16 and has a contract with a DDoS mitigation service provider that holds AS 64500. Further, assume that the DDoS mitigation service contract applies to all IP addresses covered by 192.168.0.0/22. When a DDoS attack is detected and reported by AS 64496, AS 64500 immediately originates 192.168.0.0/22, thus attracting all the DDoS traffic to itself. The traffic is scrubbed at AS 64500 and then sent back to AS 64496 over a backhaul link. Notice that, during a DDoS attack, the DDoS mitigation service provider AS 64500 originates a /22 prefix that is longer than AS 64496's /16 prefix, so all the traffic (destined to addresses in 192.168.0.0/22) that normally goes to AS 64496 goes to AS 64500 instead. In some deployments, the origination of the /22 route is performed by AS 64496 and announced only to AS 64500, which then announces transit for that prefix. This variation does not change the properties considered here.
First, suppose the RPKI only had the minimal ROA for AS 64496, as described in Section 3
. However, if there is no ROA authorizing AS 64500 to announce the /22 prefix, then the DDoS mitigation (and traffic scrubbing) scheme would not work. That is, if AS 64500 originates the /22 prefix in BGP during DDoS attacks, the announcement would be invalid [RFC 6811
Therefore, the RPKI should have two ROAs: one for AS 64496 and one for AS 64500.
ROA:(192.168.0.0/16, 192.168.225.0/24, AS 64496)
ROA:(192.168.0.0/22, AS 64500)
Neither ROA uses the maxLength attribute, but the second ROA is not "minimal" because it contains a /22 prefix that is not originated by anyone in BGP during normal operations. The /22 prefix is only originated by AS 64500 as part of its DDoS mitigation service during a DDoS attack.
Notice, however, that this scheme does not come without risks. Namely, all IP addresses in 192.168.0.0/22 are vulnerable to a forged-origin sub-prefix hijack during normal operations when the /22 prefix is not originated. (The hijacker AS 64511 would send the BGP announcement "192.168.0.0/22: AS 64511, AS 64500", falsely claiming that AS 64511 is a neighbor of AS 64500 and falsely claiming that AS 64500 originates 192.168.0.0/22.)
In some situations, the DDoS mitigation service at AS 64500 might want to limit the amount of DDoS traffic that it attracts and scrubs. Suppose that a DDoS attack only targets IP addresses in 192.168.0.0/24. Then, the DDoS mitigation service at AS 64500 only wants to attract the traffic designated for the /24 prefix that is under attack, but not the entire /22 prefix. To allow for this, the RPKI should have two ROAs: one for AS 64496 and one for AS 64500.
ROA:(192.168.0.0/16, 192.168.225.0/24, AS 64496)
ROA:(192.168.0.0/22-24, AS 64500)
The second ROA uses the maxLength attribute because it is designed to explicitly enable AS 64500 to originate any /24 sub-prefix of 192.168.0.0/22.
As before, the second ROA is not "minimal" because it contains prefixes that are not originated by anyone in BGP during normal operations. Also, all IP addresses in 192.168.0.0/22 are vulnerable to a forged-origin sub-prefix hijack during normal operations when the /22 prefix is not originated.
The use of the maxLength attribute in this second ROA also comes with additional risk. While it permits the DDoS mitigation service at AS 64500 to originate prefix 192.168.0.0/24 during a DDoS attack in that space, it also makes the other /24 prefixes covered by the /22 prefix (i.e., 192.168.1.0/24, 192.168.2.0/24, and 192.168.3.0/24) vulnerable to forged-origin sub-prefix attacks.
When responding to certain classes of prefix hijack (in particular, the forged-origin sub-prefix hijack described above), it may be desirable for the victim to perform "defensive de-aggregation", i.e., to begin originating more-specific prefixes in order to compete with the hijack routes for selection as the best path in networks that are not performing RPKI-ROV [RFC 6811
In topologies where at least one AS on every path between the victim and hijacker filters RPKI-ROV invalid prefixes, it may be the case that the existence of a minimal ROA issued by the victim prevents the defensive more-specific prefixes from being propagated to the networks topologically close to the attacker, thus hampering the effectiveness of this response.
Nevertheless, this document recommends that, where possible, network operators publish minimal ROAs even in the face of this risk. This is because:
Minimal ROAs offer the best possible protection against the immediate impact of such an attack, rendering the need for such a response less likely;
Increasing RPKI-ROV adoption by network operators will, over time, decrease the size of the neighborhoods in which this risk exists; and
Other methods for reducing the size of such neighborhoods are available to potential victims, such as establishing direct External BGP (EBGP) adjacencies with networks from whom the defensive routes would otherwise be hidden.