openbgpds not talking each other since 8.2-STABLE upgrade

[Nikolay Denev]

On Jan 3, 2012, at 9:36 PM, sthaug at nethelp.no wrote:

>> Doug, does your kernel have TCP_SIGNATURE option?  The patch[*] for
>> net/openbgpd can be used as a workaround if it was due to TCP_MD5SIG
>> option on the listening sockets.
>> 
>> [*] http://people.allbsd.org/~hrs/FreeBSD/openbgpd.20120104-1.diff
>> 
>> While this is an ugly hack and I will investigate more reasonable
>> solution for that, I want to narrow down the cause first.  Can anyone
>> who are using a 8-STABLE kenrel with TCP_SIGNATURE let me know if
>> this works or not?
> 
> 8-STABLE on several servers, csup'ed only a couple of days ago, with 
> 
> options         TCP_SIGNATURE
> options         IPSEC
> device          crypto
> device          cryptodev
> 
> and Quagga bgpd talking to Juniper M/MX routers using MD5 key on the
> BGP sessions. No problems.
> 
> Steinar Haug, Nethelp consulting, sthaug at nethelp.no

This was always working for me. My problem was that I had two routers
having BGP sessions to an ISP with md5 and a session between themselves without md5.
After I upgraded to 8-STABLE some time ago, the md5 sessions still worked, but
the ones without did not. tcpdump showed packets with md5 digest fields all zeroes.
If one of the machines does not have md5 signature support it will probably work,
since when one of the routers tries to speak tcpmd5 even with incorrect digest field,
the other one tries to respond also with tcpmd5.

Also there are some things in the tcp(4) manual page that should be fixed to reflect
the new behaviour (the part mentioning that incoming digests are not verified):

     TCP_MD5SIG   This option enables the use of MD5 digests (also known as
                  TCP-MD5) on writes to the specified socket.  In the current
                  release, only outgoing traffic is digested; digests on
                  incoming traffic are not verified.  The current default
                  behavior for the system is to respond to a system advertis-
                  ing this option with TCP-MD5; this may change.

Also in the case of my failing BGP sessions I expected to see errors as per the man page :

                  If an SADB entry cannot be found for the destination, the
                  outgoing traffic will have an invalid digest option
                  prepended, and the following error message will be visible
                  on the system console: tcp_signature_compute: SADB lookup
                  failed for %d.%d.%d.%d.

But this was not happening.

Regards,
Nikolay