IETF Logo Mail Archive

Re: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-07.txt

Ties de Kock <tdekock@ripe.net> Thu, 14 October 2021 15:07 UTC

Return-Path: <tdekock@ripe.net>
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 89AA03A0A6C for <sidrops@ietfa.amsl.com>; Thu, 14 Oct 2021 08:07:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net
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 mGr-g6-pnlyc for <sidrops@ietfa.amsl.com>; Thu, 14 Oct 2021 08:07:42 -0700 (PDT)
Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (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 E18433A16F5 for <sidrops@ietf.org>; Thu, 14 Oct 2021 08:07:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=Message-Id:To:Date:Subject:Mime-Version:Content-Type:From:CC ; bh=PF6qIAmluacmyldOSLwzFtPL5TE44f1xgQJM3NQgBmk=; b=OAbfSKtMy/Kl+9SQu9j3Af39 XwsC8G/WiXHi0ENiAopBrZX3Gp0wYoRvA24pHHfoXE/1gaRcft2iQMIbAUSx4yiir3V9MWu8diHHU lQsXvlk2S9xbnr61Yrmg4afQXjD9yDi+HcZRGq6RsvAudrWXLNzE4wLxWbv1jSzm2OVdwcCSOjAdg jTeGoZim4Rde18xnUiKuhhuCOFNqPDllotvZhSEQqm0TQncm6n6Ho9vOkEmtXPGSskGP65Mba9flX qezTNRVzzVQUDEAFg+lejO4Oqpn7F3RwiPfFOh/7Y0wvQq/S6faOr4rzHJUUS1H7gaZ0kri3Fv/KR 2ZlldC2pqg==;
Received: from allealle.ripe.net ([2001:67c:2e8:23::c100:170c]:57804) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <tdekock@ripe.net>) id 1mb2KT-00068J-UI for sidrops@ietf.org; Thu, 14 Oct 2021 17:07:33 +0200
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=smtpclient.apple) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <tdekock@ripe.net>) id 1mb2KT-00041L-Rd for sidrops@ietf.org; Thu, 14 Oct 2021 17:07:33 +0200
From: Ties de Kock <tdekock@ripe.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Thu, 14 Oct 2021 17:07:33 +0200
References: <163422093055.5218.7049827726010929590@ietfa.amsl.com>
To: SIDR Operations WG <sidrops@ietf.org>
In-Reply-To: <163422093055.5218.7049827726010929590@ietfa.amsl.com>
Message-Id: <C368116D-179F-4A2D-A9D9-613A422F0AE1@ripe.net>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e15f728f603411ac29cbe0509aaf842836
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/7g1PDm7eryhKM-5smBbB_XD9u4w>
Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-07.txt
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, 14 Oct 2021 15:07:49 -0000

Steve,

Thanks for adding text clarifying the handling of manifestNumber and thisUpdate.

> On 14 Oct 2021, at 16:15, internet-drafts@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the SIDR Operations WG of the IETF.
> 
>        Title           : Manifests for the Resource Public Key Infrastructure (RPKI)
>        Authors         : Rob Austein
>                          Geoff Huston
>                          Stephen Kent
>                          Matt Lepinski
> 	Filename        : draft-ietf-sidrops-6486bis-07.txt
> 	Pages           : 16
> 	Date            : 2021-10-14


While reading the diff I thought it would be good to discuss this on list:

> 4.2.1:
> 
>       This field is an integer that is incremented (by 1) each time a
>       new manifest is issued for a given publication point.  This field
>       allows an RP to detect gaps in a sequence of published manifests.

I would really like it if we could leave this open and allow arbitrary
increments. It's what is out there in the wild, and RPs can not check anything
against manifestnumber either: Not all of them are guaranteed to be visible. 
Strict incrementing counters are also a point of contention in implementations
due to database locking on the parent CA.

Existence/absense of manifests of a compliant CA is visible through the CRL. And
it does not make behaviour of a sloppy CA invisible.

I would also like to revisit 4.2.2.

>   letter extension.  The extension MUST be one of those enumerated in
>   the "RPKI Repository Naming Scheme" registry maintained by IANA
>   [IANA-NAMING].

Since the content of the registry is dynamic, I think it would be good to
clarify that encountering an unknown extension must not result in a failed fetch.
If RPs become intolerant to new filenames using an extension not in the
registry (for example .asa) would require a flag day. 

While reducing ambiguity in the results that RPs have when processing manifests
is good I don't think rejecting unknown types is worth the downside.

Kind regards,
Ties

v2.23.0 | Report a Bug | By Email