Re: [Sidrops] ASPA verification algorithm error

Ben Maddison <benm@workonline.africa> Mon, 15 February 2021 06:49 UTC

Return-Path: <benm@workonline.africa>
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 5992A3A0BFF for <sidrops@ietfa.amsl.com>; Sun, 14 Feb 2021 22:49:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level:
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=workonline.africa
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 i7hVryaR8ywp for <sidrops@ietfa.amsl.com>; Sun, 14 Feb 2021 22:49:04 -0800 (PST)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2060.outbound.protection.outlook.com [40.107.20.60]) (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 5CA033A0C7E for <sidrops@ietf.org>; Sun, 14 Feb 2021 22:49:02 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RaHY6v6j3/MVIV44jC1mw75EW2ZosM6cVbgdaKwDQf6QURwJPQJ24d4AouifHAHzU/K/X2yIY5CRqkaxQRKxx6IUxsr09zxzz64/kF5aLQEm3q2wnxP5HRw1U/7QMAHVnNNoPAnSclVd6+wkN7SihVsGFCnCKQjSiuZt8dtm3kyZwHwi7MvFeglceM+7g4AV9O27qGO+2r29m2rORGmbM7kHSi7laMSxLlZc5gQDajCeoqGmhhGhn3fv/dOD08s+l5yWoQ+dqy7lPAvXxSC1b33tLb1QmDtkaclUp/BjnpCjaF9eOn1sAuTGRaUv8mgMaalT+4PGdOPJESy1jMfKNA==
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=J6b2S0fzQlpNDkH16+BOOtjlWmJbXtXIphSDHUyywbE=; b=mQ/+aAW9qZNkPhbSHrl94FHATnJqan+xrXyWl3vpZHmNu/FD63g6+v8T2iPHFf59cyEr8uA4OKxAPxrbJgkCEtGZwj/IT/ojW9NaWbHBEnbpUQgNuI/zfUKhymrt7ET5gdEer2ZcG7c+dqyT8VC9brS/mPdXYdr0awkbmG8HtIR640Eeb1zl/Tqv6v4PXkz5rS/9/W8pbel+fcyiXeU9tQtPOsOwYBmdLjgTlQjIJy0vM7BgQAsoA8y3j7ra/MDaEPhiRI8Dg1p7Ih3ZNi47VWFEFxSBF4fZiTF/UYUXTI80sOO8YtUl+NOvKKJ9l8PXh/uAHDYfXEJKpcoLv9zd7A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=workonline.africa; dmarc=pass action=none header.from=workonline.africa; dkim=pass header.d=workonline.africa; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=workonline.africa; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J6b2S0fzQlpNDkH16+BOOtjlWmJbXtXIphSDHUyywbE=; b=FIvkeEVBJDrS0GT8nWlxSiVDnhC36QZq441rHhzjS+t5HMHy4pB7oqgUjn4PPS+JoodwjWySWbaqkrlndJzkUpz+t5CLnnmsFzmxasIPIFxWrwvxvlzIAtnFretr8mpRDCD7dQzk4a7WxS+bGp+Yzh3kfbmmQmeyKXEUjmuDYkI=
Authentication-Results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=workonline.africa;
Received: from DB8P190MB0746.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:12a::24) by DB6P190MB0343.EURP190.PROD.OUTLOOK.COM (2603:10a6:6:33::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3805.24; Mon, 15 Feb 2021 06:49:00 +0000
Received: from DB8P190MB0746.EURP190.PROD.OUTLOOK.COM ([fe80::a8b1:5eb6:5886:96c2]) by DB8P190MB0746.EURP190.PROD.OUTLOOK.COM ([fe80::a8b1:5eb6:5886:96c2%3]) with mapi id 15.20.3825.034; Mon, 15 Feb 2021 06:49:00 +0000
Date: Mon, 15 Feb 2021 08:48:52 +0200
From: Ben Maddison <benm@workonline.africa>
To: "Jakob Heitz (jheitz)" <jheitz=40cisco.com@dmarc.ietf.org>
Cc: Alexander Azimov <a.e.azimov@gmail.com>, "Jakob Heitz (jheitz)" <jheitz@cisco.com>, "sidrops@ietf.org" <sidrops@ietf.org>, Lukas Tribus <lukas@ltri.eu>
Message-ID: <20210215064852.atvwzzfdtazo5yya@benm-laptop>
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> <DM6PR11MB3211D016C73756ADB6E979EBC08B9@DM6PR11MB3211.namprd11.prod.outlook.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="awkouhy5w5mlepjt"
Content-Disposition: inline
In-Reply-To: <DM6PR11MB3211D016C73756ADB6E979EBC08B9@DM6PR11MB3211.namprd11.prod.outlook.com>
X-Originating-IP: [165.0.73.66]
X-ClientProxiedBy: CTXP275CA0038.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100:1::26) To DB8P190MB0746.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:12a::24)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from localhost (165.0.73.66) by CTXP275CA0038.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100:1::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.25 via Frontend Transport; Mon, 15 Feb 2021 06:48:59 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 5b552d52-2791-4d67-4d43-08d8d17dc660
X-MS-TrafficTypeDiagnostic: DB6P190MB0343:
X-Microsoft-Antispam-PRVS: <DB6P190MB03439BDEAE644B6A7826EC88C0889@DB6P190MB0343.EURP190.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: nsjxEFWNh7RdHugAV0zjEWPWNu8RkJsBuvuNM7moihUCjSTzqk264Kwqr0OWWbkXQj7yULHCrOe/YbD5jlxOO0BhW7Lnl89hcxvp6kgqmf7PjS9GCSjAci8UDbyS09JvSaRfIFTDAquME/zsnmbRbxnzy5xQ8wgwuain2ZuaIQWVCMP/crBauZxivfj3P7YtAQNaJs0BmyvVBHtx6TTymTov9TlmD8Hgnd8GAmy5LCUhIUVr+1VR2tURV/bG99ndYDbFPNqkXYO6B9Wou5BaShHtnG17qqhjyZFKxyrG+d4Wn1UVXs88/bFzrpNSbjXttL+JlFxTKTcDylEjflaTkkQHCGKWtbUvy8+XoBxij0acclODu6jJ1jMX6gMuJXbpPO5gmII0HTe7kjSyaHe2OLGGXezJYFYHx/CH7tQv+a1gztnFeuuu0u0J1H5Og2qT5w3JUJbgfQaAO2KNYm9ih/tClpN+NRcxozABGtCdOXBOekab54wxJQgJqUu90PheIBK3MIT9T06f8tJOP0JU8qQknpRCTTUUkNB/kJGVncJI7aCxHBu3lmeiNADKJm9UvQcqswLrb38a8HlW/S4qhifAmtSVeJnljgiFOloX0tw=
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P190MB0746.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(7916004)(39830400003)(396003)(366004)(136003)(346002)(376002)(26005)(956004)(316002)(186003)(6666004)(21480400003)(16526019)(4326008)(9686003)(6496006)(33716001)(44144004)(1076003)(66476007)(66556008)(83380400001)(2906002)(66946007)(33964004)(52116002)(8936002)(54906003)(5660300002)(86362001)(8676002)(6486002)(478600001)(46492009)(2700100001); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?ekVLek4yUWs2VWI1Z2NlcFcyV0hjQ042eERNQnVhazZNM242SHFYTkp2Mloz?= =?utf-8?B?cGljVUVNYytmcDFnZHFTMmFKRWVIZnByS2RwdG5uVVpPdisxSWM4VlBXOXFX?= =?utf-8?B?NUx5dDd3eStzaVNwUDR1a1IyZXY3Q09ZSGIvNzZHbGhjZ1pmSEJNaUtva2JH?= =?utf-8?B?SldMcmQzTFVObGZ4UUhQYWkxYTN5UUdHV1VkY2EyRWx6alpGN04vUnY3RFZz?= =?utf-8?B?bVhzWWx6Zi9oU05FNFlMWUZzNnIySkQ2Y2hCUUd4YTV5SHM5ZHFyZmd4ME5n?= =?utf-8?B?b2tTWCtVTEl4WDBFT3E1Q3NFTWRUNlNGbEZMcW1icy93Q0xDRlRoWjUxOURB?= =?utf-8?B?cDZydDk0MjVYc1AzTkVuQ2x1RHp6TjVVUU1yMEVtMFUwY2lsSjFyeVpmOS9C?= =?utf-8?B?Z0J4QVRodHJQM1hudTlXc2tiQmlqZGx5T2VJNjhQUXZWMXArNmFicDY2Q3ZU?= =?utf-8?B?ei92TGtoM2tNLzRFYUEzb0hJYmNjODVGT3NJUENSelJhREJ2S3FJOFpGdGRX?= =?utf-8?B?d2dvVUNOUzEyMGdBQXF5NDRCWEZpTjVNYmV4T3llQ2I2bzQyRFVYbndCeW9w?= =?utf-8?B?TW10K3NvZkZ2WFhyQ3JlU1VZVjRZbnF0VGVRN09heERUVGlwUFdOMU03QjVa?= =?utf-8?B?L1FUVjBnL0V4dmp0UXk4alN4ZmdsMWtvbGtxaE45c2FCZmp3R0pFV0gwcXVX?= =?utf-8?B?bGxoR3ViZG83M3JsN0VSY3BXazZyVkx1Q2pNY0pYWjdWbCsrdjlwS21Dd25K?= =?utf-8?B?QzAybXMzN216YjdwUkFtNmNrMHRQNXVtbytGOWdDYVZWUVBRdG12MThzMzFB?= =?utf-8?B?Rkk2eHV3TlBuNHZJQlptdDE0UU15ZGd2ZmVZT0RkSVlOK21vd1NiVCtlb0tm?= =?utf-8?B?ZEMzbnVkMjZsM09kNWR6aFhsVmlOOGcvM1VLU0tJMWsrcjBzR1J0cUtNQ0g3?= =?utf-8?B?MGJ1SGJXUzNQcEd3Q2Uwa3pmcGdJciswbzlaQTUzcFFneWtkZUFGY2puR3Rh?= =?utf-8?B?dWZCMEtyUFprcDZ6N0MzY3RSTWpsbmVzbm1YWXhtS3J0SnNvV01NaFJacm9t?= =?utf-8?B?dTlOcG4vTEdTUXRmOTdONkt3ODJEMTdpZWpIWG5aZGswRmpYRGswQi8yeUtr?= =?utf-8?B?Y201aXhKQWJ2RitycnUzRHcxMkhBL2NMa2MwMUlPemdPWXpVR3ZTdk9hbCtY?= =?utf-8?B?SWJCZHVId3JBVWxvTE02RW9TWlBHdlVpTi8yQjNGTmhXYTVya0FRbVI5N0Fw?= =?utf-8?B?bFAraENvZU5EamxRWitHdncxQU1nSUZRd3FkNUxhQ2c0L3diUnlzUGpRUnFG?= =?utf-8?B?eEhmZ3hmbVRHV205b3Rxb3h4Uk55b1FieFhVVnNydFpob01IV2NMLzBTWGs3?= =?utf-8?B?em55NzAydGRmRlBVQ2hkNi9SeUZCZlFrWlV1T0szQ2FDZkZtdG1OMjYxTzB4?= =?utf-8?B?TTMrZDB5bkR4a3pYU29aV0JoSHNMKzFSYUx0TGZsL1d4bERWQjFkRjJWU2Zy?= =?utf-8?B?YmgyeFVjQWV4TklXRzV3MUtGdlVMK2pMV3dLRVhSNGh6L0htbFEyNmZJd25F?= =?utf-8?B?Z2tuK0g2cGVlZldEYjl4c21wVTlZOW1JQlIrbGFhazZlaXM2NUpnNUYxbVM4?= =?utf-8?B?SldKT1MzNk5QSnRzeUx6Yy83TmlJSWNRVVE1R2JrcVdYdmFhaWFkTjEwcExo?= =?utf-8?B?ZU1HS3FuY3U4YUpBM1BOU3BkN3ViajBFam1MSnU0M2FTWm51UGpiU3NuZjZB?= =?utf-8?Q?/fbelUpaC2x2cBBcKbTHhF1b6kt2FpT5Qk0a/uZ?=
X-OriginatorOrg: workonline.africa
X-MS-Exchange-CrossTenant-Network-Message-Id: 5b552d52-2791-4d67-4d43-08d8d17dc660
X-MS-Exchange-CrossTenant-AuthSource: DB8P190MB0746.EURP190.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Feb 2021 06:49:00.5079 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b4e811d5-95e8-453a-b640-0fba8d3b9ef7
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: IXGWxU/KMbYXEeeiFVxGzRG18NTIBY50TUpyVRKv8kmD8ocVBiMlNkp9FGKiVrh14qWBz9KypfxIP1u4uHqS/Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P190MB0343
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/43IztkGOflNVAEcUIw1JVu-TrKQ>
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: Mon, 15 Feb 2021 06:49:09 -0000

Hi Jakob,

On 02/12, Jakob Heitz (jheitz) wrote:
> 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.

That's not quite what I said!
I think the logic you used to arrive at the conclusion is sound. I agree
that the path you illustrated should be accepted by the receiver.
However, I also gave several reasons why a validation state of Unknown
is appropriate here.
> 
> ASPA has to work as well as possible without full participation.
> It will never work if full participation is required.
> 
I'm not clear on why you believe the issue at hand impacts the
effectiveness of ASPA under partial deployment?

> 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.

The above looks sound to me on first sight.
I am going to poke it a little before I fully endorse it though...

>   *   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.
> 
The above final step is less clear to me. Could you explain your
reasoning in some more detail please?

Cheers,

Ben