Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-verification-08.txt

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 26 Oct 2021 15:13:25 +0000

Hi Andrei,

There was a shortcoming identified with the ASPA downstream verification algorithm in January this year. I am not sure you are aware of it. The thread is here:
https://mailarchive.ietf.org/arch/browse/sidrops/?gbt=1&index=xoBTzN1plByFFq1ljj5i0vPAzIk

I gave a presentation (joint work with Jakob Heitz) at IETF 110 SIDROPS: "On the Accuracy of Algorithms for ASPA Based Route Leak Detection"
https://datatracker.ietf.org/meeting/110/materials/slides-110-sidrops-sriram-aspa-alg-accuracy-01

The shortcoming was in the sense that the algorithm was yielding 'Unknow" results in some scenarios when it was "Valid". This was addressed and a revised algorithm was agreed to in principle by several of us in SIDROPS (including Alexander). You may glance through the presentation, specially the algorithm on slides 14 and 15. It was formally proven to work correctly. You are welcome to review it, and it should not have any of the issues that you are thinking about. You may let us know if you agree.

Alexander was busy so he simply refreshed the -07 draft to generate -08. So, at this point, we are waiting for draft -09. A clear, simple wording of the algorithm for the draft is being worked on, including some new minor corner cases.

Sriram

-------------------------------------------------------------------

Andrei Robachevsky <[email-masked]> Mon, 25 October 2021 13:34 UTCShow header

Hi,

I read the latest version of the draft and I am not sure that the
Downstream Path verification procedure (sec 5.2) is correct.

The draft says:
> The first unequal pair of AS_SEQUENCE segments that has an "Invalid" outcome of the customer-provider verification procedure indicates the end of the Upstream fragment.

But the procedure described in items 3 and 4 seems to skip checking that
the first downstream fragment of the path may return an invalid
verification for the "reverse" ASPA (verify_pair(Seg(I), Seg(I-1), afi).
By performing this check we can verify that that downstream customer
indeed declared the top provider as its upstream.

It seems to me that a similar verification of a "reverse" ASPA needs to
be done when detecting a leaking customer L, since verify_pair(Seg(L+1),
Seg(L), afi) will likely return "Unknown", but verify_pair(Seg(L),
Seg(L+1), afi) may be "Valid". In this case we can confidently state
that it is a leak and return "Invalid".

Thanks,

Andrei

---

From: Andrei Robachevsky <[email-masked]>
Date: Tue, 26 Oct 2021 17:41:03 +0200

Hi Sriram, thank you!

I should have paid more attention. Looking forward to the updated -09

Regards,

Andrei

Sriram, Kotikalapudi (Fed) wrote on 26/10/2021 17:13:
> Hi Andrei,
> 
> There was a shortcoming identified with the ASPA downstream verification 
> algorithm in January this year. I am not sure you are aware of it. The 
> thread is here:
> 
> <https://mailarchive.ietf.org/arch/browse/sidrops/?gbt=1&index=xoBTzN1plByFFq1ljj5i0vPAzIk>
> 
> I gave a presentation (joint work with Jakob Heitz) at IETF 110 SIDROPS: 
> “On the Accuracy of Algorithms for ASPA Based Route Leak Detection”
> 
> <https://datatracker.ietf.org/meeting/110/materials/slides-110-sidrops-sriram-aspa-alg-accuracy-01> 
> 
> 
> The shortcoming was in the sense that the algorithm was yielding 
> ‘Unknow” results in some scenarios when it was “Valid”. This was 
> addressed and a revised algorithm was agreed to in principle by several 
> of us in SIDROPS (including Alexander). You may glance through the 
> presentation, specially the algorithm on slides 14 and 15. It was 
> formally proven to work correctly. You are welcome to review it, and it 
> should not have any of the issues that you are thinking about. You may 
> let us know if you agree.
> 
> Alexander was busy so he simply refreshed the -07 draft to generate -08. 
> So, at this point, we are waiting for draft -09. A clear, simple wording 
> of the algorithm for the draft is being worked on, including some new 
> minor corner cases.
> 
> Sriram
>