On Tue, Jul 17, 2018 at 02:12:14PM -0500, Thomas Johnson wrote:
If my limited understanding of the BIRD code is correct, when the configuration of a BGP protocol instance specifies a password, the TCP_MD5SIG option is set on the listen socket (and appropriate connect sockets). Because of the change in behavior for the TCP_MD5SIG option, this effectively bars any non-MD5 connections to the listen socket.
If I change the (non-password) iBGP session configuration to use a password and reconfigure BIRD, the session comes up (as expected). Interestingly, if I then remove the password from the iBGP instance and reconfigure (both BIRD hosts), the session is restarted and works without MD5 (as shown by tcpdump). My guess is that BIRD is removing the relevant option from the listen socket when the configuration is re-read? This is not a particularly good solution (or kludge), as new/restarted sessions that require MD5 would probably fail?
Hi BIRD calls sk_set_md5_auth() on listen socket each time for each MD5-enabled BGP session (with appropriate arguments) to enable password when the BGP session is added and to disable password when the BGP session is removed. On FreeBSD, sk_set_md5_auth() both updates 'setkey' database and changes TCP_MD5SIG socket option. The problem is that TCP_MD5SIG sockopt on BSD is not parametrized, so essentially the active value for listening socket is the last one used (i.e., it is set back to zero when any MD5-enabled session is removed), This is apparently a bug in BIRD, but it was likely ignored by older FreeBSDs. Question is what is a proper value of TCP_MD5SIG socket option for listening sockets that should handle both signed and unsigned incoming connections. Will check that. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."