March 2020 - Bird-users - Mailing Lists

[PATCH 0/4] Add MAC authentication support to the Babel protocol
by Toke Høiland-Jørgensen 11 Mar '20

11 Mar '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 An initial RFC patch series was posted here in July 2018[0]. Since then, the protocol specification has progressed through the IETF, to the point where it is now in the IESG publication queue as a proposed standard RFC. This version of the patch series updates the implementation to correspond to the final version of the draft, and also addresses the review comments from the initial RFC patch. The major changes are: Major updates to the specification (for a full list see the draft appendix): - Added Blake2s as a recommended algorithm - Updated terminology to use MAC everywhere instead of HMAC (since Blake is not an HMAC algorithm). - Added expiration of neighbours and rate limiting of challenge replies - Update TLV type numbers after IANA allocation In addition, the following changes have been made to the implementation: - 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 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. Cheers, -Toke [0] http://trubka.network.cz/pipermail/bird-users/2018-July/012536.html [1] https://github.com/jech/babeld/pull/52 [2] https://github.com/tohojo/bird/tree/babel-mac-01 --- Toke Høiland-Jørgensen (4): sysdep: Add wrapper to get random bytes nest: Add Blake2s and Blake2b hash functions babel: Refactor packet parsing code for reuse in authentication checks babel: Add MAC authentication support aclocal.m4 | 49 ++++ conf/conf.c | 1 configure.ac | 15 + doc/bird.sgml | 38 +++ lib/Makefile | 2 lib/birdlib.h | 2 lib/blake2-impl.h | 160 +++++++++++++ lib/blake2-ref.h | 112 +++++++++ lib/blake2.c | 46 ++++ lib/blake2.h | 67 ++++++ lib/blake2b-ref.c | 270 ++++++++++++++++++++++ lib/blake2s-ref.c | 263 ++++++++++++++++++++++ lib/mac.c | 7 + lib/mac.h | 2 nest/config.Y | 4 proto/babel/Doc | 1 proto/babel/Makefile | 4 proto/babel/auth.c | 593 +++++++++++++++++++++++++++++++++++++++++++++++++ proto/babel/babel.c | 33 ++- proto/babel/babel.h | 54 ++++ proto/babel/config.Y | 38 +++ proto/babel/packets.c | 294 +++++++++++++----------- proto/babel/packets.h | 96 ++++++++ sysdep/unix/random.c | 78 ++++++ 24 files changed, 2068 insertions(+), 161 deletions(-) create mode 100644 lib/blake2-impl.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 create mode 100644 proto/babel/auth.c create mode 100644 proto/babel/packets.h

2 14

Unwanted IPv6 static route flap
by Neil Jerram 10 Mar '20

10 Mar '20

I am struggling to understand and ideally eliminate an unwanted flap (i.e. delete and re-add) of an IPv6 route on node M, when a neighbouring node R restarts, and R is configured to advertise that IPv6 route statically. Here is the config on R to advertise the route: protocol static { # IP blocks for this host. route fd00:10:244:0:1cc0:b1ac:ad47:e7c0/122 blackhole; } BIRD6 on node R is killed (with -9) at 12:22:08, and restarts (with the -R flag) at 12:22:14. The flap (in the kernel routing table) is detected by running "ip -ts monitor route" on the monitor node M. It reports this at 12:22:17: [2020-02-29T12:22:17.954263] Deleted fd00:10:244:0:1cc0:b1ac:ad47:e7c0/122 via 2001:20::2 dev eth0 proto bird metric 1024 pref medium [2020-02-29T12:22:17.954470] fd00:10:244:0:1cc0:b1ac:ad47:e7c0/122 via 2001:20::2 dev eth0 proto bird metric 1024 pref medium Here is the BIRD6 log on R, from when it restarted, until it reached a steady state. R's peering to M is "Mesh_2001_20__1". 2020-02-29T12:22:14.214961381Z bird: device1: Initializing 2020-02-29T12:22:14.215018144Z bird: direct1: Initializing 2020-02-29T12:22:14.215035765Z bird: Mesh_2001_20__8: Initializing 2020-02-29T12:22:14.215047665Z bird: Mesh_2001_20__1: Initializing 2020-02-29T12:22:14.215057649Z bird: Mesh_2001_20__3: Initializing 2020-02-29T12:22:14.215144477Z bird: device1: Starting 2020-02-29T12:22:14.215369797Z bird: device1: Connected to table master 2020-02-29T12:22:14.215402544Z bird: device1: State changed to feed 2020-02-29T12:22:14.215431056Z bird: direct1: Starting 2020-02-29T12:22:14.215439899Z bird: direct1: Connected to table master 2020-02-29T12:22:14.215447877Z bird: direct1: State changed to feed 2020-02-29T12:22:14.215456544Z bird: Mesh_2001_20__8: Starting 2020-02-29T12:22:14.215523493Z bird: Mesh_2001_20__3: Starting 2020-02-29T12:22:14.215716006Z bird: Graceful restart started 2020-02-29T12:22:14.215742864Z bird: Started 2020-02-29T12:22:14.215757668Z bird: direct1: State changed to up 2020-02-29T12:22:14.215770554Z bird: device1: State changed to up 2020-02-29T12:22:14.948167365Z bird: Mesh_2001_20__3: Connected to table master 2020-02-29T12:22:14.948234648Z bird: Mesh_2001_20__3: State changed to wait 2020-02-29T12:22:15.951638881Z bird: Mesh_2001_20__8: Connected to table master 2020-02-29T12:22:15.951703218Z bird: Mesh_2001_20__8: State changed to wait 2020-02-29T12:22:16.953066987Z bird: Mesh_2001_20__1: Connected to table master 2020-02-29T12:22:16.953132676Z bird: Mesh_2001_20__1: State changed to wait 2020-02-29T12:22:16.953154658Z bird: Graceful restart done 2020-02-29T12:22:16.95316785Z bird: Mesh_2001_20__8: State changed to feed 2020-02-29T12:22:16.953180658Z bird: Mesh_2001_20__1: State changed to feed 2020-02-29T12:22:16.953194942Z bird: Mesh_2001_20__3: State changed to feed 2020-02-29T12:22:17.953827137Z bird: Mesh_2001_20__8: State changed to up 2020-02-29T12:22:17.953880171Z bird: Mesh_2001_20__1: State changed to up 2020-02-29T12:22:17.953894204Z bird: Mesh_2001_20__3: State changed to up (There could be some errors here, because I've manually separated logs from both BIRD and BIRD6 that were going into the same file, and they both log with prefix "bird:".) And on M, from when R was killed, until reaching a steady state following R restart. M's peering to R is "Mesh_2001_20__2". 2020-02-29T12:22:08.943087384Z bird: Mesh_2001_20__2: State changed to start 2020-02-29T12:22:16.952861163Z bird: Mesh_2001_20__2: State changed to feed 2020-02-29T12:22:16.952950901Z bird: Mesh_2001_20__2: State changed to up Can anyone help to explain why I get the IPv6 route flap on node M, and if there is a way of eliminating it? The peering config on R is # Template for all BGP clients template bgp bgp_template { debug { states }; description "Connection to BGP peer"; local as 64512; multihop; gateway recursive; import all; export filter calico_export_to_bgp_peers; source address 2001:20::2; add paths on; graceful restart; connect delay time 2; connect retry time 5; error wait time 5,30; } protocol bgp Mesh_2001_20__1 from bgp_template { neighbor 2001:20::1 as 64512; } and the same on M but with ::1 and ::2 swapped, and __2 instead of __1. By the way, my setup also has exactly parallel IPv4 config and routes, and I reliably do _not_ see a similar flap for the corresponding IPv4 route. Many thanks, Neil

2 4

BGP routes not being propagated to kernel via OSPF
by Brian Topping 10 Mar '20

10 Mar '20

Greetings, I have a network with four routers on an OSPF backbone. Only one of the four routers cannot export the type 5 LSA entries to the kernel. I cannot figure out why. I wonder if I might kindly ask some guidance. The routers (including the problem router) are all BIRD 2.0.7 with the router with IP 10.10.4.1 running 2.0.4. The kernels are Linux 4.20.x. Here is the OSPF for a working router: > protocol ospf backbone { > ipv4 { > export all; > import filter { if net = 0.0.0.0/0 then reject; else accept; }; > }; > area 0.0.0.0 { > interface "eno2" {}; > interface "vti*" { > type nbma; > strict nonbroadcast yes; > neighbors { > 10.9.254.2 eligible; > }; > }; > }; > } The OSPF configuration of the router having problems. They are virtually identical with the exception of the interfaces: > protocol ospf backbone { > ipv4 { > export all; > import filter { if net = 0.0.0.0/0 then reject; else accept; }; > }; > area 0.0.0.0 { > interface "bond0" { > }; > interface "vti*" { > type nbma; > neighbors { > 10.9.255.1 eligible; > 10.9.254.1 eligible; > }; > }; > }; > } All the routers have *identical* LSADBs on each router (not shown). master4 is correct on the working routers: > [root@gw02 ~]# birdc show route > BIRD 2.0.7 ready. > Table master4: > 0.0.0.0/0 unicast [bgp_handy_125 02:07:43.248] * (100) [AS30475i] > via c.d.143.125 on eno1 > unicast [bgp_handy_126 02:07:43.661] (100) [AS30475i] > via c.d.143.126 on eno1 > a.b.96.0/32 unicast [backbone 02:07:46.207] E2 (150/10/10000) [c.d.143.113] > via 10.10.0.41 on eno2 > a.b.96.9/32 unicast [backbone 02:07:46.207] E2 (150/10/10000) [c.d.143.113] > via 10.10.0.41 on eno2 > a.b.96.8/32 unicast [backbone 02:07:46.207] E2 (150/10/10000) [c.d.143.113] > via 10.10.0.41 on eno2 > a.b.96.11/32 unicast [backbone 02:07:46.207] E2 (150/10/10000) [c.d.143.113] > via 10.10.0.41 on eno2 > 10.10.0.0/22 unicast [backbone 02:07:46.207] I (150/10) [c.d.143.113] > dev eno2 > 10.9.254.2/32 unicast [backbone 02:08:16.208] I (150/10) [10.10.4.21] > via 10.9.254.2 on vti3 > 10.9.254.0/24 unicast [backbone 02:08:16.208] I (150/10) [10.10.4.21] > dev vti3 > 10.9.255.2/32 unicast [backbone 02:08:16.208] I (150/10) [10.10.4.21] > via 10.9.254.2 on vti3 > 192.168.10.0/24 unicast [backbone 02:08:16.208] I (150/30) [10.10.4.1] > via 10.9.254.2 on vti3 > 10.10.4.0/22 unicast [backbone 02:08:16.208] I (150/20) [10.10.4.1] > via 10.9.254.2 on vti3 > 10.9.255.0/24 unicast [backbone 02:08:16.208] I (150/20) [c.d.143.113] > via 10.9.254.2 on vti3 weight 1 > via 10.10.0.41 on eno2 weight 1 > a.b.97.1/32 unicast [backbone 02:07:46.207] E2 (150/10/10000) [c.d.143.113] > via 10.10.0.41 on eno2 > a.b.96.10/32 unicast [backbone 02:07:46.207] E2 (150/10/10000) [c.d.143.113] > via 10.10.0.41 on eno2 > a.b.96.0/24 blackhole [public_nets_proto 02:07:35.107] * (500) > unicast [backbone 02:07:46.207] E2 (150/10/10000) [c.d.143.113] > via 10.10.0.41 on eno2 > a.b.97.0/24 blackhole [public_nets_proto 02:07:35.107] * (500) > unicast [backbone 02:07:46.207] E2 (150/10/10000) [c.d.143.113] > via 10.10.0.41 on eno2 > [root@gw02 ~]# birdc show route a.b.96.0/32 all > BIRD 2.0.7 ready. > Table master4: > a.b.96.0/32 unicast [backbone 02:07:46.207] E2 (150/10/10000) [c.d.143.113] > via 10.10.0.41 on eno2 > Type: OSPF-E2 univ > OSPF.metric1: 10 > OSPF.metric2: 10000 > OSPF.tag: 0x00000000 > OSPF.router_id: c.d.143.113 The router with problems does *not* have a correct copy of master4 table, it is missing all of the LSA type 5 entries. So of course they cannot be exported to kernel on that router: > [root@centos01 ~]# birdc show route > BIRD 2.0.7 ready. > Table master4: > 10.9.254.2/32 unicast [backbone 22:53:52.605] I (150/0) [10.10.4.21] > dev bond0 > 10.9.254.0/24 unicast [backbone 00:08:15.604] I (150/10) [10.10.4.21] > dev bond0 > 10.9.255.2/32 unicast [backbone 23:56:54.605] I (150/0) [10.10.4.21] > dev bond0 > 192.168.10.0/24 unicast [backbone 22:54:32.604] I (150/20) [10.10.4.1] > via 10.10.4.1 on bond0 > 10.10.4.0/22 unicast [backbone 22:54:32.604] I (150/10) [10.10.4.1] > dev bond0 > 10.9.255.0/24 unicast [backbone 23:57:39.604] I (150/10) [c.d.143.113] > dev bond0 What I cannot figure out is why the OSPF entries are not imported to master4 on this single machine. Thanks kindly for any thoughts. Brian

2 3

ROA with static protocol in BIRD 2
by Robert Scheck 09 Mar '20

09 Mar '20

Good evening, I wonder if there's a good, full example about ROA with static protocol in BIRD 2. The following snippet is only for BIRD 1.x, right? --- %< --- roa table roa { roa 1.0.0.0/24 max 24 as 13335; # […] } --- %< --- Based on various snippets and half examples on the Internet, I've made this currently: --- %< /etc/bird.conf %< --- # […] roa4 table roa_v4; roa6 table roa_v6; include "/var/lib/rpki-client/bird2"; function reject_invalid_roa() { if (force_roa_table_update > 0) then { if (net.type = NET_IP4) then { case roa_check(roa_v4, net, bgp_path.last) { ROA_INVALID: reject; # ROA_VALID: # ROA_UNKNOWN: } } if (net.type = NET_IP6) then { case roa_check(roa_v6, net, bgp_path.last) { ROA_INVALID: reject; # ROA_VALID: # ROA_UNKNOWN: } } } } # […] --- %< /etc/bird.conf %< --- Note that /var/lib/rpki-client/bird2 is generated on a regular base. --- %< /var/lib/rpki-client/bird2 %< --- define force_roa_table_update = 1582237716; protocol static { roa4 { table roa_v4; }; route 1.0.0.0/24 max 24 as 13335; # […] } protocol static { roa6 { table roa_v6; }; route 2001:200::/32 max 32 as 2500; # […] } --- %< /var/lib/rpki-client/bird2 %< --- This however raises the following questions for me: - Is this good style at all? - Should "roa4 table roa_v4; roa6 table roa_v6;" be moved to the include? - To cover IPv4 and IPv6, I need two different tables and two different static protocols, and there is no way using one table/channel, right? - Is "define force_roa_table_update = 1582237716;" still needed with BIRD 2.0.7 to ensure proper revalidation? - Some use "bgp_path.last_nonaggregated", some "bgp_path.last". What is more suitable here? - Is "birdc configure soft && birdc reload in all" the only/best way? Regards, Robert

4 6

Debian reposity pubkey not found
by Petr Boltík 05 Mar '20

05 Mar '20

Hi, please check pubkey for your debian repository. No valid pubkey found. Regards Petr Debian 10.3 installation from https://bird.network.cz/?download&tdir=debian/ apt-key add - ..... OK ~# apt update Err:2 http://bird.network.cz/debian buster InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B188E2B695BD4743 Reading package lists... Done W: GPG error: http://bird.network.cz/debian buster InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B188E2B695BD4743 E: The repository 'http://bird.network.cz/debian buster InRelease' is not signed.

3 3

Force gateway recursive lookup in iBGP routes
by Miroslav Kalina 04 Mar '20

04 Mar '20

Hello there, I am currently trying to use BIRD for route propagation from our baremetal Kubernetes clusters (Calico CNI, iBGP sessions within AS65100) into infrastructure via eBGP (private AS) and it works well. The issue I have is when I want also to create BGP peering between BIRD and (MetalLB) service inside Kubernetes cluster (multihop, no NAT involved, session established OK) and I receive routes /32 with BGP.next_hop to IP within Kubernetes cluster (=not directly connected). These routes are marked as "unreachable" even if I explicitly set "gateway recursive". I know this recursive gateway lookup works well for routes learned from eBGP, but I can't make Calico peers external because it won't work in my setup. Calico nodes has iBGP full mesh and I would receive all routes from every single node and I wouldn't be able to distinguish which lives where. Unfortunately BGP peer inside cluster has no support to modify next_hop and always sends self, so I am looking for workaround. Also I cannot set specific "gw" in import filter, because I have these multihop peers configured with bgp neighbor range subnet (there will be multiple of them, I don't know exact IP addresses in advance). Configuration snippet like this: # calico cluster peers filter bgp_in_okubedev1_calico { if net ~ [ 10.96.16.0/20+ ] then accept; reject; } protocol bgp okubedev1m1 { local 10.30.20.180 as 65100; neighbor 10.30.21.19 as 65100; passive yes; ipv4 { import filter bgp_in_okubedev1_calico; export none; }; } # metallb multihop peers filter bgp_in_okubedev1_metallb { # gw is recursively looked up localy and passed into BGP.next_hop #bgp_next_hop = gw; if net ~ [ 10.96.255.32/28+ ] then accept; reject; } protocol bgp okubedev1_lb_tpl { local 10.30.20.180 as 65100; neighbor range 10.96.16.0/20 as 65100; passive yes; multihop; ipv4 { gateway recursive; import filter bgp_in_okubedev1_metallb; export none; }; } Produces following routing table: bird> show route all Table master4: 10.96.255.33/32 unreachable [okubedev1_lb1 10:32:14.973 from 10.96.20.25] * (100) [?] Type: BGP univ BGP.origin: Incomplete BGP.as_path: BGP.next_hop: 10.96.20.25 BGP.local_pref: 0 10.96.20.0/26 unicast [okubedev1m1 11:15:45.704] * (100) [i] via 10.30.21.19 on enp0s4 Type: BGP univ BGP.origin: IGP BGP.as_path: BGP.next_hop: 10.30.21.19 BGP.local_pref: 100 10.30.20.0/22 unicast [direct1 13:52:46.301] * (240) dev enp0s4 Type: device univ I am almost sure I am missing some key BIRD or BGP feature, which I need to know to understand this behavior properly. Any comment or suggestion would be appreciated. Best regards -- Miroslav Kalina Systems developement specialist miroslav.kalina(a)livesport.eu +420 773 071 848 Livesport s.r.o. Aspira Business Centre Bucharova 2928/14a, 158 00 Praha 5 www.livesport.eu

2 4

BIRD drops specific IPv6 session for no reason
by Stavros Konstantaras 03 Mar '20

03 Mar '20

Hi Bird community, We are investigating a weird customer issue regarding our Bird Route Servers (version 1.6.3) and a specific IPv6 session. Customer reports a sudden drop of his IPv6 session and -until now- we could not relate those drops with any issue or instability. Everything seems normal and no other customer complained at the moment of the incident. After some packet capturing at the moment of the event, we discovered that BIRD does not send a response messages to the customer’s BGP keepalive messages (see attached picture), which result to the BGP hold timer to expire and the sessions to be dropped. We observed this anomaly with both RSs but at different time slots and the tcpdump capture was running at the Interface were Bird is sending all BGP traffic for customers. At the moment of the event, we didn’t do any maintenance or other RS related work. Has any of you experienced this in the past? If yes, how did you solve this? Any related feedback is welcomed. Best regards, Stavros Konstantaras | Sr. Network Engineer | AMS-IX M +31 (0) 620 89 51 04 | T +31 20 305 8999 ams-ix.net

5 9