Subject: Re: [Sidrops] New Version Notification for draft-ymbk-8210bis-00.txt

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Sun, 15 Nov 2020 21:05:09 +0000

One more race condition is more-specifics vs. less specifics.
A less-specific ROA will invalidate a more specific prefix that would be not-found if the ROA were to not exist.
Invalids are increasingly being dropped, whereas not-founds are not dropped and will not be dropped in the foreseeable future.
So this matters.
More-specific ROAs should be updated before less-specific.

Regards,
Jakob.

From: Sidrops <[email-masked]> On Behalf Of Alexander Azimov
Sent: Saturday, March 21, 2020 12:14 PM
To: Randy Bush <[email-masked]>
Cc: SIDR Operations WG <[email-masked]>; Martin Hoffmann <[email-masked]>
Subject: Re: [Sidrops] New Version Notification for draft-ymbk-8210bis-00.txt

The separated records for v4 and v6 ASPA were inspired by the previous research that showed a significant difference in the peering relations in v4 and v6 respectively.
I did this research a couple of years ago, it will be interesting to check if the situation has significantly changed.

I'd like to get the WG attention on the introduced update of ROA processing.
The current version of the RTR protocol related to ROAs is vulnerable to possible race conditions: if the prefix has multiple ROA records or it covering prefixes with different origin asn the state of the partial update may lead to invalidating of really valid prefixes. Here is fresh statistics:
·  16153 IPv4 prefixes with equal (5486) or more specific (11872) conflicts;
·  2250 IPv6 prefixes with equal (1202) or more specific (1164) conflicts.

The current proposal addresses this issue for ASPA and ROAs in a different way:

  *   For ASPA a single PDU per customer AS is neveling the issue;
  *   For ROAs the draft introduces ordering of the updates + suggests sending updates with the same prefix back to back.
The way ROAs will be processed decreases the chances that valid prefixes will be marked as invalid, but they are not zero. My thinking is, that since RTR protocol is negotiating its version at the start of the session there is no need to keep full backward compatibility with the way ROAs were processed previously. Instead, we can change ROA RTR PDUs is the same fashion as it is introduced for ASPA: a single PDU for a selected prefix that replaces previous records.

вт, 10 мар. 2020 г. в 06:22, Randy Bush <randy@psg..com<mailto:[email-masked]>>:
> As a separate note, ASPA in its current form includes the address
> family, ie., it has different ASPA objects for v4 and v6. This is
> missing from the proposed ASPA RTR payload PDU, but luckily there is
> enough zero space to include it.

i believe this is addressed in the draft out today; though not exactly
in the way you suggest.  thanks again for pointing this out.

randy

_______________________________________________
Sidrops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sidrops

--
Best regards,
Alexander Azimov

---

From: Randy Bush <[email-masked]>
Date: Sun, 15 Nov 2020 13:21:56 -0800

> A less-specific ROA will invalidate a more specific prefix that would
> be not-found if the ROA were to not exist. 
> Invalids are increasingly being dropped, whereas not-founds are not
> dropped and will not be dropped in the foreseeable future. 
> So this matters.

rtfd

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.