Re: Analysing traffic in context of rejecting RPKI invalids using pmacct

[Jay Borkenhagen <jayb () att com>]

On 12-March-2019, Steve Meuse writes:
> > ps. Dear Kentik & Deepfield, please copy+paste this feature! We'll
> > happily share development notes with you, you can even look at pmacct's
> > source code for inspiration. :-)
>
> Thanks Job, I just wanted to reach back out to you and the NANOG community
> that we've implemented this feature. Currently Kentik can match flow data
> with the following validation state:
>
> - VALID = Prefix fits in ROA, and ROA ASN and Prefix Origin Match
> - UNKNOWN = we haven't found any matching ROA
> - INVALID - ASN mismatch = BGP prefix fits in the ROA prefix's length BUT
> the ROA ASN differs from the Prefix Origin ASN
> - INVALID - Prefix length out of bounds = the BGP prefix doesn't have an
> ROA with large enough Max-Length to refer to
> - INVALID - ASN 0 specified = there is a matching ROA w/ the right
> max-length but the ASN associated w/ it is 0 (explicit invalid)

Hi Steve,

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

Citing from Job's description:

> Pmacct implemented Origin Validation in a cute way: it separates out
> RPKI invalid BGP announcements into two categories:
>
>     a) "invalid with no overlapping or alternative route"
>         (aka will be blackholed if 'invalid == reject')
>
>     b) "invalid but an overlapping unknown/valid announcement also
>     exists"
>         (end-to-end connectivity can still work).

Networks contemplating Origin Validation need to be able to predict
how their traffic with the rest of the Internet would change after
deploying a drop-invalid-routes policy.

When we (as7018) were preparing to begin dropping invalid routes
received from peers earlier this year, that is exactly the kind of
analysis we did.  In our case we rolled our own with a two-pass
process: we first found all the traffic to/from invalid routes by a
bgp community we gave them, then outside of our flow analysis tool we
further filtered the traffic for invalid routes which were covered by
less-specific not-invalid routes.  What remained was the traffic we
would lose once invalid routes were dropped.  Had the pmacct
capability existed at that time, we would have used it.


Regarding the ability to further partition invalid traffic into the
three sub-categories you mentioned: that would not have been of
interest to us at the time we did our analysis, and it's not clear to
me how it would be useful to a network as it contemplates adopting a
drop-invalids policy.  In this context, the reason a route is invalid
is not important; what is important is whether it is covered by a
non-invalid route or not.

Thanks.

                                                Jay B.