On 2023-06-07 12:37, Richard Laager wrote:
It turns out I made an error in the IRR prefix enforcement. So while we were enforcing the as-set requirement as intended, we were /not/ enforcing the route object requirement on rs2. Accordingly, I did /not/ make that enforcing on rs1 today as scheduled. Instead, I corrected it on rs2 and will wait another week before making it enforced on rs1.
I have separately emailed everyone who has prefixes being filtered.
From my perspective, I am on track to make this enforcing tomorrow. I have again emailed everyone who has prefixes being filtered. For the last two emails, I added the ARIN WHOIS contacts for the originating ASes (and for one email, the ARIN WHOIS contacts for the IP space involved). I've had a number of email and phone conversations with people. The list has definitely gotten much better. I have begrudgingly made exceptions for two networks. They have ARIN issues to sort out. (Yes, I am aware they could use some other registry and have mentioned that.) These exceptions will be time limited. These exceptions allow specifically the prefixes they are currently announcing that are being rejected. So these exceptions will not defeat IRR security in general (unlike just turning it off for them entirely). These exceptions will be on rs1 only, which will allow them/me to use the looking glass to rs2 to know if things are fixed. As a consequence, their routes will still be filtered when rs1 is down, e.g. for patching. They have been so informed. -- Richard