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

["Lubashev, Igor" <[e-mail]>]

On Tuesday, March 28, 2023 4:55 AM, Claudio Jeker wrote:
> On Tue, Mar 28, 2023 at 05:43:12PM +0900, Ben Maddison wrote:
> > 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.
> 
> But in general non-canonical forms are a big issue when it comes to X.509
> since it results in unequal objects that result in the same effect.
> I'm not sure if this will affect the security or not.
> 
> For the providerAS sequence there are already constrains in place:
>     * The CustomerASID value MUST NOT appear in any providerASID field.
>     * The elements of providers MUST be ordered in ascending numerical
> order
>       by the value of the providerASID field.
>     * Each value of providerASID MUST be unique (with respect to the other
>       elements of providers).
> 
> Especially number 2 and 3 make verification that AS 0 is the only element in
> the sequence fairly trivial. So adding an extra bit for AS 0 should not be
> that complex.
> 
> --
> :wq Claudio

I also think that it is best to have a single valid representation for a Provider ASN list -- it makes it easier to compare ASPA Objects and reduces the chances for implementation mistakes.

However, since the purpose of any specification is providing clarity to ensure interoperability, making it explicit whether AS0 is allowed in multi-element ASN lists is most important.  The actual decision is a secondary concern.

- Igor