Re: [Sidrops] Which 8210-bis error code should be used?

Martin Hoffmann <martin@nlnetlabs.nl> Wed, 24 May 2023 08:06 UTC

Return-Path: <martin@nlnetlabs.nl>
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 CC225C15109A; Wed, 24 May 2023 01:06:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 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_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=nlnetlabs.nl
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 Cp_ehxLJkZK8; Wed, 24 May 2023 01:06:04 -0700 (PDT)
Received: from outbound.soverin.net (outbound.soverin.net [185.233.34.18]) (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 B0CBDC14CEFC; Wed, 24 May 2023 01:06:02 -0700 (PDT)
Received: from smtp.soverin.net (c04smtp-lb01.int.sover.in [10.10.4.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 4QR3fJ6fCVz1y; Wed, 24 May 2023 08:06:00 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.100]) by soverin.net (Postfix) with ESMTPSA id 4QR3fJ3VrjzJ5; Wed, 24 May 2023 08:06:00 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1684915560; bh=myH13mkUfwJ6vPRo2bnpdXzbOKGpU/s2p4tGtnNoOBs=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=WfMk02MDRNBAEz2J6cw6JcuR4Emc1G6MtyUTPqy3EUFbS41KB2ya75qQIT7/TrGFp hbiMIfrPtrd9L50YhjohzrvMXQhGiIRsMXPnckNqs0aIRdIKxPB70TR2Mdivtwl/Xm CXqDgNlIQvcxXMjKrinjVU2BE+fGWl6+cAfXTllVXsFYG+kQaGDxDpmTRFEgl5HSMP TXLX4CPSDQzM75c/CdQv38v1HN0S230pQHKSmcHDSC83pkSbNUffYxA5WWtUnJopHg Tnu4jZxoPwTvH47wDkfgV2xeBRWQR8E1zdGXJrO/JocclijByDNP34CJFTGbhvK+6T kJHqnaEt3f3yA==
Date: Wed, 24 May 2023 10:05:58 +0200
X-Soverin-Authenticated: true
From: Martin Hoffmann <martin@nlnetlabs.nl>
To: Claudio Jeker <cjeker@diehard.n-r-g.com>
Cc: Jay Borkenhagen <jayb@braeburn.org>, "sidrops@ietf.org" <sidrops@ietf.org>, "draft-ietf-sidrops-aspa-verification@ietf.org" <draft-ietf-sidrops-aspa-verification@ietf.org>
Message-ID: <20230524100558.452d4caf@smaug.local.partim.org>
In-Reply-To: <ZG2Vobyxl/gPEfCU@diehard.n-r-g.com>
References: <SA1PR09MB8142523FA03AC4EA6E0E014E847C9@SA1PR09MB8142.namprd09.prod.outlook.com> <SA1PR09MB814235BE0566A5C6935CF5B184439@SA1PR09MB8142.namprd09.prod.outlook.com> <SA1PR09MB814231707524646D651B69B884439@SA1PR09MB8142.namprd09.prod.outlook.com> <ZGs5bFRjPLnyL2Jd@diehard.n-r-g.com> <25708.55138.924074.242182@hrabosky.cbbtier3.att.net> <ZG2Vobyxl/gPEfCU@diehard.n-r-g.com>
Organization: NLnet Labs
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/VqBqXe_EhgVnSrIthJXLpOfAKEQ>
Subject: Re: [Sidrops] Which 8210-bis error code should be used?
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, 24 May 2023 08:06:09 -0000

Claudio Jeker wrote:
> 
> I agree that ASPA-generating CAs (especially the RIR portals) need to
> stop or warn operators when they create entries that only cover one
> AFI. Actually the portals should discourage the operator to use AFI
> specific entries in the first place.

This sounds a lot like we are creating the next max-len debacle. Have
we seriously considered just not having afiLimit at all? The
consequence would be that a couple ASPAs have a couple ASNs in their
provider set that aren’t valid providers for a subset of prefixes.

How does the added protection weigh against the added complexity
at all stages of the protocol, particular in view of the strong
recommendation to not use the feature at all?

I.e.:

> Remember:
> Rule number one to improve security is to remove options, not adding
> them.> 


  -- Martin

PS: Yes, I know it is very late in the process. But this keeps popping
    up which is a good indicator that it will keep popping up later and
    cause operational issues. Perhaps avoiding that is worth the extra
    hassle now?