BGP hijacking and misconfigurations have become increasingly common, some of which can have a rapid and widespread effect on the Internet.
While ‘fat-fingers’ and malicious actors are often reported as being responsible for many BGP ‘anomalies’, there are other common sources that network operators should be aware of, including unassigned BGP AS numbers, BGP attribute 21, and broken 4-byte implementation.
Unassigned BGP AS numbers
Unassigned BGP AS numbers is a well-known issue. Most of the ‘bad’ AS numbers are just out of the range of the private 64512-65534 2-byte and 4200000000-4294967294 4-byte AS ranges. (IANA has the list of the reserved/assigned ranges.)
Examples of such AS paths seen are:
... 10026 38082 65432 38235 24492
... 33891 58599 23688 64645 136813
... 6461 209 4200000006
However, there are still various other unallocated or reserved AS numbers, including:
... 6461 701 703 65817
... 174 11845 65610
... 16637 36974 327074
... 3491 11172 65537
... 6762 3216 65536
... 9829 132717 132717 132717 132717 65542 65544
... 32489 65535
... 15290 23015 23015 23015 23015 230105
Note: These AS numbers should NEVER be visible. Please DO NOT use any reserved or unallocated AS numbers and filter your private AS numbers on external BGP sessions.
During a recent analysis for anomalies by Hurricane Electric using its new Real-Time BGP Toolkit (RT-BGP), we discovered a number of very interesting AS paths from one provider’s BGP feed (Figure 1).
Figure 1 — Unassigned AS report showing weird AS numbers behind a peer.
Further investigation revealed that these paths happen as a result of data corruption between some Brocade (now Extreme Networks), NetIron (on the local side), and Juniper routers (on the remote side). Clearing the BGP session fixed the problem.
We advise that if you are using NetIron routers to check for similar issues. The easiest way to find them is to look for seven-digit or longer AS numbers: “show ip bgp regex [0-9]{7}”.
BGP Attribute 21
Yes, old BGP attributes from IETF drafts that expired more than 10 years ago are still in use.
The AS_PATHLIMIT Path Attribute (draft-ietf-idr-as-pathlimit) has some proposed methods to limit the announcements, by giving a number of maximum AS numbers where a prefix is propagated (and then exported no further). This was implemented with a transitive, optional path attribute.
Figure 2 — Although it’s over 10-years-old, the AS_PATHLIMIT Path Attribute (draft-ietf-idr-as-pathlimit) is still in use.
Having some announcements still using AS_PATHLIMIT might cause problems such as routing loops — most routers today will ignore the attribute and propagate the prefix, but some routers that still have this implemented may drop the prefix. This could cause some loops based on inconsistent routing tables.
The good news is that we have only identified one vendor that still supports and implements this: Palo Alto Networks (see ‘Set AS Path Limit‘). We advise that if you use such a product, then leave this un-configured.
Broken 4-byte implementation
4-byte AS configurations, which are now now standard for any new AS numbers assigned,
are sometimes tricky to implement. The following is an example configuration for NetIron
routers:
isp_router# sh run | incl 64.62.153.98
neighbor 64.62.153.98 remote-as 393338
neighbor 64.62.153.98 next-hop-self
neighbor 64.62.153.98 ebgp-multihop 250
neighbor 64.62.153.98 update-source loopback 1
neighbor 64.62.153.98 remove-private-as
neighbor 64.62.153.98 filter-list 2 in
neighbor 64.62.153.98 route-map out TRANSITout
The broken 4-byte implementation is (luckily) not visible on the network but something we found while adding a peer; RT-BGP uses a 4-byte AS number to force some extended attributes.
One vendor sent us a BGP open message without the 4-byte option and rejected incoming BGP OPEN messages with an invalid AS notification. It turned out that these specific NetIron routers need to have the 4-byte capability enabled.
That the router still allows the configuration of a 4-byte AS neighbor and tries to open it without a 4-byte AS number makes no sense. Only when 4-byte AS capability is turned on (capability as4 enable), will BGP sessions work. There isn’t even a back-off after many failed attempts and the router continues to connect in an incompatible way every few seconds.
Are you monitoring your outgoing announcements?
Monitoring and cleaning up all these relatively minor bugs, misconfigurations, and outdated implementations are easy ways that ISPs can help mitigate the risk of BGP incidents.
RT-BGP Toolkit is just one of many free BGP monitoring services, including RIPE NCC’s Routing Information Service, that allows network operators to troubleshoot and analyze BGP announcements, track potential hijacks, and record unusual BGP activity on their network — please use them and verify your announcements today!
The above is a summary of a presentation I gave at RIPE 76.
Martin Winter is a researcher working on the RT-BGP toolkit for Hurricane Electric Internet Services. He is a co-founder of NetDEF (Network Device Education Foundation), where he works on FRRouting, a free open-source routing stack.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.