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) ':
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:
- We can leave it as it is; an optional blank field. If a user made a mistake, they can always edit the ROA later
- We can make it a mandatory blank field, forcing the user to make an explicit decision
- 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
- 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.
Comments 4
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.
Anonymous •
Hi Alex, <br /><br />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. <br /><br />Most ISP's will (should) filter anything smaller than a IPv4 /24 anyway. <br /><br />Regards,<br />Erik<br />
Anonymous •
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 •
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 •
My gut feeling says option 1 or perhaps 2. I agree with Larry, using pre-defined defaults may results 'authorized leaks of more specifics'.<br /><br />I think users that are responsible for administrating roa's should be expected to put a little bit of thinking into this.<br /><br />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. <br />If a prefix is not reachable the administrator will have incentive to change the roa. <br /><br />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...<br /><br /><br /><br />