Re: [Sidrops] ASPA verification algorithm error

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Fri, 12 February 2021 19:48 UTC

Return-Path: <jheitz@cisco.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 95A5D3A0D3E for <sidrops@ietfa.amsl.com>; Fri, 12 Feb 2021 11:48:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.619
X-Spam-Level:
X-Spam-Status: No, score=-9.619 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_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Qyem/Jvx; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=P7rA2rQq
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05qsXk6rSBfC for <sidrops@ietfa.amsl.com>; Fri, 12 Feb 2021 11:48:37 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B70A03A0D3D for <sidrops@ietf.org>; Fri, 12 Feb 2021 11:48:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28536; q=dns/txt; s=iport; t=1613159317; x=1614368917; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=u1TqTZQHqcv4+uhvx2VmBs41PjHzZ4tKvXOxy6g5/18=; b=Qyem/Jvx0q5cyYvsTeALo5vDs8/t6GRqsLn2T13yIFOIQXtBfFw4hi8P u98OO5jqtHN6gCbVLnwTyIpkqZNo3A/mYyKKu27iE7kYY7g0H/kiUzWhD YRuTykqfQ2x0IK7HB67QhLqMY+U93J+icWT0xzzZV+squ4mZnu6IOp3+5 Q=;
X-IPAS-Result: =?us-ascii?q?A0DsAQCe2iZgmIENJK1iHAEBAQEBAQcBARIBAQQEAQGCD?= =?us-ascii?q?4EjMCkofVo2MYRBg0gDjgYDgQWYF4JTA1QLAQEBDQEBHQEKCgIEAQGECEQCF?= =?us-ascii?q?4FwAiU4EwIDAQEBAwIDAQEBAQUBAQECAQYEFAEBAQEBAQEBhjYNhkQBAQEEA?= =?us-ascii?q?QEhBAYTAQEsBAcBDwIBBgIOAwQBAQEnAwICAiULFAkIAgQBDQUIgh1LAYF+V?= =?us-ascii?q?wMuAQ6VFZBqAooldn8zgwQBAQaFDxiCEgMGgTiCdoQFAQGGRSYcgUFBgRFDg?= =?us-ascii?q?iE1PoJdAQECgV8VFgmCYDSCK4FTBRGBIQEnFCQDGBcJAToqPyAYBxsNICmTR?= =?us-ascii?q?4c/jEqRSQqCeo9pjEOjLJADgWqCS50lhFUCAgICBAUCDgEBBoFsIYFZcBU7g?= =?us-ascii?q?mlQFwINjh8MDgmBAgEHgkSFFIVFcwI1AgYBCQEBAwl8iFUtghUBAQ?=
IronPort-PHdr: =?us-ascii?q?9a23=3AZFR+ARGHKEKkRZB1k7n7Np1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401QObUoDS6vYCgO3T4OjsWm0FtJCGtn1KMJlBTA?= =?us-ascii?q?QMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS8n7blzW5Ha16G1aFh?= =?us-ascii?q?D2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNixw?= =?us-ascii?q?=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,174,1610409600"; d="scan'208,217";a="663078664"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Feb 2021 19:48:36 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 11CJmadR031657 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 Feb 2021 19:48:36 GMT
Received: from xfe-rcd-001.cisco.com (173.37.227.249) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 12 Feb 2021 13:48:36 -0600
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Fri, 12 Feb 2021 13:48:36 -0600
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 12 Feb 2021 14:48:35 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B8SHpHkWieLti/zV1InHzTLERIEvQdfkjoAthZgODmQpZNgBR6Fli6iI+0mv1FWCZMAS8TMhTVNDVX5DyxXyYLn3BE6PsWGmtw03lSUsonQydJ0CVMsBN18V9aqVAN6wbKX+TsdSjWLi4qwAZSlo2LhWumHrEyzOVSsItcJSO4JWS24KYD+Sf/9kM141fFbXGoiZOkWfdS0Wg3gy4kr67zWVz/mo97l2ZYevGUjwrER66Wkf8+qo2WeNkbhSUcmUuwWzVTOJRaewpPIpsF+HRWycDlO0LCQ6iLl5hrRukcE/cvwMZATE3Ha1J3zFIJyZIg/vQft+etp6W7z2CEPkMQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u1TqTZQHqcv4+uhvx2VmBs41PjHzZ4tKvXOxy6g5/18=; b=jnlEwVbgG99tvDAW2G2OtxTpbgMbg3VvGviMATUgX5p1PWnxW6CHJ+S8ZMSGAuORkH6xoexluh2QKWVCcZ28sYwaR3OlecIaEriw06MZd8OcqkQ6nbIqldt86RUjzTJKwspNJ95D7r6fQ1B3Hikh9y3j5GoseR6e9UqNwDVMnO1EbILzEvbo3NNds2pI+9hUo3miFTRtntjFf9AeP1fYf781dLEGuJ4gSbfzrBs0V80D2IgEPqb/L2SBSmMhySmP1y+zG9LOO8f2//RGV08C0rkrqTiCXKbIe+UM+gBUnIz7cCtSRjVnnjAyxZ/bbs2XnBbkEOclnmEwB+gPmtBTsw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u1TqTZQHqcv4+uhvx2VmBs41PjHzZ4tKvXOxy6g5/18=; b=P7rA2rQqZCXvQNZZWj8Qf6e/AHR8Pt8l6mjDK7k93k59DRlt9slNBMCj+e/nH7GREJ0w0GhxAOeqV6Ix415oumaxzrGXNtBdfssU0Apu6NTIZLQgFRollxQsZxQgD+lZ8w93PFBcDxBikJrXmfIug3FFBXgoe0JLae4chSYzvo8=
Received: from DM6PR11MB3211.namprd11.prod.outlook.com (2603:10b6:5:58::27) by DM5PR11MB1499.namprd11.prod.outlook.com (2603:10b6:4:8::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.29; Fri, 12 Feb 2021 19:48:35 +0000
Received: from DM6PR11MB3211.namprd11.prod.outlook.com ([fe80::3db2:3099:3729:45f5]) by DM6PR11MB3211.namprd11.prod.outlook.com ([fe80::3db2:3099:3729:45f5%4]) with mapi id 15.20.3846.031; Fri, 12 Feb 2021 19:48:35 +0000
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Alexander Azimov <a.e.azimov@gmail.com>, Ben Maddison <benm=40workonline.africa@dmarc.ietf.org>
CC: "Jakob Heitz (jheitz)" <jheitz=40cisco.com@dmarc.ietf.org>, "sidrops@ietf.org" <sidrops@ietf.org>, Lukas Tribus <lukas@ltri.eu>
Thread-Topic: [Sidrops] ASPA verification algorithm error
Thread-Index: AdbwhlK9z1axTpzkRWyI9nY082H2KAPh4G+AAANgFnAAKBpWAAAFTvHwABFfS4AAFYaaAAAAF8eQ
Date: Fri, 12 Feb 2021 19:48:35 +0000
Message-ID: <DM6PR11MB3211D016C73756ADB6E979EBC08B9@DM6PR11MB3211.namprd11.prod.outlook.com>
References: <BYAPR11MB320714401DE9AFBF5D24C832C0A09@BYAPR11MB3207.namprd11.prod.outlook.com> <CACC_My906OxmEphW=DOrGhwSagZKf--hd5oLR9uF=24kuA24ag@mail.gmail.com> <BYAPR11MB3207BD021F246199C7E4CCD6C08C9@BYAPR11MB3207.namprd11.prod.outlook.com> <CACC_My8Kg33v=2kXgDZb+11QHSPwJtiFSmuXm_w=LuoEP2crBA@mail.gmail.com> <BYAPR11MB320745F7CD054ABBAD1647FBC08C9@BYAPR11MB3207.namprd11.prod.outlook.com> <20210212081003.bm52czsjoevwtnw3@benm-laptop> <CAEGSd=B7KSaAbm-zLE_FUvFHnFaUUF9Sp-1rJ6e94E_LDVpw=Q@mail.gmail.com>
In-Reply-To: <CAEGSd=B7KSaAbm-zLE_FUvFHnFaUUF9Sp-1rJ6e94E_LDVpw=Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2601:647:5701:46e0:a466:79fe:7183:c553]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4bc7c36f-3959-4d60-ffc8-08d8cf8f2f27
x-ms-traffictypediagnostic: DM5PR11MB1499:
x-microsoft-antispam-prvs: <DM5PR11MB1499D40E32A6C9507A231FDDC08B9@DM5PR11MB1499.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: wCrrPo4798FFBEcSj+ju52W1tIKoUASot83lWXQ3mxGkSMmYMbkrxmPbI2hkDxI3g73FYwWfxiR5gSHsSgYaZvlkRfbk0w8pMdyGoIUpo0JdnmvomaILwabtpbdIYcIEH0JP9vOL+Y6x7xgKvY371QODKql+tGunUn2sxGi/RyxH3FbaN8OFPMmgdBooL4UlDBdUCBNIWeZ+0yQJ9qHmf5XpAKkJeb52KOZglOQfgvwU9eAB+6VRODJr0LJSthIId+R4kd/pgN2Ig6vqtLSiob8RMqQAVl++ppEnUUEYDMc0k8Cx1h8DrH200d8H1z/lIng7Zbe1bWZ39gCIrgNblDHIPm5cecheRh+q1xWpEqcfN/DYoAQUFDXfpJ60hPe+0ahQZ98rAYYkeQaNEXGQyHd2cJmL40PjQTVUu2mu9VCOCVBLoifaFrVtgUM4AyCNql1pnDTcbGSsdX+U8ot/83ICmU2OS95OaqNdwpPdlebHDUZjid/nOuL1vCrZLlOtdcxBG1gc5EPUZHmyxAZIvr7bY/30Ktsk5VQYeAwyhPELkvHP8Sm4p9KzOjN9uyGeDrvDHCe6UE7KnBRuBob+x8an+skyR/OWfo26F+3oL8E=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3211.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(136003)(39860400002)(396003)(376002)(346002)(71200400001)(66446008)(66946007)(8936002)(186003)(966005)(76116006)(66556008)(66476007)(64756008)(15650500001)(316002)(55016002)(110136005)(9686003)(5660300002)(2906002)(83380400001)(478600001)(86362001)(33656002)(53546011)(166002)(54906003)(6506007)(4326008)(52536014)(8676002)(7696005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?aUZ0bHN3TStKUmxXdWhsL3B4L0lZRTdZbGVYaXhjbXhsSmtDWUoxY0dZKytw?= =?utf-8?B?dTg2eEUyaUdSczQ2WHMyOVoyVHR3QnpzdDdnTFc5dE9idHZNTXkxWE9DT05s?= =?utf-8?B?dHhLbGFER05BN3FYRkJGZDIwTDdMc0FUbW5FcnFSbWwzaWVqNnBqNzNhY2FF?= =?utf-8?B?dTRuSTdhQlJCdndlVWJpWlFtcUZkemwzZGJjanViaTcyWVRBQkFjeDhGaGNM?= =?utf-8?B?NWhaYnVyM3VuRER1ZUE1Z1d0MC9rSStTMXhhR0EySGNFWlBsalo3dzNvT1Uy?= =?utf-8?B?S3JCYjQxZzc3cGltYWM0OTNDYkRGK3A3ZVZiczdNLzl0dnZWeWpjbkNJV3Vz?= =?utf-8?B?Zng5dnlidmRWSzZhMkZTVURxMkJKSVhpbno1T2VwTGtPU0kxMElPK1N2QjRE?= =?utf-8?B?M3ZtdjdsNWpmN2ExMG1aQmZvNlM0MVZVVHZLSVB4SWI2SGZjalRNL2xvWWRN?= =?utf-8?B?Y05xNlFiNG1FcVVKeUE2TWJxVDU2ZFZKY3RpRU82clFjUEZNaVlqV1Q5Q2dO?= =?utf-8?B?d2hQR3VEUjk5M3YrOTJHazFPYzh2dWlxbGlXSC9INU9IazFWQUp6MEFlYmtO?= =?utf-8?B?a2VxRGxSQ3F5QWpsR3FCOXVLcFNmQy9VTEluaitPOHBsSWpTV3pMM1NEVWpt?= =?utf-8?B?UnlhVFZVR284TE4rS09BemtGcEcwTm1WeCttOHJuVVc2YVRTYkdxMVRJUUJP?= =?utf-8?B?YTZzVDNUQnc5Y2hVWHVsRkhiWTJPRmt6VEtWNjRLT1lrbVJ0djE1RDVrMXJI?= =?utf-8?B?OFp2eEpBTngxVStkTThQcVBTckUySE11WVcyZDZROTlsVENTSjNuLzRYMDF0?= =?utf-8?B?cTF4Mi9ONndCYVBTcmdqUTlXeEFsWG1YV1dhbE9zT2p4S09Sb3pISzNFVGNS?= =?utf-8?B?UGw1dndiNmhPTlBWSTNzd2t4Ny9zV0RsZUg2VFF4dzI4YVhXMy93SGg0d29G?= =?utf-8?B?cHUwM0JhTjRDcDJWcFdoY2VLYTJLc0lCclpKbkhpczdpQm9lSzQwWXd4MHor?= =?utf-8?B?bzJBRHI5VFU4NVhJV0U4Z3RuNWlkbHFNUjBYQ3MzVVZEZnh1OUpiYzNJWEk2?= =?utf-8?B?elpoMUliRmRLUDJXRmlPYnhCV3B2WnRsZUhFSG85OExReDFqSkxiaTRiMlIw?= =?utf-8?B?Tk1vSnNoNHlSeGZQMnJwRGRsekVMS0RsYVgwVkRLOWJYWU9UUE11N0p6U2V5?= =?utf-8?B?TGczcldtUGtFRFRFUTJCRXVXN1RPd1NodHlHUUxFeElpVWlJMFcyL2dyOXds?= =?utf-8?B?YS9yMm1GZGJFNkRpV29rVWhVeElpcitPUFJvQ0FkMUFLT1pzMjhibjJ6cER3?= =?utf-8?B?OHFYaFFDMmNUazhOVlBqeFMwcVNobXgyL3pPa2Y1WTJXVktrUEw4ZGIzeTNi?= =?utf-8?B?TnFyQytUVkg1bDVFM085NHNncER6RjlabytpWVlxOXBMTldPMDM4cXJzTGtl?= =?utf-8?B?TmZQRGR3Rlpla1E2aHFUOXE4YWFVb1VFMmxrbkc4VVZUYWxQSkpCbk1ZR283?= =?utf-8?B?Slc1SFFnNFUrR3ZuV1A4aXV1dWtrUkltVDRQT1M1QzRlU2ZjbXBPcHlmbjhh?= =?utf-8?B?cnByRzFWNzFESmVMOHVmOFZCNTdTNS9LbSs2Vy9nVUVrR3FJNmh3a1FMNCtu?= =?utf-8?B?UzBtTHAzdnRQQmZDbGNZK0ozbEI3aDB2dTREVUVWWmZVSDl1MWhaWUNsK0Nt?= =?utf-8?B?MkprZmNzTU5UYmkwREN5djBhc2lZMklqdVRXN08xaFNUemY2bjhHbWlpd2cv?= =?utf-8?B?NFFtQjZ3amR4dGxXUWlIM3RXOGRTQm1wZTM4K0hoaVZGaVNEWk52UXc4QjlZ?= =?utf-8?B?UkxPcmh3UTNXTm1VdS9nVnNUQ3NXVE5CdnlDQXQwaGF0ZUZMelJTTXd4RTlz?= =?utf-8?Q?p7mO1gw9TdGhc?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DM6PR11MB3211D016C73756ADB6E979EBC08B9DM6PR11MB3211namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3211.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4bc7c36f-3959-4d60-ffc8-08d8cf8f2f27
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2021 19:48:35.0709 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: I8NLCGl/JKTbSUMFOa/IBDuoSP7udPfNstMSoZGOUnIGBua0KO3Ftq0q9RT5Puxw0DCMNHSUj2kfuGHCHQo5Cg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1499
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/JeEZnHWjrS3j9ldshEoyUMMOwus>
Subject: Re: [Sidrops] ASPA verification algorithm error
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 12 Feb 2021 19:48:41 -0000

It seems we all agree that the path I illustrated is valid and the algorithm in the draft marks it unknown.
The first priority is to get the correct result.

ASPA has to work as well as possible without full participation.
It will never work if full participation is required.

I agree with Ben that it is difficult to reason with the model of ASPA as written in the draft.
Here is an alternative:

    Every transit AS in the path must have at least one neighbor that calls it a provider.

That's a lot easier to reason about than trying to figure out where upstream turns to downstream
in the presence of bilateral peers, siblings, complex relationships and ASes making no attestations.
You only need to consider one AS at a time and what is to its left and to its right.

Repeating:

Consider the as-path (1 2 3 4), where
1 attests that 2 is its provider
4 attests that 3 is its provider
2 and 3 make no attestations.
Then the path is valid.

Here is a simple and working algorithm:


  *   The received AS-path is prepared:
     *   Remove duplicate ASNs.
     *   Prepend own ASN.
     *   May also prepend Forwarded-to ASN to detect own leak. (optional)
  *   For every sequence (A, B, C) of consecutive ASes in an AS-path:
     *   If A attests that B is not a provider and C attests that B is not a provider,
then B leaked the route: B is transiting for free. The segment is invalid.
     *   If either A or C attests that B is a provider, then the AS-path segment  (A, B, C) is valid.
     *   Else if either A or C make no attestation, then the leak state is unknown. Even if B lists both A and C as providers, it is not necessarily a leak, because either A or C could consider B as a provider for some of their routes, even though they don’t attest to it.
  *   If all the path segments are valid, then the whole path is valid.
  *   If any of the path segments is invalid, then the whole path is invalid.
  *   Else, at least one path segment is unknown and one more rule must be applied: for any sequence of ASes (A, B1, ..., Bn, C), if A attests that B1 is not a provider and C attests that Bn is not a provider, then the AS-path is invalid. This is for any number of Bx greater than 1.




Regards,
Jakob.

From: Sidrops <sidrops-bounces@ietf.org> On Behalf Of Alexander Azimov
Sent: Friday, February 12, 2021 10:26 AM
To: Ben Maddison <benm=40workonline.africa@dmarc.ietf.org>
Cc: Jakob Heitz (jheitz) <jheitz=40cisco.com@dmarc.ietf.org>rg>; sidrops@ietf.org; Lukas Tribus <lukas@ltri.eu>
Subject: Re: [Sidrops] ASPA verification algorithm error

Jacob, you are right that additional heuristics can be added to ASPA logic to transform some Unknown states to Valid, though it will not improve leak/hijack detection.
Nevertheless, I agree with Ben. Such changes can result in misleading understanding if one will try to distinguish if the path is more reliable a.e. Valid from Unknown. This has special importance if we start speaking about malicious activity.



пт, 12 февр. 2021 г. в 11:10, Ben Maddison <benm=40workonline.africa@dmarc.ietf.org<mailto:40workonline.africa@dmarc.ietf.org>>:
Hi Jakob,

On 02/11, Jakob Heitz (jheitz) wrote:
> pair_check with either AS2 or AS3 as customer will return unknown.
> Therefore, the algorithm returns unknown, when it should return valid.
>
If I'm understanding you correctly:
*Any* ASPA (even an [AS0] one) issued by either AS2 or AS3 would result
in a valid path.
Therefore, you are arguing, even if no ASPA covers the AS2<->AS3
adjacency, the path should be considered *valid* since there is no possible
ASPA object that could result in it being *invalid*?

I think that logic holds. However I don't favor incorporating it into
the validation algorithm for a few reasons:
1.  We (and I expect most others) will make no policy distinction
    between valid and invalid paths in policy. Thus any additional complexity
    is a poor trade.
2.  It is important that engineers are able to easily reason about how a
    set of ASPA objects and an observed AS_PATH result in a validation
    state. Whilst I think the above logic is valid, accounting for it
    mentally is non-trivial.
3.  In the event that operators do de-pref invalid in favor of unknown
    (yes, I know I said above that they probably won't: but *if* they do),
    then AS2 and AS3 lose traffic on that adjacency (which is undesirable for
    them both - otherwise they won't have built it).
    This creates a positive economic incentive for AS2 and/or AS3 to go
    and create an ASPA. Positive incentives are in short supply in the
    routing security world - I don't think we should opt-out of them
    lightly!
4.  There is no creation dependency problem for ASPAs, like there is for
    ROAs - where e.g. a provider has to wait for customers to issue ROAs
    for all sub-allocations before issuing for the aggregate. As a
    result I don't believe that we should be spending cycles
    accommodating those operators that don't bother doing it.

Interested to hear your thoughts?

Cheers,

Ben
_______________________________________________
Sidrops mailing list
Sidrops@ietf.org<mailto:Sidrops@ietf.org>
https://www.ietf.org/mailman/listinfo/sidrops


--
Best regards,
Alexander Azimov