[c-nsp] RPKI extended-community RFC8097

[Mark Tinka]

On 12/18/20 10:25, Ben Maddison wrote:

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

Earlier this year, I did ask Jeff (and Jakob) to help fix the IOS XE 
RPKI brokenness with a myriad of suggestions.

There hasn't been much progress (specifically, feedback) on that since 
then. I was promised some test code with the recommended fixes, but the 
year is almost out, and I can understand that with the pandemic, 
priorities may have shifted.

At any rate, these are the suggestions I made to Jeff and Jakob back in 
March. Not sure if they are still relevant anymore, as we turned off 
RPKI on all our IOS XE boxes, and haven't bothered to keep up with how 
it has developed on that platform since:

*****

  *   When an RTR session is established with the validator, the router
    should be able to accept and store all validation information.
    However, it SHOULD NOT automatically use this information to make
    routing decisions. So this would be the first thing to fix so we
    have a good working base.

  * Have a single command that is configurable within BGP to
    automatically drop Invalid routes. This is useful if an operator
    wants to use RPKI mainly to drop Invalid routes, and has no need to
    evaluate other RPKI states. With this command, it negates the need
    to build a route-map to achieve the same thing. A sample
    configuration for this would be:

         router bgp 1234
             address-family ipv4
                 bgp bestpath prefix drop-invalids
             address-family ipv6
                 bgp bestpath prefix drop-invalids

  * Remove the "bgp bestpath prefix-validate allow-invalid" command, as
    with this fix, the operator can decide to do this via a route-map if
    they want to. It also takes the gun - that they could use to easily
    shoot their foot - out of their hands.

  * Remove the "bgp bestpath prefix-validate disable" command, as with
    this fix, validation does not occur by default unless the operator
    enables this via a route-map, or via the "bgp bestpath prefix
    drop-invalids" command.

  * All other methods to enable validation should be done via a
    route-map only. When a route-map with RPKI match and set conditions
    is applied to a BGP session, the router will consult the validation
    database as populated by the RTR session, and then apply the policy
    on the router accordingly, as dictated by the route-map
    configuration. The route-map should be able to apply this policy
    both on the inbound and outbound directions of a BGP session.

  * An example of what a route-map should be able to do is as per below:

           route-map BGP-POLICY permit|deny 10
             match rpki valid|not-found|invalid
             set rpki valid|not-found|invalid

  * So as per the route-map example above, matching an RPKI state ONLY
    tells the router to look for any routes in the validation database
    that correspond to the match condition defined in the route-map.
    This DOES NOT tell the router to do anything with those routes from
    a routing perspective. This is CRITICAL. It does, however, allow the
    router to export or drop those routes toward an eBGP or iBGP
    neighbor if applied in the outbound direction.

  * ONLY when the operator uses a "set" condition in the route-map does
    the router then apply the corresponding policy when used in the
    inbound direction from an eBGP or iBGP neighbor. If the operator
    does not use the "set" condition in the route-map, but applies it on
    an eBGP or iBGP session in the inbound direction, the router WILL
    NOT apply any policy related to RPKI.

  * It's VERY CRITICAL to note that the router SHOULD NOT make any
    INHERENT DECISIONS on routing policy based on the "match" or "set"
    conditions in the route-map. The decision on what to do SHOULD ONLY
    be based on whether the route-map is a "permit" or "deny" route-map.
    In other words, the router is unaware about the significance of RPKI
    state, i.e., Valid, Invalid, NotFound. To the router, those RPKI
    states are just arbitrary values with no real meaning. The router
    SHOULD ONLY make the decision under one of two circumstances:

             - The route-map's "permit" or "deny" action.
             - The "bgp bestpath prefix drop-invalids" command.

  * If an operator tries to configure both the "bgp bestpath prefix
    drop-invalids" command and the route-map version of dropping
    Invalids with a "deny" action, the router SHOULD prefer the
    route-map version over the global "bgp bestpath prefix
    drop-invalids" command. In fact, it would be helpful if the router
    can throw back an error if it recognizes that the operator has
    configured (or has tried to configure) both of these options at the
    same time. That way, the operator knows that one of the two has
    already been configured, and that the router SHOULD tell the
    operator which one will be used (and which one will be ignored) if
    both are present in the running configuration.

  * Validation state SHOULD ONLY be applied to a route if the operator
    has defined "match" and "set" conditions in a route-map in the
    inbound direction of the BGP session. If this has not been done, the
    router should mark all routes in the RIB/FIB as "RPKI State:
    Unverified".

  * The router SHOULD be able to allow operators to view a summary of
    Valid, Invalid and Not-Found records in the validation database.
    This is important in case an operator wants to quickly see what the
    validation database thinks is the RPKI state of a route vs. what the
    validator said it is. Examples of these commands would be:

             show bgp ipv4 unicast rpki table valid|notfound|invalid
             show bgp ipv6 unicast rpki table valid|notfound|invalid
             show ip bgp rpki table valid|notfound|invalid

Also, as discussed in a previous e-mail, please provide a knob that 
allows the operator to configure how long the router will hold all 
validation information during a failure of the RTR session. It would be 
good if the timeout can be configured to or beyond an hour.

*****

Would welcome any comments/feedback/suggestions from the community on 
the suggestions above.

Jakob, would also appreciate if you can let us know how far you and the 
team have come with the above suggestions, if at all. Thanks.

Mark.