IETF Logo Mail Archive

Re: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-profile-15.txt

Russ Housley <housley@vigilsec.com> Wed, 14 June 2023 00:24 UTC

Return-Path: <housley@vigilsec.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 8C24CC15171B for <sidrops@ietfa.amsl.com>; Tue, 13 Jun 2023 17:24:57 -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, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-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 mAabqIeKdimS for <sidrops@ietfa.amsl.com>; Tue, 13 Jun 2023 17:24:56 -0700 (PDT)
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 632CEC151717 for <sidrops@ietf.org>; Tue, 13 Jun 2023 17:24:56 -0700 (PDT)
Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id A2414EB69C; Tue, 13 Jun 2023 20:24:55 -0400 (EDT)
Received: from smtpclient.apple (pfs.iad.rg.net [198.180.150.6]) (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 87CE7EB45C; Tue, 13 Jun 2023 20:24:55 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <D562E769-D436-46FD-BD20-520FA495B4F2@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_40A1565C-9720-4F32-B1A0-65C043407B54"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
Date: Tue, 13 Jun 2023 20:24:45 -0400
In-Reply-To: <04D76EAA-AD2E-4A76-8709-0D063E4310EA@ripe.net>
Cc: SIDR Operations WG <sidrops@ietf.org>
To: Ties de Kock <tdekock@ripe.net>
References: <168621843689.33017.6897451444105786551@ietfa.amsl.com> <ZIGogKIH4Srb8Nxt@snel> <20230608181440.33d6926f@glaurung.nlnetlabs.nl> <0C543A94-F70E-4A40-8350-C98FAAB5A9B5@vigilsec.com> <D100381E-6498-4EAD-B056-18F89836C097@ripe.net> <96D52BC8-C3BA-43C8-90E1-DD2621C2292F@vigilsec.com> <20230613094413.364aaa8c@smaug.local.partim.org> <26E1759F-08FA-430D-8F89-BDC6C3DC4B9D@vigilsec.com> <20230613150156.29022a0e@glaurung.nlnetlabs.nl> <ZIitpTWScXigugLD@feather.sobornost.net> <04D76EAA-AD2E-4A76-8709-0D063E4310EA@ripe.net>
X-Mailer: Apple Mail (2.3731.600.7)
X-Scanned-By: mailmunge 3.11 on 66.39.134.11
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/sJ0I2r11HYCoPx-yzySA_d0yVIM>
Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-profile-15.txt
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 14 Jun 2023 00:24:57 -0000


> On Jun 13, 2023, at 2:04 PM, Ties de Kock <tdekock@ripe.net> wrote:
> 
>> On 13 Jun 2023, at 10:55, Job Snijders <job=40fastly.com@dmarc.ietf.org <mailto:job=40fastly.com@dmarc.ietf.org>> wrote:
>> 
>> On Tue, Jun 13, 2023 at 03:01:56PM +0200, Martin Hoffmann wrote:
>>> Russ Housley wrote:
>>>> I do not think we want to have decode failures if the INTEGERS are
>>>> not in sort order.
>>> 
>>> I agree, but in the past the consensus in this group has been to
>>> rigorously reject objects that have something wrong with them. By that
>>> consensus, an ASPA with unsorted provider ASNs would be rejected on
>>> grounds of violating the MUST further down. In which case it might as
>>> well be rejected during decoding.
> 
> I agree with Martin's perception of the opinion of the group. Having the SET
> may get us a little bit more implementation resiliency here.


How?  SEQUENCE leaves it entirely to the application.  SET seems to be handled inconsistently.

Russ

v2.23.0 | Report a Bug | By Email