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

[Tim Bruijnzeels <[e-mail]>]

Hi Randy, Alexander (this should also answer your point), all

> On 7 Oct 2019, at 02:07, Randy Bush <[e-mail]> wrote:
> 
> i have not thought deeply abut this.  but it seems to me that, as in
> ROAs, one enters into and leaves relationship with a provider.  whacking
> a multi-AS ROA or a multi-provider ASPA record seems ill advised.  for
> example, what if there is a delay between delete and recreate?
> 
> keep things simple, please.

I am all for keeping things simple, but we may have different ideas of what is simple :) We can also do multiple ASPA files, but I don't think that it's really much simpler and because there are more files involved I think there are more chances of delays between publish, withdraw and updates.

Let me try to make the case once more for single objects with multiple provider ASNs. TL;DR: I still think it's slightly better, but it's not a showstopper to me. And contrary to ROAs there is no fate sharing issue here.


= Simplicity

Looking at how I would implement this (hopefully in the near future!) I would let users of the CA software configure which ASNs they want to authorise as the next hop after their own ASN. Suppose that I can create a single object with all these ASNs, I would publish this all in a single signed object with a determinate name, e.g. based on the key identifier of the CA certificate key, just like is commonly done for CRLs and MFTs. Then, whenever there is an update, I would publish a new object in place of the old. To me this is actually simpler than maintaining multiple objects. It also ensures that there is no delay between delete and recreate. 

= Mismatches (race condition between RP and CA/publisher)

In the remote, but possible, event that an RP which uses rsync gets the updated ASPA file, but the old MFT - or vice versa, then the outcome is dependent on local interpretation of section 6.6 of RFC6486 (Hash Values Not Matching Manifests), but in most implementations that I know it would lead to rejection of the ASPA object. Some implementations might accept it and warn. But whatever the case, if a single object is used this would mean that there is either a complete set of upstream ASNs, or the set is empty - which would mean that all customer-provider checks fall back to "unknown" (https://tools.ietf.org/html/draft-ietf-sidrops-aspa-verification-01#section-4 <https://tools.ietf.org/html/draft-ietf-sidrops-aspa-verification-01#section-4>).

Note that CAs using RRDP will publish the new MFT, CRL and ASPA object as a single delta, and therefore RPs supporting RRDP would not be affected by this issue.

= Analogy to ROAs

As for ROAs, I think the ship has sailed on the spec. 

ROAs can have multiple prefixes, which are 'signed' (through the EE cert etc etc), and a single ASN. There has been discussion in sidrops (and sidr?) regarding not putting multiple prefixes on ROAs, as the spec allows. The main reason being that the loss of any one resource in any prefix would invalidate the ROA as a whole; all prefixes would be 'fate-sharing'. So there was advice to only use a single prefix per ROA, or well I suppose that more specific sub-prefixes are okay, e.g. if there is a /20 on a ROA, then rather than having a global max length it would be fine to have explicit more specific /24s there. However, I don't think that this advice has been incorporated in a formal BCP. I think that RFC7115, BCP-185, "Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)" predates this discussion.

Since ASPA object have a single "customerASID" which has to appear on the signing EE certificate, so for ASPA this fate sharing is not an issue, as long as the issuing CA uses a small EE cert with just that single ASN (as I suggested in my previous email).



Tim











> 
> randy