Re: [Sidrops] ASPA verification algorithm error

Ben Maddison <benm@workonline.africa> Fri, 12 February 2021 08:10 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 4A3923A1372 for <sidrops@ietfa.amsl.com>; Fri, 12 Feb 2021 00:10:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 d3gWemJJsyXw for <sidrops@ietfa.amsl.com>; Fri, 12 Feb 2021 00:10:16 -0800 (PST)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2069.outbound.protection.outlook.com [40.107.21.69]) (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 A482B3A136F for <sidrops@ietf.org>; Fri, 12 Feb 2021 00:10:14 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JmrqZM1zEHBzLYlBdvfecrMJ5CEqzjVX1G5hKWDDvZAWd0acKXto6ilfJlGHr8LraL6cZgrPGx2oNKfsC4A9a5LI8uoo3gMgIjkCEay5FwCUkdbmldjAR4ZLmb6WAhIovrHOjau2wOPg7hfCYvXFqx8RURFwL6f461QiGzd0V/GEc9f27kmfTrLzwGS5z9DRZNnFjmWZj0qt2CcZea3yhrD0qKsFjQtrHqGCD8rlaMVTD04J/QiQn+l402uIdmv/DPEF9Vo/jTfLP9Y5sFNoSMdTDd41KwDn4m9OZB3hVy3WLWyXJzSJzvb9l/+pkXleKpSTct++LCa4N+4tGTnrSA==
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=dCcHurXPY0p/S02mcpykhZg9TjI87VZ3o+CTKeGVm5U=; b=M1XMfs4Uo7uVQ3AbPrJFyxuxzOhgJ5hxZkTP0TDnu/Zfov6hkWHVihFmriPmrlqW7uRMCfLdTVm3UjS3OhxnhlIRtvrub8J+PgJSsQKPSzVgbicBx3Ixj4WBwC312/WngeMRfwzICXnscG/oO6tZ1YlkO5Euiot6pOxgZ5ZLj7z+hdYyAESwNgi/kGuu5MWPck3nBnYeLoETN9I6yiD9oUTRJWJZlMaN+QJ4WbcUChWv5IH4FO99D+LBNd2Xb6Rz0wOUAP8nbJMLqO8FmtL8TavdGsRUIPTzstyALevs7zgLZNf/BsrVM40rT1k4D1j2DWrXbyAd7+LwAz4qLReegA==
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=dCcHurXPY0p/S02mcpykhZg9TjI87VZ3o+CTKeGVm5U=; b=Ea+tW4jTmIGskQJZAfgOSmtzg/PhdRufRQFOpGRE6kwcmOYG7snu+FIrZBLWA5lKDuGxcHv+uNOcS594PKgGA4RNA8/CSbBXu+7pdua2fu8AmjWlvqFTM9YpLgJtuYZPgCncfesyot8mbpMtLcCsRyk5FVenXaf3vkGMeWmGkQA=
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 DB6P190MB0502.EURP190.PROD.OUTLOOK.COM (2603:10a6:6:3a::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3805.24; Fri, 12 Feb 2021 08:10:11 +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; Fri, 12 Feb 2021 08:10:11 +0000
Date: Fri, 12 Feb 2021 10:10:03 +0200
From: Ben Maddison <benm@workonline.africa>
To: "Jakob Heitz (jheitz)" <jheitz=40cisco.com@dmarc.ietf.org>
Cc: Lukas Tribus <lukas@ltri.eu>, "sidrops@ietf.org" <sidrops@ietf.org>
Message-ID: <20210212081003.bm52czsjoevwtnw3@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>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hootobynwpvqre3r"
Content-Disposition: inline
In-Reply-To: <BYAPR11MB320745F7CD054ABBAD1647FBC08C9@BYAPR11MB3207.namprd11.prod.outlook.com>
X-Originating-IP: [165.0.73.66]
X-ClientProxiedBy: CTXP275CA0041.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100:1::29) 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 CTXP275CA0041.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100:1::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.26 via Frontend Transport; Fri, 12 Feb 2021 08:10:10 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: c57ad1e6-126f-42ad-da54-08d8cf2d9e23
X-MS-TrafficTypeDiagnostic: DB6P190MB0502:
X-Microsoft-Antispam-PRVS: <DB6P190MB0502B7FA0E72DAD767578719C08B9@DB6P190MB0502.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: +2SfnKkZfRDDdThd11GC6GGZdq+cOegHVrUVLHXrFh8KJJTcgA1XX+38v8VG9PltzWxe+YHrpyAAbXB2qFhBZwcDW1XoMlFWWtZfXgXQMSA8HCrXz/E2+fEU5r5zKc753XSjW7FRVF0zYs5yI7mIjCf/sK16WJYs2pH3/HMGHyGCyQDom7U56MFQqVERJWeN0eDNk3YGVnxikcTYyl4zj48tGueZnzL9N2K/JFjepLeY2hPTPQ9rl6nN49Sptdr/Y3y5T3/rOEx0HOzSNt8O3yBSHP7y1cakaXNySI670d42csjqMnKX09eT6uZUiSc1e8saO6XOqYE8Qt5ntHQcsLWUrNBJQj9J3RojOPXBa5+EnzXk1ykN5Vsby59akqePlBy+xIC3N9OcM/RcUgeTdvUyI5JZxpxGX+UfVCtcIawn3wU2Pz7UJKbx/3WaKIlpsuVT56NcmCHneMiew/ZvDh3Rjf/MjYqgT7KUQnBmyl467PfUf3LjSYirQMxt6ZqjgRnVBruvZFUQS0rCjv47PtWqbWqBzht+NPVFIBUwpygt6/5X1n8Vrt7AenngzJmSEzIw//uLQW8mAEOjto8uKsTjcC4oG1OmcWnpOg6U7XM=
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)(346002)(396003)(39830400003)(366004)(136003)(376002)(86362001)(66556008)(66476007)(66946007)(8676002)(16526019)(186003)(21480400003)(6666004)(44144004)(8936002)(33716001)(1076003)(6496006)(9686003)(26005)(956004)(5660300002)(54906003)(316002)(15650500001)(478600001)(4326008)(52116002)(6486002)(83380400001)(2906002)(46492009)(2700100001); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData: =?us-ascii?Q?xFxhJg9zZpcjSX/quwU/sDnRjNgW6gbztLi1S/aTtp7VfvjTnKms6BkWmYw0?= =?us-ascii?Q?RxmFzBeCPRk8YHK5JvXBSZGGke5i4CjkURjf2qqSRKdxN/oUt8+AcRzwEXf1?= =?us-ascii?Q?eBMIlMmQsoRkT17PgJOusGw30fIRkrfxq/imzW0jnOPInj7oSpIEpAESHblo?= =?us-ascii?Q?j3mMDCvHYw0L7PlxSNaFN3tBq0VCE4qDcVtnHAZFZ3gtOrp+3WGyJoYq4V5c?= =?us-ascii?Q?4lut35soidHhVvDTErFJtnBKiw4XwGJNtMG+/0c66/qscBp0+YOefKJJ4Dvv?= =?us-ascii?Q?wJ4ZSw2ffdMmIzmF2qPrASJZKxBmbV6iotbVXf5aogJ0L7UF01aBVs9BUKgw?= =?us-ascii?Q?jn5yJZk8t3uXyvNCHHlVdrl/k0iKcT9hmFmlm1VvpZDa9Sb3XcBFbDMkP9zt?= =?us-ascii?Q?szjltYonXcmKgPJj5ziE9q2k0CtPX0ZvkkvMfizy2uGVyuiJQdRHN1a7nAdM?= =?us-ascii?Q?n844rPxNiShYRwUDF8MYqzO1JR4+nZ5dm8Q7215+AAthgloTKeVECyVml9Dp?= =?us-ascii?Q?A52oi6caS9qeIPDr/C7u033jzCvqNKwU2n3pIFg26edwTZ7hXsn1jSROPk6/?= =?us-ascii?Q?EJAd8Lb2jx4rTAvcfnHh8ArdLe4iGMrkQDo0Tp3/I2RgHbGNbDaRuQJqQkta?= =?us-ascii?Q?EZwHakO5fGQgohB67QZq5L6jh68QkJjR/SNbRbEBTuZX63O3wbRHG1DLi34I?= =?us-ascii?Q?Qq6GPbl/5K+GyOrLhOhrth6k5/2sMHXaEDBV7X/KroV5IEMubkzSi1kp5/47?= =?us-ascii?Q?wa9wtRNyzCJRRpgwzV2dDwFsvdIeh7HrdenaKe7tK3UV32xVzm4T/ZRLDDWK?= =?us-ascii?Q?kJA5JjuxHm2IU+wLr+oYxN26l2F/8BIdyhiAvtariq2L2Tf5YG8zc6PTuQ0T?= =?us-ascii?Q?VHFalaZpB6r19uNMS0GK6tocnL8ihIwGjYCd20F49nBm0pBDRx/Mctwrus4D?= =?us-ascii?Q?7s/URoJwVv1+Sdnev+/YMWtYW/OFsZJ6eZvCI7nIkuRo6QKrqEWlzL8GadMG?= =?us-ascii?Q?F7actcTLoI36ZfF4Sw8ed+F4b9M/ohY8i9YrJfiSK6GF+0x+J9HGbBEIO6GP?= =?us-ascii?Q?fZtDX4sxs9St2VsPN+oAEZZ435Jyzv2gLPL4W0seHDFwDUtegx1NSAcdBS1U?= =?us-ascii?Q?1k770arv9Bd1fml/GWHSV03UYhBm19GoZZoRyfxG8hwgOpTD2u0ua4OSpfgy?= =?us-ascii?Q?eIUV8NU40y7wgiiHYV24nh+9pKyO9N91xVeI+GufrXFJgK4FmE+Y3oSM73UZ?= =?us-ascii?Q?JroJf+I/tm2we8V0hFJEXLaeaSdOKlaWjTMx30s8qqhb6euAWpW4T6Uuq+D4?= =?us-ascii?Q?V65lgpbFo4f2CYWZH40Zt8bL?=
X-OriginatorOrg: workonline.africa
X-MS-Exchange-CrossTenant-Network-Message-Id: c57ad1e6-126f-42ad-da54-08d8cf2d9e23
X-MS-Exchange-CrossTenant-AuthSource: DB8P190MB0746.EURP190.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Feb 2021 08:10:10.9868 (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: 3sWpuFuQnTuIscI5F9EpJxFpqZ7gHHD2OIcCsztMOxWVBgn9NHdqRpAi1q1y0RfK+/v6zwVBECfhjkd46VMXTA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P190MB0502
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/Rdr1h-HX_nuA70BeCOPhKoOUbTk>
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 08:10:19 -0000

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