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

["Sriram, Kotikalapudi (Fed)" <[e-mail]>]

Hi Igor,

Thanks for the analysis.

In your first scenario, it is not a forged-origin hijack. Instead, it is a forged-path-segment attack.

One can say that a forged-path-segment attack is also always detectable (in the upstream direction) provided all ASes in the path segment are ASPA compliant.

In your second scenario, the route is going outside the island and entering back.  So, you asked:

>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?

Yes, either the whole route (all ASes in it) or at least the three consecutive ASes constituting the route leak must be within the ASPA island. 

I think the attribution is a bit hard. If there is a route leak, the verifying AS knows which AS seems to be the leaking AS. But it cannot distinguish if its provider sent a fabricated path. But the path will be detected to be a route leak either way. 

I will recheck the wording of the properties to be clear.

Sriram


________________________________________
From: Lubashev, Igor <ilubashe=[e-mail]>
Sent: Wednesday, March 29, 2023 1:16 AM
To: Sriram, Kotikalapudi (Fed); Claudio Jeker
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: [Sidrops] WGLC = draft-ietf-sidrops-aspa-verification - ENDS 03/22/2023 (Mar 22 2023)

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