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

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

>For example,  the AS 100 router announces a route with AS_PATH {100， 101，102, 101} to the AS 103 router,  and {101, 102, 101} are forcibly added through the post-routing policy.
>After receiving the route, the as103 router scans for the AS_PATH and finds that local AS 103 does not exist in the AS_PATH. Therefore, the router determines that there is no loop.
>So we need to consider the handling of these unexpected AS_PATH attributes.

BGPsec mitigates such AS_PATH manipulations.

With the use of the ASPA method, assume that 101 and 102 have ASPA: {101, 102} and {102, 115}, respectively. Then ASPA verification also mitigates this attack for the majority of possible scenarios – if the manipulated AS_PATH {100, 101, 102, 101}  is received at AS 103 from AS 100 in the upstream direction (i.e., from a lateral peer or a customer), then the AS_PATH will be detected as Invalid (route leak) by AS 103. However, if the manipulated AS_PATH is received in the downstream direction at AS 103 from AS 100 (i.e., AS 100 is a provider of AS 103), then AS 103 may fail to detect. We have already stated in Section 12 that a limitation of the ASPA method is that a provider can maliciously manipulate an AS_PATH towards its own customer and can get away with it.

I know you are thinking of detecting upfront an AS-loop that does not include the receiving AS. IMO, that seems like a question for the IDR WG. You are right that RFC 4271 has not identified that kind of manipulated AS_PATH as a malformed AS_PATH. Well, the SIDR WG came up with BGPsec to detect all types of AS_PATH manipulations. That is why Section 12 mentions that ASPA and BGPsec can work in a complimentary manner.

Sriram