What are best practices for RPKI ROV in transit networks....

Fri Oct 29 09:08:00 UTC 2021

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