IETF Logo Mail Archive

Re: [Sidrops] [WG ADOPTION] draft-yan-sidrops-roa-considerations - 04/16/2021

Randy Bush <randy@psg.com> Tue, 30 March 2021 19:52 UTC

Return-Path: <randy@psg.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 334373A201A for <sidrops@ietfa.amsl.com>; Tue, 30 Mar 2021 12:52:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 gGjzq-OsWOlP for <sidrops@ietfa.amsl.com>; Tue, 30 Mar 2021 12:52:49 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 2884B3A2010 for <sidrops@ietf.org>; Tue, 30 Mar 2021 12:52:20 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from <randy@psg.com>) id 1lRKPQ-0000J7-Eo; Tue, 30 Mar 2021 19:52:16 +0000
Date: Tue, 30 Mar 2021 12:52:16 -0700
Message-ID: <m25z18o1vz.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Tim Bruijnzeels <tim@nlnetlabs.nl>
Cc: SIDR Operations WG <sidrops@ietf.org>
In-Reply-To: <8BA83ECF-3D1A-4057-9E24-46CDA779604B@nlnetlabs.nl>
References: <87lfa94xyj.wl-morrowc@ops-netman.net> <67F48899-3B77-4722-B467-F73D50DF1006@nlnetlabs.nl> <YGL2twQ2eEsMQHPq@snel> <8BA83ECF-3D1A-4057-9E24-46CDA779604B@nlnetlabs.nl>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/DzCkDbnCmi1Kq3NtKTR4J2GGLM0>
Subject: Re: [Sidrops] [WG ADOPTION] draft-yan-sidrops-roa-considerations - 04/16/2021
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: Tue, 30 Mar 2021 19:53:00 -0000

> I have been thinking of proposing extensions to the publication
> protocol (RFC 8181) to make Publication Servers somewhat more
> responsible.  For example they could enforce quota both in terms of
> number of files, and size. They could also verify objects, e.g. only
> allow known types, and only allow objects which at least parse.

why?  we need more complexity to give misconfigurations, bugs, weaseling
on specifications, etc. more places to hide?

> The problem is that a delegated CA may not find out that a parent has
> shrunk their resources until whenever it happens to send them a
> "Resource Class List Request" as defined in RFC 6492

my memory is that the child is expected to Resource Class Query before
doing anything with resources it assumes it still has.

randy

---
randy@psg.com
`gpg --locate-external-keys --auto-key-locate wkd randy@psg.com`
signatures are back, thanks to dmarc header butchery

v2.23.0 | Report a Bug | By Email