Greetings,
We seek input on best practices for implementing RPKI ROV in a transit (partial transit) network. The Internet2 network provides partial transit for many of the K-12 and higher education institutions in the US. Our customer routes number just over 6,000. We work with our customers to assist with the adoption of MANRS, including creating RPKI ROAs for their resources.
At some point in the future, we'd like to implement RPKI route origin validation (e.g., dropping invalids). Given that some routes may have mistaken ROAs that resolve to an invalid state, is there a standard/best practice for processing exceptions? Or, do transit providers that implement ROAs drop all routes that are invalid?
Thanks,
Steve
Hello,
Given that some routes may have mistaken ROAs that resolve to an
invalid state, is there a standard/best practice for processing exceptions?
There is no point in ROV, unless you are dropping invalid routes.
Not dropping invalid routes is something you'd do during transitional
phases, when you are not yet sure about the impact. But if you keep it
that way, you may as well not deploy it in the first place.
Refer to the BGP Filterguide at NLNOG for some low level details:
Lukas
Personally I recommend dropping them invalids.
However, you could set local preferences as follows:
- Valids routes get the highest local pref
- unknown routes get a medium local pref
- Invalids routes get the lowest local pref
In this way, if you have competing routes, the one with the higher local pref gets preferred. By so doing, you are sure that an invalid route will never get preferred over an unknown one or a valid one.
But, honestly there is no point in ROV if you will allow invalids…
Hi Steve,
Greetings,
We seek input on best practices for implementing RPKI ROV in a transit
(partial transit) network. The Internet2 network provides partial
transit for many of the K-12 and higher education institutions in the
US. Our customer routes number just over 6,000. We work with our
customers to assist with the adoption of MANRS, including creating
RPKI ROAs for their resources.
At some point in the future, we'd like to implement RPKI route origin
validation (e.g., dropping invalids). Given that some routes may have
mistaken ROAs that resolve to an invalid state, is there a
standard/best practice for processing exceptions?
Yes, SLURM, defined in RFC8416, provides a means of expressing local
policy exceptions. All the RP implementations in common use (that I am
aware of) support it.
However...
Or, do transit providers that implement ROAs drop all routes that are
invalid?
We have had discard-invalid policy in production on every eBGP adjacency
since April 2019.
In that time, we have had *zero* incidents that could not be resolved
without the creation of local exceptions. My understanding from
colleagues at other operators is that their experience has been similar.
As always, your experience may be different, so it is wise to be
prepared.
Cheers,
Ben
Personally I recommend dropping them invalids.
100%
However, you could set local preferences as follows:
- Valids routes get the highest local pref
- unknown routes get a medium local pref
- Invalids routes get the lowest local pref
In this way, if you have competing routes, the one with the higher
local pref gets preferred. By so doing, you are sure that an invalid
route will never get preferred over an unknown one or a valid one.
There are two core issues with the above approach:
1/ invalid 'more-specific' routes, regardless of local pref, will 'win',
so the approach is 'useless'.
2/ modifying BGP path attributes based on the validation state introduces
needless churn and BGP UPDATE flooding.
Consider the following scenario: someone new to the RPKI ecosystem
decides to create RPKI ROAs. They expect nothing to happen, but under
the hood new BGP UPDATEs are flooded in all directions because the
LOCAL_PREF attributes needs to be updated. Same problem when associating
BGP communities to validation states.
To quote myself from Rejecting RPKI Invalid BGP Routes – BGP Filter Guide – Guidance on BGP Filtering
"""
It is considered harmful to manipulate BGP Path Attributes (for example
LOCAL_PREF or COMMUNITY) based on the RPKI Origin Validation state.
Making BGP Path Attributes dependent on RPKI Validation states
introduces needless brittleness in the global routing system as
explained here. Additionally, the use of RFC 8097 is STRONGLY ABSOLUTELY
NOT RECOMMENDED. RFC 8097 has caused issues for multi-vendor network
operators.
"""
Nick Hilliard shared similar sentiment:
Kind regards,
Job