March 2021 - Bird-users - Mailing Lists

[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

BIRD 2.0.8
by Ondrej Filip 14 Apr '21

14 Apr '21

Hello! I have great news for you! My colleagues did a fantastic job and after a while we can present a new BIRD release - 2.0.8. Here is a list of changes: o Automatic channel reloads based on RPKI changes o Multiple static routes with the same network o Use bitmaps to keep track of exported routes o Per-channel debug flags o CLI commands show info from multiple protocols o Linux: IPv4 routes with IPv6 nexthops o Filter: Optimized redesign of prefix sets o Filter: Improved type checking of user filters o Filter: New src/dst accessors for Flowspec and SADR o Filter: New 'weight' route attribute o Filter: BGP path mask loop operator o Filter: Remove quitbird command o RIP: Demand circuit support (RFC 2091) o BGP: New 'allow as sets' and 'enforce first as' options o BGP: Support for BGP hostname capability o BGP: Support for MD5SIG with dynamic BGP o BFD: Optional separation of IPv4 / IPv6 BFD instances o BFD: Per-peer session options o RPKI: Allow build without libSSH o RPKI: New 'ignore max length' option o OSPF: Redesign of handling of unnumbered PtPs o OSPF: Allow key id 0 in authentication o Babel: Use onlink flag for routes with unreachable next hop o Many bugfixes Notes: Automatic channel reloads based on RPKI changes are enabled by default, but require import table enabled when used in BGP import filter. BIRD now uses bitmaps to keep track of exported routes instead of re-evaluation of export filters. That should improve speed and accuracy in route export handling during reconfiguration, but takes some more memory. Per-channel debug logging and some CLI commands (like 'show ospf neighbors') defaulting to all protocol instances lead to some minor changes in log and CLI output. Caution is recommended when logs or CLI output are monitored by scripts. So please test it, run it and write your feedback! Cheers Ondrej

15 62

ignore max length as an argument of roa_check
by Pier Carlo Chiodi 31 Mar '21

31 Mar '21

Hello, first, thanks to the devs for 2.0.8! I see the option 'ignore max length' was introduced, and that it's possible to enable it at protocol configuration time. ignore max length switch Ignore received max length in ROA records and use max value (32 or 128) instead. This may be useful for implementing loose RPKI check for blackholes. Default: disabled. I was wondering what other people's feelings would be about having a similar option available at validation time, more specifically as an argument of roa_check. If my understanding is correct, being the current option available only at protocol level, it means that all the ROAs that are present inside the ROA table are used as if the maxLength attribute is not set. This means that it wouldn't be possible to configure a filter to perform a strict OV check (where the maxLength is also taken into account) using ROAs from that table. Having that option available at roa_check time, the same table could be used to perform both strict validation and also a loose validation, for example depending on the presence of the BLACKHOLE BGP community: (pseudo-code follows) # ... regular sanity checks done here... if BLACKHOLE { if (roa_check(ignore_max_lenght=True) = ROA_INVALID) then { reject; } accept; } else { if (roa_check() = ROA_INVALID) then { reject; } accept; } (Assuming ignore_max_lenght has default value == False.) Does it make sense? Thanks Pier Carlo Chiodi

5 7

[PATCH] MRT: Add overwrite switch (default: off)
by Wydrych, Piotr 29 Mar '21

29 Mar '21

Hello, I was working recently with MRT dumps. I wrote a small patch that allows bird to overwrite the dump file. Piotr -- Piotr 'GhosT' Wydrych ........ Engineering Manager, SDN ......... Akamai ........................................................................ A: Because it messes up the order in which people normally read text. .. Q: Why is top-posting such a bad thing? ................................

1 0

BGP connect retry time
by dev＠kou.li 29 Mar '21

29 Mar '21

Hello, I am running bird's BGP on a slower link with accounted data. I would like to lower connection attempt frequency when the peer is down. I found only two parameters mentioning connection delays: 'connect delay time' and 'connect retry time'. From documentation, I understood to change the 'connect retry time' to slow down failed connection attempts, but the bird seems to use 'connect delay time' repeatedly if the connection fails (test: bird 1.6.6, peer's firewall drops all BGP packets). So, what is the 'connect retry time' used for? Also, if I increase the 'connect delay time' to lower BGP data throughput in case the peer is offline, I introduce also unwanted delay when everything works and only the BGP protocol is restarted... I understand bird 1.6.6 is rather old to ask for any help here. However, it is such a basic functionality I do not believe it to have changed recently. Also, I found no mention of these parameters in the NEWS file. Milan

2 1

BMP protocol support - request for review and merge
by Maslanka, Pawel 29 Mar '21

29 Mar '21

Hi BIRD devs, Akamai team have implemented basic subset of BMP (BGP Monitoring Protocol) specification for BIRD project (according to RFC 7854). We are happy to share our work with BIRD community and would ask for review patch. Please feel free for modify this patch to meet BIRD source code requirements for merge it to BIRD mainline code since we post this patch under to GPLv2+ license (please look at |proto/bmp/LICENSE|). It worth to note that there are few minor unimplemented things from RFC 7854, but the most important are: - not implemented Route Mirroring message - not implemented Stats Report message This implementation has been tested with open source BMP collectors like OpenBMP and pmacct. This patch is compatible with BIRD v2.0.7 release. Additionally I would like to take the opportunity to thank Ondrej Zajicek for hints to contribution of this patch according to BIRD project specification. Thanks, Pawel Maslanka Software Engineer at Akamai Technologies, Inc.

2 1

Incorrect setting of BGP Path Attribute Extended Length flag breaks MRT output
by Simon Marsh 28 Mar '21

28 Mar '21

Hi, i run bird as a route collector in DN42 and so get a variety of different BGP daemons peering with and passing routes to the collector. We recently ran in to an issue where MRT dumps from bird were not readable by any of the common MRT parsers and, on investigation, found a bug in how bird handles the BGP Path Attribute Extended Length flag. The issue occurred because peers using the FRR daemon set the Extended Length flag on the AS PATH attribute by default, regardless of the actual data length. When bird re-encodes the AS Path (for example as part of the MRT dump) it correctly re-calculates whether to use an 8 bit or 16 bit length field for the attribute, but simply copies the flags and does not reset the Extended Length flag in the 8 bit case. This results in an AS PATH attribute being output that has the Extended Length flag set but with the actual length field being only 8 bits. Of course, any parsers trying read this get very confused. A simple fix is to ensure the Extended Length flag is cleared when encoding the 3 byte attribute header: diff --git a/proto/bgp/attrs.c b/proto/bgp/attrs.c index 6752cb7f..5c7b4fdd 100644 --- a/proto/bgp/attrs.c +++ b/proto/bgp/attrs.c @@ -118,7 +118,7 @@ bgp_set_attr(ea_list **attrs, struct linpool *pool, uint code, uint flags, uintp static inline int bgp_put_attr_hdr3(byte *buf, uint code, uint flags, uint len) { - *buf++ = flags; + *buf++ = flags & ~BAF_EXT_LEN; *buf++ = code; *buf++ = len; return 3; Cheers Simon

2 1

A ifname counterpart for the "from" attribute
by Marcel Krüger 26 Mar '21

26 Mar '21

Hi, is there any way to identify in a filter the interface the route was learned from? So basically an attribute which relates to "from" like ifname and ifindex relate to "gw"? This would be particularly useful when "from" is a link lcal address and therefore might not be enough to identify the source. If this doesn't exists, is there another way to enforce that the "gw" is always on the same interface the route was learned on whithout having to use interface specific configuration (e.g. customized filters or special igp tables in BGP). (I am mostly interested in BGP, but I guess that most solutions would apply more gnerally) If not, would a patch implementing such an route attribute have a chance of being merged? Best regards, Marcel

2 1

Re: Foreign upstream gateway for remote maintenance
by Bernd Naumann 26 Mar '21

26 Mar '21

Good morning Nils, On 26.03.21 08:47, Nils van Lück wrote: > Hello! > > I am using the latest Bird version from the git repo under Debian. I > have one dedicated NIC for the LAN, one dedicated NIC for BGP sessions > and one NIC with an IP from a foreign ASN for remote maintenance. How > can I make the routed traffic go through Bird but still connect to a > foreign gateway via SSH through another NIC? Also the operating system > updates (apt-get) should run over the third NIC and not over the bird > routes. > > NIC 1: LAN / OSPF > NIC 2: BGP / Peering / routed traffic over bird > NIC 3: foreign gateway fo remote maintenance of the routers debian instance > > Regards, > > Nils van Lück I'm not 100% sure... but I see two two ways, but both with limitations. Maybe someone can comment on these approaches, or provide an alternative better idea. 1) Use different routing tables. This way you can ensure that traffic which hits nic3 goes out of nic3 then. See https://tldp.org/HOWTO/pdf/Adv-Routing-HOWTO.pdf Section 4.2.1. Split access for the general setup But I do not know how you would /tell/ `apt` to use that table or a specific source address (so its traffic would then go out of nic3). However, bird is able to use different tables. 2) Using namespaces Start `sshd` in a separate namespace, and call `apt` also only from within this namespace. This namespace would only have `lo` and `nic3`. See for instance https://lwn.net/Articles/580893/ While using a namespace for sshd and apt, you would not need to configure bird / tell bird about it. Hope this helps somehow. Best, Bernd

2 1

Foreign upstream gateway for remote maintenance
by Nils van Lück 26 Mar '21

26 Mar '21

Hello! I am using the latest Bird version from the git repo under Debian. I have one dedicated NIC for the LAN, one dedicated NIC for BGP sessions and one NIC with an IP from a foreign ASN for remote maintenance. How can I make the routed traffic go through Bird but still connect to a foreign gateway via SSH through another NIC? Also the operating system updates (apt-get) should run over the third NIC and not over the bird routes. NIC 1: LAN / OSPF NIC 2: BGP / Peering / routed traffic over bird NIC 3: foreign gateway fo remote maintenance of the routers debian instance Regards, Nils van Lück

1 0