Re: [Sidrops] nlnet rp and rsync

I agree in the current spec, its MTI.

I also believe the intent of the deprecate-rsync draft remains: Remove
this dependency.

If this means we need to discuss the implications of channel security
and TLS on deployment, and specify the certificate chain validation
requirements on publication points and clients, thats what we need to
do.

But, until deprecate-rsync is adopted and published, the current
specification I feel is clear: you must support rsync, both sides of
the equation.

All the discussions on validation clarifications go to 'removing
objects' -What is the nature of transport security failings, if not to
permit removal of objects? And, if an object can be occluded or
removed because of a lack of channel security, what does this mean in
terms of denial of service attacks?

-George

On Tue, May 12, 2020 at 3:33 AM Randy Bush <randy@psg.com> wrote:
>
> rrdp is more fragile.  e.g. the nlnet labs client (rightly, imiho)
> checks the full certificate chain.  if any piece of the chain expires,
> is CRLed, ... the client does not go to rsync.  bam!
>
> falling back to rsync is not a 'downgrade' in that the rpki uses an
> object, not transport, security model.  well, until the last hop to the
> router, and you can see the transport security section from hell in rfc
> 8210.
>
> the goal in rrdp was to make the rpki more, not less reliable.  we found
> the nllnet labs misfeature in the wild when CA data were no longer
> fetched.  imiho not good.
>
> randy
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops