Re: [Sidrops] ASPA duplicates

Hi,

> On 28 Apr 2020, at 19:03, Job Snijders <job@sobornost.net> wrote:
> 
> On Tue, Apr 28, 2020, at 18:53, Jay Borkenhagen wrote:
>> The current ASPA Verification draft:
>> 
>> https://tools.ietf.org/html/draft-ietf-sidrops-aspa-verification-04
>> 
>> .... says in Section 3 "For a selected Customer AS MAY exist only
>> single ASPA object."
>> 
>> I concur that an ASPA object should list every authorized upstream ASN
>> to avoid possible race conditions, and as such it makes sense for only
>> a single ASPA object to exist at any point in time.
>> 
>> But how is that uniqueness to be ensured?  What should RPs do if
>> multiple validated ASPA objects are ever found to exist?
> 
> Good question. What should it do?

In my mind it's good to that CAs can create a single ASPA object for a customer ASN they hold for all their provider(*) ASNs.

But, I think it may be better to cover that CAs SHOULD (or even MUST if you will) combine all provider ASNs on a single ASPA objects as a separate BCP, and leave a bit more flexibility in the profile and validation drafts. This makes it easier to change things, should we find that we need to change our minds on what is best.

I don't think that RPs have to check whether the CA did indeed use a single ASPA object for a customer ASN. I think it should just validate all ASPA objects it finds, and build a list Verified Asn Relations <or insert alternate acronym here>. Furthermore, I think that  8210bis should then specify that the RP (cache) MUST exclude duplicates when sending these relations to routers.

And veering a bit further into that document, I am not sure why those updates should be sent as a single PDU containing all current provider ASNs. I think it make sense to do the same as with ROAs where 'announcement' (add) or 'withdraw' VRPs (excluding duplicates) are sent over RTR. I read the comment about race conditions, but I don't see how this is an issue when such PDUs are sent as a typical exchange (section 8.2) between a Cache Response and End of Data PDUs.

*) relations as defined in draft, not necessarily the business relation.

> I expect such duplicates *will* exist if ASPA were to be deployed for real: in cases where an ASN is transferred from one RIR to another RIR and one wishes to make before break.

Well in that case one would expect objects for the same customer ASN in different parts of the RPKI tree.

But a similar issue could also come up if a parent issues the same ASN to multiple children. Which could be a working model if a large operation operates the same ASN globally, but has different teams managing it. In that case an organisation could chooses to run a delegated CA and issue certificates to child CAs in use by those teams. (I am not sure how likely this is, you have much more operational insight than I do, but it's definitely possible under the standards).

In those cases any of those CAs can issue valid ASPA objects, and they should be combined as above.

Furthermore, the security considerations (section 8) of the AS path verification draft can use some additional words to warn that this also means that any ASPA issuer can potentially invalidate other users of the same ASN if they exist.

Maybe the idea of multiple parties operating the same ASN is ludicrous, but then I think it would be good to have words that discourage delegating the same ASN to multiple CAs, and similarly, discourage issuing ASPA for customer ASNs that are also delegated.

Note that this issue is somewhat similar to ROAs for prefixes which are also (partially) delegated, or received by multiple organisations.

> 
> Kind regards,
> 
> Job
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops