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

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

Hi Yangyang,

Thank you for the comments. My responses are inline below marked with [KS:].

My responses to #3 and #4 complement Claudio's 
( https://mailarchive.ietf.org/arch/msg/sidrops/jTlhzDKCKv21WIUd-Kv00Qtsmk8/ ).

Sriram

-----Original Message-----
From: Yangyang Wang <[e-mail]> 

Comments as follows.
1. a few typos.
In section 3, "The definition of Provider AS in given in Section 1" -->"The definition of Provider AS is given in Section 1"
Page 7, "If N = 1, then then the procedure" --> remove the extra "then"
Page 10, downstream path verification procedure, step 4 "lowest value of v
(2 <= u <= N)" --> " lowest value of u (2 <= u <= N)"

[KS:] Thanks. Will fix those.

2. This draft claims that "An AS SHOULD NOT have more than one ASPA". 
If a Customer AS signs only one ASPA object including all its Provider ASes, it needs to resign and update it when any one of the provider ASes changes.
It may affect the validation.

[KS:] The AS operator would follow the principle of make before break. Create a new ASPA first and then delete the old one. It is not a MUST NOT. So, two ASPAs may exist for a short period. The ASPA profile draft authors (cc'ed here) may include an operational guidance statement about this in that draft.  

3. In the algorithm for downstream paths, it says that if 1 <= N <=2, then the AS_PATH is trivially Valid.  
If N=2, assuming AS_PATH is (AS2, AS1), the path verification is just hop-check hop(AS(1), AS(2)) and may be one of "Provider", "Not Provider" and "no Attestation". 
If it is "Provider", the AS_PATH is Valid. 
If it is "Not Provider" or "no Attestation", I feel that the AS_PATH is actually unclear, which may be Valid, or forged link as the (AS(5), AS(2)) shown in Section 12.

[KS:] The path is (AS2, AS1) and received by a validating AS (say AS3) that is downstream (i.e., AS2 is a provider to AS3). Without even looking at the ASPA, this path is trivially Valid because no matter whether AS1 to AS2 is C2P, P2C, or p2p (lateral peers), there is no valley in the path and hence there is no route leak.

[KS:] For the case of a forged-origin attack (with provider doing mischief on a customer) that you mention, I feel the draft discusses that security concern adequately in Section 12. The strength of the ASPA method is in detecting route leaks and a majority of (but not all) path manipulation attacks. It cannot catch all path manipulations -- BGPsec would be needed for that.  

4. It seems that the algorithms for path verification are not complete to cover all possible cases.

For example, shown in the figure below:

Receiving & validating AS 5 --  AS(4)
				 \
				   \
                                                          AS(3)     AS(1)
                                                              \        /
			 	      \     /
                                                                AS(2)
ASPAs: {AS(2), [AS(3), AS(1)]}

AS5 is the Receiving & Validating AS. And, only AS(2) register an ASPA object in RPKI. 
It assumes that AS5 receives an AS_PATH [AS(4), AS(3), AS(2), AS(1)], and there is a route leak from AS(3) to AS(1) by the customer AS(2) hop(AS(1), AS(2)) = "no attestation"
hop(AS(2), AS(3)) = "Provider"
hop(AS(3), AS(4)) = "no attestation"
According to the step 4 and 5 of the algorithm for upstream paths in section 6.1,  there is not an i for which hop(AS(i-1), AS(i)) = "not Provider". This path is invalid, but will be verified as "Unknown".

Maybe I'm missing something or make a mistake.

[KS:] To add what Claudio has said... please keep in mind that AS(1) has no ASPA and that means that a sibling relationship between AS1 and AS2 is still possible. See the definition of sibling in Section 2 and the corresponding ASPA registration requirement in Section 4. So, if AS1 and AS2 are siblings, then the path would be Valid. If they are not siblings, the path would be Invalid. So, given that AS1 does not have an ASPA, the algorithm correctly gives "Unknown" result.

Sriram