BGP Path Attribute Filtering - A Powerful Tool to Mitigate Alien Attributes

The BGP Attribute Soup

This was not the first time such a thing has happened, nor will it be the last. IETF is people. People make mistakes. People learn from mistakes. That's the essence of any progress. But how can we protect ourselves against issues like this in the future? Here's a practical guide, for at least some most commonly seen BGP implementations.

So, what is this story about? Most of you are probably already familiar with BGP and all those buzzwords that come along with it, such as Origin, AS_PATH, Local Preference, MED, Communities etc. In short - as you probably know - BGP operates as a rumor mill. Each network connected to the world wild net advertises the IP prefixes belonging to it to its direct neighbors, using BGP, claiming: "Those networks belong to us". The neighbors, hearing that rumor, carry this message further to their neighbors, claming: "Those networks belong to AS number X" and the process repeats itself further on. But then, every BGP-speaking router in the Internet, receiving those rumors, a.k.a. BGP updates, needs to know which update message to trust and which not, which to accept, which to drop, which to pass further. To make this possible, every update message about a set of IP prefixes also contains some additional info. For instance, a sequence of network AS numbers traversed to reach those prefixes. Then, tags added by various operators on the way, known as Communities. Then, various metrics, known as Local Preference and MED. All those additional entities are called BGP Path Attributes and they are standardized by RFC4271.

BGP Path Attributes are a part of each BGP UPDATE message. They are encoded as a vector of TLV (Type, Length, Value) like fields and processed by each BGP-speaking router in the Internet. For the router to be able to recognize them correctly, each Attribute has its unique code, administered by IANA. The official list of BGP Attribute Codes, assigned by IANA, can be found at their BGP Parameters page. For those attributes we can say they are kind of ... hm ... "legal". BGP software developers should know about this list and they should consult it when developing new capabilities, address families or any other BGP features. Should they require a new code during development, the value of 255 is precisely reserved for that. Please, do not "squat" other values! Oh well ...

Alien Attack

Regrettably, the world is not perfect. Squatting of various protocol code points by white and black hats, as well as regular software developers, is not a new issue. So is the case with BGP. As stated in RFC8093, it has been discovered that certain BGP Path Attribute values, not assigned by IANA, have been "illegally squatted" in BGP implementations that have been deployed in the wild. Such an event was noticed when BGP Large Communities [RFC8092] were introduced. IANA assigned the code 30 for those, but when first operators tried large communities in their network the routers started to act strangely. Some of them starting to withdraw routes being tagged with large communities, while some routers running older software simply kept resetting the BGP sessions. Reason? Their software expected a differently-formatted TLV field for the BGP attribute code 30 and as a result, this was treated as an error by their routers. Newer implementations, adhering to RFC7606, caused the routes containing the malformed attribute to be treated as withdrawn and remove it from the routing table, while those more old-fashioned BGP implementations simply followed RFC4271 and torn the BGP sessions down.

But this was not the last such event. A recent one was very similar, although still a bit different in practice. A month ago, people started noticing their BGP sessions resetting, with their routers screaming syslog messages about "alien attributes" coming their way. The "alien", however, turned out to be a "legal alien" - BGP Entropy Label Capability was introduced by RFC6790, as an innovative idea to improve load balancing in MPLS networks. But 3 years later on, this "legal alien" was banned and declared illegal - i.e. deprecated by RFC7447. The reason for banning it was precisely the observed issues with many implementations back then, causing more problems than any good.

However, recently, this deprecated BGP Attribute started to ride along in the BGP UPDATE messages worldwide. Even though in theory this attribute should only be used internally in MPLS networks and should not span in the public Internet, sometimes unwanted messages do leak to the public network. And of course, there are always malicious people spoofing BGP UPDATE packets and trying to disrupt global routing. So, is there anything you can do?

BGP Attribute Filtering

Many vendors offer various possibilities to deal with BGP update messages containing unknown or malformed BGP attributes. In the further text we'll describe most of those and give you some clues what you can do to protect your networks against those events. Of course, the best way to protect yourself would be to always keep track of the IANA list of path attributes and filter out any deprecated, reserved or unassigned values. But that would make your router configurations long, while a new attribute, appearing as a result of technology innovations might cause you to reconfigure lots of routers. Besides, excessive filtering might cause you issues in the future.

A balanced approach to this problem would be to filter out only deprecated values. RFC8093 is certainly a good start. And then, only values that were really used in the past. Values 28, 30, 31 and 129 would definitely be recommended to be filtered out. Other values, falling into the range 130-254 are not likely to be encountered. And even if they are, your software will definitely treat as unknown and discard (or withdraw the route containing them), because no regular BGP implementation parses them anyway.

Cisco - IOS / IOS-XE and FRR

IOS Release 15.3(1)T (or newer) and IOS-XE Release 3.17S (or newer) offer you the possibility to filter out BGP Attributes in BGP Update messages, instructing the router to treat updates containing those attributes as:

• Route withdrawal (treat-as-withdraw), or:
• Discard the attribute whatsoever - the whole attribute is removed from the update message and not propagated further to other peers; valid attributes are processed normally.

In either of the two cases above an inbound Route Refresh to ensure that the routing table is up to date.

The identical feature, with the same syntax, is implemented within the open-source FRR Project.

The best way to simply discard BGP Path Attributes 28, 30, 31 and 129 is to add the following into your BGP configuration:

Cisco - IOS-XR

IOS-XR Release 4.2.3 (or newer) supports BGP attribute filtering. Similarly to IOS and IOS-XE, this feature allows you to withdraw the routes with unknown attributes or simply discard the attribute and process other, valid attributes. To filter out attributes 28, 30, 31 and 129 the following configuration applies:

Juniper Networks - Junos OS - ignore-path-attributes

As of Junos OS Release 10.2 a hidden CLI knob drop-path-attributes is available to make the router simply discard a BGP attribute of your choice from further processing by BGP. Since the drop action takes effect during inbound processing, all issues relating to processing of corrupt attributes are mitigated. This knob can be added either on the global BGP level (in which case it is valid for all BGP peers), BGP group level or BGP neighbor level and it will cause the unrecognized attribute to be dropped, but also not propagated to any other BGP peer, external or internal. That latter behavior, however, may violate RFC4271 - Chapter 5, since it doesn't distinguish between transitive and non-transitive attributes - simply any attribute matching the code in the list is dropped. On the other hand, RFC4271 states:

If a path with an unrecognized transitive optional attribute is accepted and passed to other BGP peers, then the unrecognized transitive optional attribute of that path MUST be passed, along with the path, to other BGP peers with the Partial bit in the Attribute Flags octet set to 1. If a path with a recognized, transitive optional attribute is accepted and passed along to other BGP peers and the Partial bit in the Attribute Flags octet is set to 1 by some previous AS, it MUST NOT be set back to 0 by the current AS. Unrecognized non-transitive optional attributes MUST be quietly ignored and not passed along to other BGP peers.

Luckily, to meet those strict criteria, a similar, also hidden CLI knob, yet a bit different in its behavior, was introduced later on - ignore-path-attributes. Similarly to the above mentioned knob drop-path-attributes this one also instructs the router OS to skip processing attributes listed in the statement. However, contrary to drop-path-attributes , this one keeps the skipped BGP attribute in the original update message and passes it as-is to other BGP peers.

In summary - any of those options you chose, the usage is very simple. To skip processing attributes 28, 30, 31 and 129 you can use:

If you are running multiple routing instances on the router, the best way to apply this knob to all routing contexts is to add the following configuration group to your router configuration:

Juniper Networks - Junos OS - bgp-error-tolerance

Filtering BGP attributes requires revising the router configurations from time to time. What if IANA reassigns once deprecated code points, when we run out of the 8-bit code point space? What if someone still decides that a deprecated attribute is useful and revamps it from the Mordor? Well, that actually happened with the mentioned BGP ELC - now revamped as ELCv2/v3. Sure, for those, a new code point is reserved, but still ... why not seek a more stable, general solution for the problem?

Back in 2012, when IETF community started to work on an enhanced BGP error handling and the first version of draft-ietf-idr-error-handling was published, Juniper implemented a feature in Junos OS Release 13.2 called Revised error handling for BGP update messages, or BGP Error Tolerance. Later on, the mentioned Internet draft evolved into a full standard - RFC7606. Juniper's implementation of this feature mostly follows that RFC. It can be also configured either on the global BGP level (valid for all peers), BGP group level or BGP neighbor level. In its simplest form, on the global BGP level, it's sufficient to add:

This feature has several useful knobs. For more details, please refer to the reference page for bgp-error-tolerance knob.

Conclusion

BGP was designed in the early days on the Internet, when the whole networking world was based on trust, rough consensus and running code. In the current world you can barely trust anyone anymore. Therefore, we're now busy with RPKI, BGPsec and who knows what more. Still, none of those will fully protect you from various routing software bugs that come every now and then. But at least for some of those mitigation mechanisms are in place. So use them!