[c-nsp] RPKI extended-community RFC8097

[Ben Maddison]

Hi Jakob,

On 12/18, Jakob Heitz (jheitz) wrote:
> Hi Lukas, Mark, Ben,
> 
> The default bestpath prefix-validate behavior treats invalid routes
> as unfeasible and prefers valid routes over not-found.
> 
> The default bestpath prefix-validate behavior cannot be used unless
> all paths of a net have the correct RPKI validity. That can only
> happen if all EBGP sessions into an AS validate their incoming
> routes and apply the RFC8097 extended community.

And, iff all ASBRs have a consistent set of VRPs from the validation
caches, which is a very fragile assumption, and the root of most of the
impact we've seen from this.

> If these conditions are not satisfied, then you cannot use the
> bestpath prefix-validate behavior and you must use
> route-maps to process the RPKI validity, like this:
> 
> router bgp ...
>  bgp rpki server tcp [...]
>  address-family ipv4
>   bgp bestpath prefix-validate disable
> [...]
> route-map RM_EBGP_IN deny 10
>  match rpki invalid
> [...]
> 
> I have a proposal to improve the bestpath prefix-validate behavior
> to better match how most operators use it. By a new configuration,
> I would treat valid and not-found with the same preference. Invalid
> would continue to be unfeasible. Then, a received IBGP route without
> the RFC8097 community will be fine.
> 
> Thoughts?
> 
That certainly sounds like an improvement (a large one), but it doesn't go far enough
for me.

The router should not *act* on validation status unless told to by the
operator at all.
I would suggest that the 'bgp bestpath prefix-validate ...' commands be
deprecated altogether, and be replaced with a single per-afi/safi
command that simply enables rov-checking (i.e. records the status in the
RIB, but takes no policy action).
Everything else can be done in a route-map.

I have heard the argument from other vendors that "operators want a
single command to apply, without touching routing policy".
I think this is false. At least in 2020, you would be very hard pressed
to find an operator doing ROV, but scared of writing a non-trivial
routing policy.

Getting from where you are today, to what I'm advocating obviously means
changing existing behaviors, which can be an unwelcome surprise.

I would suggest the following strategy:
1.  Introduce a new address-family mode command (something like 'bgp
    rpki-validate origin' to provide syntax space for aspa and others in
    future).
    Make it a no-op if 'bgp bestpath prefix-validate' is enabled, otherwise
    make it enable rov state checking as above.
2.  Start issuing a warning on the CLI, in logs, etc, when 'bgp bestpath prefix-validate'
    is used.
3.  After some time make 'bgp bestpath prefix-validate' a no-op hidden
    command.
4.  After some more time, error if 'bgp bestpath prefix-validate' is
    used.

Hope that helps.

Cheers,

Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20201218/1a8d1d46/attachment-0001.sig>