Re: [Sidrops] trying to limit RP processing variability

Martin Hoffmann <martin@opennetlabs.com> Wed, 15 April 2020 13:01 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 693A33A00C0 for <sidrops@ietfa.amsl.com>; Wed, 15 Apr 2020 06:01:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 mCGyWWYUY2Ps for <sidrops@ietfa.amsl.com>; Wed, 15 Apr 2020 06:01:45 -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 2FD7E3A0063 for <sidrops@ietf.org>; Wed, 15 Apr 2020 06:01:44 -0700 (PDT)
Received: from glaurung.nlnetlabs.nl (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id C07181B662; Wed, 15 Apr 2020 15:01:41 +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: Wed, 15 Apr 2020 15:01:41 +0200
From: Martin Hoffmann <martin@opennetlabs.com>
To: Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>
Cc: "sidrops@ietf.org" <sidrops@ietf.org>
Message-ID: <20200415150141.016d021d@glaurung.nlnetlabs.nl>
In-Reply-To: <a9448e54-320f-300c-d4f9-d01aca2b6ef4@verizon.net>
References: <a9448e54-320f-300c-d4f9-d01aca2b6ef4.ref@verizon.net> <a9448e54-320f-300c-d4f9-d01aca2b6ef4@verizon.net>
Organization: Open Netlabs
X-Mailer: Claws Mail 3.17.5 (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/Ybc0aHnxBjQuutkDxXBaG21M_ZQ>
Subject: Re: [Sidrops] trying to limit RP processing variability
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: Wed, 15 Apr 2020 13:01:46 -0000

Stephen Kent wrote:
>                                     *Overview *
> 
[...]
> 
> *Terminology*
>
> Missing: an object named in a Manifest, but not available for
> download from a PP, is termed *missing*. An RP has no obvious way to
> acquire missing objects, but operators SHOULD be warned about which
> objects are missing.

Since "missing" seems to be the opposite of the "present" in the case
overview below, I think we need to more precisely define the meaning
for both manifests and CRLs.

I would define the meaning of "manifest missing": the manifest
referenced in the CA certificate is not available for download from a
PP. That leads to the case where there is a valid manifest at the PP
but it is not the one on the CA certificate.

"CRL missing" is a little more complicated, since there is two places
where CRLs are referenced: in the manifest and in the EE certificates
of signed objects. So we also have the case where a CRL in an EE
certificate isn’t actually mentioned in the manifest.

> *Case analysis*
[...] 
> 
> Below is a proposed outline for the cases. The group needs to decide 
> what action is to be taken in each case.

To get that discussion started, here’s my proposals for these cases (in
line with what I argued earlier).

> 1.Manifest present, valid, current

If there is a present, valid, and current manifest, the CRL can safely
be ignored for all objects.

In order to avoid using partial sets of information, the entire content
of the PP is ignored if any object is missing, corrupted, or invalid.

Presumably this chould only be limited to objects of the same type,
i.e., if there is a least one missing, corrupted, or invalid ROA,
discard all ROAs.

If the aim is to avoid risking accidentally marking routes as invalid,
this should probably also extend to all information published by child
CAs.

> 2.Manifest present, valid, stale

Not sure about this one. Naively I would say "use as above but warn."
There’s also an option to distinguish based on the transport protocol
used for synchronizing the PP: ignore if rsync is used, use but warn if
RRDP is used.

> 3.Manifest present, but invalid

The entire PP is ignored.

> 4.Manifest not present

The entire PP is ignored.

This essentially ignores the CRL for any object published within the
repository and essentially moves its role over to the manifest. The CRL
would still be considered for objects published outside the repository,
such as the proposed Resource Tagged Assertions.


Kind regards,
Martin