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

[Claudio Jeker <[e-mail]>]

On Thu, Mar 23, 2023 at 01:22:32PM +0000, Amreesh Phokeer wrote:
> Hello,
> 
> Thank you to all those involved in this draft. We have reviewed the document and here are our comments:
> 
>   1.  Section 4: “An AS SHOULD NOT have more than one ASPA”
>      *   It should be clarified that one ASPA per AFI is tolerated

In general this is a bad adivice and therefor should not be further
clarified. As with all ASPA objects the RP software and router must build
the union of all providers per CAS. Now one could issue an object per
provider and AFI but it is not a very sensible thing to do.

The CAS is the primary lookup key. If there is any valid ASPA object for an
AS X in RPKI then AS X should be protected by ASPA validation. The AFI
should not matter. You should not be able to enable ASPA validation only
for half of your ASPATHs. It would result in operational nightmares.

>      *   How do you do “make before break” in case an AS is changing provider or in the case of a resource transfer?

The draft is clear that the union of all valid objects is formed using the
CAS as the primary key.
So make before break is no issue as long as the certificates covering the
CAS are adjusted ahead of time. In that regard ASPA behaves like ROA and
has the same issues.

>   2.  VAP: it is unclear whether how the VAP will be merged but grouped by AFI in the case of multiple ASPAs?

See 1.

>   3.  Validation of the ASPA payload
>      *   A Customer ASID cannot be 0, should it be mentioned in the document or rather in the profile document?

The customer ASID must be covered by the EE certificate and the full path
up to the TA. So it is impossible to have a valid ASPA object that has
Customer ASID 0 unless a RIR made a major boo-boo.

>      *   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?

This is a problem in the profile specification. The addition of AS 0 to
the SPAS does not change the outcome. It is an issue I raised in earlier
mails.

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

For ASPA validation a state of "notfound" makes little sense. A path consists
of many lookups and calling the final state "notfound" is none intuitive
since some of the lookups may actually return a valid provider
relationship. ROV and ASPA validation are two different things.

Btw. ASPA only tells if an ASPATH is plausible or not. So the use of
the term "valid" is actually a bit too strong.

-- 
:wq Claudio