Re: Analysing traffic in context of rejecting RPKI invalids

["Jakob Heitz \(jheitz\) via NANOG" <nanog () nanog org>]

If at least one ROA matches a route, then the route is valid.
This is to cover the case when more than one AS is authorized to
originate a particular prefix.

https://tools.ietf.org/html/rfc6811
Page 5:
   o  NotFound: No VRP Covers the Route Prefix.

   o  Valid: At least one VRP Matches the Route Prefix.

   o  Invalid: At least one VRP Covers the Route Prefix, but no VRP
      Matches it.

BTW, this rule allows you to issue a ROA authorizing AS0 to originate
your complete address space.

Why would you do that? Suppose you own an address space, but you only
want to announce a portion of it to the internet. If you issue a ROA
for the unannounced portion authorizing your own ASN, then an attacker
can announce that portion and prepend your ASN. The attacker can thus
hijack your unannounced space and appear valid by RPKI!

To prevent that, you issue a ROA for your complete address space
authorizing AS0 and your BGP announced space authorizing your own ASN.

An AS path containing AS0 is malformed, being treated as withdraw.
https://tools.ietf.org/html/rfc7607

Regards,
Jakob.

-----Original Message-----
Date: Wed, 13 Mar 2019 11:17:22 -0400
From: Steve Meuse <smeuse () mara org>
> Thanks for the update, but based on that description I'm not certain
> that you implemented the same thing that pmacct built, which IMO is
> what is needed by those considering deploying a drop-invalids policy.
> (Perhaps you omitted mentioning that ability in your description but
> included it in your implementation.)
Thanks Jay, you are correct. As we were talking through the logic we
realized we missed that bit. Internally, we're working though the logic to
understand if there is a covering route, is that route valid, and if not,
will we recurse and look for another covering route that is valid?

Either way, we'll be updating our software with that functionality shortly.

-Steve