You are here: Home > Publications > RIPE Labs > Alex Band > Using the ‘Maximum Length’ Option in ROAs

Using the ‘Maximum Length’ Option in ROAs

Alex Band — 19 Apr 2011
Contributors: Rene Wilhelm
In the resource certification system you specify your routing policy via Route Origin Authorization (ROA) objects. One of the options you can set is the ‘Maximum Length’, which specifies the maximum length of an IP address prefix that the AS is authorised to advertise. In this article we will analyse if this feature is being used properly.


Specifying your routing policy in the  resource certification system is done via a  Route Origin Authorization (ROA) object. This object essentially states: “I authorise this Autonomous System (AS) to originate these prefixes”. One of the options you can specify in a ROA is the so called the ‘Maximum Length’.

This is how the feature is described in the IETF Internet Draft ' A Profile for Route Origin Authorizations (ROAs) ': 

"When present, the maxLength specifies the maximum length of IP address prefix that the AS is authorized to advertise. (For example, if the IP Address prefix is 10.0/16 and the maxLength is 24, the AS is authorized to advertise any more specific prefix having length at most 24. That is, in this example, the AS would be authorized to advertise 10.0/16, 10.0.128/20, or 10.0.255/24, but not When the maxLength is not present, the AS is only authorized to advertise exactly the prefix specified in the ROA."

This is how the Maximum Length option is reflected in the RIPE NCC Resource Certification service user interface:

Figure 1: The Maximum Length option in the ROA specification interface

The feature is implemented exactly according to the specification. This means it is an optional field and when you take the example above, AS65411 is only allowed to announce exactly a /21. Any more specific announcement will be invalid.

After several months of running the production Resource Certification service, we analysed a snapshot of the entire repository  on 12 April 2011,  containing ROAs for 732 prefixes. 314 of them had a maximum length set, the other 418 did not. In the latter case, it means the creator either really intended to authorise the AS to announce only the exact prefix in the ROA, or they perhaps don’t have a good understanding of the option and simply left it blank.

We compared this list with the BGP routing tables seen by the  RIPE NCC Routing Information Service  (RIS)  on 15 April 2011. We limited ourselves to only 'widely seen' prefixes, which means they have to be seen by at least ten RIS peers. The result shows 51 cases where BGP has more specific prefixes originated by the ASN listed in the ROA which are longer than the maximum length allowed by the ROA. 46 of these 51 are prefixes in ROAs for which the Local Internet Registry (LIR) did not specify a maximum length. In total 512 prefixes are invalidated because of a seemingly misconfigured or empty Maximum Length field.

Judging from this, it would seem that quite a number of LIRs left the Maximum Length field blank when they really shouldn't have. To solve this, we could change the implementation of the specification in several ways. In the majority of the cases, the prefix owner and the advertiser are one and the same entity, so one could also argue that the default should impose as little constraint as possible. On the other hand, this does make the AS vulnerable to certain types of attacks where the AS number is spoofed and a more specific prefix is announced.

We would like to get your feedback on what you think the default setting should be:

  1. We can leave it as it is; an optional blank field. If a user made a mistake, they can always edit the ROA later
  2. We can make it a mandatory blank field, forcing the user to make an explicit decision
  3. We can make it an optional field, but pre-filled with a prefix that imposes minimal constraint by default, i.e. /32 for IPv4, and /128 for IPv6 
  4. Lastly, we can make it a mandatory field but still pre-fill it with a prefix that imposes minimal constraint by default, as suggested above

Please keep in mind that we intend to make a notification system in the Certification system that alerts the user when a ROA does not match real world routing. So whatever the we do, the user will always be made aware of the effect of their choice.

As always, we look forward to your input. 



Anonymous says:
19 Apr, 2011 05:45 PM
Hi Alex,

It would be my suggestion to take option 3, but pre-fill it with the most common most-specific 'accepted' prefix limit to a /24.

Most ISP's will (should) filter anything smaller than a IPv4 /24 anyway.

Anonymous says:
19 Apr, 2011 07:18 PM
I see little difference between 3) & 4), tbh, but I would opt for /24 as the prefill. If neither of these suits, then go for 2). I think leaving it as optional and empty will only cause further problems in the long run, even if it is following the strict specification.
Anonymous says:
20 Apr, 2011 04:11 PM
 I consider the ability to filter not just on origin AS, but also prefix length, to be an important feature of ROA's. If you look at the history of BGP hijacks/misannouncements, the most destructive ones have almost universally involved more specifics.
Anonymous says:
21 Apr, 2011 04:24 AM
My gut feeling says option 1 or perhaps 2. I agree with Larry, using pre-defined defaults may results 'authorized leaks of more specifics'.

I think users that are responsible for administrating roa's should be expected to put a little bit of thinking into this.

It's better to not have a (more specific) prefix reachable (because of failed validation) then to have unexpected (but validated) more specifics out there.
If a prefix is not reachable the administrator will have incentive to change the roa.

Of course users can still add a max length value of /24 (v4) or say a /48 for ipv6 to allow for some flexibility. But at least then they put 'some' thought into it...

Add comment

You can add a comment by filling out the form below. Comments are moderated so they won't appear immediately. If you have a RIPE NCC Access account, we would like you to log in.