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

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

Hi Claudio,



Discussing one your earlier points (March 15) for now as below and this might address Martin's question also:



>Section 5:

>

>More AFI nightmares in figure 1:

>          "no Attestation" if AS(i)

>          does not have ASPA (i.e., VAP)

>          for mentioned AFI



>Again there is no conept of an ASPA for mentioned AFI. So what does that mean? I already asked this question and did not get a reponse. So let me ask again:



I think SPAS can distinguished as ASPA-SPAS (before X.509 validation) and VAP-SPAS (after X.509 validation). What we are interested in the above are the VAP-SPAS. The VAP-SPAS can be separated per {CAS, AFI} into:



CAS, VAP-SPAS(AFI=1)

CAS, VAP-SPAS(AFI=2)



VAP-SPAS(AFI=1) and VAP-SPAS(AFI=2) are two sets created per CAS post X.509 validation of the ASPA(s).



Now we can edit the above (what you quoted from Section 5) to read:



          "no Attestation" if AS(i) has an empty VAP-SPAS(AFI) set



>Consider the following ASPA entry:

>            customerASID: 42

>            ProviderASSet: [ { providerASID: 4242, afiLimit: 0001 } ] an ASPA entry for AS42 with a single provider AS4242 that is limited to IPv4.

>

>What is the result of hop(42, 4242, 2) and what about hop(42, 123, 2)?

>

>The specification is ambiguous in this case because both "Not Provider"

>and "no Attestation" could be considered a valid outcome. Now my view is that the result MUST be

>"Not Provider" since 42 has an ASPA record but this really needs to be clarified before this draft can pass WGLC.



We can eliminate the above problem with this addition in Section 4:



ASPA registration is REQUIRED for a compliant AS. The ASPA-SPAS for a CAS MUST list at least one providerASID for each allowed value  of the AFI (1 and 2), either implicitly (by not specifying the afiLimit) or explicitly. This includes the possibility of providerASID = 0 for one or both AFIs. For example, if a CAS X registers only the ASPA: [customerASID = X, {providerASID = Y,  afiLimit = 1}], that is not permitted because it leaves out AFI =2. Instead, if the CAS X registers ASPA: [customerASID = X, {providerASID = Y}], or ASPA: [customerASID = X, {providerASID = Y,  afiLimit = 1},  {providerASID = 0,  afiLimit = 2}], or ASPA: [customerASID = X, {providerASID = Y,  afiLimit = 1},  {providerASID = Z,  afiLimit = 2}], any of those is permitted.



With the above updated recommendation, maybe the objection about the ASPA RTR PDU per draft-ietf-sidrops-8210bis (Martin's question) also goes away... since if the separation of VAP-SPAS per {CAS, AFI} is performed at the RPKI cache, the router can benefit (avoid having to do the processing on the router).



Your thoughts?



Thanks.



Sriram