The Registry team at APNIC is currently working on route management prevalidation, a feature designed to prevent users from inadvertently causing routing problems for their announcements in BGP.
Once implemented, users will receive warnings if they attempt to submit route management changes in MyAPNIC that would cause any of their current BGP announcements to be considered ‘RPKI-invalid’. Users can then make adjustments as required and avoid running into reachability issues and similar as a result.
Although the benefits here are fairly clear, there are several motivating factors with this work.
The Route Origin Validation process can be difficult to understand
The Route Origin Validation (ROV) process is documented in RFC 6483. This process classifies a given BGP announcement as one of ‘valid’, ‘invalid’, or ‘unknown’.
Although the process is well-defined and logical, some aspects can make it difficult to understand whether a given change will cause problems. For example, the validity state of an announcement is a function of all overlapping Route Origin Authorizations (ROAs) that exist. This means that changes that appear to be fine in isolation can be problematic, depending on the state that’s already in the system.
By setting up validation that implements the logic from RFC 6483, difficulties around determining validity ahead of time can be avoided.
Incorrect ROAs created before origin validation taking effect
Although ROV deployment has become more widespread over the past few years, there are still several networks that do not make use of it.
If an address holder decides to make ROAs at a point when the relevant announcements are not subject to origin validation, then they may construct ROAs that cause their announcements to become RPKI-invalid without realising that that’s a problem. Subsequently, when an upstream or a transit network enables origin validation and the address holder’s announcements are dropped, the cause of the problem may not be obvious (or worse, may be blamed on the origin validation deployment itself, rather than on the incorrect ROAs).
By validating ROA changes when they happen, it should be possible to minimize this sort of problematic action-at-a-distance.
MANRS requirements
The Mutually Agreed Norms for Routing Security (MANRS) CDN and Cloud Task Force published a document last year, Common ROA Management Requirements and Security Standards for Operators of RPKI Services (ORS). This document sets out various things that RPKI service operators, principally Regional Internet Registries, should do to facilitate the effective use of the system.
One of those things is route management prevalidation (see section 4 of the document), due to the reasons described in the previous two paragraphs. This sort of message from the community is a key consideration when it comes to the prioritization and planning of the work done by the Registry team.
Let us know what you think
The implementation of the prevalidation work is currently scheduled for the end of June 2022.
Feedback on this work is much appreciated. It can be sent privately to software@apnic.net, or publicly to the apnic-services@apnic.net mailing list.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.