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

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Thu, 17 December 2020 07:50 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 5CDF83A152C for <sidrops@ietfa.amsl.com>; Wed, 16 Dec 2020 23:50:00 -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=g6jqMqJe; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=R9ILUZaN
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 G5ydgTzaLuum for <sidrops@ietfa.amsl.com>; Wed, 16 Dec 2020 23:49:58 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 921EE3A152B for <sidrops@ietf.org>; Wed, 16 Dec 2020 23:49:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5482; q=dns/txt; s=iport; t=1608191398; x=1609400998; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hAf8bCjmk1oltLAXq2OFVrtP4CNkrE/8QRlKVbBBIhc=; b=g6jqMqJel1UpmtN2CgbcrE7eT49acJ+bXVDbRkC6iCXCSXO+8i0qoe8v V00+C9AlPxuHonKeGxOJt5Tp5VMQqF2kAc3GMlTzaJk8+Q2VdMJhKNyd0 G9LaTL0o3rb8vap5qpwtjIWFwwBsedTvwKsdeAxV4AvtOp9L4BZHMD+EG w=;
IronPort-PHdr: =?us-ascii?q?9a23=3A4dfkOR0qywYQj4pPsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWGvadpkEXIG4jGuLpIiOvT5qbnX2FIoZOMq2sLf5EEUR?= =?us-ascii?q?gZwd4XkAotDI/gawX7IffmYjZ8EJFEU1lorHWnK0kTFdutL1HXq2e5uDgVHB?= =?us-ascii?q?i3PAFpJ+PzT4jVicn/1+2795DJJQtSgz/oarJpJxLwpgLU5cQ=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BxAAA9Ddtf/49dJa1iGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAUCBPgMBAQELAYFRUQeBUC8uhD+DSAONXQOBBZgHglM?= =?us-ascii?q?DVAsBAQENAQEtAgQBAYRKAheBWQIlNwYOAgMBAQsBAQUBAQECAQYEcYVhDIV?= =?us-ascii?q?yAQEBAQIBEhEEDQwBATcBBAcEAgEIEQQBAQECAiYCAgIwFQgIAQEEDgUIGoV?= =?us-ascii?q?aAw4gAaMTAoE8iGl2fzODBAEBBYUwGIIQCYEOKgGCdIJqTkKGNiYbgUE/gRF?= =?us-ascii?q?DgiE1PoJdBIE/IIMVM4IsgWkpNS4OAWIIIw4NVhIpKQFfkwKlDQqCdJAWi1e?= =?us-ascii?q?iPbBbhFMCBAIEBQIOAQEFgWwkgVdwFTuCaVAXAg2OIYNxilh0AjUCBgoBAQM?= =?us-ascii?q?JfIZqAiYEA4E4XwEB?=
X-IronPort-AV: E=Sophos;i="5.78,426,1599523200"; d="scan'208";a="844374967"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Dec 2020 07:49:57 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 0BH7nvpP016387 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 17 Dec 2020 07:49:57 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 17 Dec 2020 01:49:57 -0600
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 17 Dec 2020 02:49:55 -0500
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 17 Dec 2020 01:49:55 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dFXqe/TUBbBrXHmH+fvKey/fkE6oaGqE8O9cckUHk9IdrbLP/j7eXeqmqo1xDuLDQfcHDWlCffXO+kSm/DmLN+rK3ZPf5NGh0ZVztk3pmfg4sFxkAoMetsMcfZ+xbED7I8lM37k2YpXSTUJP180cX7mcjSs/k9oxLCBpKaloPKpjYaFN21s0UIW6MoP3Ex4YPzP6WQABw+NmKLwJZhZnD72OmPkDfg4uX02bBE4Q4Mmw6YYLTM1LsfWYNWsN3VzWVGk68CGEmY4YL+pDZiCXudHQoi5U7REEbrycIq+6S11Sy4Czk/99pjvr0wG+ONaNWumbiJ2cJY1YM0aRBdRCyA==
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=hAf8bCjmk1oltLAXq2OFVrtP4CNkrE/8QRlKVbBBIhc=; b=UA5FWl1A9jbV9yt2EaFxleUih5QZ9dmXYhu48HcFq5mt39FlNtunkL+ra7rTiYYa15j2F+HQeo4eb4q7rRNP1PG9Kk2mixKuq2sdLcmZkYeGH33zOtOvGSSWF4RVnCIniVd0Rit20EOzWTNmhiJU8MV6OgRTDviTRNdkOUp6UFK/GCHHpR6dJKb/rgH0DhPfBh02KSRScmQ9ESOdsyNDNvKDNTdgSLeEHSxNvYdxjz8E+r7rtkMyiNc8urQfQe1NV0qmtaim4+2TRye/Sso1mNMC9vAHHjOcE2iYkD/pLGNRH8FFuoM8zO7qYI4o/TPrqj3ym3k/vSqP12NHOb8PKQ==
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=hAf8bCjmk1oltLAXq2OFVrtP4CNkrE/8QRlKVbBBIhc=; b=R9ILUZaN9ASgxG1nEHvdZvapsNKNoCNwIVTKGYU4l8qs5+P0ymJ0lAANrUpvZeVCQcmQIKeF3Q12cfJ4mTzYAS3JpM2AyDp3CVFJR8VlgQmZjYJWKXOaePgsHehuP1NTm1ystZxTLkWdBUGpzOjKACQsp0CxMq5ptwMOVPFnhlE=
Received: from BYAPR11MB3207.namprd11.prod.outlook.com (2603:10b6:a03:7c::14) by BYAPR11MB3335.namprd11.prod.outlook.com (2603:10b6:a03:1d::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.19; Thu, 17 Dec 2020 07:49:53 +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; Thu, 17 Dec 2020 07:49:53 +0000
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Lukas Tribus <lukas@ltri.eu>
CC: "sidrops@ietf.org" <sidrops@ietf.org>
Thread-Topic: [Sidrops] ASPA: Is this really a leak?
Thread-Index: AdbSrCwFetkGBNO+QeG28ivY3Q354wBHfvcAAASgXmAABNPhAAAWKsvg
Date: Thu, 17 Dec 2020 07:49:53 +0000
Message-ID: <BYAPR11MB3207C21FE8283774AA23DC15C0C40@BYAPR11MB3207.namprd11.prod.outlook.com>
References: <BYAPR11MB3207E12FA868D4ECCF064161C0C60@BYAPR11MB3207.namprd11.prod.outlook.com> <24538.14458.724169.315853@oz.mt.att.com> <BYAPR11MB32070C5D14ED8CF368D05785C0C50@BYAPR11MB3207.namprd11.prod.outlook.com> <CACC_My8syKeHaB8DERPAhYfyPz5hJDw8PtJrPSfrgd=mox1m0g@mail.gmail.com>
In-Reply-To: <CACC_My8syKeHaB8DERPAhYfyPz5hJDw8PtJrPSfrgd=mox1m0g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ltri.eu; dkim=none (message not signed) header.d=none;ltri.eu; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2601:647:5701:46e0:e82d:ab03:2132:19e4]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6f4df225-c0bb-4fc7-dfe6-08d8a26056f3
x-ms-traffictypediagnostic: BYAPR11MB3335:
x-microsoft-antispam-prvs: <BYAPR11MB3335C3F8271103517FD566EBC0C40@BYAPR11MB3335.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: FCDTr+wxIUidipsy3ml1AddI4KCg+W0UkvynOmVr4uTny2dzY8Ugv0vNRRQIGtfDUsc14iMeZplgDpImg7b9HHarLp39eVqF+0Ghs1Ts5xpIM5hNKRNrooPArXnEy67mrcoCrnJhA1N/9kJBX5Hlt/zcjsN7QQ6bj346yRK8YuoqJOk9Pkn3OJhur+ETbixAwUy9yjywcnay5gPdEwvhregpTcaq/7S9cyvalXfr3IsBKtQTc/tCZVcWxICHXBFQLonnVBE8vnza7RdoCNE9EF+OYtUoHcPNIRHC8lw7HUihNkkViNWZiP23CO5CSI9e
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:(376002)(39860400002)(396003)(366004)(136003)(346002)(4326008)(66556008)(186003)(52536014)(316002)(478600001)(6506007)(86362001)(5660300002)(66946007)(66446008)(2906002)(64756008)(33656002)(7696005)(83380400001)(8936002)(66476007)(9686003)(8676002)(66574015)(6916009)(53546011)(55016002)(71200400001)(76116006); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?dHNCSTUwTkk3STF4WUlJMWZnbDBWTCtwRkpEZnNmS2V3L1pVT0RDTER2Rndh?= =?utf-8?B?WEZVN0lWVHJHV2YwWTJ0K0hwSnN2azZWc0FXRVUyTWJUOTE0M1VCZVhwOVFS?= =?utf-8?B?NEhrMjRmemFONjc3M2svZnRCWjhaM3hPamtRRklUelFnTmtYRGwrOHlBUG9K?= =?utf-8?B?NFJmV2VHOHBFMHREMlBkeDBOSEJjeFZJcVFNVEtPOVpGL05vY2lUNXhCRGZ6?= =?utf-8?B?ZjhBT2l2NU5hWHZIQXVpWU5DQjdyaXBXbXFCTFVFZ3N4RnUzQ3hBckVoRVI0?= =?utf-8?B?WDVFMFRQOUl3Q3ZQMm5pYllzZWpOMGxqYUxoWUw2NmoweG5KMkRiM1cxQUJ6?= =?utf-8?B?VFJta01na2VGMmthNHRkU1J3WUVCN2FoNEhlOUNrRVFMMUtiYnU3RllDYTNu?= =?utf-8?B?YmxqVGJvcXprNzZ6bU9MWnZVSWQ4ajhENnliZ2VBcThPNEhodGtad0pjSmIx?= =?utf-8?B?ZWxKV3QyMHZ4ZTlpUHROMnBFZi82YlA0aHgrbzByM1M2dHlSZVh6dGFpSTQy?= =?utf-8?B?TGxoZDkxQmdVVkJrM1AzM0ZmL2NORlBFR0xvL1dqOHFnSGtDTG1UeENHZHRV?= =?utf-8?B?TXNKbE9kUTBzWTFBcTBEZHpFMVNFOHM2cGFYZ3VPWmdQdkQ1MjBJdlFHZnBO?= =?utf-8?B?WVVPWHFMS2ZNd0pTcEhRcHlqRUJnd3ROQ1RsSmRhK1JXWkJrUXo0dkxPejR5?= =?utf-8?B?aHVaQ2FqakdTWEFmdXFVbkJIODI5UzVmNElzTi9IMFRONlRYM0Y4NW5JcjF5?= =?utf-8?B?U2U5MXk3T2IvRkhQdkFuZG5XaWpaVkdKQUc0eDNSSTdVREVFdlBzVGMzUGVv?= =?utf-8?B?OE0zR0ZMTEcwRTFtV253Zys1Qm84OWVvdEJhNko2eWpmVmJyUFp5K0lWTTRR?= =?utf-8?B?T3RmUndpcndMK2djNEdua0JvSDFqS2tMSSsyM0N5MUxPamQwU1hjZ1hjV292?= =?utf-8?B?VHhwUCttVE5rUThmSHY5aDYza0VWZDhJOEIyM3NSR0oyN1dLME1CQ0RLaTJZ?= =?utf-8?B?U2IzSGdEVCtQTnJ2MVl1NDBzdmZ1TEdxYWRYUmNTbjdRQUQ4RUI2cVdDRjFa?= =?utf-8?B?Q1ZXR09xd1lWNWNiZzZLZGd5UjRkMEttd0c4Mkd6UU1ubDU5M3g2N09sajlM?= =?utf-8?B?QXF2QWdjczZ1MlNIMTVjak1kd29OS3BRSVlqOVEzRjBIZkFEMjdFK3I2TUZK?= =?utf-8?B?QWR3Z056MEh5NGRkKzlOMzMzYnFOK3dTYXlDcVhzQTVRc2lSWDEzc2Rta0Zy?= =?utf-8?B?cktvUDlwanNod2RsRzc0NjcwK3llMUxZT2JzY0cwREVaTnBnbnpkeTJ2bHl4?= =?utf-8?B?WVJQYUIvSXQ4SEtvS3Q0aGhSbjZ3WG11YVZXY0thWEVZdGtubm9mZ2JocEJK?= =?utf-8?Q?yNR/tj5GJ+TAMSKmOkEiSOguJahY5HRM=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: 6f4df225-c0bb-4fc7-dfe6-08d8a26056f3
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2020 07:49:53.1398 (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: 45NpSzd5tEkMQj8p2WhzOed801+txeorvv/H1bic8XxMPPBO6+nLv8NpBuxX+2xs+xPSIwtS3VF6KxsB7NEFzw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3335
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/lomPumSawAAz2SnAQVza-cuBK4c>
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: Thu, 17 Dec 2020 07:50:00 -0000

Thanks Lukas. Good explanation.

So, if AS20 were to allow this, would it list AS2 as a provider in its ASPA record?

Regards,
Jakob.

-----Original Message-----
From: Lukas Tribus <lukas@ltri.eu> 
Sent: Wednesday, December 16, 2020 1:11 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>
Cc: Jay Borkenhagen <jayb@braeburn.org>rg>; sidrops@ietf.org
Subject: Re: [Sidrops] ASPA: Is this really a leak?

Hello Jakob,


On Wed, 16 Dec 2020 at 20:57, Jakob Heitz (jheitz)
<jheitz=40cisco.com@dmarc.ietf.org> wrote:
>
> Jay,
>
> I disagree that the algorithm in ASPA rejects routes whose AS_PATHs are
> contra-indicated by the expressed wishes of the AS resource-holders,
> as communicated by the set of validated ASPA records.
>
> I posit that it rejects more than that.
>
> Suppose AS1 has providers AS2 and AS20.
> AS20 is also a provider for AS2.
>
> What I am proposing is that AS2 should be allowed to divert traffic
> that it received from the Internet through AS20 on its way to AS1.
> Internet --> AS2 --> AS20 --> AS1.
> The algorithm stated in ASPA prevents that.
>
> Nobody is breaking any laws or contracts by doing that.

I disagree. AS2 is breaking the contract which is that it won't
announce my routes to non-customers peers. The fact that we are
talking about AS1 originated routes which is a customer of both AS20
and AS2 doesn't change that.

AS20 AS1 is an as-path that AS2 must not announce to non-customers,
unless specifically authorized by AS20. AS2 doesn't get to share AS20
routes, whether the origin-as AS1 is a common customer or not.

AS20 must decide whether this is acceptable or not. Not AS2 and not AS1.


> Nobody is seeing any traffic that they are not permitted to by doing that.

I disagree. If I'm AS20 and my customer AS2 shares prefixes with
non-customers without authorization, I will order AS2 (my customer) to
stop. I don't care if those routes are AS1 originated.

What if AS2 has insufficient capacity to deal with the traffic? AS20
has SLAs with AS1, but if AS2 suddenly thinks it has to be a transit
provider for AS20->AS1, then AS20 can no longer guarantee those SLA's,
because suddenly AS2 will pick up the traffic.

What if AS1 specifically disconnects AS2 to route around temporary
technical issues in the AS2 network? Now AS2 is still involved,
despite best efforts of both AS1 and AS20 to not traverse it.


This is an unauthorized announcement (unless AS20 says otherwise), and
a nightmare with real technical and contractual consequences. If my
customer AS2 insists on doing this, actively impeding my ability to
guarantee SLA's to AS1, then I will disconnect AS2. You can bet that I
will have the legal/contractual power to do so.


> This kind of diversion happens frequently on the internet and
> ASPA should not prevent it.

It happens frequently by mistake because of the use of static prefixes
list instead of BGP communities. It also causes damage. If this basic
and common leak is not something that ASPA prevents, then I'm afraid a
lot of network operators won't even bother with ASPA.


> The big difference is that AS2 is a provider for AS1.

Your opinion is that this changes something. I'm saying it doesn't
change anything at all.

The example you provided causes a number of issues for all 3 parties
involved. Nobody wants this:

AS1 doesn't want this, because it cannot reroute around technical
problems in AS2 by disconnecting it. It is multihomed for a reason.
AS2 doesn't want this, because it would just give AS20 free transit
and overload it's own network with traffic that is not generating
revenue (but may happen erroneously due to static prefix list).
AS20 doesn't want this, because it will be unable to guarantee SLA's
to AS1 when an unauthorized transit provider is involved.

If this is something that both AS2 and AS20 agree on, then the proper
authorizations will be in place and all is good anyway.




- regards,
lukas