Accepting the unacceptable (reserved / unallocated space)

Hola all,

TLDR: Can people call their sales contacts (the ones cold calling everybody normally) at transits/hosters and ask why they are forwarding BGP prefixes from reserved/unallocated ASN/prefixes?


A wee bit of a long rant... but maybe we can make the Internet finally a wee bit better:

For many many many years already, Geoff Huston has been monthly sending out the CIDR Report to various NOG lists.

In that report there is a section of Unallocated and Reserved ASNs and Prefixes being announced wild on the Internet:

https://www.cidr-report.org/#Bogons (IPv4)
https://www.cidr-report.org/v6/as2.0/#Bogons (IPv6)

There are vasts amounts of unallocated/reserved space being allocated, or worse IMHO, ASNs in the path that are reserved/unallocated. Fun ones like the DoD, Department of Defense eh War apparently... should be even a national security concern would they not be? Noting that even big cloud "security" folks have prefixes they do not check their customers for: eg https://bgp.tools/prefix/216.120.131.0/24 or https://bgp.tools/as/40186#connectivity
but there are many transits, for which we pay bits, who do not filter either...


That means, even if anybody normally would even reply to an abuse message for known prefixes (some sites still do fortunately answer, but with webforms as abuse reporting etc it is rarer and rarer, let alone that action is done) there is no abuse contact as there is these are unknown what is actually behind it, except: the upstreams = transits.

It definitely means though that whatever ASN is passing that BGP on, that they did not do their due diligence on who their customer is, if they are allowed to announce that prefix, or even if that ASN is theirs to announce (and reserved/unallocated means, that it is not).


In the current world, not everybody checks RPKI ROA's yet, let alone ASPA, but they should, and it is relatively cheap to do. As most ISPs and transits do not yet though, we cannot yet rely on ROA = VALID to accept prefixes as there are too many that are currently UNKNOWN. Improving that status by implementing ROV validation would help the Internet at whole a lot.


Anybody playing transit though MUST do that: when they require RPKI ROA validity from their customers, it ensures that they are not passing on BGP announcements that are invalid. Even if the clients status with a RIR changes.

If a transit sees a prefix that is ROA UNKNOWN, that should ring alert bells; in the same way that if one sees a prefix in the CIDR report with your ASN in that path, check it out, fix it.


APNIC actually publishes an AS0 ROA for unallocated/reserved space.
https://www.apnic.net/community/security/resource-certification/apnic-limitations-of-liability-for-rpki-2/
though as one can see from the lists above, even APNIC space is included in those very lists, received by APNIC...
Seems nobody honors that AS0 ROA either ;)


With all the aggressive scraping happening today, it would be good to at least kinda attribute that to something, which is hard when there is not even a real registered entity behind a prefix or ASN (unless one blames the upstream!).


Thus next to demanding from your transits that they know their customers and that those are legit to pass traffic, one could verify it yourself.

Where can you find the unallocated/reserved data? at the RIRs, in the delegated files:

https://ftp.afrinic.net/pub/stats/afrinic/delegated-afrinic-extended-latest
https://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-extended-latest
https://ftp.apnic.net/stats/apnic/delegated-apnic-extended-latest
https://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest
https://ftp.arin.net/pub/stats/arin/delegated-arin-extended-latest

The data is there (as used by CIDR-Report), thus one can verify this.

One trick I do is to generate a unallocated.json in the style of rpki-client.json (see https://console.rpki-client.org <https://console.rpki-client.org/> and then the /rpki.json link from there) and feed that to StayRTR (https://github.com/bgp/stayrtr/) in a separate instance from the normal ROA edition. Then simply check if prefixes are VALID (as that means there is a fake ROA for them) and voila, reason to take action, read: drop, that prefix/ASN.

Currently a rpki-client.json is about 100MiB / 980k lines, an unallocated.json comes in at 40MiB / 333k lines


Of course, the only advantage is that it is a few prefixes less of possible abuse, as noted, abuse reporting has been long as good as dead, and the actors behind various attacks just use residental proxies nowadays that are everywhere...

End of rant, back to your 'operational issues', good luck out there, especially those in heatwaves, forest fires and facing other problems...

Regards,
 Jeroen

_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/[email protected]/message/XOZXIJCX6PPMXXO7MHWFOMQDMDMHIXK2/