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

[Ben Maddison <[e-mail]>]

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