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

[Yangyang Wang <[e-mail]>]

Hi all

 

My comments in lines.

 

From: [e-mail] [mailto:[e-mail]] On Behalf
Of Sriram, Kotikalapudi (Fed)
Sent: 2023年3月23日 6:47
To: Claudio Jeker <[e-mail]>; Martin Hoffmann
<[e-mail]>
Cc: [e-mail]; [e-mail];
[e-mail];
[e-mail]
Subject: Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-verification - ENDS
03/22/2023 (Mar 22 2023)

 

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. 

 

 

[WYY:]  

This addition is good. This kind of format of ASPA is clear. It can
distinguish whether a provider registration is left out or not.

If a CAS X has a provider Y in IPv4, and no provider in IPv6. It should
register ASPA [customerASID = X, {providerASID = Y,  afiLimit = 1},
{providerASID = 0,  afiLimit = 2}].  This ASPA is a “normal ASPA”, and
this “normal ASPA” has AS 0 in the Provider AS list.

 

 

 

 

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