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

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

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 <[e-mail]> 
Sent: Wednesday, December 16, 2020 1:11 PM
To: Jakob Heitz (jheitz) <[e-mail]>
Cc: Jay Borkenhagen <[e-mail]>; [e-mail]
Subject: Re: [Sidrops] ASPA: Is this really a leak?

Hello Jakob,


On Wed, 16 Dec 2020 at 20:57, Jakob Heitz (jheitz)
<jheitz=[e-mail]> 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