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

[Alexander Azimov <[e-mail]>]

Hi Tim!

Thank you for the detailed overview.

Correct if I'm wrong, the mentioned problem with rsync can also affect
ROAs, am I right? For ROA it is just less critical since prefixes with
multiple originators are not the majority of the routing table.

ср, 21 авг. 2019 г. в 12:11, 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
>
>
>
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops
>


-- 
Best regards,
Alexander Azimov