[Sidrops] Minor comments on draft-ietf-sidrops-aspa-profile-00

[Tim Bruijnzeels <[e-mail]>]

Hi all,

Triggered by an email exchange with Alexander, I figured I would send my (minor) comments on the aspa profile to the list as well.

= Multiple "providerASID"

For ASPA verification it's important that routers get all "providerASIDs" for a "customerASID". Since it's a single "customerASID" who signs the ASPA I think it would be best to allow all "providerASIDs" in a single object. Like so:

OLD:
       ASProviderAttestation ::= SEQUENCE {
           version [0] ASPAVersion DEFAULT v0,
           AFI  AddressFamilyIdentifier,
           customerASID  ASID,
           providerASID  ASID }

NEW:
       ASProviderAttestation ::= SEQUENCE {
           version [0] ASPAVersion DEFAULT v0,
           AFI  AddressFamilyIdentifier,
           customerASID  ASID,
           providerASID  SEQUENCE (SIZE(1..MAX)) OFASID }


Of course it's possible to make separate ASPA objects for each "providerASID", but I think it introduces avoidable risks with no clear benefits. When managing separate objects signing CAs would need to make sure that they publish changes as a set. If RPs use rsync as the fetch protocol they may learn of some, but not all, objects if the repository is being updated just as they are fetching.

The use of RRDP can mitigate this issue, but having a single object in this case is cheap and avoids some of the risks. An RP would always see the full set (for the moment that it validates).


= Small EE certs

The draft currently has:

      The autonomous system identifier delegation extension [RFC3779] is
      present in the end-entity (EE) certificate (contained within the
      ASPA), and the customer AS number in the ASPA is contained within
      the set of AS numbers specified by the EE certificate's autonomous
      system identifier delegation extension.

I think it's better practice to require that:

      The autonomous system identifier delegation extension [RFC3779] MUST
      be present in the end-entity (EE) certificate (contained within the
      ASPA), and MUST contain a single AS number that matches the customer
      AS number. The IP address delegation extensions MUST NOT be used.

The reason for this is fate-sharing. If any of the other irrelevant resources on the EE certificate would no longer be contained on the CA certificate - e.g. because of a resource transfer - then the object as a whole would become invalid.

There is still discussion about transfers and the deployment of 'reconsidered' validation rules. But.. I think that's best discussed outside of this draft. Here it seems that the problems can simply be avoided by having a single AS on the EE cert.


= Add file extension to section 6 (IANA considerations)

In addition to the OIDs I believe a filename extension should be registered. 

   IANA is to add an item for the Signed TAL file extension to the "RPKI
   Repository Name Scheme" created by [RFC6481] as follows:

          Extension  |   RPKI Object              | References
          -----------+-------------------------------------------
           .asp      |   Trust Anchor Keys        | [this document]

(of course feel free to chose another extension - I think four characters: .aspa would also be fine) 

File extensions were introduced to help RPs in parsing - so they don't have to do trial an error parsing of objects as all possible types. The OIDs are not quite enough, because certificates and CRLs are not RPKI signed objects.


Kind regards

Tim