[Sidrops] RRDP and rsync URIs

Tim Bruijnzeels <tim@nlnetlabs.nl> Thu, 25 June 2020 12:47 UTC

Return-Path: <tim@nlnetlabs.nl>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB113A0A13 for <sidrops@ietfa.amsl.com>; Thu, 25 Jun 2020 05:47:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpFDzKw55MVO for <sidrops@ietfa.amsl.com>; Thu, 25 Jun 2020 05:47:47 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC98D3A0A3B for <sidrops@ietf.org>; Thu, 25 Jun 2020 05:47:47 -0700 (PDT)
Received: from [IPv6:2001:981:4b52:1:216c:1f5c:36e0:10c6] (unknown [IPv6:2001:981:4b52:1:216c:1f5c:36e0:10c6]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 8609E2E4F3; Thu, 25 Jun 2020 14:47:45 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl
Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1593089265; bh=ZUIMjZGYtVpmR15anc7FpWl6W8ChIMXvLYyZJccmEnU=; h=From:Date:Subject:To; b=qGGLqPn9QQcl+82V4LYZGocQ8/MUaju+mJhqtjNDaUfIlkRD6GdoRpqgTvtx71/vb Dx/DBwr9pOva5++W0z3XN+gPiyCb1je/u8lVX6hmGlFCEwz6YLqBMKvwPgapQYzh5a DhbCzt6fl6mHl5ZC7whvDcjNgxmjiBU2C2PzXDqA=
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 25 Jun 2020 14:47:45 +0200
Message-Id: <E04565D3-58DF-41F1-9088-34F83AB5B320@nlnetlabs.nl>
To: SIDR Operations WG <sidrops@ietf.org>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/FrAjMFWY5a_cofpOoCEO5Yr_ZLI>
Subject: [Sidrops] RRDP and rsync URIs
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jun 2020 12:47:50 -0000

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