Subject: [Sidrops] draft-ietf-sidrops-aspa-profile add ASPANumber?

From: Job Snijders <[email-masked]>
Date: Fri, 8 Oct 2021 14:47:33 +0200

Hi all,

Similar to how in RPKI Manifests there is a BigNum embedded in the
eContent to help figure out which object is the 'most current', there
may be benefits to adding such a number to ASPA objects too.

Doing so would change the ASN.1 to the below:

    ct-ASPA CONTENT-TYPE ::=
        { ASProviderAttestation IDENTIFIED BY id-ct-ASPA }
    id-ct-ASPA OBJECT IDENTIFIER ::= { id-ct TBD }
    ASProviderAttestation ::= SEQUENCE {
        version     [0] ASPAVersion DEFAULT v0,
        AspaNumber      INTEGER (0..MAX),          -- NEW ELEMENT
        aFI             AddressFamilyIdentifier,
        customerASID    ASID,
        providerASSET   SEQUENCE (SIZE(1..MAX)) OF ASID }
    ASPAVersion ::= INTEGER  { v0(0) }
    AddressFamilyIdentifier ::= OCTET STRING (SIZE (2))
    ASID ::= INTEGER

Some suggested natural language text:

"""
    Aspa numbers can be expected to contain long integers. ASPA verifiers
    MUST be able to handle number values up to 20 octets. Conforming
    ASPA issuers MUST NOT use number values longer than 20 octets.

    Select the CA's current ASPA (the "current" ASPA is the ASPA issued
    by this CA having the highest AspaNumber among all valid ASPAs, and
    where ASPA validity is defined in Section 4).
"""

Note: The above doesn't fully resolve all possible duplication
scenarios, for example if two CAs are entitled to issue statements for a
given ASID, which of the two to pick?

Thoughts?

Kind regards,

Job

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 8 Oct 2021 15:28:40 +0200

Hi Job, all,

> On 8 Oct 2021, at 14:47, Job Snijders <job=[email-masked]> wrote:
> 
> Hi all,
> 

My take on this: don't.

No, I am not trying to be negative :)

TL;DR:
I think this is covered because the manifest has a number and it refers
to ASPA objects by name and hash.

The extended version:

I would expect multiple ASPA objects under a single CA. As written it
would have to be one per "customerASID" and "aFI". So, if "AspaNumber"
is to be used then I would expect it to be tied to these values at least.

Keeping track of this adds a fair amount of state tracking. What if an
ASPA is added for a "customerASID" and "aFI", then removed completely,
and later a new ASPA is added for the same "customerASID" and "aFI".
Should we keep history, and then continue counting? Why would this matter
when validating? Would RPs keep track of numbers of previously removed
ASPA objects?

Even if CAs MUST (as section 3 says) issue a single ASPA per "customerASID",
multiple CAs publishing ASPAs for the same customer AS can be a feature
of either resource transfers, or organisations moving from one CA
implementation to another. There is also nothing stopping operators from
delegating the CA to multiple child CAs who all issue ASPAs for it. No,
this is probably not the best idea, but it's possible.

I realise we still need to do work on RTR for ASPA, but I imagined it
would work in a similar way to ROAs, i.e. in the end routers should
get something like "Verified ASPA Payloads" -- VAPs :), a list of tuples:
  (customer as, provider as, afi)

If multiple valid ASPAs are published for the same customer ASN, then get
the union of all VAPs, excluding duplicates. Just like we do with ROAs
and VRPs.

Tim

> 
> Kind regards,
> 
> Job
> 
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Job Snijders <[email-masked]>
Date: Fri, 8 Oct 2021 13:49:11 +0000

> to ASPA objects by name and hash.

Ah, good point. Thanks, Tim.

Kind regards,

Job

---

From: Geoff Huston <[email-masked]>
Date: Fri, 8 Oct 2021 21:59:40 +0000

This seems like an odd and somewhat extraneous adornment to me. Why wouldn’t a ASPA publisher simply revoke the certificates of the ASPA’s that it wanted to “unsay”? What is the point of leaving valid detritus lying around?

> On 8 Oct 2021, at 11:47 pm, Job Snijders <job=[email-masked]> wrote:
> 
> Hi all,
>

---

From: Job Snijders <[email-masked]>
Date: Fri, 8 Oct 2021 22:12:27 +0000

On Fri, Oct 08, 2021 at 09:59:40PM +0000, Geoff Huston wrote:
> This seems like an odd and somewhat extraneous adornment to me. Why
> wouldn’t a ASPA publisher simply revoke the certificates of the ASPA’s
> that it wanted to “unsay”? What is the point of leaving valid detritus
> lying around?

Good observation on top of Tim's point, thanks Geoff.

Kind regards,

Job