In an early version of TCP, published in RFC761, Jon Postel wrote a paragraph that became known as his robustness principle:

TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.

This principle has been applied to most Internet protocols. For protocols that exchange a small amount of data, this principle can easily be supported. For BGP, that uses TCP connections that never stop, this can be more difficult. BGP routers use BGP sessions to synchronize their routes. How should a BGP router react if it receives over an existing session a BGP message that it does not understand and cannot decode ? Since BGP runs above TCP, this errored messages should not be due to a transmission error but due a malfunction in the peer router. If the peer router is misbehaving, then it becomes difficult to trust the routes received from this peer. The BGP specification recommends to send a NOTIFY message and close the BGP session upon reception of a malformed message.

When a BGP session is reset due to a malformed message, the two communicating BGP routers need to update their routing tables and remove all the routes received from the peer. The BGP session is then brought up again to exchange all the routes and hope that no malformed message would arrive…

Network operators monitor session resets and recently routers had to reset some of their sessions because they received a malformed attribute 28. Emile Aben analyses these resets in an interesting blog post. The root cause of these session resets is not yet known, but this is not the first time that some routers are affected by malformed messages. In 2010, an experiment resulted in a disruption of a significant percentage of the global Internet traffic during 30 minutes.

RFC7606 has argued for a less rigid approach to handle malformed BGP messages. We’ll see in the coming years whether its deployment reduces the disruptions caused by malformed messages.

You can follow this blog by subscribing to its RSS feed or by following @cnp3_ebook on mastodon.