February 2021 - Bird-users

[PATCH v4 0/8] Add MAC authentication support to the Babel protocol
by Toke Høiland-Jørgensen 11 Jun '21

11 Jun '21

This series adds MAC authentication support to the Babel protocol as specified in in RFC8967: https://www.rfc-editor.org/rfc/rfc8967 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-256 keys. Given the above, and the fact that the RFC was finally published at the 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. [1] https://github.com/jech/babeld/pull/52 [2] https://github.com/tohojo/bird/tree/babel-mac-04 Changelog: v4: - Update RFC references to the published RFC numbers (for both MAC and Babel itself). - Rework WALK_TLVS macro to not cast initial argument, and not use goto for framing errors. - Change MAC validation logic to just let algorithms specify min/max len and enforce full key size length even for the smaller-output variants of Blake2. v3: - Add variants with smaller digest sizes for blake2s and blake2b. - Rebase on current master 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 (8): 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 babel: Update RFC references to new standards track RFC8966 conf/cf-lex.l | 31 + conf/conf.h | 5 + conf/confbase.Y | 2 + doc/bird.sgml | 49 +- lib/Makefile | 2 +- lib/blake2-impl.h | 160 ++ lib/blake2-kat.h | 4111 +++++++++++++++++++++++++++++++++++++++++ lib/blake2-ref.h | 112 ++ lib/blake2.c | 48 + lib/blake2.h | 65 + lib/blake2b-ref.c | 270 +++ lib/blake2s-ref.c | 263 +++ lib/mac.c | 35 +- lib/mac.h | 11 + lib/mac_test.c | 91 + lib/string.h | 1 + lib/strtoul.c | 27 + nest/config.Y | 54 +- nest/password.c | 6 + nest/password.h | 1 + proto/babel/Makefile | 2 +- proto/babel/babel.c | 162 +- proto/babel/babel.h | 66 +- proto/babel/config.Y | 42 +- proto/babel/packets.c | 667 ++++++- 25 files changed, 6164 insertions(+), 119 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 15

[PATCH] Client: add "show hostname" command, and add client prompt hostname display
by Molly Miller 05 Mar '21

05 Mar '21

Hi all, The recent patch on the list from Vincent Bernat which added support for the draft BGP hostname capability [1] reminded me of a thread from last year, in which there was a feature request for the ability to display the system hostname in the Bird client prompt [2]. This feature doesn't appear to have been implemented since then, and now that a hostname is tracked internally by Bird, I've written a proof-of-concept patch (appended inline) which displays the daemon hostname in the client prompt. This patch adds a "show hostname" command to the daemon for convenience, and modifies the client to automatically issue this command when starting in interactive mode. The client then intercepts the response (which will either contain the daemon hostname, or be a syntax error if the daemon does not understand the command), and then sets the received hostname in the prompt if the response is a success code. (The rationale for not simply calling uname(2) in the client is that the resulting nodename may not match the hostname configured in the daemon, in the case where the daemon configuration contains a hostname "<foo>" directive. It's also possible to connect to the daemon over a Unix socket forwarded over SSH, in which case the client would be running on a separate system with a different hostname regardless of the daemon configuration -- thanks to Tim Stallard for pointing this out.) I don't know how willing the Bird maintainers would be to commit this patch, however I thought I'd post it to the list in case anyone else is interested. Cheers, --mm. [1]: https://bird.network.cz/pipermail/bird-users/2021-February/015187.html, merged as 71423871 [2]: https://bird.network.cz/pipermail/bird-users/2020-July/014678.html -- >8 -- Subject: [PATCH] Client: add "show hostname" command, and client prompt hostname display. This patch adds a "show hostname" command to the daemon, which returns the server's currently configured hostname, and extends the command line client to issue this command upon connecting to the daemon, in order to retrieve a hostname to display in the client's prompt. A '-p' option has also been added to suppress this behaviour. molly on flywheel ~> birdc BIRD v2.0.7 ready. bird (flywheel)> show hostname Hostname: flywheel bird (flywheel)> exit molly on flywheel ~> birdc -p BIRD v2.0.7 ready. bird> show hostname Hostname: flywheel bird> quit Additionally, the error message generated by older versions of the daemon when running the "show hostname" command is caught, in order to remain interoperable with versions which do not have this patch. The client program does not, however, have any means of detecting whether the hostname changes as part of an online configuration update, so changes in the daemon's hostname will not be propagated to a client which is persistent across the configuration change. --- client/birdc.c | 11 +++++++++-- client/birdcl.c | 8 +++++++- client/client.c | 48 ++++++++++++++++++++++++++++++++++++++++++------ client/client.h | 2 ++ doc/reply_codes | 1 + nest/cmds.c | 7 +++++++ nest/cmds.h | 1 + nest/config.Y | 3 +++ 8 files changed, 72 insertions(+), 9 deletions(-) diff --git a/client/birdc.c b/client/birdc.c index f1aea2fe..b1b9b218 100644 --- a/client/birdc.c +++ b/client/birdc.c @@ -162,7 +162,7 @@ input_init(void) rl_readline_name = "birdc"; rl_add_defun("bird-complete", input_complete, '\t'); rl_add_defun("bird-help", input_help, '?'); - rl_callback_handler_install("bird> ", input_got_line); + rl_callback_handler_install(prompt_string, input_got_line); // rl_get_screen_size(); term_lns = LINES; @@ -184,7 +184,7 @@ input_reveal(void) tcdrain(STDOUT_FILENO); rl_end = input_hidden_end; - rl_expand_prompt("bird> "); + rl_expand_prompt(prompt_string); rl_forced_update_display(); prompt_active = 1; @@ -201,6 +201,13 @@ input_hide(void) prompt_active = 0; } +void +input_reload(void) +{ + input_hide(); + input_reveal(); +} + void input_notify(int prompt) { diff --git a/client/birdcl.c b/client/birdcl.c index 4508185c..d36914c9 100644 --- a/client/birdcl.c +++ b/client/birdcl.c @@ -38,6 +38,12 @@ input_stop_list(void) /* Empty in non-ncurses version. */ } +void +input_reload(void) +{ + /* Empty in non-ncurses version. */ +} + void input_notify(int prompt) { @@ -45,7 +51,7 @@ input_notify(int prompt) if (!prompt) return; - printf("bird> "); + printf(prompt_string); fflush(stdout); } diff --git a/client/client.c b/client/client.c index 97cf6639..0de7aaaf 100644 --- a/client/client.c +++ b/client/client.c @@ -37,8 +37,11 @@ #include "sysdep/unix/unix.h" #define SERVER_READ_BUF_LEN 4096 +#define SERVER_PROMPT_LEN 64 +#define SERVER_PROMPT_DEFAULT "bird> " +#define SERVER_HOSTNAME_PREFIX "Hostname: " -static char *opt_list = "s:vrl"; +static char *opt_list = "s:vrlp"; static int verbose, restricted, once; static char *init_cmd; @@ -47,12 +50,15 @@ static int server_fd; static byte server_read_buf[SERVER_READ_BUF_LEN]; static byte *server_read_pos = server_read_buf; -int init = 1; /* During intial sequence */ -int busy = 1; /* Executing BIRD command */ -int interactive; /* Whether stdin is terminal */ +int init = 1; /* During intial sequence */ +int busy = 1; /* Executing BIRD command */ +int hostprompt = 1; /* Whether to show hostname in prompt */ +int interactive; /* Whether stdin is terminal */ +char prompt_string[SERVER_PROMPT_LEN]; /* Prompt string */ static int num_lines, skip_input; int term_lns, term_cls; +static int hostname_read = 0; /*** Parsing of arguments ***/ @@ -60,7 +66,7 @@ int term_lns, term_cls; static void usage(char *name) { - fprintf(stderr, "Usage: %s [-s <control-socket>] [-v] [-r] [-l]\n", name); + fprintf(stderr, "Usage: %s [-s <control-socket>] [-v] [-r] [-l] [-p]\n", name); exit(1); } @@ -87,6 +93,9 @@ parse_args(int argc, char **argv) if (!server_changed) server_path = xbasename(server_path); break; + case 'p': + hostprompt = 0; + break; default: usage(argv[0]); } @@ -199,6 +208,12 @@ init_commands(void) exit(0); } + /* Set up local prompt, and attempt to retrieve daemon hostname */ + memset(prompt_string, 0, sizeof(prompt_string)); + strcpy(prompt_string, SERVER_PROMPT_DEFAULT); + if (hostprompt) + submit_server_command("show hostname"); + input_init(); term_lns = (term_lns > 0) ? term_lns : 25; @@ -239,6 +254,16 @@ more(void) more_end(); } +static void +update_prompt(char *x) +{ + if (strncmp(x, SERVER_HOSTNAME_PREFIX, sizeof(SERVER_HOSTNAME_PREFIX)-1) != 0) + return; + + memset(prompt_string, 0, sizeof(prompt_string)); + snprintf(prompt_string, sizeof(prompt_string), "bird (%s)> ", x+sizeof(SERVER_HOSTNAME_PREFIX)-1); +} + /*** Communication with server ***/ @@ -281,7 +306,18 @@ server_got_reply(char *x) (x[4] == ' ' || x[4] == '-')) { if (code) - PRINTF(len, "%s\n", verbose ? x : x+5); + { + if ((code == 1026 || code == 9001) && !hostname_read && hostprompt) + { + hostname_read = 1; + if (code == 1026) { + update_prompt(x+5); + input_reload(); + } + } + else + PRINTF(len, "%s\n", verbose ? x : x+5); + } if (x[4] == ' ') { diff --git a/client/client.h b/client/client.h index f9693def..8de7b38c 100644 --- a/client/client.h +++ b/client/client.h @@ -9,6 +9,7 @@ extern int init, busy, interactive; extern int term_lns, term_cls; +extern char prompt_string[]; /* birdc.c / birdcl.c */ @@ -16,6 +17,7 @@ void input_start_list(void); void input_stop_list(void); void input_init(void); +void input_reload(void); void input_notify(int prompt); void input_read(void); diff --git a/doc/reply_codes b/doc/reply_codes index 02f4e656..47f9d3e8 100644 --- a/doc/reply_codes +++ b/doc/reply_codes @@ -61,6 +61,7 @@ Reply codes of BIRD command-line interface 1023 Show Babel interfaces 1024 Show Babel neighbors 1025 Show Babel entries +1026 Show hostname 8000 Reply too long 8001 Route not found diff --git a/nest/cmds.c b/nest/cmds.c index 18f39eb5..a412faf3 100644 --- a/nest/cmds.c +++ b/nest/cmds.c @@ -95,6 +95,13 @@ cmd_show_memory(void) cli_msg(0, ""); } +void +cmd_show_hostname(void) +{ + cli_msg(-1026, "Hostname: %s", config->hostname); + cli_msg(0, ""); +} + void cmd_eval(const struct f_line *expr) { diff --git a/nest/cmds.h b/nest/cmds.h index 194a9d7f..14c7293d 100644 --- a/nest/cmds.h +++ b/nest/cmds.h @@ -16,6 +16,7 @@ struct f_inst; void cmd_show_status(void); void cmd_show_symbols(struct sym_show_data *sym); void cmd_show_memory(void); +void cmd_show_hostname(void); struct f_line; void cmd_eval(const struct f_line *expr); diff --git a/nest/config.Y b/nest/config.Y index 39bf6149..72ea0726 100644 --- a/nest/config.Y +++ b/nest/config.Y @@ -564,6 +564,9 @@ CF_CLI(SHOW STATUS,,, [[Show router status]]) CF_CLI(SHOW MEMORY,,, [[Show memory usage]]) { cmd_show_memory(); } ; +CF_CLI(SHOW HOSTNAME,,, [[Show current hostname]]) +{ cmd_show_hostname(); } ; + CF_CLI(SHOW PROTOCOLS, proto_patt2, [<protocol> | \"<pattern>\"], [[Show routing protocols]]) { proto_apply_cmd($3, proto_cmd_show, 0, 0); } ; -- 2.20.1

1 1

shutdown BGP sessions without administrative shutdown?
by Tim Meusel 05 Mar '21

05 Mar '21

Hi! I'm running many boxes with Bird 2.x. They all peer with virtual JunOS routers via BGP. Each Bird instance announces routes for IP addresses from local virtual machines. In case bird dies or gets stopped for upgrades, I want that the JunOS route reflectors keep the routes for a certain amount of time. My config currently looks like this: template bgp VMX { local $ip as $as; multihop; # we don't have a layer 2 connection to the routers bfd graceful; hold time 240; startup hold time 240; connect retry time 120; graceful restart yes; graceful restart time 0; long lived graceful restart yes; long lived stale time 90; ipv4 { export filter virtual_machines_v4; import none; next hop self; }; ipv6 { export filter virtual_machines_v6; import none; next hop self; }; } protocol bgp $peer from VMX { description $desc; neighbor $ip> as $as; } this works fine if I do: * birdc reconfigure * kill -HUP on the bird pid * killall -9 bird however if I do a `systemctl stop bird`, it does an administrative shutdown and the virtual MX drops the routes. As far as I understand the RFC for LLGR this is the correct behavior. Can one of you tell me if there is an option on JunOS to keep the routes, even after a ` administrative shutdown`, or if I can advice Bird to not cleanly shutdown sessions? Cheers, Tim

2 2

[PATCH] Add 'preferred' route attribute for selective add-path
by Trisha Biswas 04 Mar '21

04 Mar '21

Hi all, The attached patch adds a 'preferred' route attribute to check whether the route being processed has been selected as the best-path for the network it belongs to. This attribute does not take in a value, and returns a boolean. This is useful for allowing selection in an add-path enabled BGP session. The motivation behind selective add paths is to reduce the number of routes that are shared in an add-path enabled BGP session on a per-prefix basis. Instead of sending all paths to all destinations for an add-path session, we would like to specify prefixes (and/or other route attributes) for which all paths are to be shared. Further, if there are thousands of ways to reach a destination, simply negotiating add paths for a prefix would result in sharing all additional paths to the peer. This in turn would result in a flood of advertisements to be sent between the nodes, and a high memory footprint on the peer. To avoid this, we are considering a filter-based selection criteria that would unlock the potential of purposefully sending additional paths when desired. Adding the 'preferred' keyword allows us to always send the best-path whether or not other criteria in the export filter match. In the following example, a route is exported when it is either the best route or one of 172.16.0.0/16, 10.0.0.0/8{16,24} (regardless of best route status). In the case of 8.8.8.0/24, we export it if it's the best route, or if it additionally has the specified extended community attached to the route. protocol bgp { [....] add paths tx; export filter { if preferred || (net = [172.16.0.0/16, 10.0.0.0/8{16,24}]) then accept; if preferred || (net = 8.8.8.0/24 && (ro, 1, 2) ~ bgp_ext_community) then accept; #remaining filter code reject; } } Cheers, Trisha -- *Trisha Biswas* | Sr. Software Engineer, Network Systems fastly.com | @fastly <https://twitter.com/fastly> | LinkedIn <http://www.linkedin.com/company/fastly>

3 5

Support for ECMP on FreeBSD 13
by Zhenlei Huang 26 Feb '21

26 Feb '21

Hi, Currently Bird 2.x does not support ECMP on FreeBSD system. Thanks Alexander V. Chernikov's work, the feature ECMP route was enabled by default in FreeBSD 13 amd64 GENERIC. Are there any plans Bird2.x will support ECMP on FreeBSD, or at least on FreeBSD 13 ? Links: https://gitlab.nic.cz/labs/bird/commit/f9f2e280ea4fa1af19d8ce9e54abeb495694… https://reviews.freebsd.org/D26449 Thanks, zlei

5 5

Bird pipe/filter change on "external" conditions
by ico 23 Feb '21

23 Feb '21

Hello, Is there some way to change bird's configuration on some external event? I would use it like this: There are 2 routers, active and passive. Active router exports default route for the rest of network. Passive router has exactly the same configuration, but filters out default route. When active/passive switch function, the new active somehow removes default route filter, the new passive adds default route filter. Another usage would be to change interface cost in OSPF at run-time and thus redirecting traffic from that particular interface. Currently I am doing it with rewritting bird's config file and reloading configuration. Is there some better way? Like setting some variable, which causes changes some filter conditions? Thanks ico

3 3

What causes unreachable OSPF neighbor?
by ico 22 Feb '21

22 Feb '21

Hello, I have 10 routers talking OSPF on a switch on network 10.10.4.0/24. Now I want to add 11th and am unable to make it work. I see the new router in neighbors, also other neighbors on the new router. The new router doesn't get any routes from others, because others see it as unreachable (10.10.4.45 is the new router, 10.10.4.48 is one of old working routers): bird> show ospf topology all ... router 10.10.4.45 unreachable network 10.10.4.0/24 metric 10 router 10.10.4.48 distance 10 network 10.8.253.0/26 metric 50 network 10.10.4.0/24 metric 10 ... On the new router - all old routers are unreachable: bird> show ospf topology all ... router 10.10.4.45 distance 0 network 10.10.4.0/24 metric 10 router 10.10.4.48 unreachable network 10.8.253.0/26 metric 50 network 10.10.4.0/24 metric 10 ... The normal traffic (ping, ssh) works of course, IP configuration is currently at minimum (single interface, IP 10.10.4.45/24). OS is Linux 5.10, bird 2.0.7. Thanks for any help with this. ico

1 1

BGP sessions flapping before daemon restart
by Alarig Le Lay 19 Feb '21

19 Feb '21

Hi, Yesterday I added six sessions on a router (3 v4, 3 v6). First, all new sessions were flapping, then the v6 one went stable, but the v4 one were still flapping. I restarted bird and then all the sessions became stable. So I don’t understand why it was limited to IPv4 and why the restart fixed it, and why other sessions weren’t flapping as well (there are 16 in total). Here are pcaps in case I missed something obvious. https://herbizarre.swordarmor.fr/garbage/documents/bird_bgp_flap-1.pcap https://herbizarre.swordarmor.fr/garbage/documents/bird_bgp_flap-2.pcap My side is the Intel MAC. The router has an uptime 147 days, so bird was pretty close to that. I’m running a 4.14.x kernel. Regards, -- Alarig Le Lay

1 0

Next 1.6 release
by Vinod Padmanabhan 18 Feb '21

18 Feb '21

Hi, Are there any plans to release another Bird 1.6 version or will the subsequent releases be based only on Bird 2.x? Thanks, Vinod

2 1

route aggregation
by Kseniya Blashchuk 18 Feb '21

18 Feb '21

Hello! Is there any chance we will have route aggregation for BGP soon? I have found some mentions of it in old emails however it seems that it's not yet implemented. Can anybody share this information? Thanks in advance.

2 1