Re: [Sidrops] weak validation is unfit for production (Was: Reason for Outage report)

[Job Snijders <[e-mail]>]

On Sat, Aug 29, 2020 at 12:22:54PM +0200, Nathalie Trenaman wrote:
> Last month, we released a “strict mode” for our validator. It takes
> into account 6486bis except the use of cached data, which I did not
> see consensus on yet (correct me if I’m wrong please).

I think you are wrong on the cached data consensus, but it doesn't
matter, it is a small implementation detail. If an implementer doesn't
want to take advantage of their local file cache, they don't need to.
RPs are expected to be able to function with empty caches as well.

> Where Job sees around 400 objects missing, we do see a lot more. 
> 
> We have been monitoring the amount of missing objects and we see a
> difference of around 4500 objects. Mainly from the APNIC region.

The difference between rpki-client and ripe ncc validator
'insecure-mode=off / rsync-only' seems to be about 2,500 VRPs. However,
the ripe ncc validator logs 5 only errors: https://rpki.meerval.net/trust-anchors/monitor/2

One of the errors appears to be logged at "2020-08-29 18:08:48" and
indicates: "CRL next update was expected on or before 2020-08-29T22:46:19.000Z"
It is not clear why it errors on things still in the future. The 2,500
VRP difference might be caused by a software issue rather than a
specifications issue?

For example, I can't find a reason why a VRP for Prefix:
203.163.202.0/23 Maxlength: 24, Origin: AS10085, TA: APNIC is not
emitted by the ripe ncc validator. It is also curious to see RRDP
fetches are performed while 'rpki.validator.rsync-only=true' is set.

Are you sure the current version implemented things correctly?

> This is why I believe Tim’s suggestion for a flag day sounds
> reasonable to me. We have to inform CAs about the impact changing the
> behaviour of RPs has on them. 

A flag day to release a security update? Flag day's generally are used
for other types of events.

Regards,

Job