[c-nsp] RPKI extended-community RFC8097

[Ben Maddison]

Hi Lukas,

On 11/28, Lukas Tribus wrote:
> 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).
> 
Thanks for the heads up - I hadn't noticed this.

And of course, none of the fine folk at Cisco that I spent hours
documenting this broken implementation to has bothered to follow up.
(To be clear, that is not directed at Jakob - he put me in touch promptly with
the right people to try and get this resolved)

> 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.
> 
That's hilarious.
Perhaps bonus calculation is now based on lowest
lines-of-code/closed-bugs ratio? Maybe it always was?

So TL;DR: the "fixed" behavior is exactly the same, but now it breaks different
routes. <slow-clapping/>

> 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.
> 
I would imagine that everyone who is soldiering on with ROV on XE at
this stage has been sufficiently burned at least once to proceed with a
great deal of caution, regardless of what is or isn't in the RNs.

Cisco's RNs have become, at best, a general hint as to what might have
changed, rather than an authoritative source of information.
> 
> 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
>  [...]
> 
Does the route-map 'match' still work here? Which release?
I remember trying this workaround before our initial rollout of ROV and
nothing matched that statement when 'prefix-validate disable' was
configured. I forget the exact release, but that would have been
16.9.3-ish.

At this stage, I don't really care if they fix this anymore.
We're now firmly pointed at the "no more XE in the field" target, and
this is only one (admittedly large) reason why.
> 
> Vpnv[46] support and RTR via SSH is still not there.
> 
Hahaha, don't hold your breath. Source interface selection isn't even
available.

Resignedly,

Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20201128/54a14c2f/attachment.sig>