Re: [Sidrops] feedback on draft-michaelson-rpki-rta

Based our experience of evolving and operating RPSITR2, I don’t really think multiple signatures on RTA is good idea as per current RPKI repository architecture. It will bring about complexity to RP’s validation algorithm.

Through a separate system that RPs achieve RTAs could be an option.

Di

> 2021年2月3日 00:56，Martin Hoffmann <martin@nlnetlabs.nl> 写道：
> 
> Job Snijders wrote:
>> 
>> I've consulted with various subject matter experts, and at George's
>> request I again reconsidered. Unfortunately I could not arrive at a
>> different conclusion about the current RTA proposal, it is too
>> complicated for me to support.
> 
> There’s a detail I would like to point out: You can only use the
> existing software more or less unchanged if you distribute RTAs through
> the regular RPKI repository system. I think doing so is a bad idea
> for two reasons.
> 
> For one, an RTA is an exchange between a very small number of
> participants -- typically just two --, but distribution via the RPKI
> repository system results in every single relying party having to
> downloading the object. That strikes me as rather wasteful. At the very
> least relying parties need to download the object and calculate a hash
> over them to determine whether the manifest is valid. Every one needs
> to do that. Yet only really one or two parties actually care.
> 
> Second, distribution through the RPKI repository is actually quite
> cumbersome as it involves a kind of break of gauge: You exchange
> documents in whatever way you choose (likely some kind of HTTP API) but
> then have to stop, fire up an RPKI relying party tool and wait until it
> sees the promised object. Because there uncertainties in timing of RPKI
> publication, you need to be prepared to wait for quite a bit.
> 
> If, conversely, the RTA can be distributed by any other means, i.e., it
> is just a file, it can be transferred as part of your document
> exchange. Bundle it with your document for automated processing or
> upload it manually via a browser. No waiting involved: both parties
> know that the RTA has been transmitted.
> 
> But if you allow that, you can’t use RFC 6488 signed objects anymore --
> or, well, not properly since at the very least you don’t have the a
> signedObject SIA rsync URI anymore. (And yes, the current draft glances
> over this fact.)
> 
> So, if you have to change your code anyway, why not allow it to deal
> with a legitimate, existing use case?
> 
> In addition to allow multiple signatures, the draft also allows the
> signer to include all necessary certificates and CRLs so that for
> validation you wouldn’t even need to access the RPKI repository system
> at all. Needless to say, doing that requires quite a bit of different
> code but, I do believe that this is worth it, as it seriously
> streamlines any process that involves validating RTAs as it can now be
> done in a library pretty much without keeping state.  
> 
>  - Martin
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops