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

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

All: I just uploaded a revised draft version -13. All comments received in this thread have been carefully considered and changes incorporated as necessary.

Version-13:  https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/ 

Diff:  https://author-tools.ietf.org/iddiff?url1=draft-ietf-sidrops-aspa-verification-12&url2=draft-ietf-sidrops-aspa-verification-13&difftype=--html 

Hi Claudio: I went with many of your suggestions below and earlier. It is easy enough to assume a single VAP-SPAS table even in the description in this doc. You should like what I did in the revised Sections 3, 4, and 5.

Igor: I addressed your discomfort with the earlier rosier description of the merits of ASPA verification in Section 8. I now systematically describe the key properties (mitigation capabilities) in Sec. 8 and the limitations are stated in Section 12. Hopefully, you'll find it accurate and more insightful.

Tim, Job, Martin, and others: Your comments/discussions relating to Sections 3 and 4 carefully considered and folded in.

Amir, Nan:  The changes promised are included.

Amreesh, Aftab, Yangyang: Please review the diff. You should find your comments addressed as well.

All: Please let me know if missed anything important.

Thanks to all who have kindly devoted time to reading and giving feedback.

Sriram

________________________________________
From: Claudio Jeker <[e-mail]>
Sent: Monday, March 27, 2023 7:08 PM
To: Sriram, Kotikalapudi (Fed)
Cc: Martin Hoffmann; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-verification - ENDS 03/22/2023 (Mar 22 2023)

On Wed, Mar 22, 2023 at 10:47:20PM +0000, Sriram, Kotikalapudi (Fed) wrote:
> 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?
>

Right now both BGP-SRx nor OpenBGPD implement a single aspa table.
At least for OpenBGPD this was done to have a single, cache efficent and
extremly fast lookup function. Performance of ASPA is a big concern since
it must be applied to every path received.
The lookup table consists of many sources (static config and each RTR
session) data is merged and compiled into one lookup table.
Adding more work in that compile step has little impact on BGP performance
which is fine as long as the basic lookup still works.

The operational impact of AFI dependent ASPA objects was little discussed.
ASPA is already complex enough and unlike ROA validation the outcome
depends not only on a single resource. Also every AS may get different
outcomes because the view is different (downstream path).
So having to figure out why one path is accepted and another fails is
already complicated without doubling the pain with AFI=1 and AFI=2.
Having a disconnect between an ASPA object in RPKI and the resulting lookup
object in BGP makes this not easier.

Now your requirement that ASPA objects MUST cover both supported AFI is an
option but all RP software MUST follow that rule and discard badly encoded
ASPA objects (which they should anyway but people still like to argue
about this a lot). Also BGP router need to follow that rule and make sure
that RTR ASPA PDUs always come in couples.
So this needs to be explicitly mentioned in all three specifications.
Not sure in which document you want to alter Section 4. Right now I think
that in draft-ietf-sidrops-aspa-profile-12 section 4 needs to be extended,
in draft-ietf-sidrops-aspa-verification-12 section 3, 4 and 5 need some
adjustements and in draft-ietf-sidrops-8210bis-10 it would be good to
extend 5.12 a little bit.

Now if I understand you correctly a Valid ASPA Payload would always cover
both AFIs (since an object MUST list some value for both AFI). So your
suggestion above:
>           "no Attestation" if AS(i) has an empty VAP-SPAS(AFI) set
can be replaced with
>           "no Attestation" only if AS(i) has no CAS entry
since if one VAP-SPAS(AFI) set exists the other set MUST exist as well.

--
:wq Claudio