Re: [Sidrops] ASPA duplicates

Hi,

> On 4 May 2020, at 15:39, Randy Bush <randy@psg.com> wrote:
> 
>> 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).
> 
> from draft-ietf-sidrops-8210bis
> 
> 11.  ROA PDU Race Minimization
> 
>   When a cache is sending ROA PDUs to the router, especially during an
>   initial full load, two undesirable race conditions are possible:
> 
>   Break Before Make:  For some prefix P, an AS may announce two (or
>      more) ROAs because they are in the process of changing what
>      provider AS is announcing P.  This is is a case of "make before
>      break."  If a cache is feeding a router and sends the one not yet
>      in service a significant time before sending the one currently in
>      service, then BGP data could be marked invalid during the
>      interval.  To minimize that interval, the cache SHOULD announce
>      all ROAs for the same prefix as close to sequentially as possible.
> 
>   Shorter Prefix First:  If an AS has issued a ROA for P0, and another
>      AS (likely their customer) has issued a ROA for P1 which is a sub-
>      prefix of P0, a router which receives the ROA for P0 before that
>      for P1 is likely to mark a BGP prefix P1 invalid.  Therefore, the
>      cache SHOULD announce the sub-prefix P1 before the covering prefix
>      P0.

Thanks for the pointer! It's unfortunate that there are no transactions, but I accept (already did) that this is what it is.

However, my point which you quoted was about the suggestion that Alexander made that there MUST NOT be multiple ASPA objects for the same customer ASN in the RPKI, and that if there are they should all be ignored - even if they are all valid objects.

At least that was my understanding of his intent. So that there is a simple model to deal with ASNs being present on multiple CA certificates in the RPKI (delegated or different TAs even) and the confusion and race conditions that may arise from managing ASPA objects with that ASN as customer ASN all together. Ignoring the objects provides a soft landing then.

I am not against this per se, but I think *this* needs clarification in the ASPA doc, and possibly some more discussion here. I am sure that it's possible, but it requires that RPs keep more state than they do today.

Furthermore, I see some advantage here (it's a simple model), but as a downside this provides a sort of denial attack where a parent CA can issue an ASPA object to essentially invalidate the object issued by the operational holder of the ASN. Worse, this can happen between TAs, so only one TA would need to be subverted in order to invalidate ASPA objects under any of the other TAs.

For ROAs the RPs just build a complete list of all VRPs found on all valid ROAs anywhere, and only then a set is made and duplicates are excluded when talking to the router. So VRPs appearing elsewhere do not have the power to force other VRPs to the 'ignore list'. For ROAs the advice is that parent CAs have a responsibility NOT to invalidate their children's announcements, and for inter RIR transfers make before break is at least theoretically possible. A similar model could also apply to ASPA objects.

I know this is a political minefield as much as a technical issue. Nonetheless, I think we should make a clear decision which scenario is desired under today's operational reality.

Tim

> 
> randy
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops