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

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

Thanks, Sriram.  Yes, some additional clarification for the properties would be helpful.

I think it would be valuable to mention another "mitigation property".  When an AS generates ASPA, it makes it less likely that prefixes belonging to its customers will be hijacked, if the customers also generate ASPA.
A hijack attack that resists ASPA validation requires the hijacker to prepend its AS_PATH with a prefix containing the shortest possible sequence of ASNs identified as Providers in ASPA (transitively), starting from the hijacked ASN up to the first Provider ASN not in ASPA. When a provider generates ASPA, it forces attacker's AP_PATH to be one ASN longer, which reduces the likelihood of success of such hijack.

I think this could be a great business driver for ASPA adoption -- customers would be seeking out providers with an ASPA registration (and especially those whose providers also have ASPA registrations), since that would make their prefixes more resistant to hijacks. 

- Igor


On Tuesday, March 28, 2023 7:23 PM, Sriram, Kotikalapudi wrote:
> 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]; draft-ietf-
> [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
>