[Sidrops] RRDP and rsync URIs

[Tim Bruijnzeels <[e-mail]>]

Hi,

As discussed yesterday I would send a commentary to the list regarding rsync URIs in RRDP.

The <publish> and <withdraw> elements in RRDP snapshot and delta files include a 'uri' attribute which corresponds to the uri where the object would have been found if rsync where used. But, these uris can be anything, they do not need to correspond to the https uri of where the snapshot or delta file was retrieved.

I remember now that some hallway discussions occurred at least (can't find stuff written right now) where this was considered to be a feature. E.g. for RIPE NCC the RRDP files are hosted under 'rrdp.ripe.net' while rsync uses a different hostname altogether: 'rpki.ripe.net'.

However, this can lead to issues if RPs naively map the rsync uris to files on disk and add / update / remove these files. In particular it's possible for different RRDP servers to have the same (each other's) rsync uris. There is some text in section 3.4.2 of RFC 8181 (RRDP) that alludes to this:

   o  When a Relying Party encounters a "withdraw" element, or a
      "publish" element where an object is replaced, in a delta that it
      retrieves from a Repository Server, it MUST verify that the object
      to be withdrawn or replaced was retrieved from this same
      Repository Server before applying the appropriate action.  Failing
      to do so will leave the Relying Party vulnerable to malicious
      Repository Servers instructing it to delete or change arbitrary
      objects.

There are several ways to deal with this.

Routinator uses a strategy where each RRDP server (identified by its notification.xml) gets a separate namespace on disk, and rsync uris are mapped to files under these namespaces. When objects need to be localized for a CA certificate which uses RRDP then both the notification.xml uri and expected rsync uris are known. So, objects can be found without issue. I believe that this is the simplest way to approach the potential rsync uri collisions between RRDP servers.

Other approaches include being more uri agnostic, i.e. find manifest candidates by matching Key Identifiers, purge invalid / superceded manifests, and find objects on manifests by hash. Dropping objects could then be done when the reference count from ALL known manifests drops to 0. That way I cannot include your object on my mft, then remove it, and mislead you into dropping the object.

I am sure that there are more ways. I do not think that we must define the approach used to a single solution. But it is worth exploring boundaries.



Kind regards,
Tim