Alex Band

Using the ‘Maximum Length’ Option in ROAs

Alex Band
Contributors: Rene Wilhelm
0 You have liked this article 0 times.

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:

MaxLength Screenshot

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. 


0 You have liked this article 0 times.

You may also like

View more

About the author

Alex Band Based in Amsterdam

Director of Product Development at NLnet Labs

Comments 4