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

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Tue, 15 December 2020 22:10 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 536A83A033F for <sidrops@ietfa.amsl.com>; Tue, 15 Dec 2020 14:10:51 -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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=jGrg+mGn; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=D75c+o4t
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 Z4Fm47ShYr1f for <sidrops@ietfa.amsl.com>; Tue, 15 Dec 2020 14:10:49 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DB823A0365 for <sidrops@ietf.org>; Tue, 15 Dec 2020 14:10:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4324; q=dns/txt; s=iport; t=1608070249; x=1609279849; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=iV0AibE36J4S+C+RxvM4nLWsHl03MZHvX1CQI7t92bI=; b=jGrg+mGnMTRIvABPycKtIMKdWZ+ndwLTYoxeQc1dG62ZdIdGu3eAVfvJ LuQfjbRHdlY/y0Mjeg/GgK9JGfYMUn3AtpYpgN8XLAB7Nn/qgJsijVaqL 0H5tbB7kEV6Z1XzgdYF9rywdDyjcsXH//ibGXGpz3lw/Geb6w3e5FvVFa 4=;
X-IPAS-Result: A0AdBACuM9lfkJtdJa1iHQEBAQEJARIBBQUBQIFPgVIpKHxbLy6IBwONWgOZCoJTA1QLAQEBDQEBIwoCBAEBhEoCgXACJTgTAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQEBAQEBhjgMhXIBAQEBAgESKAYBASUGBQcBBAcEAgEIEQQBAQEeEDIdCAEBBA4FCAwOgjlLAYJVAw4gAQ6hagKBPIhpdIE0gwQBAQWBMwEDAgYBg2MYghADBoE4gnWKLyYbgUE/gRFDglY+gl0BAQIBFoFIg0iCLIISAlQbKB0mDgIWGCFHQARUGI9hqDAKgnSJI5JKgyaKJpRxnR6BdJYbAgQCBAUCDgEBBYFtIYFZcBWDJFAXAg2Je4QmDA4Jg06FFIVEdAI1AgYKAQEDCXyHDiyBPlwBAQ
IronPort-PHdr: 9a23:1HXfWx/uabJwb/9uRHGN82YQeigqvan1NQcJ650hzqhDabmn44+7ZhCN6fBkllSPXIjH5bRDkeWF+6zjWGlV55GHvThCdZFXTBYKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGFMP3fVaUo3Cu43gVABqsfQZwL/7+T4jVicn/3uuu+prVNgNPgjf1Yb57IBis6wvLscxDiop5IaF3wRzM8XY=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.78,422,1599523200"; d="scan'208";a="615019490"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Dec 2020 22:10:48 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 0BFMAmPq006570 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Dec 2020 22:10:48 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 15 Dec 2020 16:10:48 -0600
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 15 Dec 2020 17:10:47 -0500
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 15 Dec 2020 17:10:46 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WQOkvMkfxUZCmJgw466qF23f8x1o9DxCmEl2aTcVrzn5d8BzQTFU78eXj4xNRlHJGiKPLLFR8v6UZzgJ5aaWNlTRbemLquKGmMQ2d6EbGOq11X2K4X2s/6csRtjF9Cn/IvCbU8PTyQe8tqNmV/KMGCcdtHTRW/Y9+t8kgv2Vx2rhh6Lofa5Jor6RP/BsN5fqBzgciEis194sO1XMF0bKAIhSvMW2So8UNbBpvPiVvCEOCOSjn5kjYBjXvYdp5fqZ+lUP7eRi7pHYoaOl617zzZzOLtF1xJWmTy+i1KtaHd25zs5kGxrfVwH26BJPLlLtyNc8gVCgh3FXUXHroDLl4g==
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=iV0AibE36J4S+C+RxvM4nLWsHl03MZHvX1CQI7t92bI=; b=lJxpQofa6g6aJUrvJCYvJHLGIQncNKhOXKuES7RoraqL5rTu1YeprT7bsAu+RlQIPLRHPwVNlqcoPFNxD/W6xDxsjNr3qXwElhA+DK6/zGVtNe4v6vGn1bpsuH3SKPiGmjhxl2rfSkqewaVSq3X9opDPaIH9CrYGZIsEkTBAbDWwRX9nLC/TzGouLurCqdvkIa+WYJbxgVNSm6jUUlup1VyBo9HpWFZOZGj/T5oeJzVdAEfqioIS50eMhZnj4JDoEgs2CT5FcwQBd1+7iEMR/mkjlAXgpjum+zoL5IXdDqEWIZz1I+iUQmstp+gExR1ikoIxGhTXGpDcmPNs5l5Rfg==
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=iV0AibE36J4S+C+RxvM4nLWsHl03MZHvX1CQI7t92bI=; b=D75c+o4tvaWUnFT5MFu6RS7Px9NWYbmMmF3tKhOUsX53MaeJa5SN3hbadgQpCjrri80vC8Uz+VigcD3bVE6NdlPm4yapSXlI2VWwcTfnYeMEaCG0N18o24fkcYLjSBXZEE4KvWxnAsumFPwFpV8XcAfDw3ZTt7K0JBRJuFdHEV8=
Received: from BYAPR11MB3207.namprd11.prod.outlook.com (2603:10b6:a03:7c::14) by SJ0PR11MB5120.namprd11.prod.outlook.com (2603:10b6:a03:2d1::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.17; Tue, 15 Dec 2020 22:10:45 +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 22:10:45 +0000
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Ben Maddison <benm=40workonline.africa@dmarc.ietf.org>
CC: "sidrops@ietf.org" <sidrops@ietf.org>
Thread-Topic: [Sidrops] ASPA: Is this really a leak?
Thread-Index: AdbSrCwFetkGBNO+QeG28ivY3Q354wANKJOAABOAS7A=
Date: Tue, 15 Dec 2020 22:10:45 +0000
Message-ID: <BYAPR11MB32078EDE75F76EB2843A050EC0C60@BYAPR11MB3207.namprd11.prod.outlook.com>
References: <BYAPR11MB3207E12FA868D4ECCF064161C0C60@BYAPR11MB3207.namprd11.prod.outlook.com> <20201215125003.k4mnemxkmi2372rj@benm-laptop>
In-Reply-To: <20201215125003.k4mnemxkmi2372rj@benm-laptop>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; 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: c23b8a2c-0151-49c0-56f9-08d8a146455f
x-ms-traffictypediagnostic: SJ0PR11MB5120:
x-microsoft-antispam-prvs: <SJ0PR11MB5120B66E26685F783BB3EDE7C0C60@SJ0PR11MB5120.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: YEJxC4mJ8dyc1FhxrVMhzHNg6G1s+6Y1u588lvFiF1XX9RWFYFrrOZPIH1JH35a0qOB7u9GfMCia9dNHRdblYd6kaa8cpDTmvrStWkEwr9qnJaRQ1njInIkjhLXH1P5sfJJ+FLINq9lJA7p4e4HDBjWoR6Ewkcx5gcYNP/VrguB1YgwiET+yWFHfkHsGkpfctiaEGvRFPF3wS7SUlD63bfU9r9Li825U2qal4WzgAR4v2TjAE+q+QFPTYJwBqxQQnSHWXq3u5GrER4LWGMU9v0INlquvUBZzsrpqkUzINvddbSrrvRFlZJtk4xgktFW5cE1TQ8RiqTD+1E8f0N0GolfpKRFAxqy48pSQ3DTPsbFuJuJ6mejmnitr5Q1j365mNeDkke/f+RQOXyc3Xei/nw==
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)(39860400002)(396003)(366004)(346002)(376002)(966005)(55016002)(9686003)(6506007)(53546011)(4326008)(186003)(8676002)(478600001)(71200400001)(83380400001)(66574015)(76116006)(64756008)(66446008)(66476007)(316002)(2906002)(66556008)(7696005)(5660300002)(33656002)(66946007)(52536014)(8936002)(86362001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 5OOIHhJsszWiwJ55wNMDJ9FFco+s4izgIpjxGSm6+Y2o2kyT2x7UYYYylSd6QD89shkSzRef0aZ7T2J3MPO/6jPtkuDtVfNI4EGBlxwnwCJv3dXugwR4Mz2asfFZxU1h0DSzdz2WL+KFJ6D2zswk0X6C/MBFyktaP5ajVDbOAd5nT+cu0Iw77PSVTZ02SHkXFe4luRnfEtKHI27l+sXMY08ZW6u9N78t0ZvzGxiw9GcZ620lRHwn6sC1I4qSx9FeWI9xFZ/eUlF8Z9v/Rgbv0ATZOuXjlmjpBl7MtD1AI1LuB/XV3uEv6sxTiz7acLvrHUAm0lEIA54qMFpZanqDOwh1Pe9scFztRbpU5LoReDTkTVSc43nthc1z3Bf+HlUy++KkAPS1GYeImIMYGWRgC0eOE/ueuCB5A8ZnhzsgLT51WZo9pVsPBcOi47GTK0sik75h+ELhdgbPILE4VBYezq7kVKPp1zkoDVjSARW5xr48apijPQ98z0qg1aRmzF5J0Qhm+Wgpy/ezPKYwdR/0KFGoPEk2P1ASD9rWbNi8qbjxON7sGnOwB4Nxuqaa+sajH5mBCmMYido1YyG3X8sN9mUUaCGdMRDx8yAhF+KDrEz9P5L5nQJ64042O8Gmb0QAVgHoZmUdp5dkKJrGcVHyqQtosYzpb101KLVD+f0zkVOkt3rlySwY4bwrqlG86g0ShUplVkH3hmtKRb+gaAUTdX1xsb4mJjwUvGrmrrTKJrcybcZRTw5+NL4nKSJLpB5++bfyAir2moV3vtrnrnvJU2E9h0bupzsFNh80MNX8pEX5/FGolwoVe9xFm3F5eZlf4DtITdgQoEA3p0XruXlg8SXdS2skE4wNGwEd/EYRa/Y0CpwHZUL5oq979bQiNTfjRHjieP/4u69oYgOxLGS/FYgKY69dXfOyTcVUZ2uVy/1YRpYvPaoYWj9xU/hLNlHE6j2AahgXn1mtPX9IzlNeoNjz+fDYYDYAqzD+xtOAjxakWUdE2b82pd0eHiHp2h1GIcA7Wb9p4dTW1WPYcFz2SYN0RvSCOzwoGz4J8uUsgcI=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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: c23b8a2c-0151-49c0-56f9-08d8a146455f
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2020 22:10:45.6014 (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: p3XTzL2tERpUQMbn6hLJjvxzyPfCacZ8H5Ihym8oRo/AOW4vWvfCa2VDsQkiJIrG5XYDhtqzoj73DtMbH2j3dA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB5120
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/qd7gWaJ1MdBqWk6WXfZUeXvactY>
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 22:10:51 -0000

Ben,

Your scenario is possible.
However, it is only that: possible.
That makes it a suspected leak, not an unequivocal leak.
There are plenty of unequivocal leaks to stop.
Let's start with those and not bring down a lot
of unsubstantiated "suspected leaks".

Regards,
Jakob.

-----Original Message-----
From: Ben Maddison <benm=40workonline.africa@dmarc.ietf.org> 
Sent: Tuesday, December 15, 2020 4:50 AM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>
Cc: sidrops@ietf.org
Subject: Re: [Sidrops] ASPA: Is this really a leak?

Hi Jakob,

On 12/15, Jakob Heitz (jheitz) 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.
> [cid:image001.jpg@01D6D269.84D10C20]
> 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.

No. This is about as clear cut and obvious a leak as you could hope to
find!

33765 is a customer of both 3491 and 37100. It is learning paths from
the former, and advertising it to the later. If ASPA won't drop that on
the floor then it's basically useless.

> 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.
> 
I think this is a misunderstanding of the nature of the "authorisation" that
an ASPA object describes.
The question of whether an AS is authorized to carry traffic to a
particular destination is orthogonal to the question of whether a route
is being leaked.
The question is: when ASX advertises path P to ASY, does ASX authorise
ASY to propagate it to its non-customer peers.
In the above example, I'd expect that the answer is no (although, one
would need to get their hands on an ASPA signed by 3491 to be sure).

> 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.
> 
That would exclude some of the most common and harmful species of leaks.
We most often see these when an AS provides transit, but filter towards
their peers on based on prefix-lists (no community, as-path filters,
etc).
When (due to an outage, badly conceived traffic engineering, etc) they
select a route as best which is originated by a customer but learned
from a peer, the route matches their egress filters, resulting in a
leak.
These cause congestion in unexpected places, send traffic through
middleboxes that aren't configured for it, and generally cause hard to
troubleshoot pain and suffering. Usually with collateral damage
included.

Mitigating this kind of thing is right at the heart of what makes ASPA a
good idea. Let's not gut it please.

Cheers,

Ben