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

"Hollyman, Michael" <mhollyman@verisign.com> Thu, 01 June 2023 17:53 UTC

Return-Path: <mhollyman@verisign.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 CB404C1522C6; Thu, 1 Jun 2023 10:53:38 -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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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=verisign.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 oLpPeSmWts-L; Thu, 1 Jun 2023 10:53:34 -0700 (PDT)
Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89E74C151B1A; Thu, 1 Jun 2023 10:53:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=1930; q=dns/txt; s=VRSN; t=1685642014; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Q93Q2IrAmmjEUp1hRsnLkVqNTXeod5TMWW7mf3Z7Fnw=; b=jH0SA45V14GBoiqrLe2hB6uBsIQLHRjdiY9vWPU3NZtNXxJFV93BycXt dhpvcUPqClYiltd+RidQcUcgIkMHxCibOMuXV/bt8urclqfgIVUVDy7Xv 8aj4sNG0gRZcByut2uN2Ftqd5jENeM+/d3xRKBAmNulSlbnM/XgaPfq3J 4mkNQQVq8PLeCoTzNBmNg4X1pvuEXz3s3L+Ayas99Fn9SLjEb0aJZpPpS ktCF62JQsK6Id1qL9eeU4L1CkkUVTuD+Q7W772vhp5yQCUalprg7VTGLG FNMNkdrJYE1m+1grCjkwqh6ONqh0VsI+GmM2jI7TopQQKQmU4QKefZgv0 Q==;
IronPort-Data: A9a23:Rhyz+a6WSBQcLnn1W+wgoAxRtDjGchMFZxGqfqrLsTDasY5as4F+v mFNWW+EPPmCY2r1KI13b47ioEJX756AzYVlSVZu+yo9Eysa+MHIO4+Ufxz6V8+wwm8vb2o8t plDNYOQRCwQZiWBzvt4GuG59RGQ7YnRGvymTras1hlZHWdMUD0mhQ9oh9k3i4tphcnRKw6Ws LsemeWGULOe82Ayajp8B56r8ks156ys4GpA5TTSWNgQ1LPgvyhNZH4gDfzpR5fIatE8NvK3Q e/F0Ia48gvxl/v6Ior4+lpTWhRiro/6ZWBiuFIPM0SRqkEqShgJ70oOHKF0hXF/0GzVwo8rm L2hgrTrIeshFvWkdO01DUEEQ3kmVUFM0OevzXOX6aR/w6BaGpdFLjoH4EweZOUlFuhL7W5m0 PAbNisVYTK/i8mc0rS1cOB+3f8hBZy+VG8fkikIITDxJ8wAGK/lbpWSvJlG1zAqnoZHEbDAf dEfLzFoaXwsYTUWYhFOV8l4xbrzwCWvG9FbgAv9Sa4f5mjUyAhg1bHrGMTYYN2RRMpT2E2fo woq+kyjWU1EaI3GmFJp9Fqlj6jTxRLlZ74rBZy518Zuoh7C93IMXUh+uVyT5KPRZlSFc8leJ 1YT4jEGrKUu+gqsVNaVdxGiqXCY+x8RR9QVCOw28gaV0e/d+B6QQ3YJVD9PadcvqM4xQxQr2 0OH2dTzClRSXKa9Q2ibr6iSoCPqYG0OM3VEYC4fCAECpdP5pth1kAjUSJBoF6vdYsDJJAwcC gui9EAW74j/R+ZSv0ln1TgrWw6Rm6U=
IronPort-HdrOrdr: A9a23:G7hhAqMeKDMfncBcThyjsMiBIKoaSvp037BN7TEVdfU1SL37qy nAppQmPHPP5gr5O0tOpTnoAsDpfZq2z+8X3WB+B9afdTijlmeuIJpr8IfuhxbxcheTysdtkY NtabJ3BtG1L1Rr5PyR3CCIV/It2sOO/qztv/rZ1HsFd2xXQrtt9Bh0ETyWFUBKRA1LbKBTKK ah
X-Talos-CUID: 9a23:INciEGv+FGNxT0CPqBiu93k26IsAfn7D12/fAXO0Ikx7TrOvQE3Lw6FNxp8=
X-Talos-MUID: 9a23:BPhGgA5suFl2/PmpquXdQoiJxoxh6uOyUHETrqk/quiFFBR0GXTMvSqoF9o=
X-IronPort-AV: E=Sophos;i="6.00,210,1681171200"; d="scan'208";a="23464919"
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.23; Thu, 1 Jun 2023 13:53:33 -0400
Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([10.173.153.49]) by BRN1WNEX02.vcorp.ad.vrsn.com ([10.173.153.49]) with mapi id 15.01.2507.023; Thu, 1 Jun 2023 13:53:33 -0400
From: "Hollyman, Michael" <mhollyman@verisign.com>
To: "sidrops@ietf.org" <sidrops@ietf.org>
CC: "draft-ietf-sidrops-aspa-verification@ietf.org" <draft-ietf-sidrops-aspa-verification@ietf.org>
Thread-Topic: [Sidrops] Which 8210-bis error code should be used?
Thread-Index: AQHZlLH7syb/BcM9AE+wusevk3DUTw==
Date: Thu, 01 Jun 2023 17:53:33 +0000
Message-ID: <F338C878-E41A-4DB7-A4C6-1CEE0A6F6502@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <CE95010A71FF484795C47B8BBC5B15EA@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/ApbY90exqBHM2sVlqI1ADnWlBTA>
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: Thu, 01 Jun 2023 17:53:38 -0000

I tend to agree with Claudio and Martin here. I think the afiLimit should be removed from ASPA, if possible, or it will become just like max-length: "It is here but don't use it."  There shouldn't be any inference of intent in ASPA when one is published with an AFI and another without. 

It appears to me that the spirit of ASPA is to simply list the provider ASes for a CAS. Keeping that simple and by AS, not by AFI, seems to be a logical choice. 

Full path control is BGPSec. ASPA is an incremental step forward in preventing leaks and some hijacks.  Simplicity of ASPA should be the key in order to gain the most acceptance and usage. 

Mike

On 5/24/23, 03:39, "Sidrops on behalf of Claudio Jeker" <sidrops-bounces@ietf.org <mailto:sidrops-bounces@ietf.org> on behalf of cjeker@diehard.n-r-g.com > <mailto:cjeker@diehard.n-r-g.com>> wrote:


> I would love to remove the optional afiLimit from ASPA.
> I brought this up a few times (well before there was any implementation of
> any ASPA draft) and every time the answer of some of the authors was no
> (without any particular reason).


> As one of the developers of the first RP and only BGP implementation
> handling ASPA I would enjoy to remove all the code required to handle the
> afiLimit. We probably control most test deployments (RP and BGP side) and
> are willing to make this change.
 

> -- 
> :wq Claudio