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

[Ben Maddison <[e-mail]>]

Hi all,

On 03/27, Claudio Jeker wrote:
> On Fri, Mar 24, 2023 at 11:35:35AM +1100, Aftab Siddiqui wrote:
> > 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.
>  
> Adding AS0 to any ASPA object with other ASID in the SPAS is not altering
> the outcome. {CAS, [AS(139038), AS(0)]} and {CAS, [AS(139038)]} are
> equivalent. The big unsolved question is if the profile spec should limit
> this alternative encoding (with the RP software enforcing that MUST).

This point is key. Disallowing AS0 in PAS, other than in the case that
it is the only item doesn't actually change any behaviour or fix
anything.

The only benefit that I can see is that we guarantee a single canonical
representation.

Enforcing this in the ASN.1 of the profile can (I think) be done, but
would significantly complicate the module. I'm not convinced this is a
price worth paying.

I do not think that we should introduce new normative restrictions that
are *not* described by the ASN.1.

Cheers,

Ben