[Sidrops] Re: AS 0 mixed in ASPA 'providers'? (Was: I-D Action: draft-ietf-sidrops-aspa-profile-21.txt)

[Job Snijders <[e-mail]>]

On Fri, Jan 30, 2026 at 05:02:46PM +0000, Sriram, Kotikalapudi (Fed) wrote:
> >My concern is in the realm of unintended malleability: our goal is to
> >specify a canonical encoding and I can only see downsides to allowing
> >superfluous encoding of the 'zero provider'.
> 
> What would be one or two specific examples of the downsides?

Malleability and canonicalization is a fascinating topic. Perhaps
https://cborbook.com/part_2/determinism.html is of some help?

As a rule of thumb, in SIDROPS we strive to use canonical encoding
rules. A normalized form helps when comparing information elements (e.g.
memcmp() can be used), which in turn makes debugging easier, and also
makes detecting of corruption in memory/programflow/etc easier, and also
allows implementers to optimize algorithms for inserting into internal
data structures. The practise of using canonical forms (especially in
security sensitive contexts!) dates back to RFC 3779 and even before
that.

> My inclination is towards being tolerant about the presence of AS 0 in
> the ASPA. Tim was also initially thinking along these lines. We should
> try to avoid seemingly unnecessary churn in the RP/RTR
> implementations. 

But why allow for malleability? How does this churn affect you? What I
rpopose really is a small change which only needs to be executed by a
very limited group of individuals. And it seems all those individuals
are engaged and planning accordingly.

Should you have concern that changes like these negatively impact the
publication process, I have good news: finding edges cases like these
"now" really is the most expedient way forward. There are i's to be
dotted and t's to be crossed, and these things must be done in order for
SIDROPS to deliver a high quality product. I suspect that dealing with
this canonicalization refinement "now" (January 2026) will save our
future selves from a discussion on an Errata filing and even possible
tedious -bis document projects.

> Tim said: "Fwiw we plan to update our implementation to disallow this
> in future, and tell our users to either use AS0 (and confirm that they
> are REALLY SURE THAT THEY HAVE NO PROVIDERS) or 1 or more other ASNs."
> 
> Yes, good. I would prefer that the RPKI registration systems (ARIN,
> RIPE, etc.) alert the AS owner (registrant) so that the superfluous
> cases are prevented. 

Great.

> I think you have not considered the case when an AS owner already has
> a registered AS 0 ASPA; the AS may or may not be operational. Later,
> they register a new ASPA listing their newly contracted provider
> ASN(s) in the SPAS; this is a separate new ASPA. They forgot (or
> ignored) that there was an AS 0 ASPA. 

> I think it is too harsh to penalize them and treat both ASPAs (AS 0
> ASPA and the normal ASPA) as invalid in RPKI and discard them.

Ah, I think you misunderstand the implications of enforcing the
canonical form in the context of Signed Object's eContent.

When two distinct ASPAs exist, (one AS 0 provider, and another one with
a set of providers using non-zero ASes), they can both be valid at the
same time and if that is the case they'll be merged/deduplicated
appropriately by the cache.

The canonicalization rule refinement is about the byte structure of a
*single* ASPA. The scenario that you describe with two valid ASPAs is
not applicable. To re-iterate: going forward, it is disallowed to
combine AS 0 and non-zero ASes in a *single* ASPA, but it is not illegal
to issue two separate valid ASPAs (one with AS 0 and one with a non-zero
AS as provider). Obviously, while the other ASPA exists in parallel, the
AS0 ASPA has become superfluous for the time being and has no impact on
route decision making processes.

> If we do this by changing the ASPA object verification (X.509 related)
> specification, it also causes a significant churn in the
> implementations of the ASPA profile draft.  Plus, AS owner is
> penalized harshly, when in fact, their AS 0 ASPA can be simply ignored
> (rendered ineffective) and the other normal ASPA prevails. 

No no... the proposed refinement is a very modest change, it'll be done
in a jiffy.

> It also sends an unwarranted (false) scare to users on the ROA side.
> ROA registrants (prefix owners) might be confused and would scramble
> to do something in case they have an AS 0 ROA and normal ROA for the
> same prefix(es). They must not go through such unwarranted churn. We
> want them to feel free about registering an AS 0 ROA initially when
> they newly acquire the resource and later add a normal ROA when they
> wish to start using it in routing; deleting the AS 0 ROA is optional.

I'm sure that the proposed change will not change any such dynamics for
the worse.

Kind regards,

Job