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