The dark side of BGP community attributes

A while ago, RIPE Labs published the two-part article BGP Communities – A Weapon for the Internet. That may have been a bit of a shock for those of us making good use of BGP community attributes as an important tool in our BGP arsenal.

Those of us a little less familiar with BGP communities might even think this is some part of the RIPE community. However, of course, the RIPE community is the community of people involved with running the European internet, related to, but separate from the Réseaux IP Européens Network Coordination Centre (RIPE NCC), which gives out IP addresses and BGP AS numbers in Europe, the former Soviet Union, and the Middle East.

BGP community attributes, on the other hand, are little tags attached to the IP address prefixes that are exchanged through the BGP protocol. We covered BGP communities in previous Noction blog articles, starting with Understanding BGP Communities and then Using communities to filter BGP announcements. Also, see the BGP Inbound Traffic Engineering article in our knowledge base.

Note that there are different types of communities: the regular 32-bit ones defined in RFC 1997 are by far the most common. They look like 3356:123, 3356:2003, 3356:9999, or similar. The 32-bit value is displayed as two 16-bit numbers converted to decimal separated by a colon. In most cases, the first number is the AS number of the network that defined the community. The second number then conveys the desired information. However, this only works with traditional 16-bit AS numbers. For 32-bit AS numbers, we need to use large communities, as defined in RFC 8092. These allow for three 32-bit numbers with colons between them, with the first being the 32-bit (or 16-bit) AS number of the defining network. There are also extended communities (RFC 4360), but these are less common and used for different purposes.

Networks (especially larger ISPs and carriers) define BGP community attributes for three purposes. First of all, for internal use (filtering). In a large network with many BGP customers, customer prefixes are tagged with one community and prefixes learned from peer networks with another community. This way, customer prefixes can be propagated to peers, but prefixes learned from one peer aren’t propagated to other peers, which would be bad. The other uses for BGP community attributes are to provide information to customers and peers and to allow customers to request certain actions.

For instance, 3356:123 means a prefix belongs to a Level3/CenturyLink (AS 3356) customer. 3356:2003 indicates a prefix learned by AS 3356 in Los Angeles, and customers can attach 3356:9999 to a prefix to request that AS 3356 blackholes all traffic towards that prefix. And that’s something that may not happen as desired in all cases.

Possible attacks

So let’s have a look at the RIPE article. First of all, it notes that BGP community attributes usage is increasing, with the number of communities seen by BGP data collection services almost tripling between 2010 and 2018.

The article calls communities used by networks to convey information “passive” and communities that trigger actions “active”. However, there are very few standardized communities, so without documentation (which some networks link on their PeeringDB page), there’s no way to know if a BGP community attribute is a passive or active type. Obviously, passive communities won’t cause any issues, but active communities can. To complicate the issue further, many networks will propagate communities they don’t recognize: the article observes that 50% of communities survive at least four AS hops. And after multiple hops, there is no way of knowing which AS earlier in the path attached a given community.

Because of this, the article states “our assessment here is that there is a high risk of misuse or even attacks!”

Such an attack could happen based on the remote triggered blackhole system based on BGP communities. This system is described in the previous Noction blog article The Number of the Beast or the Practical usage of the Blackhole Community. This system is usually used by networks that are under a denial-of-service attack where one or a few of their addresses receive large amounts of unwanted traffic. The network then injects a prefix into BGP that only covers the address or addresses under attack. A blackhole community defined by their transit ISP is attached to this prefix. The normal advertisement for the network’s full prefix or prefixes remains in place unchanged.

As a result, the transit network filters out all traffic towards the address or addresses in question. This way, although the attackers have succeeded in making the address they attacked unreachable, at least the rest of the network is no longer overloaded by the attacking traffic.

But what if it’s not the network owning a certain prefix that advertises a more specific with a blackhole community? The article has an example where another transit provider of the target network does this. (Even though it’s usually not good business practice to attack your customers.) In this case, the transit network doing the blackholing wouldn’t filter that prefix, as the path through the second transit provider is a valid path. However, with less rigorous filtering, a network that provides a blackholing service may actually accept a blackhole route from completely unrelated networks.

Without robust automatic sanity checking built-in in BGP, it’s extremely important that transit ISPs have good filters, so only the legitimate owner/user of a prefix gets to advertise that prefix to the rest of the world. But even some networks that otherwise have good BGP filters may be vulnerable to abuse of the remote triggered blackhole mechanism: if they apply the blackholing before applying regular BGP filters or RPKI.

Apparently, such attacks have already happened in the wild.

See the second part of the article for a number of recommendations to defend against such attacks.

In addition to those recommendations, it’s a good idea for networks providing remote triggered blackhole functionality to limit this to prefixes with a one-hop AS path. Then combine this with RPKI, which enforces the correctness of the origin AS in AS paths. With a one-hop AS path, the RPKI origin thus validates the entire AS path, which it normally can’t do. This should make it impossible for third parties to trigger unwanted blackholing.

Communities = weapons?

This community-based attack is definitely something we need to be prepared for and defend against. But does this warrant considering BGP communities “a weapon for the internet”? That seems a bit extreme. It’s hard to see how we could make today’s internet routing happen without BGP communities—they’re an indispensable tool. But communities make the already complex operation of BGP in large networks even more complex, allowing for unforeseen problems. So treat your BGP communities with respect, you don’t want to encounter their dark side.