Re: [Sidrops] Multiple publication points in certificate

[Tim Bruijnzeels <[e-mail]>]

Hi Job, all,

> On 28 Jul 2022, at 11:50, Job Snijders <job=[e-mail]> wrote:
> 
> Dear Koen, Geoff, others,
> 
> On Thu, Jul 28, 2022 at 12:20:09PM +0000, Geoff Huston wrote:
>> RFC6487: SIA (sec 4.8.8.1)
>> 
>> Other accessDescription elements with
>> an accessMethod of id-ad-caRepository MAY be present. In such cases,
>> the accessLocation values describe alternate supported URI access
>> mechanisms for the same directory. The ordering of URIs in this
>> accessDescription sequence reflect the CA's relative preferences for
>> access methods to be used by RPs, with the first element of the
>> sequence being the most preferred by the CA.
>> 
>>> So far it seems that:
>>> - Routinator only visits the first
>>> - OctoRPKI only visits the second
>>> - rpki-client outputs "RFC 6487 section 4.8: SIA: rpkiNotify already specified" and visits neither
>>> - FORT outputs "Extension 'SIA' has multiple 'rpkiNotify' HTTPS URIs." and visits neither
> 
> Thanks Koen, I appreciate you testing this. It seems there is room for
> improvement in rpki-client, I'll take a stab at visiting *at least one*
> RRDP Access Description (if multiple are specified).

I think that fallback to a secondary RRDP 'rpkiNotify' URI should be feasible.
Fallback to secondary rsync URIs for 'id-ad-caRepository'/'id-ad-rpkiManifest'
would be more problematic for RPs - if they rely on these URI to build their
idea of the RPKI tree(*). Fallback to a secondary 'rpkiNotify' would incur a
cost (download snapshot) but presumably the rsync URIs associated with the
contained <publish> objects retrieved this way would match those of the
primary.

(*): alternatively one could use a URI agnostic approach - e.g. based on key
identifiers and hashes as was done by the RIPE NCC RPKI Validator 2 series.
See: RFC 8488.

>> Seems that the relevant standard specifies that a relying party should
>> work with the entire list of URIs listed in the certificate’s SIA
>> field and work through them until success or until all locally
>> supported URI access methods have been tried. The CA provides the
>> CA-preferred order to test the URI list, but the Relying Party can
>> apply its own preference to the list of course.
> 
> Right. To some degree all validators (I know of) already do this: first
> rpkiNotify is followed, and if there is a HTTP error code or TLS error,
> the RPs fall back to RSYNC.
> 
> At the start of this thread Koen mentioned investigating hosting ROAs at
> multiple places to improve robustness / availability; I'd argue that
> with the "RRDP first, RSYNC second" pattern that has established in the
> last 2 years we achieved a well working flavor of duplicity.
> 
> I've noticed that some repository operators at times end up deploying
> TLS configurations which either lack intermediate TLS certs, or perhaps
> a lack of common HTTPS trust anchors between RP and Repo; in such
> cases I think there is merit to attempt to use a vastly different
> protocol (rsync) which has no dependency on WebPKI.

I think that listing dozens of backup URIs would not be helpful, and it
might even give (malicious) CAs more tools to attack RPs by giving them
lots of bad repositories to check. That said, having the option of specifying
say 2 'rpkiNotify' URIs would help to solve issues in my opinion.

If I were to use this, I would most likely have the primary 'rpkiNotify'
point to a CDN backed infrastructure. While the secondary could be pointing
to either my own infrastructure, or a secondary CDN. It would be good
if both systems relied on different web TAs and different https server
implementations.


Tim

> At the bottom of https://console.rpki-client.org/ there is a terminal
> output under "comm -3 vrps-rrdp-rsync.csv vrps-rsync-only.csv" which
> shows the difference in VRPset when synchronizing over RRDP+RSYNC vs
> "RSYNC only"; it seems that most of the time there is minute differences
> (which probably can be explained by transient/timing differences, the
> RPKI is a distributed database of course). By and large the RRDP and
> RSYNC worlds seem to be very much in sync with each other, to me that
> seems a good sign.
> 
> Kind regards,
> 
> Job
> 
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops