Re: [Sidrops] 6486bis: referenced object validation

Hello!

On Fri, 4 Dec 2020 at 16:58, Tim Bruijnzeels <tim@nlnetlabs.nl> wrote:
> On 6486 in particular there was a strong desire communicated by operators
> that RPs behave the *same* way.

If I recall correctly, I expressed this desire, yes.

This was based on my gross underestimation of the complexities of the
RPKI repository system and also a lack of understanding of how routers
will handle multiple RTR servers at the time.

As a network operator, I like the fact that BGP implementations across
vendors, given the same/similar parameters, select the same best path.
This means I can replace vendor X with vendor Y in location Z and keep
the rest of the network as is, without routing loops. However
different VRP outputs from RP's do not cause routing loops in networks
(when deployed correctly). Apart from routing loops in the BGP
analogy, same exact VRP output means that I don't have to think about
what happens if different RP software disagrees, which I can
appreciate. However the RPKI repository system is just too complex and
has too many variables.

In the WebPKI world, although TLS is standardized, TLS clients will
behave differently. Firefox is actively querying OCSP servers, Chrome
will never do that and will wait for Google to push CRL-sets to the
browser. Implementation choices vary widely. If the TLS RFC's would go
into such details like specifying whether Firefox or Chrome is "right"
(should a browser actively query OSCP server and what about walled
gardens [...]), that would probably make RFC ratifications take a
*very long* time (too long to keep up, while the real world moves on)
and defeat it's entire purpose. And how would this impact something
like 1/n-1 record splitting (the workaround for the BEAST
vulnerability, which all browsers implemented after Chrome made the
first step forward [1])?

While the same exact VRP output from different RP's would be *nice to
have* for us network operators, I fail to see how this is actually
necessary. It certainly is more convenient to not have to think about
those mismatches, that's the reason why I advocated for this, but that
is not a luxury we can afford.

This is why I now believe expecting the same VRP output from different
RP's is an unrealistic goal and actually harmful. A software
implementer must feel free to implement fixes for important
operational issues as they see fit.

Best regards,

lukas

[1] https://www.imperialviolet.org/2012/01/15/beastfollowup.html

Which is why we were hesitant to implement the changes suggested by
you in the GH issue. In fact we even agree with the approach in the
issue. But it's different from where the -bis text is headed until
now. We felt that the desire for universal behaviour (-bis) outweighed
the rush to make a quick change here. You are welcome to disagree with
that assessment, but understand that there was well intended reasoning
behind it.
>
> > You mentioned some kind of testbed, indeed it would be wonderful if we
> > can easily reproduce states of the RPKI and allow implementers to
> > provide annotations on why software (versions) behaves in a certain
> > way. The December 1st, 2020 case is definitely one I'd add to the
> > testbed archive.
>
> It would be. I think this is an effort in itself. Do you have a proposal in mind?
>
> >
> >>> The real goal is to keep the network running, where in this context
> >>> our role is to create software for network operators for them to
> >>> securely validate the wishes of the Internet number resource
> >>> holders.
> >>
> >> Agree to that!
> >>
> >> Let's keep the good spirit of collaboration and learning together.
> >
> > For sure!
>
>
> For sure!
>
> Tim
>
> >
> > Kind regards,
> >
> > Job
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops