Goal
This initiative aims to simplify the process of BGP configuration and, as a result, avoid route leaks. Route leak is a network anomaly, when route learned from provider or peer is announced to another provider or peer. The effect of such issues could vary from increased network delays for victim (originator of prefix) to DoS for both victim and leaker. According to our research main reason of these routing issues are mistakes in BGP configuration.
Today a proper announce distribution could be implemented using communities, which are optional. We believe that the mechanism of route leak prevention and detection should become solid part of BGP routing protocol.
Technical description
To achieve this goal we propose adding mandatory Role option in each BGP session configuration section. Roles reflect the real-world agreement between two BGP speakers about their business relationship. This Role option could have only 5 possible values: customer, provider, peer, complex and internal.
But the mere presence of BGP Role doesn't automatically guarantee role agreement between two BGP peers. To enforce correctness, new capability option “Role” was added, which uses value from Role configuration option. BGP session will be established only if speaker and its neighbor have appropriate pair of Roles: (Provider, Customer), (Customer, Provider), (Peer, Peer), (Complex, Complex), (Internal, Internal).
We also propose a strict mode. This is a specific option which is set for each BGP session independently. By default, if a neighbor doesn’t use roles, the BGP session will establish. This approach guarantees full backward compatibility. But in strict mode speaker must send a notification if the role is not set. This mode could become a good mechanism of motivation during adoption of this BGP extension.
To automate process of leak prevention we propose new non-transitive optional attribute Internal Only to Customer (iOTC). This attribute has zero length as it used only as a flag. It has quite simple usage:
- The iOTC attribute must be added to all incoming routes if the receiver's Role is Customer or Peer.
- Routes with the iOTC attribute set must not be announced if the sender's Role is Customer or Peer.
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 general problem of route leak propagation. To detect route leaks created by foreign parties we add new optional transitive attribute External Only to Customer (eOTC). eOTC is set when route is announced to peer or customer and its value equals to autonomous system number (ASN), which set it. This gives simple way to route leak detection – if route speaker role is provider or peer and eOTC attribute is set and its values is not equal to neighbor ASN then it signals that this route was leaked. Such route should be deprioritized or may be filtered.
Together Roles, iOTC, eOTC could bring comprehensive solution to route leak problem.