[c-nsp] RPKI validation weirdness

[Mark Tinka]

On 8/May/20 01:25, Robert Raszuk wrote:

> Well this is not a feature (even in Cisco land - it is a design bug).
> Just a few days ago I had a phone chat with a person who implemented
> origin validation in Cisco and he actually confirmed.

It's all mangled, but specifically, the part that Cisco interpreted as a
feature (which is actually a bug against the RFC) is automatic
application of policy based on RPKI state, which then forms the initial
stages of the BGP best path algorithm. It is even officially documented
in the manual at:

   
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-3s/irg-xe-3s-book/bgp-origin-as-validation.html


    Use of the Validation State in BGP Best Path Determination

There are two ways you can modify the default BGP best path selection
process when using RPKI validation states:

  *

    You can completely disable the validation of prefixes by the RPKI
    server and the storage of that validation information. This is done
    by configuring the bgp bestpath prefix-validate disable command. You
    might want to do this for configuration testing. The router will
    still connect to the RPKI server and download the validation
    information, but will not use the information.

  *

    You can allow an invalid prefix to be used as the BGP best path,
    even if valid prefixes are available. This is the default behavior.
    The command to allow a BGP best path to be an invalid prefix, as
    determined by the BGP Origin AS Validation feature, is the bgp
    bestpath prefix-validate allow-invalid command. The prefix
    validation state will still be assigned to paths, and will still be
    communicated to iBGP neighbors that have been configured to receive
    RPKI state information. You can use a route map to set a local
    preference, metric, or other property based on the validation state.

During BGP best path selection, the default behavior, if neither of the
above options is configured, is that the system will prefer prefixes in
the following order:

  *

    Those with a validation state of valid.

  *

    Those with a validation state of not found.

  *

    Those with a validation state of invalid (which, by default, will
    not be installed in the routing table).

These preferences override metric, local preference, and other choices
made during the bestpath computation. The standard bestpath decision
tree applies only if the validation state of the two paths is the same.

If both commands are configured, the bgp bestpath prefix-validate
disable command will prevent the validation state from being assigned to
paths, so the bgp bestpath prefix-validate allow-invalid command will
have no effect.

These configurations can be in either router configuration mode or in
address family configuration mode for the IPv4 unicast or IPv6 unicast
address families.



>
> But your point is very valid. Unfortunately, when you hire excellent
> developers who develop features without ever getting full picture on
> what it is that they are actually developing and without deep
> understanding how those things are going to work in the real world you
> will like to see such fruits. And frankly this goes way beyond just
> cisco these days ...

Which we can all appreciate. But we brought this to Cisco's attention
all the way back in 2016/2017. Yes, it's getting fixed now, but we
weren't asking to make EIGRP an inter-domain routing protocol.

Mark.