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

["Jakob Heitz (jheitz)" <[e-mail]>]

In oix-full-snapshot-2020-10-11-1800 from routeviews, I see the as-path:
(1299 40065 3491 138995).
From https://asrank.caida.org/asns?asn=138995,
I see that 40065 is a provider for 138995, so
(1299 40065 138995) is possible.
Indeed, there is another route in the same file with just this AS-path.
The fact that 40065 used 3491 to reach 138995 rather than
its direct link is nobody's business but its own.

Now, if the relationship between 40065 and 138995 did not exist, then
I agree, (1299 40065 3491 138995) would be an unequivocal leak.

We need to differentiate between such "traffic engineering" leaks
and unequivocal leaks, else ASPA will cause a lot of collateral damage.

We must start slowly. Drop only what we are sure is bad.
Then carefully make it stronger.

Regards,
Jakob.

-----Original Message-----
From: Sidrops <[e-mail]> On Behalf Of Jared Mauch
Sent: Monday, December 14, 2020 11:55 PM
To: Jakob Heitz (jheitz) <jheitz=[e-mail]>
Cc: [e-mail]
Subject: Re: [Sidrops] ASPA: Is this really a leak?

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=[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops

_______________________________________________
Sidrops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sidrops