[NLNOG] deploying RPKI based Origin Validation

[Job Snijders]

On Thu, Jul 12, 2018 at 09:09:44PM +0000, Weber, Markus wrote:
> > 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 ... 

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

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

> 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 hosted peeringdb.com for a while inside my own ASN which does RPKI
Origin Validation - this resulted in about 1 complaint per year. I've
CCed Sebastiaan Koetsier, he'll be able to comment more on what he has
seen in the last 6 months.

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

I think it'll be quite challenging to get everyone timing wise lined,
but we can keep this idea in the back of our heads should we fail to
make progress through other means.

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

Yes, agreed. We should not ask this from customers.

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

I was thinking that for blackhole routes you pretend the MaxLength
attribute of the ROA is 32 (or 128). This way you can still do _origin_
validation for blackhole routes, but the prefix-length check will fail.
This definitely needs a bit more thinking, but we don't need to solve it
immediately. If you want to move forward fast you can just let
blackholes function as they function today (based on IRR).

Kind regards,

Job