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.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp archive at
http://puck.nether.net/pipermail/cisco-nsp/
message-rfc822.eml (6.08 KB)
