[Sidrops] 6486bis: Failed Fetches

Martin Hoffmann <martin@opennetlabs.com> Mon, 17 August 2020 14:31 UTC

Return-Path: <martin@opennetlabs.com>
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 EEB863A15A9 for <sidrops@ietfa.amsl.com>; Mon, 17 Aug 2020 07:31:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 LpKtdNIVd4eD for <sidrops@ietfa.amsl.com>; Mon, 17 Aug 2020 07:31:38 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.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 08C753A15A1 for <sidrops@ietf.org>; Mon, 17 Aug 2020 07:31:37 -0700 (PDT)
Received: from glaurung.nlnetlabs.nl (unknown [IPv6:2a04:b904::743]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 375B02D466 for <sidrops@ietf.org>; Mon, 17 Aug 2020 16:31:35 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com
Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com
Date: Mon, 17 Aug 2020 16:31:34 +0200
From: Martin Hoffmann <martin@opennetlabs.com>
To: sidrops@ietf.org
Message-ID: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl>
Organization: Open Netlabs
X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/m5bI0fxmRtc162tjTP85FPvYQFI>
Subject: [Sidrops] 6486bis: Failed Fetches
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: Mon, 17 Aug 2020 14:31:48 -0000

Heisann,

I started to implement the rules laid out in section 6 "Relying
Party Processing of Manifests" of the draft and now have a few
questions and remarks. I decided to split these up into separate
messages. So, expect a few more messages ...

                             *   *   *

It is not quite clear how to deal with failed fetches. Section
6.4 dictates that invalid signed objects (but curiously not invalid
certificates or CRLs) fail a fetch. The consequence of this is that a
fetch already fails if a single ROA (or worse: a single ghost-buster
record) is expired.

Section 6.7 now states that I should keep using "cached versions of the
objects associated with this CA instance." What does that actually
mean? What are these objects associated with the instance? The objects
listed on the new manifest or the old manifest? Or does objects here
mean validated output generated earlier?

If indeed it means RPKI objects, then doesn’t the expired ROA
essentially block all updates to the other objects to the CA? That
would strike me as counter-productive in terms of robustness.

This rule also blocks skipping objects of types I don’t know or care
about. I will have to at least do signed object validation on them,
which means reading and parsing them and then do signature validation.
If that is intended, I think this should be called out explicitly in
the document.

But I’m not even sure it provides any benefit. I, say, I am validating
a resource tagged association (RTA, [0]), I don’t care about the ROAs
at all. Does the RTA become invalid because a CA somewhere in the
validation chain had an expired ROA?

Kind regards,
Martin

[0] https://datatracker.ietf.org/doc/draft-michaelson-rpki-rta/