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

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

An alternative to a special 'AS 0 ASPA' would be allowing a zero-length Provider AS list. Then there are no special rules at all. But if 'AS 0 ASPA' is used, a further special rule is needed to describe how a 'union' is taken when both 'AS 0 ASPA' and a 'normal' ASAP are present (maybe from different RPKI registries).

- Igor

On Mar 25, 2023 6:40 AM, gengnan <gengnan=[e-mail]> wrote:
Hi Aftab and Job,

From: Sidrops <[e-mail]> On Behalf Of Aftab Siddiqui
Sent: Friday, March 24, 2023 8:36 AM
To: Job Snijders <job=[e-mail]>
Cc: Amreesh Phokeer <phokeer=[e-mail]>; [e-mail]; Aftab Siddiqui <[e-mail]>; Max Stucchi <[e-mail]>; Hanna Kreitem <[e-mail]>
Subject: Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-verification - ENDS 03/22/2023 (Mar 22 2023)

Hi Job,


>      *   To make it clear “AS 0 ASPA MUST only have AS 0 as Provider
>          AS”, it doesn’t clearly mention that “normal” ASPA (non AS 0
>          ASPA) MUST NOT have AS 0 in the Provider AS.
>      *   In the absence of point ‘b’ what if AS 0 is added as Provider
>          AS in the ‘normal’ ASPA?

I'm a bit unclear on what is meant with the above two points, can you
further clarify?

As per the definition "An ASPA object showing only AS 0 as a provider AS is referred to as an AS0 ASPA." i.e. {CAS, AS(0)}
Any ASPA which is not "AS 0 ASPA" is referred to in the draft as "normal ASPA" but it doesn't say that normal ASPA can't have AS 0 in the provider AS. i.e. {CAS, AS(139038), AS(0)}. Yes, there is no reason to have AS 0 in the provider AS but make it clear in the draft.

[NAN]: Agreed. AS 0 MUST NOT appear in the normal ASPA. IMO, two points can be clarified in either the profile or the verification draft: 1) CAS MUST NOT be AS 0, and 2) AS 0 MUST NOT be included in the provider AS list if the ASPA is a normal ASPA. There is a section of “4.  ASPA Registration Recommendations” in the verification draft which can be the candidate place to make the clarification.

I think some descriptions also need to be added in the verification draft. Actually, the verification process works normally even there exists AS 0 in normal ASPA data. In the v11 of the verification draft (sec. 5.4), there are some related descriptions which somehow are removed  from v12:
“
If AS 0 coexists with other provider ASes in the same ASPA (or other
   ASPA records in the same AFI), then the presence of the AS 0 has no
   effect on the AS_PATH verification procedures.  The validation
   procedures simply consider the other (distinct from AS 0) providers
   as the authorized providers of the AS in consideration.
”




>   4.  ROV vs ASPA validation states, keep the states consistent (Unknown/notfound)
>      *   ROV States [valid, invalid, notfound] vs ASPA states [valid, invalid, unknown]

Why? Route Origin Validation and ASPA verification are two different
algorithms with different inputs and different outputs. To me it doesn't
seem to increase consistency.

OK then why using terms like "valid", "invalid" and "unknown" why not just use "Provider", "Not Provider" and "No Attestation" because these are actual outputs of the function? don't you think the latter creates more clarity than the former?

[NAN]: I guess they were talking about the outputs of ASPA verification, instead of ASPA Hop-check function. For Hop-check function, the terms like "Provider", "Not Provider" and "No Attestation" are suitable. For ASPA verification, "valid", "invalid" and "unknown" will be used to indicate the validity states of AS paths.

--
Best Wishes,

Aftab Siddiqui