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: mail@qrator.net
Qrator Team.