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

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 <sidrops-bounces@ietf.org> On Behalf Of Alexander Azimov
Sent: Saturday, March 21, 2020 12:14 PM
To: Randy Bush <randy@psg.com>
Cc: SIDR Operations WG <sidrops@ietf.org>; Martin Hoffmann <martin@opennetlabs.com>
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:randy@psg.com>>:
> 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
Sidrops@ietf.org<mailto:Sidrops@ietf.org>
https://www.ietf.org/mailman/listinfo/sidrops

--
Best regards,
Alexander Azimov