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