What are best practices for RPKI ROV in transit networks....
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, On Thu, 28 Oct 2021 at 21:35, <ssw@iu.edu> wrote:
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: https://bgpfilterguide.nlnog.net/guides/reject_invalids/ 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…
On 29 Oct 2021, at 00:20, Lukas Tribus <lukas@ltri.eu> wrote:
Hello,
On Thu, 28 Oct 2021 at 21:35, <ssw@iu.edu> wrote: 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: https://bgpfilterguide.nlnog.net/guides/reject_invalids/
Lukas
On Fri, Oct 29, 2021 at 01:20:33AM +0400, Musa Stephen Honlue wrote:
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 https://bgpfilterguide.nlnog.net/guides/reject_invalids/ """ 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: https://mailarchive.ietf.org/arch/msg/sidrops/dwQi9lgYKRVctdlMAHhtgYkzhSM/ Kind regards, Job
Hi Steve, On 10/28, ssw@iu.edu wrote:
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
participants (5)
-
Ben Maddison -
Job Snijders -
Lukas Tribus -
Musa Stephen Honlue -
ssw＠iu.edu