November 2020 - Bird-users

Calling named filters from another filter
by Michael Rack 23 Nov '20

23 Nov '20

Hi, i did not find anything for this on the internet, so sorry if that topic was discussed already before. I have a named filter and I like to call this filter from another filter. filter peers_v4_in() { ...... }; > filter special_peer_v4_in() { ......; peers_v4_in(); }; > protocol bgp myspecialpeer { > ipv4 { import special_peer_v4_in(); }; > }; Is this even possible? Thank you. Michael.

2 1

Unable to get Bird 2 to listen on the BGP socket
by Skyler Mäntysaari 23 Nov '20

23 Nov '20

Hi there, I’m fairly certain that my issue is something rather small, or stupid but I’m unable to get Bird to listen on the 179 port. The other side has direct in the protocol definition which is correct, and I tried this side with that as well but it only says “as213021_hel_node: Waiting for fe80:10::1%wg1 to become my neighbor” so I don’t really have more clues. I did try to do strace and look for bind events, but couldn’t find any except for the control socket. My config can be seen here: https://dpaste.com/6P6NAUPNX <https://dpaste.com/6P6NAUPNX> & peer config: https://dpaste.com/HJ3SNL8RH <https://dpaste.com/HJ3SNL8RH>

10 20

BIRD crashing when --enable-debug is set
by andreas＠rammhold.de 23 Nov '20

23 Nov '20

Hi, I've been playing with the BIRD source code and implementing a new extension to Babel but that is not what this mail is about. While doing that I noticed passing --enable-debug to configure causes BIRD to crash regardless of configuration: > $ bt > #0 0x00007ffff7d9741a in raise () from /nix/store/2wrfwfdpklhaqhjxgq6yd257cagdxgph-glibc-2.32/lib/libc.so.6 > #1 0x00007ffff7d81523 in abort () from /nix/store/2wrfwfdpklhaqhjxgq6yd257cagdxgph-glibc-2.32/lib/libc.so.6 > #2 0x00000000004912c7 in bug (msg=msg@entry=0x4a06d8 "Assertion '%s' failed at %s:%d") at sysdep/unix/log.c:281 > #3 0x000000000049175f in add_tail (n=0x4e4880 <lc_syslog>, l=0x4e8060 <log_list>) at ./lib/lists.c:79 > #4 default_log_list (syslog_name=<synthetic pointer>, initial=0x0) at sysdep/unix/log.c:345 > #5 log_switch (initial=initial@entry=0x0, logs=logs@entry=0x4eecb0, new_syslog_name=0x0) at sysdep/unix/log.c:373 > #6 0x000000000049216b in sysdep_commit (new=new@entry=0x4eec70, old=<optimized out>) at sysdep/unix/main.c:188 > #7 0x0000000000420a1a in config_do_commit (c=c@entry=0x4eec70, type=type@entry=0x1) at conf/conf.c:265 > #8 0x0000000000420c29 in config_commit (c=c@entry=0x4eec70, type=type@entry=0x1, timeout=timeout@entry=0x0) at conf/conf.c:361 > #9 0x0000000000492f3a in main (argc=<optimized out>, argv=<optimized out>) at sysdep/unix/main.c:912 > #10 0x00007ffff7d82dbd in __libc_start_main () from /nix/store/2wrfwfdpklhaqhjxgq6yd257cagdxgph-glibc-2.32/lib/libc.so.6 > #11 0x000000000041087a in _start () at ../sysdeps/x86_64/start.S:120 The statement triggering this is the check for n->prev == NULL in lib/lists.c:79: 75 │ LIST_INLINE void 76 │ add_tail(list *l, node *n) 77 │ { 78 │ EXPENSIVE_CHECK(check_list(l, NULL)); -> 79 │ ASSUME(n->prev == NULL); 80 │ ASSUME(n->next == NULL); 81 │ 82 │ node *z = l->tail; 83 │ 84 │ n->next = &l->tail_node; 85 │ n->prev = z; 86 │ z->next = n; 87 │ l->tail = n; 88 │ } Note: Expensive checks are disabled. To reproduce build BIRD on the current master (3347aaf as of this writing) pass --enable-debug to the configure script. Create a simple configuration file that contains at least one protocol. I used just "protocol device {}" as the whole of the configuration file. Then execute "./bird -c minimal.conf -s test.ctl -f" and observe it crash. Bisecting the issue from v2.0.7 to the latest master branch showed that this seems to have been broken / uncovered in baac700: > commit baac7009063d94799821422ecc63ea2af41561ea (refs/bisect/bad) > Author: Maria Matejka <mq(a)ucw.cz> > Date: Wed Aug 14 16:23:58 2019 +0200 > > List expensive check. (https://gitlab.nic.cz/labs/bird/-/commit/baac7009063d94799821422ecc63ea2af4…) Looking at the backtrace we can see that `default_log_list` is being called just before the check is being made: sysdep/unix/log.c 341 │ #ifdef HAVE_SYSLOG_H 342 │ if (!dbgf) 343 │ { 344 │ static struct log_config lc_syslog = { .mask = ~0 }; -> 345 │ add_tail(&log_list, &lc_syslog.n); 346 │ *syslog_name = bird_name; 347 │ } 348 │ #endif This code path is being called twice during the startup. One of the call chains is the one visible in the backtrace (which happens after/during configuration commit) and the other happens very early in the process startup: sysdep/unix/main.c 843 │ int 844 │ main(int argc, char **argv) 845 │ { … 851 │ parse_args(argc, argv); -> 852 │ log_switch(1, NULL, NULL); … 912 │ config_commit(conf, RECONFIG_HARD, 0); // 2nd call, see bt Since the log_config struct is static (sysdep/unix/log.c:344) the same entry is being added twice to the log_list and thus at the 2nd attempt of adding it the prev field is no longer the expected NULL value and thus triggering the shown abort. The log_list itself is also static (in default_log_list) but initialized on every execution of the function. Probably purposely. This still leaves for a brief moment where structures are inconsistent. I am not yet familiar enough with the BIRD code base to reason about where threading is use and if this is an actual issue or not. Now the question is where the fix should happen? We could add code to the log_close logic that resets the node pointers of each of the entries? Another option could be in the default_log_list function by just reassigning the value of each fo the log_config structs on every single call to the function. As the log_list is also initialized on every call this is perhaps the simplest but also not cleanest way to deal with this? The initially described issue also occurs when not setting --enable-debug it just goes silently unnoticed. I went ahead and applied the below patch to make all ASSUME invocations log (in a normal build) to see how many more of those messages are going unnoticed. ------< snip >------ diff --git a/lib/birdlib.h b/lib/birdlib.h index 23036c1b..76848e2c 100644 --- a/lib/birdlib.h +++ b/lib/birdlib.h @@ -176,7 +176,7 @@ void debug(const char *msg, ...); /* Printf to debug output */ #endif #else #define ASSERT(x) do { if (!(x)) log(L_BUG "Assertion '%s' failed at %s:%d", #x, __FILE__, __LINE__); } while(0) -#define ASSUME(x) /* intentionally left blank */ +#define ASSUME(x) do { if (!(x)) log(L_BUG "Assertion '%s' failed at %s:%d\n", #x, __FILE__, __LINE__); } while(0) #endif ------< snip >------ On one of my machines with a few BGP sessions and Babel interfaces I instructed GDB to print a backtrace whenever the n->prev == NULL condition fails. Here the those few that I saw and could distinguish after a very brief look. > Breakpoint 1, add_tail (n=0x110f298, l=0x7fff7cb58b60) at ./lib/lists.c:80 > #0 add_tail (n=0x110f298, l=0x7fff7cb58b60) at ./lib/lists.c:80 > #1 babel_process_packet (pkt=<optimized out>, len=<optimized out>, saddr=..., ifa=<optimized out>) at proto/babel/packets.c:1393 > #2 0x000000000043e2aa in babel_rx_hook (sk=<optimized out>, len=<optimized out>) at proto/babel/packets.c:1472 > #3 0x000000000040a9d3 in sk_read (s=s@entry=0x110dc80, revents=<optimized out>) at sysdep/unix/io.c:1910 > #4 0x000000000040b394 in io_loop () at sysdep/unix/io.c:2342 > #5 0x000000000040b760 in main (argc=<optimized out>, argv=<optimized out>) at sysdep/unix/main.c:923 > Breakpoint 1, add_tail (n=0x110f6d0, l=0x1108848) at ./lib/lists.c:80 > #0 add_tail (n=0x110f6d0, l=0x1108848) at ./lib/lists.c:80 > #1 babel_enqueue (msg=<optimized out>, ifa=0x11087b0) at proto/babel/packets.c:1309 > #2 0x0000000000445143 in babel_send_seqno_request (p=p@entry=0x109bc20, e=e@entry=0x11050c8, sr=sr@entry=0x1271718) at proto/babel/babel.c:911 > #3 0x00000000004459c5 in babel_add_seqno_request (p=p@entry=0x109bc20, e=e@entry=0x11050c8, router_id=<optimized out>, seqno=<optimized out>, hop_count=hop_count@entry=0 '\000', > nbr=nbr@entry=0x0) at proto/babel/babel.c:337 > #4 0x0000000000445cf3 in babel_select_route (p=p@entry=0x109bc20, e=0x11050c8, mod=<optimized out>) at proto/babel/babel.c:775 > #5 0x0000000000445f13 in babel_update_cost (nbr=nbr@entry=0x1111710) at proto/babel/babel.c:611 > #6 0x000000000044626b in babel_expire_hello (p=p@entry=0x109bc20, nbr=nbr@entry=0x1111710, now_=now_@entry=242732001004) at proto/babel/babel.c:486 > #7 0x00000000004462ed in babel_expire_neighbors (p=p@entry=0x109bc20) at proto/babel/babel.c:506 > #8 0x00000000004473ae in babel_timer (t=<optimized out>) at proto/babel/babel.c:2072 > #9 0x000000000045da19 in timers_fire (loop=0x4db740 <main_timeloop>) at lib/timer.c:235 > #10 0x000000000040afe9 in io_loop () at sysdep/unix/io.c:2192 > #11 0x000000000040b760 in main (argc=<optimized out>, argv=<optimized out>) at sysdep/unix/main.c:923 > Breakpoint 1, add_tail (n=0x22c61a8, l=0x7ffe4c97c250) at ./lib/lists.c:80 > #0 add_tail (n=0x22c61a8, l=0x7ffe4c97c250) at ./lib/lists.c:80 > #1 babel_send_unicast (msg=0x7ffe4c97c2a0, ifa=0x22bfa20, dest=...) at proto/babel/packets.c:1283 > #2 0x00000000004451d9 in babel_send_route_request (p=<optimized out>, e=<optimized out>, n=0x22c8800) at proto/babel/babel.c:869 > #3 0x0000000000445233 in babel_refresh_route (p=p@entry=0x2252c20, r=r@entry=0x2423108) at proto/babel/babel.c:220 > #4 0x00000000004471c3 in babel_expire_routes_ (p=p@entry=0x2252c20, rtable=rtable@entry=0x2252d58) at proto/babel/babel.c:243 > #5 0x0000000000447388 in babel_expire_routes (p=p@entry=0x2252c20) at proto/babel/babel.c:293 > #6 0x00000000004473a6 in babel_timer (t=<optimized out>) at proto/babel/babel.c:2071 > #7 0x000000000045da19 in timers_fire (loop=0x4db740 <main_timeloop>) at lib/timer.c:235 > #8 0x000000000040afe9 in io_loop () at sysdep/unix/io.c:2192 > #9 0x000000000040b760 in main (argc=<optimized out>, argv=<optimized out>) at sysdep/unix/main.c:923 > Breakpoint 1, add_tail (n=0x234ac30, l=0x241f620) at ./lib/lists.c:82 > #0 add_tail (n=0x234ac30, l=0x241f620) at ./lib/lists.c:82 > #1 sl_alloc (s=0x21bd7d0) at lib/slab.c:264 > #2 0x000000000044f3e2 in rte_get_temp (a=0x22ffe18) at nest/rt-table.c:282 > #3 0x0000000000434220 in bgp_rte_update (s=s@entry=0x7ffe4c97c110, n=n@entry=0x7ffe4c97bf80, path_id=path_id@entry=0, a0=a0@entry=0x7ffe4c97bfd0) at proto/bgp/packets.c:1326 > #4 0x00000000004359db in bgp_decode_nlri_ip4 (s=0x7ffe4c97c110, pos=<optimized out>, len=<optimized out>, a=0x7ffe4c97bfd0) at proto/bgp/packets.c:1479 > #5 0x0000000000432f2b in bgp_decode_nlri (s=s@entry=0x7ffe4c97c110, afi=afi@entry=65537, nlri=<optimized out>, len=<optimized out>, ea=ea@entry=0x22fa4c0, nh=<optimized out>, > nh_len=<optimized out>) at proto/bgp/packets.c:2410 > #6 0x00000000004383a9 in bgp_rx_update (conn=conn@entry=0x2250728, pkt=pkt@entry=0x22c8a20 '\377' <repeats 16 times>, len=len@entry=227) at proto/bgp/packets.c:2505 > #7 0x0000000000438ef9 in bgp_rx_packet (conn=conn@entry=0x2250728, pkt=pkt@entry=0x22c8a20 '\377' <repeats 16 times>, len=227) at proto/bgp/packets.c:3097 > #8 0x0000000000438fb5 in bgp_rx (sk=0x22c88d0, size=<optimized out>) at proto/bgp/packets.c:3142 > #9 0x00000000004039a0 in call_rx_hook (s=s@entry=0x22c88d0, size=<optimized out>) at sysdep/unix/io.c:1796 > #10 0x000000000040a8dd in sk_read (s=s@entry=0x22c88d0, revents=1) at sysdep/unix/io.c:1884 > #11 0x000000000040b394 in io_loop () at sysdep/unix/io.c:2342 > #12 0x000000000040b760 in main (argc=<optimized out>, argv=<optimized out>) at sysdep/unix/main.c:923 Are these all false positives or should there be more cleanup code on these list entries? Sorry for the noise, Andi

4 8

[PATCH] babel: Initialise objects from slab completely
by Toke Høiland-Jørgensen 22 Nov '20

22 Nov '20

The babel protocol code was initialising objects returned from the slab allocator by assigning to each of the struct members individually, but wasn't touching the NODE member while doing so. This leads to warnings on debug builds since commit: baac7009063d ("List expensive check.") So let's change the babel code to make sure we also zero-initialise the list node. For the packet parser, just move the existing memset() out of babel_read_tlv() and in all other places, use struct assignment for initialising members, which is idiomatic for Bird. Signed-off-by: Toke Høiland-Jørgensen <toke(a)toke.dk> --- proto/babel/babel.c | 31 ++++++++++++++++++------------- proto/babel/packets.c | 7 ++++--- 2 files changed, 22 insertions(+), 16 deletions(-) diff --git a/proto/babel/babel.c b/proto/babel/babel.c index 618abaa8a..588b29eaa 100644 --- a/proto/babel/babel.c +++ b/proto/babel/babel.c @@ -114,10 +114,12 @@ babel_get_source(struct babel_proto *p, struct babel_entry *e, u64 router_id) return s; s = sl_alloc(p->source_slab); - s->router_id = router_id; - s->expires = current_time() + BABEL_GARBAGE_INTERVAL; - s->seqno = 0; - s->metric = BABEL_INFINITY; + *s = (struct babel_source) { + .router_id = router_id, + .expires = current_time() + BABEL_GARBAGE_INTERVAL, + .seqno = 0, + .metric = BABEL_INFINITY, + }; add_tail(&e->sources, NODE s); return s; @@ -160,10 +162,10 @@ babel_get_route(struct babel_proto *p, struct babel_entry *e, struct babel_neigh return r; r = sl_alloc(p->route_slab); - memset(r, 0, sizeof(*r)); - - r->e = e; - r->neigh = nbr; + *r = (struct babel_route) { + .e = e, + .neigh = nbr + }; add_tail(&e->routes, NODE r); add_tail(&nbr->routes, NODE &r->neigh_route); @@ -326,11 +328,14 @@ babel_add_seqno_request(struct babel_proto *p, struct babel_entry *e, sr = sl_alloc(p->seqno_slab); found: - sr->router_id = router_id; - sr->seqno = seqno; - sr->hop_count = hop_count; - sr->count = 0; - sr->expires = current_time() + BABEL_SEQNO_REQUEST_EXPIRY; + *sr = (struct babel_seqno_request) { + .router_id = router_id, + .seqno = seqno, + .hop_count = hop_count, + .count = 0, + .expires = current_time() + BABEL_SEQNO_REQUEST_EXPIRY, + }; + babel_lock_neighbor(sr->nbr = nbr); add_tail(&e->requests, NODE sr); diff --git a/proto/babel/packets.c b/proto/babel/packets.c index d4ecf649d..98037ce69 100644 --- a/proto/babel/packets.c +++ b/proto/babel/packets.c @@ -1144,7 +1144,6 @@ babel_read_tlv(struct babel_tlv *hdr, return PARSE_ERROR; state->current_tlv_endpos = tlv_data[hdr->type].min_length; - memset(msg, 0, sizeof(*msg)); int res = tlv_data[hdr->type].read_tlv(hdr, msg, state); if (res != PARSE_SUCCESS) @@ -1278,7 +1277,7 @@ babel_send_unicast(union babel_msg *msg, struct babel_iface *ifa, ip_addr dest) struct babel_msg_node *msgn = sl_alloc(p->msg_slab); list queue; - msgn->msg = *msg; + *msgn = (struct babel_msg_node) { .msg = *msg }; init_list(&queue); add_tail(&queue, NODE msgn); babel_write_queue(ifa, &queue); @@ -1305,7 +1304,7 @@ babel_enqueue(union babel_msg *msg, struct babel_iface *ifa) { struct babel_proto *p = ifa->proto; struct babel_msg_node *msgn = sl_alloc(p->msg_slab); - msgn->msg = *msg; + *msgn = (struct babel_msg_node) { .msg = *msg }; add_tail(&ifa->msg_queue, NODE msgn); babel_kick_queue(ifa); } @@ -1387,6 +1386,8 @@ babel_process_packet(struct babel_pkt_header *pkt, int len, } msg = sl_alloc(p->msg_slab); + memset(msg, 0, sizeof(*msg)); + res = babel_read_tlv(tlv, &msg->msg, &state); if (res == PARSE_SUCCESS) { -- 2.29.2

2 1

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

Bird 2 - Diferences between versions, and Roadmap
by Douglas Fischer 19 Nov '20

19 Nov '20

Some projects, like BSDRP, does references on their release do specific "sub-versions" of Bird. I'm trying to find de differences between versions 2.0.7 , 2.0.7_1 , 2.0.7_2. On https://gitlab.nic.cz/labs/bird/-/releases there are no releases available. On https://gitlab.nic.cz/labs/bird/-/commits/master I found some comments about an issue related to the counting of the accepted routes... But I'm not sure if that is the difference between 2.0.7_1 and 2.0.7_2 I also saw in some communications, like this mail-list and slack channels, some references to future versions of Bird 2.0.8. There is any milestone or project defined to that? Roadmap? -- Douglas Fernando Fischer Engº de Controle e Automação

2 1

OSPF v3 DR - intra-area-prefix LSA generation
by Bala Sajja 18 Nov '20

18 Nov '20

I am running bird 2.0.7. Seeing issue with respect to ipv6 address add/delete on DR. This added/deleted ipv6 address prefix convergence is not happening till LSA refresh timer fires . Topology contains 3 routers connected to a switch. Say IPV6 addresses configured on Routers R1(1111::100/64), R2(2222:200/64),R3(3333::300/64). If we are deleting ipv6 addresses other than DR, I could see intra-area-prefix generated by DR and all routers converged with respect to add/deleted ipv6 addresses. With the below change, I could see intra-area-prefix LSA generated on DR also when ipv6 address added/deleted on DR. Please advise if this fix is correct ? --- a/bird-2.0.7/proto/ospf/iface.c +++ b/bird-2.0.7/proto/ospf/iface.c @@ -1187,6 +1187,8 @@ ospf_ifa_notify3(struct proto *P, uint flags, struct ifa *a) /* RFC 5340 4.4.3 Event 5 - prefix added/deleted */ ospf_notify_link_lsa(ifa); ospf_notify_rt_lsa(ifa->oa); + if(ifa->state == OSPF_IS_DR) + ospf_notify_net_lsa(ifa); } } Regards, Bala.

2 3

PATCH: Added BGP attribute example to docs
by Nigel Kukard 18 Nov '20

18 Nov '20

Hi guys, It took me some time to figure this out, perhaps a slight improvement to the docs attached may help. :) -N

2 1

[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