Today, we explore an ongoing issue where it looks like an ASN is hijacking address space, but it is actually a router misconfiguration issue that unfairly penalizes certain ASNs.
First, a few vocabulary reminders:
- An autonomous system (AS) is a group of IP prefixes with a clearly defined external routing policy. To interact with other networks, each AS needs a unique autonomous system number, or ASN. There are thousands of ASNs on the Internet.
- A ‘route hijack’ or ‘prefix hijack’ is when a network announces IP prefixes belonging to another network as if those prefixes are theirs. If you need a refresher on hijacking, read “What is BGP Prefix hijacking (Part 1 and Part2)?”.
- AS path prepending extends the AS path length of a prefix advertisement by adding additional AS numbers into the AS Path of an advertised prefix and is often done for traffic engineering purposes (for example, to implicitly cause a router that prefers shorter routes to pick another route first, thereby deprioritizing the artificially longer route).
In recent years, we’ve noticed that single-digit ASNs (ASN1 through ASN9) often appear to be route hijackers. Is this true? We dug into the data and ultimately realized no, single-digit ASNs are not hijacking address space at an alarming rate. What’s happening is the result of a misconfiguration issue because of the “AS path prepend” command on Mikrotik routers. Said simply, using this command on Mikrotik routers can erroneously result in adding what appears to be any of the nine single-digit ASNs at the beginning of the path, essentially “self-hijacking” these routes by adding the wrong ASN in error to the beginning of the path. (Here is a YouTube video of my presentation at NANOG last year that explains the issue in detail.)
In the images below, we see routes originated by AS2, which is assigned to the University of Delaware (RDAP details for AS2).
ASNumber: 2 ASName: UDEL-DCN ASHandle: AS2 RegDate: 1991-01-10 Updated: 2012-06-21 Ref: https://rdap.arin.net/registry/autnum/2
At first glance, AS2 appears to be hijacking prefixes of various network operators around the world. But AS2 is not hijacking these routes at all; this is simply a misconfiguration issue originating in AS134159, AS135216, and all the others mentioned in the above route dump. Unfortunately, many BGP hijack detecting systems will detect this issue as “AS2 has hijacked X.X.X.X/X” because that is what it looks like; it appears that AS2 is announcing routes that it doesn’t and can’t possibly own.
For example, this hijack notification from bgpstream.com suggests that AS2 hijacked 220.127.116.11/24:
On the contrary, it was AS44227 that accidently used AS2 as the origin, by using the errant Mikrotik command referred to earlier. RIPE whois information suggests that 18.104.22.168/24 belongs to AS44227, although why bgpstream.com suggests that this prefix belongs to AS25418 is a discussion for another time, (hint: RADb).
% Information related to '22.214.171.124/24AS44227' route: 126.96.36.199/24 origin: AS44227 mnt-by: BeeMaster-MNT created: 2022-03-08T13:32:08Z last-modified: 2022-03-08T13:32:08Z source: RIPE
The second notification is from GRIP (operated by the Georgia Institute of Technology) showing that AS2 hijacked 188.8.131.52/24, which belongs to AS138362:
The route dump from route-views shows the real issue:
184.108.40.206/24 36236 58682 138362 2 220.127.116.11/24 45437 9498 58682 138362 18.104.22.168/24 63956 58682 138362 2 22.214.171.124/24 32653 6939 58682 138362 126.96.36.199/24 38726 45903 58682 138362 2 188.8.131.52/24 63956 58682 138362 2
Once again, AS138362 is most likely using a Mikrotik router and has made the same misconfiguration error whilst performing the AS Path prepend.
AS138362 is the legitimate holder of 184.108.40.206/24 (see route object in APNIC whois below). AS2 is not hijacking this prefix as it is not a downstream customer of AS138362. AS2 is only shown as originating 220.127.116.11/24 because of the router misconfiguration. Genuine route advertisements from AS2 should show a different path.
route: 18.104.22.168/24 country: BD origin: AS138362 descr: Md. Mobarak Hossain House 34, Road 1, Block A , Bansree mnt-by: MAINT-PLEXUSCLOUD-BD last-modified: 2018-10-22T08:52:35Z source: APNIC
Because AS2 appears to be hijacking prefixes, it may be penalized by other networks by, for example, having its legitimate routes dropped. This is wrong as it is the fault of other networks incorrectly using a command; this problem is also affecting other single-digit ASNs, as we discuss in the NANOG presentation linked above.
A longer-term problem worth mentioning here is if everyone starts to realize intuitively that a router configuration can cause a false positive of a route hijack and ignores these hijacks considering them benign, it might be more attractive for real attackers to use single-digit ASNs to accomplish route hijacks.
This highlights that a routing incident classifier could, for example, keep a list of all ASNs that it infers use Mikrotik routers (based on past misconfiguration announcements of single-digit ASN prepend) and then have a better idea if a new instance is a legit misconfiguration or someone trying to hide a hijack in the noise.
What can we do about it? We can ask Mikrotik to provide more documentation for their customers to try to prevent this problem from happening, or ask Mikrotik to add a warning message when someone attempts to use “set-bgp-prepend-path” instead of “set-bgp-prepend”. We understand removing or replacing the command can be a complicated change and could result in creating more issues but using the ‘set-bgp-prepend-path’ command will result in a single digit added to the beginning of the path. Something must be done.
If you know someone at Mikrotik willing to work with the MANRS community to help resolve the issue, please reach out to us.
This issue highlights how the MANRS Actions work together to safeguard the routing system. With correct ASN-based filtering in place, these errors would be trapped at the point of origin.
In the meantime, MANRS will change the conformance measurements, and ask those networks who accidentally announce their prefixes with incorrect single-digit ASNs to look at their configuration and filtering processes.