Re: [OPSAWG] Paul Wouters' Discuss on draft-ietf-opsawg-9092-update-10: (with DISCUSS and COMMENT)
Russ Housley <housley@vigilsec.com> Wed, 14 February 2024 21:25 UTC
Return-Path: <housley@vigilsec.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A91BC151090; Wed, 14 Feb 2024 13:25:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apGe4eNyFPXY; Wed, 14 Feb 2024 13:25:01 -0800 (PST)
Received: from mail3.g24.pair.com (mail3.g24.pair.com [66.39.134.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31FABC151520; Wed, 14 Feb 2024 13:25:01 -0800 (PST)
Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id 8C77E17E95F; Wed, 14 Feb 2024 16:25:00 -0500 (EST)
Received: from smtpclient.apple (unknown [96.241.2.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail3.g24.pair.com (Postfix) with ESMTPSA id 68BEC17F291; Wed, 14 Feb 2024 16:25:00 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <m2sf1ulpc1.wl-randy@psg.com>
Date: Wed, 14 Feb 2024 16:24:50 -0500
Cc: Paul Wouters <paul.wouters@aiven.io>, IESG <iesg@ietf.org>, draft-ietf-opsawg-9092-update@ietf.org, opsawg-chairs@ietf.org, Ops Area WG <opsawg@ietf.org>, mcr+ietf@sandelman.ca
Content-Transfer-Encoding: quoted-printable
Message-Id: <D3E92E84-D5A0-451E-83E4-305F929CEA14@vigilsec.com>
References: <170784829052.7939.16825522646369028165@ietfa.amsl.com> <E75F2235-A91D-40D3-A1E5-AA6EB30FCA4F@vigilsec.com> <m2sf1ulpc1.wl-randy@psg.com>
To: Randy Bush <randy@psg.com>
X-Mailer: Apple Mail (2.3731.700.6)
X-Scanned-By: mailmunge 3.11 on 66.39.134.11
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/Mx8pn9qEk-ivc_fBrJ90dQ26BEY>
Subject: Re: [OPSAWG] Paul Wouters' Discuss on draft-ietf-opsawg-9092-update-10: (with DISCUSS and COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Feb 2024 21:25:05 -0000
Randy: >> >> Suggested edits: >> >> The address range of the signing certificate MUST cover all prefixes >> in the signed geofeed file. If not, the authenticator is invalid. >> >> The signing certificate MUST NOT include the Autonomous System >> Identifier Delegation certificate extension [RFC3779]. If it is >> present, the authenticator is invalid. >> >> As with many other RPKI signed objects, the IP Address Delegation >> certificate extension MUST NOT use the "inherit" capability defined >> in Section 2.2.3.5 of [RFC3779]. If "inherit" is used, the >> authenticator is invalid. > > sure > >> The consumer of geofeed data SHOULD fetch and process the data >> themselves. Importing datasets produced and/or processed by a third- >> party places significant trust in the third-party. > > this is in sec cons already. you want it moved up or duplicated? i > kinda like it where it is, but am flexible. I was not suggesting a new placement, just the edit to the last line. >> I think is is probably better to drop the following from Section 6: >> >> When using data from a geofeed file, one MUST ignore data outside the >> referring inetnum: object's inetnum: attribute address range. > > this is meant for an unsigned file. e.g. multiple diverse inetnum:s > refer to the single geofeed file https://rg.net/geofeed. it allows an > operator not signing to maintain one file. > > all geofeeds are not signed for a number of reasons > > o rpki data may not exist for some, cf. decades of difficulty getting > rpki allowed by all RIRs. plus, you do not really want to tie the > two operational processes together. > > o geofeed data are not critical. they just hints to geoloc obsessed > content providers I propose adding that to the bottom of the paragraph that starts: If and only if the geofeed file is not signed per Section 5, ... By doing that, it does not conflict with the requirement in Section 5 that the address range of the signing certificate cover all prefixes in the signed geofeed file. Russ
- Re: [OPSAWG] Paul Wouters' Discuss on draft-ietf-… Randy Bush
- [OPSAWG] Paul Wouters' Discuss on draft-ietf-opsa… Paul Wouters via Datatracker
- Re: [OPSAWG] Paul Wouters' Discuss on draft-ietf-… Job Snijders
- Re: [OPSAWG] Paul Wouters' Discuss on draft-ietf-… Randy Bush
- Re: [OPSAWG] Paul Wouters' Discuss on draft-ietf-… Russ Housley
- Re: [OPSAWG] Paul Wouters' Discuss on draft-ietf-… Randy Bush
- Re: [OPSAWG] Paul Wouters' Discuss on draft-ietf-… Russ Housley
- Re: [OPSAWG] Paul Wouters' Discuss on draft-ietf-… Russ Housley