Subject: [Sidrops] Experimental ASPA object published in testbed

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 5 Nov 2021 22:40:17 +0100

Dear all,

It's not my habit to announce new Krill releases here, but... we added
experimental ASPA support to the new release candidate (0.9.3-rc2).

We are running this version in our acceptance environment as a child under
the RIPE NCC Test environment:

https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-test-environment

We have created an ASPA object, based on the latest proposed profile on
the list, at the following location:

rsync://rsync.accept.krill.cloud/repo/accept/0/AS211321.asa

Because there is no official OID yet, and we don't wish to squat one either,
we use a private OID that Ben Maddison set aside for this purpose:

  1.3.6.1.4.1.35743.3.1.1.1.7

We will update this when an official OID becomes available.

If anyone wants to try out the CA side of this, please have a look at
the documentation here:

https://krill.docs.nlnetlabs.nl/en/prototype-aspa-support/manage-aspas.html

Note that to use the CLI for this, you will have to explicitly compile
krill with the 'aspa' feature enabled. Of course we hope to make this all
available by default in future, but at this point in time this is really
meant to support the WG in getting hands-on implementation experience.

Please, do not try to use this under any of the production RIR TAs.

If you have any questions or find any issues, please let me know!

Kind regards,

Tim

---

From: Ben Maddison <[email-masked]>
Date: Thu, 11 Nov 2021 19:48:23 +0200

Hi all,

> rsync://rsync.accept.krill.cloud/repo/accept/0/AS211321.asa
This object can be successfully decoded by rpkimancer-aspa (using the
"tim-revised-profile" branch), using the following ASN.1 module:

    RPKI-ASPA-2020
      { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
         pkcs-9(9) smime(16) modules(0) id-mod-rpki-aspa-2020(TBD) }

    DEFINITIONS IMPLICIT TAGS ::=
    BEGIN
    IMPORTS

    CONTENT-TYPE
    FROM CryptographicMessageSyntax-2010  -- RFC 6268
        { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
          pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ;

    ContentSet CONTENT-TYPE ::= { ct-ASPA, ... }

    --
    -- ASPA Content Type
    --

    id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }

    id-ct OBJECT IDENTIFIER ::= { id-smime 1 }

    id-ct-ASPA OBJECT IDENTIFIER ::= { id-ct 49 }

    ct-ASPA CONTENT-TYPE ::=
        { TYPE ASProviderAttestation IDENTIFIED BY id-ct-ASPA }

    ASProviderAttestation ::= SEQUENCE {
      version [0]   ASPAVersion DEFAULT v0,
      customerASID  ASID,
      providers     ProviderASSet
    }

    ASPAVersion ::= INTEGER  { v0(0) }

    ProviderASSet ::= SEQUENCE (SIZE(1..MAX)) OF ProviderAS

    ProviderAS ::= SEQUENCE {
      providerASID  ASID,
      afiLimit      AddressFamilyIdentifier OPTIONAL
    }

    ASID ::= INTEGER

    AddressFamilyIdentifier ::= OCTET STRING (SIZE (2))

    END

There are several issues I have with this module, most of which have
been discussed previously. It would be great to finish off the
discussion on these so that implementations can stabilise:

1.  Should we keep the enumerations of ASPAVersion, or use a simple
    INTEGER?
    My preference is the latter.

2.  Should we keep the "AS0" method of asserting transit-free-ness, or
    use an empty SEQUENCE OF?
    Again, my preference is the latter.

3.  Should AddressFamilyIdentifier be defined as SIZE(2) (as above), or
    SIZE(2..3) for consistency with 3779?
    I think that the current definition is preferable.

4.  (New, I think) The ContentSet information object set definition does
    not seem to serve any useful purpose.
    I assume the intention is to "extend" the ContentSet defined in
    CryptographicMessageSyntax-2010, but I don't believe that is what
    the above construction means.
    Russ, I think your input is necessary here.

Cheers,

Ben

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 18 Nov 2021 17:01:36 +0100

Hi,

in-line

> On 11 Nov 2021, at 18:48, Ben Maddison <[email-masked]> wrote:
> 
> Hi all,
> 

I have no strong preference - as it amounts to the same on the wire.

>    Again, my preference is the latter.

I have a slight preference for the latter, because I like explicit. But,
in the end what is important is that it's well understood.

If the empty list is used, then it may be needed to cover this case more
explicitly in validation. As in: an explicit empty list would be different
from no ASPA exists for the customer AS. This may also impact 8210-bis.

In that sense AS0 as the only provider, where AS0 cannot naturally occur
in the wild as a real AS, may allow for an easier validation algorithm - similar
to how things are done with ROAs and AS0 as the only ROA for a given prefix.

I realise this seemingly contradicts what I said about preferring explicit,
but what I am trying to say is.. given the impact on other documents I can
live with either.

It would be good to hear what others think.

>    I think that the current definition is preferable.

I agree. In the end the possible values are restricted, so 2-3 always results
in 2 because only 00 01 (v4) and 00 02 (v6) are allowed. But it takes more
parsing of text by RP implementers.

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 26 Nov 2021 09:57:16 +0100

Hi,

> On 18 Nov 2021, at 17:01, Tim Bruijnzeels <[email-masked]> wrote:
> 

Ok, so after re-reading and commenting on the 8210-bis LC..

I am starting to think that it would be best if we stick to a SEQUENCE OF 1..MAX
and use AS0.

I really don't like overloading and implicit stuff, but...

  ASPA for customer AS with no providers != no ASPA for customer AS

The first would lead to 'invalids' by design, while the second should result
in 'not found'. In order to communicate the difference to routers we would
need to add specific PDU handling in 8210 for the no providers case vs no ASPA,
and we would need to revise the wording in the validation algorithm.

I am not convinced that this is worth it. If we would go down the empty sequence
path then we need to explore the impact in terms of changes to the validation doc,
and 8210-bis - for which we would need to reconsider LC then as well.

Tim