BIRD fork for 'Route Leak Mitigation' initiative
BIRD Internet Routing Daemon with built in Route Leak protection This is a fork of BIRD Routing daemon (v1.5.0) with built in protection against BGP 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. This BGP implementation supports full compatibility with other BGP implementations except the case where strict_mode is set by user. Currently, this branch supports mechanism for route leak prevention and procedure for mutual verification of peering relations, which are described in draft-ymbk-idr-bgp-open-policy. Also in branch eOTC_support was added mechanism for route leak detection, described in draft-ymbk-idr-bgp-eotr-policy. Finally, in branch ISP_border in addition you can find some mechanism for supporting new definition of border between two ISP, which is described in draft-ymbk-idr-isp-border. Change in BGP Configuration: In each BGP protocol section you must set a role option. Currently, there are 5 possible values for this option: 1) "provider" - sender is transit provider to neigbor; 2) "customer" - sender is customer of neigbor; 3) "peer" - sender and neighbor are peers; 4) "internal" - sender is part of an internal AS of an organsation which has multiple ASs; 5) "complex" - sender want to use per prefix role policies. Without setting a role in BGP protocol section you will receive error message from config parser. Also you could set strict_mode option in BGP protocol section. In this scenario BGP session with your neighbor will be established only if your neighbor also support Roles and corresponding Role is correct. BGP Protocol modification: There are two main changes in BGP protocol behaviour: 1. BGP Update modification: add mechanisms for route leak prevention using new nontransitive optional BGP PATH attribute iOTC (code 19 in this realization), which is following next set of rules: "a. The iOTC attribute MUST be added to all incoming routes if the receiver’s Role is Customer or Peer; b. The iOTC attribute MUST be added to all incoming routes if the receiver’s Role is Complex and prefix Role is Customer or Peer; c. Routes with the iOTC attribute set MUST NOT be announced if the sender’s Role is Customer or Peer; d. Routes with the iOTC attribute set MUST NOT be announced if the sender’s Role is Complex and prefix Role is Customer or Peer." 2. BGP Open modification: to OPEN messages add new capability option "Role" (Capability code 38 in current realization), in which broadcast value of Role configuration option. Establish connection only if speaker and its neighbor have appropriate pair of Roles: (provider, customer), (customer, provider), (peer, peer), (internal, internal), (complex, complex). How to install BIRD: ./configure make make install Example of configuration with new options can be seen in doc/bird.conf.example Contact: firstname.lastname@example.org Qrator Team.