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

Ties de Kock <tdekock@ripe.net> Wed, 14 June 2023 16:54 UTC

Return-Path: <tdekock@ripe.net>
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 8F957C1526F7 for <sidrops@ietfa.amsl.com>; Wed, 14 Jun 2023 09:54:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level:
X-Spam-Status: No, score=-7.096 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=ripe.net
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 04iuFhJulTIG for <sidrops@ietfa.amsl.com>; Wed, 14 Jun 2023 09:54:01 -0700 (PDT)
Received: from mail-mx-1.ripe.net (mail-mx-1.ripe.net [IPv6:2001:67c:2e8:11::c100:1311]) (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 E4AF0C15199F for <sidrops@ietf.org>; Wed, 14 Jun 2023 09:54:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Cc:Date:Subject:Mime-Version:Content-Type:Message-Id:From ; bh=P0VB6zYwZzdLXo29HvVYS7RfQzH8eW3Nkujzyk1fvYE=; b=PF9aIn6azW6ChAv9Jm3qgTvh BJQqnIzn+eIGe6JHrc+yDPKnAdkZ1OEUsb3vX9LfbqdOe29iJgJ0hffyrsP9Jx9q54FwgK/ubdkeU aqW7DsOF3RSPq73A7tXRhuEe4H09KIQUfHkTIez5b272EsF9VtT5RQXdCMFCqW7qf44+dGQ5vWBvd cbTrzc3pdeTsiqNWwUkVivttLsKQ7q5/h5bABW7NMhWjdQK6AR0VfSTHr/thTp84Kzq33kl1npifj FZlPkFLCHcsMTIASz2qX1yaiii993cmOS05VQFeW0/+ckIQ2/simSR5qYVJZ/ISTMi5ipddZFNXer CrbYEzixJA==;
Received: from bufobufo.ripe.net ([2001:67c:2e8:23::c100:170d]:44550) by mail-mx-1.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <tdekock@ripe.net>) id 1q9Tks-006gTB-0B; Wed, 14 Jun 2023 16:53:58 +0000
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=smtpclient.apple) by bufobufo.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <tdekock@ripe.net>) id 1q9Tkr-0001kD-2m; Wed, 14 Jun 2023 16:53:58 +0000
From: Ties de Kock <tdekock@ripe.net>
Message-Id: <38DD326C-3AA7-4E60-8C0E-3F00D0BD217A@ripe.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1859CEC1-C5F3-43EB-9B5A-D4188075F49B"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
Date: Wed, 14 Jun 2023 09:53:10 -0700
In-Reply-To: <D562E769-D436-46FD-BD20-520FA495B4F2@vigilsec.com>
Cc: SIDR Operations WG <sidrops@ietf.org>
To: Russ Housley <housley@vigilsec.com>
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> <D562E769-D436-46FD-BD20-520FA495B4F2@vigilsec.com>
X-Mailer: Apple Mail (2.3731.600.7)
X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e1b42c863331f977ceadb525a7224535fc
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/eDAhZgVUxt7zCkza2MAv4cdUCPY>
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 16:54:05 -0000

Hi Russ,

> On 13 Jun 2023, at 17:24, Russ Housley <housley@vigilsec.com> wrote:
> 
> 
> 
>> 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.

SET should give you the proper semantics on encode (as a safety net). When
decoding I would expect an implementer to use a lower-level API that gives
access to the elements in the SET/SEQUENCE iff an implementation does not do the
checks implicitly.

I do not have a strong preference between SET/SEQUENCE. However SET is
semantically clearer to me.

Kind regards,
Ties