[NLNOG] deploying RPKI based Origin Validation

[Weber, Markus]

Hi Job,

nice to see some more noise around OV.

You (and a few others) already know it, the wider community probably
not) ... so here we go (again).


> Hoe/waar zijn jullie met implementaties van RPKI Origin Validation?

AS286 is "prepared", but not yet rejecting anything. 

Once the customer cone is clean (or customers had enough time to get
their or their customer's or their customer customer's invalids
corrected), reject will be enabled (and not disabled again). 
Round about a dozen of invalids of downstreams remain ... 

For peers - stopped at 95% of geographical coverage enabled with
reject ... then some got too scared of reachability issues for own
space and single homed customers and what to do when someone complains;
to some extend a "is there a process" issue with "who will take the
work load" discussion paired with "as long as the risk to get blamed
for breaking connectivity is significant higher than the coolness or
honour factor - better be careful".
So the more the market makes a hype about it, the more likely a quick
deployment -with reject- will be.

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

I haven't done yet any analysis what's in there - eyeballs, customers,
know and famous pages or whatever (and unlikely will do it soon).

Anyone willing to share their experience with invalid == reject and
broken reachability?


I already proposed to Job to bring into being -like the World IPv6 day-
a "No Invalid" day (or hours) - as long as sufficient larger networks 
participate it might wake up people to get their ROAs fixed (some 
of them are not even aware ...).

> Hebben mensen hulp nodig?

What I'm still struggling a bit with is: RV (OV) vs RTBH, selective BH
and AS286's rtdsCoS. 

Guess it's very unlikely networks will publish /32 (or little larger)
or /128 (or little larger) ROA.

Falling back to IRR might be ok to some extend for RTBH (it just breaks
connectivity), but with sBH and rtsdCoS it allows to some extend 
traffic hijacking.

Another idea is taking valid ROAs and building upto /32|/128 filters
out of them and only allow RTBH, sBH, rtsdCoS for space ROAs are published.
At least it might encourage more networks to publish ROAs. 
But that still needs some fine tuning as e.g. 10.0.0.0/8-16,AS1 and
10.0.10.0/24,AS2 - is AS1 allowed to BH 10.0.10.0/32 or only AS2?
And not everyone might be able to create ROAs for all address space
they have "easily".


How are the networks already rejecting invalids and offer BH/sBH or alike
handle it?
How would you expect your peer/upstream handle your BH announcements if
if doesn't validate (as there's no /32 valid ROA for it)?


Cheers,
Markus

-- 
FvD, Markus Weber, AS286
KPN EuroRings Germany B.V. Rüsselsheimerstr. 22, DE-60326 Frankfurt
Amtsgericht Frankfurt HR99781, GF Jesus Martinez & Hugo van den Akker