This initiative aims to simplify the process of BGP configuration and, as a result, avoid route leaks. Route leak is a network anomaly occurring when the route learned from a provider or a peer is announced to another provider or peer. The effect of such issues may vary from increased network delays for the victim (originator of prefix) to DoS for both the victim and the leaker. According to our research, the main reason of these routing issues lies in the mistakes of BGP configuration.
Today, a proper announce distribution can be implemented using communities, however their usage remains purely optional. We believe that the mechanism of route leak prevention and detection should become a solid part of BGP routing protocol.
To achieve this goal we propose adding a mandatory Role option in each BGP session configuration section. Roles reflect the real-world agreement between the two BGP speakers about their peering relationship. This Role option could have only 4 possible values: Customer, Provider, Peer and Internal.
But the mere presence of BGP Role doesn't automatically guarantee any role agreement between two BGP peers. To enforce correctness, we need a new capability option “Role” which takes its values from the Role configuration option. With that in mind, a BGP session will be established only if the speaker and its neighbor have an appropriate pair of Roles: (Provider, Customer), (Customer, Provider), (Peer, Peer), (Internal, Internal).
We also propose a strict mode. This is a specific option set for each BGP session independently. By default the non-strict mode is used -- if a speaker’s neighbor doesn’t support the role mechanism, the BGP session will be established anyway. This approach guarantees full backward compatibility. But if the strict mode is enabled the speaker must send a notification in case the role is not set. This setting can be a good source of motivation during adoption of this BGP extension.
To automate the process of leak prevention we propose new a non-transitive optional attribute Internal Only to Customer (iOTC). This attribute has zero length as it is used only as a flag. It has quite simple usage:
So, iOTC models proper configuration of communities, but in automated way and as solid part of BGP.
While automatic leak prevention could be very helpful for newcomers, it will not solve the general problem of route leak propagation. To detect route leaks created by foreign parties we propose to add a new optional transitive attribute External Only to Customer (eOTC). eOTC is set when the route is announced to a peer or a customer and its value equals to autonomous system number (ASN) by whom is was set. This gives a simple way to detect route leaks – if the route speaker’s role is set to Provider or Peer and the eOTC attribute is set to a value unequal to its neighbor’s ASN, it sends a signal saying that this route was leaked. Such route should be deprioritized or may be dropped.
Given together, Roles, iOTC and eOTC can form a comprehensive solution to the problem of route leaks.