October 2020 - Bird-users

handling of unreachable routes with gateway direct
by Alexander Zubkov 22 Nov '20

22 Nov '20

Hello, We have some routes that are passed via transit bird bgp-daemons without installing them to the kernel. And for some of these routes we need to keep their next hop attribute, because it is meaningful on the destination host, but may be unreachable on those transit hosts. If we have "gateway recursive" sessions with these transit hosts, then such routes are accepted, just marked unreachable, but we can work with them. And if we make the sessions "gateway direct", then such routes are ignored by the bird with "Invalid NEXT_HOP attribute" messages in log. Looks like it is caused by this piece of code in proto/bgp/packets.c in function bgp_apply_next_hop(): if (!nbr || (nbr->scope == SCOPE_HOST)) WITHDRAW(BAD_NEXT_HOP); It seems reasonable, of course, but it breaks things for our case. So I want to suggest some changes to make our setup possible. At the moment, I consider the possibility of adding something like "gateway <direct_with_recursive_fallback>" so that it would behave like "gateway direct", but in the case of a non-reachable neighbour, it would switch to recursive logic. What do you think? Whether this is a good idea or maybe you can suggest some better variants? We have a couple of reasons why we want "gateway direct": We want to avoid double recursion, which is not allowed - we might have some other recursive routes that use direct routes received in this session. We could make separate sessions for direct and transit routes, but I'm not sure that the whole thing would be simpler. And there is an issue with next-hop resolution when we have the same ips on different interfaces. As I understand, bird daemon currently does not support that case.

2 4

BIRD 2.0.7 Segmentation fault when using receive limit
by Pier Carlo Chiodi 19 Nov '20

19 Nov '20

Hello, I'm getting a "Segmentation fault" error on BIRD 2.0.7 when I use 'receive limit X'. I've got the error when using either 'action block' or 'action disable'. In the same scenario, if I change the config to use 'import limit X' everything works fine. The error happens as soon as the daemon receives the first "extra" route from its peer (in the example, the 5th route while the limit is 4). Output of '-d -f' can be found at the bottom of this msg. If the number of routes received from the peer is equal to the limit, the issue is not hit. I was able to consistently reproduce what I've mentioned above using the following config on a Docker container based on Debian 10.1 (Linux f484b919cd3a 4.19.76-linuxkit #1 SMP Tue May 26 11:42:35 UTC 2020 x86_64 GNU/Linux - Dockerfile can be found here https://github.com/pierky/dockerfiles/blob/master/bird/2.0.7/Dockerfile) BIRD 1.6.8 works fine. Thanks. Pier Carlo router id 192.0.2.2; define rs_as = 999; log "/var/log/bird.log" all; log syslog all; debug protocols { states, routes, filters, interfaces, events }; timeformat base iso long; timeformat log iso long; timeformat protocol iso long; timeformat route iso long; protocol device {}; ipv4 table master4 sorted; ipv6 table master6 sorted; filter receive_from_AS1_1 { if !(source = RTS_BGP ) then reject "source != RTS_BGP - REJECTING ", net; if !(net.type = NET_IP4) then reject "AFI not enabled for this peer - REJECTING ", net; accept; } protocol bgp AS1_1 { local as 999; neighbor 192.0.2.11 as 1; rs client; passive on; ttl security off; interpret communities off; # --------------------------------------- ipv4 { table master4; secondary; receive limit 4 action block; import table on; import keep filtered on; import filter receive_from_AS1_1; export none; # --------------------------------------- }; } Output of '-d -f': root@f484b919cd3a:~# bird -c /etc/bird/bird.conf -d -f bird: device1: Initializing bird: AS1_1: Channel ipv4 connected to table master4 bird: AS1_1: Initializing bird: device1: Starting bird: device1: Scanning interfaces bird: device1: State changed to up bird: AS1_1: Starting bird: AS1_1: State changed to start bird: Started bird: AS1_1: Started bird: AS1_1: Incoming connection from 192.0.2.11 (port 49457) accepted bird: AS1_1: BGP session established bird: AS1_1: State changed to up bird: AS1_1 > added [best] 1.0.1.0/24 unicast bird: AS1_1 < rejected by protocol 1.0.1.0/24 unicast bird: AS1_1 > added [best] 1.0.3.0/24 unicast bird: AS1_1 < rejected by protocol 1.0.3.0/24 unicast bird: AS1_1 > added [best] 1.0.2.0/24 unicast bird: AS1_1 < rejected by protocol 1.0.2.0/24 unicast bird: AS1_1 > added [best] 1.0.5.0/24 unicast bird: AS1_1 < rejected by protocol 1.0.5.0/24 unicast bird: Protocol AS1_1 hits route receive limit (4), action: disable Segmentation fault

2 5

[PATCH v2 0/7] Add MAC authentication support to the Babel protocol
by Toke Høiland-Jørgensen 17 Nov '20

17 Nov '20

This series adds MAC authentication support to the Babel protocol as specified in by the IETF Babel working group in draft-babel-hmac-10: https://tools.ietf.org/html/draft-ietf-babel-hmac-10 This is the follow-up to v1, posted in February[0]. See changelog below. I have performed basic interoperability testing between this implementation and the current babeld HMAC implementation[1]. The two implementations were able to successfully exchange authenticated messages with both HMAC-256 and Blake2s keys. Given the above, and the close-to-final state of the specification at the IETF, I believe this series is ready for merging (subject to review, of course). For those wanting to test the code, a version of Bird with this series applied is available on Github[2] for easy consumption. [0] http://trubka.network.cz/pipermail/bird-users/2020-February/014251.html [1] https://github.com/jech/babeld/pull/52 [2] https://github.com/tohojo/bird/tree/babel-mac-02 Changelog: v2: - Don't reinvent AC_CHECK_FUNCS() for configure - Make sure random_bytes() never fails (without taking the whole daemon with it) - Use existing endianness defines in blake2s code - Just leave MAC-related code in babel.c/packets.c instead of adding a new file - Add blake2s test vectors (new patch 3) - Support supplying mac keys as raw hexadecimal bytes and allow algorithms to validate keys on configure (new patches 4-5) v1: - Add wrapper function to bird sysdep code to pick a suitable source of random bytes - Import reference Blake2 implementations into lib/ - Rename function names and data structures to use an auth_ prefix instead of hmac_ - Perform a separate authentication pass before parsing the packet, and move the authentication-related code to its own source file - Enforce key length recommendation from the specification - Add a 'permissive' configuration mode where outgoing packets are signed but incoming packets are accepted even though they fail authentication - Add user documentation for the authentication configuration, and function docstrings to the main authentication functions - Fix a bunch of nits and code style issues --- Toke Høiland-Jørgensen (7): sysdep: Add wrapper to get random bytes nest: Add Blake2s and Blake2b hash functions mac_test: Add tests for blake2s and blake2b nest: Allow specifying security keys as hex bytes as well as strings config: Allow MAC algorithms to specify a function to validate their keys babel: Refactor TLV parsing code for easier reuse babel: Add MAC authentication support conf/cf-lex.l | 31 + conf/conf.h | 5 + conf/confbase.Y | 2 + doc/bird.sgml | 47 +- lib/Makefile | 2 +- lib/blake2-impl.h | 160 ++ lib/blake2-kat.h | 4111 +++++++++++++++++++++++++++++++++++++++++ lib/blake2-ref.h | 112 ++ lib/blake2.c | 62 + lib/blake2.h | 69 + lib/blake2b-ref.c | 270 +++ lib/blake2s-ref.c | 263 +++ lib/mac.c | 9 + lib/mac.h | 12 + lib/mac_test.c | 91 + lib/string.h | 1 + lib/strtoul.c | 27 + nest/config.Y | 53 +- nest/password.c | 6 + nest/password.h | 1 + proto/babel/Makefile | 2 +- proto/babel/babel.c | 156 +- proto/babel/babel.h | 66 +- proto/babel/config.Y | 45 +- proto/babel/packets.c | 661 ++++++- 25 files changed, 6152 insertions(+), 112 deletions(-) create mode 100644 lib/blake2-impl.h create mode 100644 lib/blake2-kat.h create mode 100644 lib/blake2-ref.h create mode 100644 lib/blake2.c create mode 100644 lib/blake2.h create mode 100644 lib/blake2b-ref.c create mode 100644 lib/blake2s-ref.c

2 10

Delete all BGP communities except
by Brooks Swinnerton 29 Oct '20

29 Oct '20

Hello, Is it possible to delete all BGP communities from prefixes learned from a specific BGP session except ones that start with a given value? For example something like: if (bgp_path ~ 64496) then { bgp_large_community.delete([(!64496, *, *)]); } I haven't tested this syntax, but I can't imagine it would work. I'm mostly curious if there's a concept of "except" when deleting BGP communities.

2 3

Bird 2.0.8 release date question
by Piotr KOWALCZYK 28 Oct '20

28 Oct '20

Dear BIRD IRD developers, Could you please tell us when do you plan to release next 2.0.8 version? There were 0 updates this year and I wonder if this will happen this year? Approximate relase date would be nice -- Best Regards

4 3

Erroneous withdrawls and EOR announcements
by micah anderson 22 Oct '20

22 Oct '20

Hello, We have been experiencing heavy DDoS attacks, and one of the mitigation techniques we've used is to peer with Team Cyrmu's UTRS bgp server[0] in order to announce /32s to null route. We also connect with one of our tranist provider's null route services, and our internet exchange's null route service to push these out when they happen. We were contacted by the UTRS folks because it seems like we are sending 'withdrawl' messages for networks that we do not control that are larger than /32, and EOR announcements. For example, from their logs: 2020-10-20T00:19:21+00:00 xp07-as19 UTRS[6681]: receive-routes: update: withdrawal|16652|198.252.153.1|88.16.0.0/16 Our ASN is 16652, and that 198.252.153 address is ours, but that /16 is not ours. I suspect we might be sending withdrawls for every route in our table. It also appears we are sending "eor" advertisements: 2020-10-21T01:01:29+00:00 xp07-as19 UTRS[6681]: receive-routes: update: announcement|16652|198.252.153.1|eor It seems that neither of these are desired by them, and I'm at a loss as to what I can do to make them stop. My bird configuration looks like this, I would greatly appreciate any help in improving this, we cannot afford to lose our UTRS peer, and I'd like to keep us from polluting our friendly neighborhood logs! define LOOPBACKADDR = 198.252.153.1; protocol kernel { learn; # Learn all alien routes from the kernel preference 10000; scan time 15; # Scan kernel routing table every 20 seconds import all; # Default is import all export where ! our_network(); # set preferred source address of routes, # otherwise connections initiated by router might have the transfernet as source address. export filter { krt_prefsrc = LOOPBACKADDR; accept; }; } protocol device { scan time 15; # Scan interfaces every 10 seconds } protocol static static_bgp { import all; preference 10000; include "static_bgp.conf"; } protocol static static_nullroute { import filter static_nullroutes; include "static_nullroutes.conf"; # example: route xxx.xxx.xxx.xxx/32 blackhole; } define OURNETS = [ xxx+ ]; define PEER1 = [ xxx ]; define PEER_ASNS = [ xxx]; function martians() { return net ~ [ 169.254.0.0/16+, 192.168.0.0/16+, 10.0.0.0/8+, 172.16.0.0/12+, 172.24.0.0/13+, 172.25.0.0/16+, 172.26.0.0/16+, 172.27.0.0/16+, 172.28.0.0/16+, 172.29.0.0/16+, 172.30.0.0/16+, 172.31.0.0/16+, 224.0.0.0/4+, 240.0.0.0/4+, 0.0.0.0/32-, 127.0.0.0/8+ ]; filter static_nullroutes { if proto = "static_nullroute" then { bgp_community = -empty-; bgp_community.add((ASN,666)); accept; } } function our_network() { return net ~ OURNETS; } function rt_export() { if proto = "static_bgp" then return true; if proto = "static_nullroute" then return true; if source != RTS_BGP then return false; if martians() then return false; if bgp_path.len > 64 then return false; return bgp_path.first ~ PEER_ASNS; } function rt_export_all() { if proto = "static_links" then return false; if proto = "static_bgp" then return true; if proto = "static_nullroute" then return true; if source != RTS_BGP then return false; if martians() then return false; if bgp_path.len > 64 then return false; return true; } # for outgoing BGP we do not want to announce anything but our own nets filter bgp_out { # SIX nullrouting: https://www.seattleix.net/blackholing if (ASN,666) ~ bgp_community && net.len = 32 && our_network() then { bgp_community = -empty-; bgp_community.add((65535,666)); } # only allow our networks that are statically configured to be announced if ! rt_export() then { reject; } accept; } filter sink { reject; } # anything that is announced via the UTRS peer that has the community 64496:0 set # and is a /32 is null-routed filter bgp_in_utrs_bl { if (64496,0) ~ bgp_community && net.len = 32 then { dest = RTD_BLACKHOLE; accept; } else reject; } filter bgp_out_utrs_bl { if (ASN,666) ~ bgp_community && net.len = 32 && our_network() then { bgp_community = -empty-; bgp_community.add((ASN,0)); accept; } else reject; } filter bgp_nullroute { if (ASN,666) ~ bgp_community && net.len = 32 && our_network() then { accept; } else reject; } -- micah 0. https://team-cymru.com/community-services/utrs/getting-started/

1 0

A study on community-triggered updates in BGP
by Thomas Krenc 19 Oct '20

19 Oct '20

Dear BIRD users and developers, As a team of researchers from NPS and TU Berlin, we are investigating the impact of BGP community attributes on the update behavior between ASes. We find that when a route is associated with multiple distinct community attributes it does not only lead to multiple announcement at the tagging AS, but also at neighboring ASes, if communities are not filtered properly. This behavior is wide-spread. In order to better understand our observations, we have performed a series of laboratory experiments using Cisco IOS, Junos OS, as well as the BIRD daemon. We find that - by default - all routers generate announcements with changing community attributes, even when other attributes do not change. In addition, when communities are filtered at egress, Cisco und BIRD send duplicate announcements (Juniper does not). Is this side-effect known to the BIRD community and would you consider it a bug or a feature? Since our findings are limited to observations in public data as well as few router implementations, we would like to share our research and kindly ask you to have a look at: https://www.cmand.org/communityexploration/ There, we provide some resources documenting our research, as well as open questions. We greatly appreciate any feedback and insights you can offer. Also, please don't hesitate to contact us directly: communityexploration AT cmand DOT org best regards Thomas Krenc Postdoctoral Researcher Naval Postgraduate School

2 3

roa_check RPKI
by Fabiano D'Agostino 11 Oct '20

11 Oct '20

How does roa_check(roa_table,net,bgp_path.last) work? Having such a ROA as example: origin AS: 64513 prefix: 78.150.40.0/20 max mask: 24 and a BGP announcement: origin AS: 64514 prefix: 78.150.45.0/22 so it's as invalid, but how does this check work? roa_table: validated roa record (validated cache) net: should be the current prefix so 78.150.45.0/22 what is bgp_path.last and how does roa_check function do the check? Thanks, Fabiano

2 3

[Bug] Multiple BFD protocol instances for one VRF should be prohibited
by Wang Shanker 10 Oct '20

10 Oct '20

Hi, all Before commit `f9deedf1`, BFD was implemented allowing only one instance of BFD protocol. The implementation was not prepared for multiple BFD protocol instances. In that commit, to support VRF, the check for multiple BFD instances was removed, which results in the possibility that multiple BFD protocol instances are configured for one VRF. `bfd_add_request()` will success only if given `bfd_proto` and `bfd_request` belong to the same VRF. So for each VRF, only the first BFD protocol instance will take effect. This can be reproduced by the following configuration with the latest commit in branch legacy and similar configuration with the latest commit in branch master: ``` router id 192.168.0.1; protocol bfd bfd1{ interface "eth0" { interval 5s; idle tx interval 5s; }; }; protocol bfd bfd2{ interface "eth1" { interval 10s; idle tx interval 10s; }; }; protocol device { }; protocol static { route 2001:db8::/32 multipath via fe80::1%eth0 bfd via fe80::2%eth1 bfd ; }; ``` As shown in `show bfd session`, the configuration in instance `bfd2` is ignored: ``` # ./birdc -s bird6.ctl sh bfd sess bfd1 BIRD 1.6.8 ready. bfd1: IP address Interface State Since Interval Timeout fe80::2 eth1 Down 03:51:32 1.000 0.000 fe80::1 eth0 Down 03:51:32 5.000 0.000 # ./birdc -s bird6.ctl sh bfd sess bfd2 BIRD 1.6.8 ready. bfd2: IP address Interface State Since Interval Timeout ``` Expected behavior: I suggest such configuration be seen invalid and rejected when parsed. Cheers, Miao Wang

1 0

typo in 2.x bird documentation.
by Sergey Kulikov 05 Oct '20

05 Oct '20

I was writing import filter to use with both v4 and v6 prefixes and set krt_prefsrc, so I need to identify prefix belonging to v4 or v6. So docs saying this: "Whether the address is IPv4 or not may be checked by .is_ip4 which returns a bool." But it's not working, and as I can see from sources in fact correct name for that function is ".is_v4" in config.Y: | term '.' IS_V4 { $$ = f_new_inst(FI_IS_V4, $1); } and it works, is this mailing list correct place to report this typo? Other users can experience issues trying to use ".is_ip4". -- Best regards, Sergey mailto:serg@rangerovers.ru

2 1