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 22: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 DF38EC151090; Wed, 14 Feb 2024 14:25:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=vigilsec.com
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 kzrWu_HcA6gT; Wed, 14 Feb 2024 14:25:17 -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 D5167C151084; Wed, 14 Feb 2024 14:25:17 -0800 (PST)
Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id 3C6F512C862; Wed, 14 Feb 2024 17:25:17 -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 0A9F812CABB; Wed, 14 Feb 2024 17:25:17 -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: <m2r0helm7e.wl-randy@psg.com>
Date: Wed, 14 Feb 2024 17:25:06 -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: 7bit
Message-Id: <5B197823-A52A-4AE8-993F-162978ACA84F@vigilsec.com>
References: <170784829052.7939.16825522646369028165@ietfa.amsl.com> <E75F2235-A91D-40D3-A1E5-AA6EB30FCA4F@vigilsec.com> <m2sf1ulpc1.wl-randy@psg.com> <D3E92E84-D5A0-451E-83E4-305F929CEA14@vigilsec.com> <m2r0helm7e.wl-randy@psg.com>
To: Randy Bush <randy@psg.com>
X-Mailer: Apple Mail (2.3731.700.6)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vigilsec.com; h=content-type:mime-version:subject:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=pair-202402141609; bh=NYgLkAeGWI9/DsrqbECsBiSiTKJCJlTmUS7a6odC+A0=; b=c/6bf79NkhMwgsfk/l20BG1y7ErV6Mudt925YqWUnoiiZLKKeNeiogD6nTJx3LmA2RQEuQwV/niWD0ye4Austjv9Lz+H4L/TeZ0mJudcbQqwdVqVCJ52+7GmdqH+sIp/oP/Q72k9AZqu9pZmRwI37DAWermGC3zSmGpAluKdPqaClM0iSO/9xr9c/UAAtju1wwiNHZXe2GYDeN1hEo5GTLG2xB3QVg92ex3ZHfxc6Kxdm9ILXxRev97szTmBJU5Ve8BjCot/JB9waV9/5wpVFCwWKu8JtW09FyptaP+F1X6oPIK+L6hy67OhfZtP0v8z2B7+mYhSBjqBtP58XlkQsg==
X-Scanned-By: mailmunge 3.11 on 66.39.134.11
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/2zoBOUlY-njAFOAHaBNLLMJanVY>
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 22:25:22 -0000

Randy:

>>>>  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.
> 
> sorry.  sure.
> 
>> 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.
> 
>   When reading data from an unsigned geofeed file, one MUST ignore data
>   outside the referring inetnum: object's address range.  This is to
>   avoid importing data about ranges not under the control of the
>   operator.  Note that signed files MUST only contain prefixes within
>   the referring inetnum:'s range as mandated in Section 5.

Fine with me.

Russ