Re: [Sidrops] ASPA duplicates

[Tim Bruijnzeels <[e-mail]>]

Hi,

> On 2 May 2020, at 20:39, Alexander Azimov <[e-mail]> wrote:
> 
> Thank you all for comments.
> 
> First of all, I'd like to address the reasons for that change at the side of RTR.
> 
> And the comparison with ROA is important. The RTR documents don't say that "you MUST apply diff after receiving EOD", instead it is applied incrementally. So, the race in the updates for selected address space may invalidate the correct routes. One may say that finally, all data will become consistent and the router will make a proper marking. Unfortunately, it's not true for two reasons:
> 	• You never know when all data will arrive, there may be every kind of network issues between cache and router (and it's TCP after all);
> 	• Even if all updates finally arrives some routing software will keep the result of original verification. I'm not sure how it is covered with RFC, but I know that such implementations exist.
> As a result, we may end with hard to debug prefix propagation issues. These race conditions are partially addressed in the RFC8210bis by adding order to the ROA updates - from more specific to less specific routes. It solves the problem with less specifics, but issues for prefixes that have multiple records may still exist.
> 
> In the ASPA, we are trying to prevent race conditions from happening. And the easiest way is to guarantee the atomicity of updates for each key-value pair. In our cases - to pack all ASPA records for the selected customer AS into one PDU. I hope this will make clear the motivation why ASPA PDU is different from what we have now for ROA. Btw, I will vote to update ROA too (and the update of RTR is a good time for such change, there is no requirement for compatibility between versions).
> 
> The way new ASPA records are issued and the way they are received by RTR (rsync?) is another place for race conditions. And it seems native to guarantee consistency the same way - making a single ASPA object, thus preventing possible misconfigurations.

Ok, understood. Makes sense now.

> Now the question - what should be done if RTR cache receives multiple RTR records for ASPA? Let's discuss possible scenarios:
> 	• There is misfunction at the level of RPKI software that issued records;
> If we face a bug in the hosting RPKI software it should be gracefully processed, without effect on operations.
> 	• Tim's example with administrative domain splitting;
> The administrative domain splitting in RPKI doesn't seem to be a good idea, it significantly increases chances to get in the state with a partial set of customer-providers pairs with hardly predictable outcomes.  
> 	• Transfer between RIRs.
> And the last seems to be on the same board - such semistate isn't safe, and one should keep one record at any point in time.
> 
> Keeping in mind that the absence of ASPA record is less dangerous then inconsistent state my thinking is that if RPKI cache receives multiple ASPA records for selected customers AS it should ignore all of them. IMO looks like a fair good compromise: prevent race conditions and also do not have an effect on operations if something goes wrong.

This might not be easy for existing RPs - with ROAs the thought has also been that they are cumulative. Now you would need to keep much more state, and even check between all configured TAs - which until now could just be processed in parallel.

I understand your reasoning, but I think this warrants at least some normative wording in the document and discussion in the security section. And most importantly I am curious to learn what RP software implementers think (nowadays I do the CA side, which is much easier in this context).

Tim


> 
> 
> ср, 29 апр. 2020 г. в 15:26, Tim Bruijnzeels <[e-mail]>:
> Hi,
> 
> > On 28 Apr 2020, at 19:03, Job Snijders <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sidrops
> 
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops
> 
> 
> -- 
> Best regards,
> Alexander Azimov