[c-nsp] RPKI extended-community RFC8097

[Jakob Heitz (jheitz)]

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.
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?

Regards,
Jakob.

-----Original Message-----
From: Lukas Tribus <lukas at ltri.eu> 
Sent: Friday, November 27, 2020 3:47 PM
To: Mark Tinka <mark.tinka at seacom.mu>; Jakob Heitz (jheitz) <jheitz at cisco.com>
Cc: Cisco-nsp <cisco-nsp at puck.nether.net>
Subject: Re: [c-nsp] RPKI extended-community RFC8097

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