Subject: [Sidrops] ASPA false leak

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 15 Oct 2019 23:45:00 +0000

Consider the topology:

   AS5      AS3
     \     /   \
      \   /     \
       AS4     AS2
         \     /
          \   /
           AS1

AS1 has providers AS2 and AS4.
AS2 has provider  AS3.
AS4 has providers AS3 and AS5.

AS5 receives a route with AS-path (4 3 2 1).
ASPA would declare that AS4 leaked the route from AS3 to AS5.
However, AS4 is an authorized provider for AS1.
Even though AS4 has a path to AS1, it chose to use an alternative
valid path to reach AS1. This might be to relieve congestion or to
avoid an outage. Regardless of the reason, I don't think this
route should be rejected.

I think we need an additional rule:
If an AS is found to be leaking a route, but an alternative valid
path can be found from that AS to the originator AS, then the AS
is not leaking. A path (X(1), ..., X(n)) is a valid alternative
if for each X(i), X(i+1) attests that X(i) is its provider.

Thoughts?

Regards,
Jakob.

---

From: Randy Bush <[email-masked]>
Date: Wed, 16 Oct 2019 03:45:44 +0200

> valid path to reach AS1.

and that alternate path sure looks a lot like a route leak.

randy

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 16 Oct 2019 03:31:57 +0000

The actual path is (5 4 3 2 1). Technically a leak.
However, all transited ASes are authorized, therefore it should be allowed.
The alternative is (5 4 1). Not a leak.

Regards,
Jakob.

-----Original Message-----
From: Sidrops <[email-masked]> On Behalf Of Randy Bush
Sent: Tuesday, October 15, 2019 6:46 PM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: SIDR Operations WG <[email-masked]>
Subject: Re: [Sidrops] ASPA false leak

randy

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

---

From: Ben Maddison <[email-masked]>
Date: Wed, 16 Oct 2019 06:35:55 +0000

Hi Jakob,

The distinction here is between path selection and announcing transit. AS4 in this example is entirely entitled to select the path via AS3, but unless authorized to do so, is not entitled to announce it to non-customer peers.
I think the operation of the model is correct in this example.

In fact, today, if AS4 is replaced by AS37271 in this example (us), and AS1 were to set 37271:120* on their direct session with us, the result would be that we select the path via peering with AS3, but not announce it to non-customers: exactly as expected in the ASPA model.

Cheers,

Ben

* set LP below default value for routes from peers

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Sidrops <[email-masked]> on behalf of Jakob Heitz (jheitz) <[email-masked]>
Sent: Wednesday, October 16, 2019 5:31:57 AM
To: Randy Bush <[email-masked]>
Cc: SIDR Operations WG <[email-masked]>
Subject: Re: [Sidrops] ASPA false leak

Regards,
Jakob.

-----Original Message-----
From: Sidrops <[email-masked]> On Behalf Of Randy Bush
Sent: Tuesday, October 15, 2019 6:46 PM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: SIDR Operations WG <[email-masked]>
Subject: Re: [Sidrops] ASPA false leak

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 16 Oct 2019 08:42:27 +0200

> and that alternate path sure looks a lot like a route leak.

lemme try a different way

the attacker A3 wishes tio siphon jelly beans from A5's traffic to A1.
so she convinces A4 to prefer the A4 A3 A2 A1 path, which A4 then
announces to A5 as her best path.  profit.

randy

---

From: Alexander Azimov <[email-masked]>
Date: Wed, 16 Oct 2019 23:41:17 +0300

And another real-world scenario.

The significant number of route leaks today happens when an ISP is using
the prefix-list of their customers as the only egress filter (no ingress
filters/no communities).
In this case, just like in your scenario, it starts to leak customer's
prefixes when it gets them from providers/peers, thus spoiling TE of their
customers. More then, the customer even can't redirect traffic from such
misconfigured upstream provider even if it experiences a service
degradation.

I don't believe we should legitimize such behavior.

-- 
Best regards,
Alexander Azimov

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 16 Oct 2019 21:31:46 +0000

So, should AS5 just drop the traffic?

Regards,
Jakob.

From: Alexander Azimov <[email-masked]>
Sent: Wednesday, October 16, 2019 1:41 PM
To: Randy Bush <[email-masked]>
Cc: Ben Maddison <benm=[email-masked]>; Jakob Heitz (jheitz) <[email-masked]>; SIDR Operations WG <[email-masked]>
Subject: Re: [Sidrops] ASPA false leak

The significant number of route leaks today happens when an ISP is using the prefix-list of their customers as the only egress filter (no ingress filters/no communities).
In this case, just like in your scenario, it starts to leak customer's prefixes when it gets them from providers/peers, thus spoiling TE of their customers. More then, the customer even can't redirect traffic from such misconfigured upstream provider even if it experiences a service degradation.

randy

_______________________________________________
Sidrops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sidrops

--
Best regards,
Alexander Azimov

---

From: Randy Bush <[email-masked]>
Date: Thu, 17 Oct 2019 03:29:06 +0200

> So, should AS5 just drop the traffic?

yes

it is a leak or an attack

randy

---

From: Ben Maddison <[email-masked]>
Date: Thu, 17 Oct 2019 06:59:44 +0000

Yes. Right on the floor.

Get Outlook for Android<https://aka.ms/ghei36>
________________________________
From: Jakob Heitz (jheitz) <[email-masked]>
Sent: Wednesday, October 16, 2019 11:31:46 PM
To: Alexander Azimov <[email-masked]>; Randy Bush <[email-masked]>
Cc: Ben Maddison <[email-masked]>; SIDR Operations WG <[email-masked]>
Subject: RE: [Sidrops] ASPA false leak

Regards,
Jakob.

randy

--
Best regards,
Alexander Azimov