Implementing RTBH filtering / BGP tagging

[Gregg Berkholtz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks for the help and suggestions, we have a working configuration that now imports and uniquely tags/announces blackhole specific kernel route entries.

For the archives, here's a basic working "example" config. I opted to get away from statically configuring blackhole routes within BIRD itself, as existing tooling adds/removes kernel route table entries on the linux-based router, and keeping this within kernel routing tables is a simpler approach for us.

If using a Linux 2.6 kernel based router, and when tracking blacklisted IPs via a 2nd route table:

To blacklist 192.0.2.44/32, run:
~$ sudo ip route add blackhole 192.0.2.44/32 table 10

Using the below configuration, within 10 seconds BIRD will detect a new addition to kernel routing table 10, and:
 1) Auto-add a corresponding blackhole entry to your kernel's master routing table...truly blacklisting the IP on your router.

 2) Announce 192.0.2.44/32 with a BGP tag of 64665:666 to your upstream provider, enabling you to leverage a customer blackhole community config (e.g. RTBH portion of RFC3882).

Relevant portions of bird.conf:
"...
# Scans and learns of blackhole routes from table 10, every 10 seconds
table blackholes;
protocol kernel blackhole {
  table blackholes;
  kernel table 10;
  scan time 10;
  learn;
  import all;
  export all;
}

# Merges kernel route table 10 into the kernel's active/master routing table
protocol pipe {
  table master;
  peer table blackholes;
  mode transparent;
  import filter {
    print "Importing blackhole list.";
    accept;
  };
}

filter bgp_out_upstream {
  # Limit to blackholed routes
  if (proto = "blackhole" ) then
  {
    # Limit to /32 netmask
    if net.len = 32 then {
      bgp_community.add((64665,666)); # Replace 64665 with your upstream's ASN
      printn "Nulling ";
      print net;
      accept;
    }
  }
  if net ~ [192.0.2.0/24] then accept; # Replace 192.0.2.0/24 with your local netblock(s)
  reject;
}

protocol bgp upstream {
...
  export filter bgp_out_upstream;
...
}
..."

Hope this helps others,
Gregg Berkholtz
Datacenter consulting, hosting & support since 1995
  www.tocici.com  |  503-488-5461 x17  |  AS14613

On Mar 20, 2012, at 3:25 PM, Ondrej Zajicek wrote:

> On Tue, Mar 20, 2012 at 11:42:05AM -0700, Kelly Cochran wrote:
>>> Or much simpler solution - remove secondary tables, add blackhole routes
>>> to bird config as static routes (in static protocol) and have everything
>>> in the master table.
>> 
> 
>> Which is exactly what I wound up doing when testing this sort of thing
>> internally.  Soft config reloads won't bounce the session when you
>> change items in the static protocol.  Good use for an include, generate
> 
> BTW, even 'hard' reconfiguration will not restart the session if there is
> no change in the BGP session protocol (and its filters). The difference
> between soft/hard reconfiguration in BIRD is just whether filter changes
> are considered.
> 
>>> BTW, in the filter bgp_out_he(), i guess you want accept all routes with
>>> proto = "blackhole", otherwise only your routes would be exported (and i
>>> suppose blackholed IPs are foreign).
>> 
> 
>> Blackholed IPs would actually have to be local.  This mechanism is
>> common for dropping a DDoS at your upstream's borders, and not just your
>> own border, as it's presumably not something you can effectively
>> mitigate internally.  Remote IPs would be S/RTBH, and that's not usually
>> seen in transit networks due to the nature of what that would require to
>> affect only the requestor of the blackhole, and not the network as a
>> whole.  (VRFs for everyone!  Wait... that requires how much RAM? 
>> Nevermind...)
> 
> Yes, i thought more about S/RTBH. 
> 
> BTW, to implement other side of RTBH we would probably need to support
> explicit change of received BGP route destination to
> unreachable/blackhole/prohibit type. This currently could by done by
> some tricks, so explicit filter operator for that would be useful, i
> suppose.
> 
> -- 
> Elen sila lumenn' omentielvo
> 
> Ondrej 'SanTiago' Zajicek (email: santiago at crfreenet.org)
> OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
> "To err is human -- to blame it on a computer is even more so."

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAk9zYNkACgkQw+5R43T/iWXgUgCfcH5j2/vF2i40C4RHf5o5gKIV
5C0AoJlSRUJmzzVlAyitQTSWR8NrYmaj
=bn0k
-----END PGP SIGNATURE-----