Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-verification - ENDS 03/22/2023 (Mar 22 2023)

["Lubashev, Igor" <[e-mail]>]

Sriram, thank you for updating the draft and getting into additional details of what leaks and hijacks can be mitigated during partial ASPA deployment.



I have a few questions about the new Section 8 "mitigation properties".



> 2.  Again let AS A and AS B be any two ASes in the Internet doing

                      ASPA (generation and verification) and no assumption is made

                      about the deployment status of other ASes.  Consider a route

                      received at AS B from its customer or lateral peer that is a

                      forged-origin prefix hijack [RFC9319] involving AS A as the

                      forged-origin.  The ASPA-based path verification at AS B always

                      detects such a forged-origin prefix hijack.



See the diagram below. Suppose AS B receives AS_PATH [C, P, A] from AS C, where A is a forged origin, AS P is A's provider in ASPA, and AS C is B's customer.  AS P did not deploy ASPA.  How would AS B detect this hijack of A by C?



 Z

/ \

B   P

|   |

C   A





> 3.  Consider an ASPA island (i.e., a connected set of ASPA capable

                      ASes).  Let AS A and AS B be any two ASes in the ASPA island.

                      Consider a route propagated from AS A in any direction (i.e., to

                      a neighbor AS with any of the BGP roles described in Section 2)

                      and leaked by an offending AS in the AS path before being

                      received at AS B from any direction.  The ASPA-based path

                      verification at AS B always detects such a route leak though it

                       may not be able to identify the AS that originated the leak.



Does it mean that the BGP advertisement is only forwarded within the "island"?  If so, AS B should be able to identify the AS that leaked the route, no?

But if forwarding is allowed outside of the island, AS B will not always be able to detect a route leaked outside of the island. In the diagram below, AS A originates a route to its Provider AS P (outside of the island), which forwards it to its other customer AS L, which leaks it to its other provider AS C, which is a provider for AS B (in the island). Since there are no ASPA Objects for ASes P, L, and C, AS B cannot tell whether AS L is a common customer or a common provider for ASes P and C.

 P  C

/\ / /

A  L /

\  / <- [C,L,P,A]

  B



Many thanks,



  *   Igor



On Tuesday, March 28, 2023 1:00 AM Sriram, Kotikalapudi wrote:

> All: I just uploaded a revised draft version -13. All comments received in this

> thread have been carefully considered and changes incorporated as

> necessary.

>

> Version-13:

> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/__;!!GjvTz_vk!U_j82WLWnhnUdVaT4XZWfNqw-Uo4irI7hxtEzFM5aoYEXCr25uZZVTVb0k0PYsXELy2ZuBB9erosN5dagDRzoGmztRzrJQ$>

> sidrops-aspa-verification/__;!!GjvTz_vk!U_j82WLWnhnUdVaT4XZWfNqw-<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/__;!!GjvTz_vk!U_j82WLWnhnUdVaT4XZWfNqw-Uo4irI7hxtEzFM5aoYEXCr25uZZVTVb0k0PYsXELy2ZuBB9erosN5dagDRzoGmztRzrJQ$>

> Uo4irI7hxtEzFM5aoYEXCr25uZZVTVb0k0PYsXELy2ZuBB9erosN5dagDRzoGmzt<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/__;!!GjvTz_vk!U_j82WLWnhnUdVaT4XZWfNqw-Uo4irI7hxtEzFM5aoYEXCr25uZZVTVb0k0PYsXELy2ZuBB9erosN5dagDRzoGmztRzrJQ$>

> RzrJQ$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/__;!!GjvTz_vk!U_j82WLWnhnUdVaT4XZWfNqw-Uo4irI7hxtEzFM5aoYEXCr25uZZVTVb0k0PYsXELy2ZuBB9erosN5dagDRzoGmztRzrJQ$>

>

> Diff:  https://urldefense.com/v3/__https://author-<https://urldefense.com/v3/__https:/author-tools.ietf.org/iddiff?url1=draft-ietf-sidrops-aspa-verification-12&url2=draft-ietf-sidrops-aspa-verification-13&difftype=--html__;!!GjvTz_vk!U_j82WLWnhnUdVaT4XZWfNqw-Uo4irI7hxtEzFM5aoYEXCr25uZZVTVb0k0PYsXELy2ZuBB9erosN5dagDRzoGmBhBlIJw$>

> tools.ietf.org/iddiff?url1=draft-ietf-sidrops-aspa-verification-12&url2=draft-<https://urldefense.com/v3/__https:/author-tools.ietf.org/iddiff?url1=draft-ietf-sidrops-aspa-verification-12&url2=draft-ietf-sidrops-aspa-verification-13&difftype=--html__;!!GjvTz_vk!U_j82WLWnhnUdVaT4XZWfNqw-Uo4irI7hxtEzFM5aoYEXCr25uZZVTVb0k0PYsXELy2ZuBB9erosN5dagDRzoGmBhBlIJw$>

> ietf-sidrops-aspa-verification-13&difftype=--<https://urldefense.com/v3/__https:/author-tools.ietf.org/iddiff?url1=draft-ietf-sidrops-aspa-verification-12&url2=draft-ietf-sidrops-aspa-verification-13&difftype=--html__;!!GjvTz_vk!U_j82WLWnhnUdVaT4XZWfNqw-Uo4irI7hxtEzFM5aoYEXCr25uZZVTVb0k0PYsXELy2ZuBB9erosN5dagDRzoGmBhBlIJw$>

> html__;!!GjvTz_vk!U_j82WLWnhnUdVaT4XZWfNqw-<https://urldefense.com/v3/__https:/author-tools.ietf.org/iddiff?url1=draft-ietf-sidrops-aspa-verification-12&url2=draft-ietf-sidrops-aspa-verification-13&difftype=--html__;!!GjvTz_vk!U_j82WLWnhnUdVaT4XZWfNqw-Uo4irI7hxtEzFM5aoYEXCr25uZZVTVb0k0PYsXELy2ZuBB9erosN5dagDRzoGmBhBlIJw$>

> Uo4irI7hxtEzFM5aoYEXCr25uZZVTVb0k0PYsXELy2ZuBB9erosN5dagDRzoGmB<https://urldefense.com/v3/__https:/author-tools.ietf.org/iddiff?url1=draft-ietf-sidrops-aspa-verification-12&url2=draft-ietf-sidrops-aspa-verification-13&difftype=--html__;!!GjvTz_vk!U_j82WLWnhnUdVaT4XZWfNqw-Uo4irI7hxtEzFM5aoYEXCr25uZZVTVb0k0PYsXELy2ZuBB9erosN5dagDRzoGmBhBlIJw$>

> hBlIJw$<https://urldefense.com/v3/__https:/author-tools.ietf.org/iddiff?url1=draft-ietf-sidrops-aspa-verification-12&url2=draft-ietf-sidrops-aspa-verification-13&difftype=--html__;!!GjvTz_vk!U_j82WLWnhnUdVaT4XZWfNqw-Uo4irI7hxtEzFM5aoYEXCr25uZZVTVb0k0PYsXELy2ZuBB9erosN5dagDRzoGmBhBlIJw$>

>

> Hi Claudio: I went with many of your suggestions below and earlier. It is easy

> enough to assume a single VAP-SPAS table even in the description in this

> doc. You should like what I did in the revised Sections 3, 4, and 5.

>

> Igor: I addressed your discomfort with the earlier rosier description of the

> merits of ASPA verification in Section 8. I now systematically describe the key

> properties (mitigation capabilities) in Sec. 8 and the limitations are stated in

> Section 12. Hopefully, you'll find it accurate and more insightful.

>

> Tim, Job, Martin, and others: Your comments/discussions relating to Sections

> 3 and 4 carefully considered and folded in.

>

> Amir, Nan:  The changes promised are included.

>

> Amreesh, Aftab, Yangyang: Please review the diff. You should find your

> comments addressed as well.

>

> All: Please let me know if missed anything important.

>

> Thanks to all who have kindly devoted time to reading and giving feedback.

>

> Sriram