Re: [Sidrops] ASPA: Is this really a leak?

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Tue, 15 December 2020 21: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 46D203A0062 for <sidrops@ietfa.amsl.com>; Tue, 15 Dec 2020 13:48:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=cr0shwa0; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=DKZj3NeV
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 7uzXwwFQJ8RH for <sidrops@ietfa.amsl.com>; Tue, 15 Dec 2020 13:48:25 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BAF33A07EA for <sidrops@ietf.org>; Tue, 15 Dec 2020 13:48:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5186; q=dns/txt; s=iport; t=1608068898; x=1609278498; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TRtozaIBG8B9fQta9LNTYchLCadL67Et2vqvymvClGw=; b=cr0shwa0Pt+6klhEOvHhgpwbQ9yQmciKvi5gaBKSgQqPuARU+HE9l5dC k5OL/ONMGnNfeNGaIvVgvkWc15NEX3SrhedZTNl4cSQsIWC44ZeIpXHDR TgeU13mSabYyvV3lNEi22s1iudFsq6SEam4gtA3CUXW3APUcvUnL2Icvq Q=;
X-IPAS-Result: =?us-ascii?q?A0AjAgDqLdlf/4cNJK1iGwEBAQEBAQEBBQEBARIBAQEDA?= =?us-ascii?q?wEBAUCBT4FSKSgHdVsvLoQ/g0gDjVoDmQqCUwNUCwEBAQ0BARgLCgIEAQGEB?= =?us-ascii?q?kQCF4FZAiU4EwIDAQEBAwIDAQEBAQUBAQECAQYEcYVhDIVyAQEBAQIBAQEQE?= =?us-ascii?q?QQNDAEBJQcEBwEEBwQCAQgRBAEBAQICJgICAiULFQgIAQEEDgUIGoI5TIJVA?= =?us-ascii?q?w4gAQ6hZwKBPIhpdn8zgwQBAQWBMwEDAgYBg10YghADBoEOKoJ1g3mGNiYbg?= =?us-ascii?q?UE/gRFDglY+gl0BAQIBFoFIFYMAM4IsgWkpAm8ZDx0KKgIWOQs8QHCPYYMjp?= =?us-ascii?q?Q0KgnSJI5JKoj2dHoF0lhsCBAIEBQIOAQEFgW0jgVdwFTuCaVAXAg2Je4QmD?= =?us-ascii?q?BeDToUUhUR0AjUCBgEJAQEDCXyHDiyBPlwBAQ?=
IronPort-PHdr: =?us-ascii?q?9a23=3AB17Y1B0lp7YwiJ+LsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWFu6d1kVTKG4PW9/JJkazQvryzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutf0DZoTu04CISFw?= =?us-ascii?q?+5Mwdpdaz5H4fIhJGx0Oa/s5TYfwRPgm+7ZrV/ZBW7pAncrI8Ym4xnf60w0R?= =?us-ascii?q?DO5HBPfrdb?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.78,422,1599523200"; d="scan'208";a="610236215"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Dec 2020 21:48:17 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 0BFLmHNg011312 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Dec 2020 21:48:17 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 15 Dec 2020 15:48:16 -0600
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 15 Dec 2020 15:48:16 -0600
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 15 Dec 2020 16:48:16 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SF5RKt+9BQzCoK/l1rP+T9DO42bZzp7IbZTAb6RBSegyUOZiWKt9uMyE1w60UaSt4EIw/yG57bT3y2RZTEEDGXpUDc6NtIrE5t5un0+iR7H5rKJXRGmzfshgUgbpSKwBidfeKPnpTgAZQNmehunl1JWFZJzLXw+dx6G3UuLKzg1ecZsp2sD9kEq1Cypz206XfKLwxk69VIq+80kOo+0zmSazJM/kPbaFvfpicMchDEgPT1NiQKI5AwzLtaRe2oV3ASWX94iELguvUxqBQ/BbwmH7k43KhVTCTDXLxbYJrC1lz6pa6ETLvpGMvj45gFbRoJi8SD40FcGvI1EMTeTSjg==
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=TRtozaIBG8B9fQta9LNTYchLCadL67Et2vqvymvClGw=; b=M3jajI216CfdgJxGKat1MejPyWeVrJItB7EZ6rrCUGlZflaqA84fxhpJuNHe5GYFWeUOs8Qaf75kRxgMBVknStevdKiKoV/oekbV+HXOBriYKsl5Omxst99174NDs5mcq/sVwf54RH1VmFQQpTLS6WUq+nVPkjNyIszp8bQAkjpPriUKO95z1w/VQK/rCHrRYe/qslUo9cpLKPEivxdKgGwRI+t/S5jKdJx8dV80+zgT3nXfR4+I7uWnsUrIgi7X2B0nv1QgB3+0rqlAY5eLdx62FZPGNOGD4I8V3tI69rQMBI7HYzBk0f+1g4VMqh2+X16oXI8yYTYM4ogI/JDJcQ==
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=TRtozaIBG8B9fQta9LNTYchLCadL67Et2vqvymvClGw=; b=DKZj3NeVhGtdO0DYRW0QZezkNwUdpHttJKhaDQy5ZIUIHjtZ5ZLXuHXY/pdpFjUaM4LpOdyAz+C9uK/5ZfNUzQj4I6427+djM6ZVpg5B1s78DmMN+EeVcgK7EI2Ov77kGEzd54GfXZotAs3dd1hKko2drKMyL6T/h6fA4H5cOmk=
Received: from BYAPR11MB3207.namprd11.prod.outlook.com (2603:10b6:a03:7c::14) by BYAPR11MB3574.namprd11.prod.outlook.com (2603:10b6:a03:b1::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.15; Tue, 15 Dec 2020 21:48:15 +0000
Received: from BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::2581:444d:50af:1701]) by BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::2581:444d:50af:1701%4]) with mapi id 15.20.3654.025; Tue, 15 Dec 2020 21:48:15 +0000
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Jared Mauch <jared@puck.nether.net>
CC: "sidrops@ietf.org" <sidrops@ietf.org>
Thread-Topic: [Sidrops] ASPA: Is this really a leak?
Thread-Index: AdbSrCwFetkGBNO+QeG28ivY3Q354wAC3NuAABpy6DA=
Date: Tue, 15 Dec 2020 21:48:15 +0000
Message-ID: <BYAPR11MB32071EE2F6B774D306555457C0C60@BYAPR11MB3207.namprd11.prod.outlook.com>
References: <BYAPR11MB3207E12FA868D4ECCF064161C0C60@BYAPR11MB3207.namprd11.prod.outlook.com> <C94D8684-F95E-49B7-BD15-3B3E8EA6710B@puck.nether.net>
In-Reply-To: <C94D8684-F95E-49B7-BD15-3B3E8EA6710B@puck.nether.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: puck.nether.net; dkim=none (message not signed) header.d=none;puck.nether.net; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2601:647:5701:46e0:45ca:9d3c:5636:a4db]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7aead971-b641-4d38-ad93-08d8a143208a
x-ms-traffictypediagnostic: BYAPR11MB3574:
x-microsoft-antispam-prvs: <BYAPR11MB357424EF7D48CFA3C9D770EAC0C60@BYAPR11MB3574.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: /O7yeSb8bH8YUpCny+DWl1Wp2VFdf8z94PSfkrwKw+QKFlR72c4Xw3eRUbep6N9e+r1jgPnswqvGPKxWVfGe9bDDrBsAbfgaGiJg8o4vD1RLOBsVogJ7ulTT56W+3y40xW9cAr4BIBoKExhqvttUV2+hHsuOzqCUZJwgTS0pNwS1bb/r9OqsAq3dppvCVjyev7ChDTG8Fuhfd5XQeNmWkEJKTycVsuQCyBJII4L1QrChodOExWiEs+8ezbh31SzUkRf9Zmw1ZBY1ZsDLSSkVuirNSlgxF2t88zko92NxfL/AIABKRoCY3OeX8XbCmNW+MFihcAOxHwapoRgH5hidaSxYBvV6aLyZWlMF8a/sh8bMFogrdYBLGz4D7d0TH72luVBG71GokX/vIIiCThzY1g==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3207.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(366004)(376002)(346002)(6506007)(53546011)(66446008)(66556008)(66476007)(6916009)(8936002)(64756008)(33656002)(76116006)(8676002)(966005)(52536014)(5660300002)(9686003)(4326008)(4001150100001)(66574015)(508600001)(2906002)(86362001)(71200400001)(66946007)(186003)(83380400001)(7696005)(55016002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?c2g4YVNtWFlpT2V1eTNybHhYLzVvM3R4YmMzanpiVFI4OFNUYlBoS21EMVEr?= =?utf-8?B?eWVKdGZWZFUyRS82OTdNU0hLTzJIZEl1Z3pIdGc1SjRobGw4VlpFUEJ1c2Fr?= =?utf-8?B?Z3dmMk9abzhHTmhjREJMMDdrYWlPSXpXUFo1dU1QQ2xEcjY3bnp5Q0ZYd090?= =?utf-8?B?eUlUd09BcDYvNEViR3RtaklsNlhKWjZOdUpwOXl4bXA3U1dxRUs1Y1NSYm1E?= =?utf-8?B?bVRvVGVHY010VlRTUU5IbVFuU0dZNXorN3BEU0l5Vzl4R2o2M0E5aG8vRUJ3?= =?utf-8?B?SFpaQzNkelFuSXdLTUxFWFA4cmhrSFQ1MkNiMkxFYmFsUStxRk1sNk5EUnRF?= =?utf-8?B?K0ttUDBnZHNRZ2QwZ0pvR056L0pKNkl0N1dBbGpORlpCMVpiaExDdVI4bEdO?= =?utf-8?B?YU12cXN1MExYWTNpUGlpOENpN01aSGsxclcwbENkZXNyOE9xOHZ2Y1pLYjh5?= =?utf-8?B?SHI1Z0RXcDdtN0dqck8yRGNTWGFyeVZOVEZYYnFvZmZ4a1FZT2lkMHRlYmpM?= =?utf-8?B?NWh2NTIwY08veXlkcG5WeUxMSXNBWitMUFkvUTczZU9DRDVpSjhzdmRFZDli?= =?utf-8?B?RkZvQmR0VkxRSlJmTjZERnViRm1md3g2REtlR1BzOERlUEVBZVp4WGhHT1cw?= =?utf-8?B?N3V6M3R5MXMvTFNMZFRjakQ4VzNVLzQyWDlpR09PWE9OYStIcDY2REhTWmNP?= =?utf-8?B?Ym5Ca1RndlBzTjZlUkpEM3dsSnlUQkMxNTZhMlJrUjJjNWNWOGUwOEdTUFZR?= =?utf-8?B?Tmx1LzdDM3pSWjl2VUJCT1NqWUZFVElDNnN6c1dXT0w5b1UxTTBLZ3NKVU1u?= =?utf-8?B?cmMwanZtMGROZWhNbFRBZXE4UlhYSW9WaW5WM3REVEJqdHdxekF1Y3gydW5a?= =?utf-8?B?UW1FSTRtbUhkaGo5MENKS2J5a2c1M0srV0FjT2lqZ205dS9FYmMwRG80UFdF?= =?utf-8?B?SklJVjc4VE1GOEM4ZnlDQkU3dWQ4MEcrUVB3VkJUUWRvQlpVeVo2V0tiSXA0?= =?utf-8?B?Yk9JVWpZdE45UGdRMkVpRjhmVXE3T213WE9HQW13TWJRQVRLekNYeUpBMVhN?= =?utf-8?B?ZHcrWjdGMGdCRzErcGY3Um9CU2g2aEkxUnp1cjRhcHA5Q1NHeTU0TG1ZU2tr?= =?utf-8?B?TEhyQ0plaXovZlpmM3p1UGt5YThCZlBKU3RIYkdpK01vUElVWDhKR0RvTm0z?= =?utf-8?B?VHJNOGFhZmRFU1ZKdFNCQSt4T3AzcmFKeXJtK1pGTTRSZHhsaVEzRW5PTnZn?= =?utf-8?B?dFhxMTNTQUtRSGtFQ3RiTFU3b1ZHMnVZVGRkRGROUHAraVRPZktzV3JFUDlm?= =?utf-8?B?ZFd4V3RrK1ZrZElBbFpJazdLdXF3WmlSYzdxMk5kaUFnTTBGMzNvY0dEQVUy?= =?utf-8?Q?4Mr6+akcE1SElf15+tavzmF4MrbhSvyQ=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3207.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7aead971-b641-4d38-ad93-08d8a143208a
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2020 21:48:15.2675 (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: nnx1Izy0cK65pxH4qLzPx27Xvm0YnTGKed4geyYKMwG9BW1dxroVlDgYdROi+TShLILgwr27WtVkn2k9PIcjew==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3574
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com
X-Outbound-Node: alln-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/Pq4TJzqcC7R0Uaq8gwcAGJV8pr4>
Subject: Re: [Sidrops] ASPA: Is this really a leak?
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: Tue, 15 Dec 2020 21:48:31 -0000

In oix-full-snapshot-2020-10-11-1800 from routeviews, I see the as-path:
(1299 40065 3491 138995).
From https://asrank.caida.org/asns?asn=138995,
I see that 40065 is a provider for 138995, so
(1299 40065 138995) is possible.
Indeed, there is another route in the same file with just this AS-path.
The fact that 40065 used 3491 to reach 138995 rather than
its direct link is nobody's business but its own.

Now, if the relationship between 40065 and 138995 did not exist, then
I agree, (1299 40065 3491 138995) would be an unequivocal leak.

We need to differentiate between such "traffic engineering" leaks
and unequivocal leaks, else ASPA will cause a lot of collateral damage.

We must start slowly. Drop only what we are sure is bad.
Then carefully make it stronger.

Regards,
Jakob.

-----Original Message-----
From: Sidrops <sidrops-bounces@ietf.org> On Behalf Of Jared Mauch
Sent: Monday, December 14, 2020 11:55 PM
To: Jakob Heitz (jheitz) <jheitz=40cisco.com@dmarc.ietf.org>
Cc: sidrops@ietf.org
Subject: Re: [Sidrops] ASPA: Is this really a leak?

I can tell you by looking that it’s a leak (or poison) due to the AS_PATH as 1299 <-> 3491 should be adjacent 

If you go to route-views, you can see plenty of routes with _1299_3491_

- Jared

> On Dec 15, 2020, at 1:45 AM, Jakob Heitz (jheitz) <jheitz=40cisco.com@dmarc.ietf.org> wrote:
> 
> https://tools.ietf.org/html/draft-ietf-sidrops-aspa-verification-06
> finds suspected leaky AS paths.
> However, not all routes with suspected leaky AS-PATHs should be automatically dropped,
> because some of them may not be unequivocal leaks.
> A BGP monitoring service should provide alerts to all suspected leaks.
> However, a router should automatically drop only unequivocal leaks.
>  
> https://bgpstream.com/event/258771 is listed as a leak.
> <image001.jpg>
> The as-path is the red line.
> The black line is a customer-provider relationship that exists between
> 37545 and 33765 as can be seen at https://asrank.caida.org/asns?asn=33765.
> Therefore, 33756 is an authorized carrier of traffic for 37545 and
> ought to not be called out as a leaker.
> The route may not have taken the black line because of a temporary
> failure of that link. An apparently leaky detour should be allowed
> for a temporary failure as long as all the ASes involved are in the
> provider cone of either the source AS or the destination AS.
> All ASes in the provider cone of an AS are either directly or indirectly
> authorized to carry traffic for that AS.
>  
> This is just one example. It's easy to find more.
>  
> ASPA should add a section that defines an unequivocal leak, such that
> a BGP router can optionally drop only unequivocal leaks.
>  
> The definition of an unequivocal leak is based on the provider cone.
> The provider cone of an AS consists of all the providers of that AS and
> all the providers of those providers and so on.
>  
> All providers in the provider cone of either the originator or the receiver
> of the route are permitted (contracted, actually) to carry the traffic for the
> route between these two ASes. Therefore, the AS-path is only invalid if it
> contains any ASes not within these provider cones. If valleys exist in the
> AS-path, but these valleys are entirely within these provider cones, then
> all the ASes in the AS-path are still permitted to carry the traffic and the
> route should be declared valid.
>  
>  
> Regards,
> Jakob.
>  
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops

_______________________________________________
Sidrops mailing list
Sidrops@ietf.org
https://www.ietf.org/mailman/listinfo/sidrops