[c-nsp] RPKI validation weirdness

[Robert Raszuk]

Yes your story how you found it is exactly as mine - with just one
exception that I was looking at my upstream ISPs across two ASBRs and
debugging what is going on :) But the core of the issue was precisely
identical !

Well I am still running it .. just enabled ext comms.

Frankly this was ugly as quite unexpected - but relatively easy to see what
is going on. In this space I am much more worried about RPKI db accuracy
then any of the implementation issues. I found number of cases so far where
what is in RPKI is just plain wrong - read INVALID :). And that is supposed
to be the source of truth ...

Now I am considering actually automation of detection of RPKI bad info and
some sort of publishing it.

See when you sign a block then sell this block without removing your RPKI
signature, then the block gets cutted into chunks and sold further - and no
one in this process of transaction chain cares about RPKI - this entire
story of using this for validation becomes pretty weak. And this is no
longer NOT-FOUND. You get false INVALIDs which some may apply to suppress
or drop.

Best,
R.


On Fri, May 8, 2020 at 11:32 AM Mark Tinka <mark.tinka at seacom.mu> wrote:

>
>
> On 8/May/20 11:23, Robert Raszuk wrote:
>
> >
> > But in what you pasted in I do not see statement that paths received
> > over IBGP with no state information should be considered VALID. I
> > think they just thought North - South then if you validate on ingress
> > rest of the domain should assume the IBGP path received is VALID.
>
> Yes, agreed on that. The e-mail I got from someone back in 2016 on that
> issue was "this is designed as per normal".
>
> The link I sent was specific to them documenting a mis-interpretation of
> the RFC on policy application, despite being called out on it years ago.
>
>
> > With that they apparently  never thought about iBGP also going
> > East-West between ASBRs or via RRs where you are using add-paths or
> > best external :)
>
> We just disabled RPKI on our ASR1000 edge routers, especially since they
> only handle about 2 customers across the entire backbone. Much of that
> heavy-lifting is done by our MX480's, which implement ROV correctly.
>
> One of the issues we hit that led us to this decision was when you learn
> a non-ROA'd customer route via eBGP in one location, but that specific
> edge router decides to send the traffic back to them via iBGP to another
> site where they may have a second connection to you or via a peering
> partner, because on the local edge router, Cisco automatically applies
> NotFound for the route, but Valid for the iBGP-learned route. Since
> Cisco will automatically apply policy by default the moment you enable
> RPKI, the local eBGP route will never be chosen as the best path, even
> though it is.
>
> Utter madness!
>
> Mark.
>
>