[NLNOG] deploying RPKI based Origin Validation

[Job Snijders]

On Thu, Jul 12, 2018 at 09:44:47PM +0000, Weber, Markus wrote:
> | From my perspective you are almost squacky clean! I see two invalids
> | 88.159.27.0/24 (invalid, but covered by valid route 88.159.0.0/16) and
> | 94.103.31.0/24 (also covered by valid 94.103.16.0/20). I'm sure there
> | are more, but if you drop these two prefixes it shouldn't result in loss
> | of connectivity because there are covering valid routes.
> 
> From that perspective - yes, close to clean. But don't surprise and
> annoy customers without warning them upfront that eventually their or
> their customer's (TE) announcement suddently stop to work ... esp.
> don't give your (my) 1st line NOC a very hard time then in the need to
> explain it to the customer when he calls in the middle of the night
> (esp. when simple IRR filtering often causes headache).

Well - if you want to be kind to your customers, just deploy "invalid ==
reject" on your peering partners first. This way your customers benefit
from a form of protection layer, while not being subjected to the same
strictness you apply to peers. I bet you most BGP hijacks &
misconfigurations come into AS 286 via the peering partners, as all
customers already are filtered based on IRR data (if I am not
mistaken?).

> |> Yes, there are some (not just a few) invalids out there, not covered
> |> by not-invalid less specifics: https://as286.net/data/ana-invalids.txt
> |> (note: not a perfect report, limited to AS286 peer routes, downstream
> |> routes excluded, potential wrong altpfx for <12 prefixes [...])
> 
> | We should compare notes on how you generate this. I looked today and
> | only 2,200 prefixes become unreachable due to misconfigured RPKI ROAs.
> | http://instituut.net/~job/rpki-report-2018.07.12.txt - I think the
> | majority of invalid more-specifics simply are attempts at
> | traffic-engineering and not critical.
> 
> Take invalids received from eBGP peers on every PE, note prefix and
> path.  Take "clean" (without invalids) table of DFZ. For every invalid
> lookup in the invalid free DFZ table if there's a valid same or a less
> specific.  If not, altpfx=NONE and expect connectivity issue.
> 
> Your 2200 are more or less the 2277 ones in my list with altpfx=NONE 
> Aggregated ~876 ;-) (#of IPs remain the same).

Ah, so we arrive at same conclusion. I misunderstood your file format.

It is of paramount importance that this number is brought down, I think
the only way to bring down the number is to deploy Origin Validation and
create the feedback loop that 'wrong roa == poor connectivity'.

Kind regards,

Job