Re: [Sidrops] ASPA duplicates

[Alexander Azimov <[e-mail]>]

Hi Tim,


вт, 5 мая 2020 г. в 10:45, Tim Bruijnzeels <[e-mail]>:

> Hi,
>
> > On 4 May 2020, at 15:39, Randy Bush <[e-mail]> 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.
>
I do agree. In this thread was raised the proper question which wasn't
covered by the current draft and we may have found the proper answer.
I'll add clarification with the next update.


> 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.
>
If we ignore duplicate object it can't be used for DoS. The draft doesn't
suggest any actions against 'unknown' paths.
The question of what happens if one TA issues invalid records for address
space/ASNs that are operated by another TA where such records do not exist,
should be discussed separately if we admit such an attack vector. IMO it is
highly unlikely, but if it happens can already lead to global connectivity
disruption.


> 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 believe the operation requirements for address space transfer is
different from the ASN transfer from one RIR to another. But even in the
ROA scenario, different ROAs existing in two RIRs simultaneously might
cause problems.


> 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.
>
The ASN transfers do happen, but as far as I know, it doesn't represent
common day-to-day operations. IMO the security reasoning should prevail for
ASPA and might be reconsidered for ROA.