Accepting the unacceptable (reserved / unallocated space)

[Jeroen Massar via NANOG <nanog () lists nanog org>]

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/nanog () lists nanog org/message/XOZXIJCX6PPMXXO7MHWFOMQDMDMHIXK2/