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

Jared Mauch <jared@puck.nether.net> Tue, 15 December 2020 07:55 UTC

Return-Path: <jared@puck.nether.net>
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 8D5423A0D6F for <sidrops@ietfa.amsl.com>; Mon, 14 Dec 2020 23:55:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 e3gwy-rmBKKK for <sidrops@ietfa.amsl.com>; Mon, 14 Dec 2020 23:55:20 -0800 (PST)
Received: from puck.nether.net (puck.nether.net [204.42.254.5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FDB53A0E65 for <sidrops@ietf.org>; Mon, 14 Dec 2020 23:55:20 -0800 (PST)
Received: from [10.0.0.129] (unknown [23.138.112.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id BD07D540129; Tue, 15 Dec 2020 02:55:15 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\))
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <BYAPR11MB3207E12FA868D4ECCF064161C0C60@BYAPR11MB3207.namprd11.prod.outlook.com>
Date: Tue, 15 Dec 2020 02:55:15 -0500
Cc: "sidrops@ietf.org" <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C94D8684-F95E-49B7-BD15-3B3E8EA6710B@puck.nether.net>
References: <BYAPR11MB3207E12FA868D4ECCF064161C0C60@BYAPR11MB3207.namprd11.prod.outlook.com>
To: "Jakob Heitz (jheitz)" <jheitz=40cisco.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3654.40.0.2.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/dpsxEBy8Pid0ZEGZgXcfRe7SAIQ>
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 07:55:22 -0000

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