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

[Nimrod Levy <[e-mail]>]

If we go down this path, would it make sense to add a similar constraint
(if one does not already exist), that a prefix should not have a ROA
specifying both AS0 and another ASN?

Nimrod


On Thu, Jan 29, 2026 at 8:38 AM Job Snijders <[e-mail]> wrote:

> Dear all,
>
> Apparently our attempt at specifying a canonical encoding for ASPA
> eContent wasn't _entirely_ successful, please see the following object
> decoding.
>
>
>         $ rpki-client -f
> rpki.ripe.net/repository/DEFAULT/76/9d7cd7-ee63-4886-8fe1-b5ce6b6fd4d1/1/ygtEKAvCPKS208hGgxgvNBoaYpA.asa
>         File:                     ygtEKAvCPKS208hGgxgvNBoaYpA.asa (raw,
> json)
>         Hash identifier:
> PRA1qTJjgc8ZVUJi9mvFCAL+qKXJHkWZ1Nr5Ustka0M=
>         Subject key identifier:
>  CA:0B:44:28:0B:C2:3C:A4:B6:D3:C8:46:83:18:2F:34:1A:1A:62:90
>         Certificate issuer:
>  /CN=e1977859d071f7150837b2acb4353ff33efd831c
>         Certificate serial:       019BE8C1BFD4ED33FFBFE0409D48662CF8ED
>         Authority key identifier:
> E1:97:78:59:D0:71:F7:15:08:37:B2:AC:B4:35:3F:F3:3E:FD:83:1C
>         Authority info access:    rsync://
> rpki.ripe.net/repository/DEFAULT/4Zd4WdBx9xUIN7KstDU_8z79gxw.cer
>         Subject info access:      rsync://
> rpki.ripe.net/repository/DEFAULT/76/9d7cd7-ee63-4886-8fe1-b5ce6b6fd4d1/1/ygtEKAvCPKS208hGgxgvNBoaYpA.asa
>         Signing time:             Fri 23 Jan 2026 02:49:30 +0000
>         ASPA not before:          Fri 23 Jan 2026 02:49:30 +0000
>         ASPA not after:           Thu 01 Jul 2027 00:00:00 +0000
>         Customer ASID:            215219
>         Providers:                AS: 0
>                                   AS: 6939
>         Validation:               OK
>         Signature path:           rsync://
> rpki.ripe.net/repository/DEFAULT/76/9d7cd7-ee63-4886-8fe1-b5ce6b6fd4d1/1/4Zd4WdBx9xUIN7KstDU_8z79gxw.crl
>                                   rsync://
> rpki.ripe.net/repository/DEFAULT/76/9d7cd7-ee63-4886-8fe1-b5ce6b6fd4d1/1/4Zd4WdBx9xUIN7KstDU_8z79gxw.mft
>                                   rsync://
> rpki.ripe.net/repository/DEFAULT/4Zd4WdBx9xUIN7KstDU_8z79gxw.cer
>                                   rsync://
> rpki.ripe.net/repository/DEFAULT/KpSo3VVK5wEHIJnHC2QHVV3d5mk.crl
>                                   rsync://
> rpki.ripe.net/repository/DEFAULT/KpSo3VVK5wEHIJnHC2QHVV3d5mk.mft
>                                   rsync://
> rpki.ripe.net/repository/aca/KpSo3VVK5wEHIJnHC2QHVV3d5mk.cer
>                                   rsync://
> rpki.ripe.net/repository/aca/7DNNDzoYvgAht7joQih2Qayxcxo.crl
>                                   rsync://
> rpki.ripe.net/repository/aca/7DNNDzoYvgAht7joQih2Qayxcxo.mft
>                                   rsync://
> rpki.ripe.net/repository/ec334d0f3a18be0021b7b8e842287641acb1731a.cer
>                                   rsync://
> rpki.ripe.net/repository/ripe-ncc-ta.crl
>                                   rsync://
> rpki.ripe.net/repository/ripe-ncc-ta.mft
>                                   rsync://rpki.ripe.net/ta/ripe-ncc-ta.cer
>         Signature path expires:   Fri 30 Jan 2026 02:01:06 +0000
>
> What stands out is the "AS: 0" Providers entry mixed with a non-zero
> provider.
>
> When an AS resource holder specifies any non-zero AS as provider IN
> ADDITION to specifying AS 0 (zero) as provider, the outcome of the
> validation algorithm is as if the "AS 0" provider entry didn't exist.
> In other words, the "AS 0" provider entry becomes superfluous in the
> presence of any other non-zero provider entries. Right? From that it
> follows that issuer implementations should not permit subscribers to
> specify AS 0 alongside non-zero provider entries....
>
> I propose we add an extra constraint in Section 3.3
>
> https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-profile-21#name-providers
>
> NEWLY ADDED:
>
> -------------------------------------------------------------------------------
>
>         * When multiple providers are listed, each ASID value MUST be a
> positive integer.
>
>
> -------------------------------------------------------------------------------
>
> What do others think?
>
> and perhaps draft-ietf-sidrops-8210bis should be updated to align?
>
> Kind regards,
>
> Job
>
> _______________________________________________
> Sidrops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>