[c-nsp] RPKI extended-community RFC8097

[Lukas Tribus]

Hello Mark, hello Jakob,


On Sun, 19 Apr 2020 at 03:03, Mark Tinka <mark.tinka at seacom.mu> wrote:
> On 18/Apr/20 16:23, Lukas Tribus wrote:
>
> >
> > More about this issue here:
> > https://www.mail-archive.com/nanog@nanog.org/msg104776.html
> >
> > Code with CSCvc84848 fixed will hopefully ship this summer, until then
> > I'm not touching RPKI on IOS(-XE) devices.
>
> Time to check in with them.

So CSCvc84848 actually shipped (in 16.9.6, 16.12.4 and 17.3.2).

The change appears to be that IBGP routes are now tagged as "NotFound"
as opposed to "Valid". This addresses one specific case, doesn't
tackle the root cause and introduces new problems.

It is still intervening in the best path selection, even if
"prefix-validate allow-invalid" is set, despite the documentation
claiming otherwise (see "Use of the Validation State in BGP Best Path
Determination" [1]). Only "prefix-validate disable" really disables
best path intervention madness (because it basically switches it off).

Here's an example of the post-CSCvc84848 behavior:

An AS has both a customer and a peer/transit, but not on the same
router; also the customer routers are RPKI Valid.

Router1 connects to the customer, accepts the RPKI valid routes from
the customers and makes them best-path (and announces them in IBGP).
Router2 connects to your peer/transit, does not consider the customers
routes from Router1, because IBGP routes are NotFound, while the same
routes from peer/transit (EBGP) are actually Valid, so the latter
become best-path.

Before CSCvc84848 the issue was with prefixes not covered by ROA's
(IBGP is always Valid, which trump's EBGP NotFound routes, ignoring
best-path selection).
Now with CSCvc84848 applied, a similar issue exists, just with RPKI
Valid routes instead (IBGP is always NotFound, which is trumped by
EBGP Valid routes, ignoring best-path selection).

I'm assuming this will surprise folks when they bring their networks
to post-CSCvc84848 code and suddenly they don't announce their
customers' valid prefixes to transits anymore. It would be helpful if
the release notes would actually mention CSCvc84848.


The only way to avoid messing with the best-path is to disable
prefix-validation completely. RPKI Invalids can still be discarded in
route-maps, although this disables all the outputs from the BGP table
(like whether a route is valid or notfound, which we may still want to
know).

router bgp ...
 bgp rpki server tcp [...]
 address-family ipv4
  bgp bestpath prefix-validate disable
[...]
route-map RM_EBGP_IN deny 10
 match rpki invalid
route-map RM_EBGP_IN permit 20
 [...]


Vpnv[46] support and RTR via SSH is still not there.


cheers,
lukas

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