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

Jared Mauch <> Tue, 15 December 2020 07:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D5423A0D6F for <>; Mon, 14 Dec 2020 23:55:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.002
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e3gwy-rmBKKK for <>; Mon, 14 Dec 2020 23:55:20 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2FDB53A0E65 for <>; Mon, 14 Dec 2020 23:55:20 -0800 (PST)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (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.\))
From: Jared Mauch <>
In-Reply-To: <>
Date: Tue, 15 Dec 2020 02:55:15 -0500
Cc: "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: "Jakob Heitz (jheitz)" <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [Sidrops] ASPA: Is this really a leak?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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) <> wrote:
> 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.
> 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
> 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