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

[Claudio Jeker <[e-mail]>]

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