Openbgpd incorrectly sets TCP_MD5 on the listen socket, regardless of configuration

[Nikolay Denev]

On Nov 21, 2011, at 3:29 PM, Borja Marcos wrote:

> 
> (Sent to freebsd-bugs as well, copied here for discussion, if needed)
> 
> 
> 
> 
> 	
> Sorry for the brief report and the scarce details. The f****ing form insists on rejecting the captcha after one hour writing a report. 
> 
> So, in short:
> 
> If TCP_MD5 is available on the system,
> options         IPSEC
> options         TCP_SIGNATURE           #include support for RFC 2385
> device	      crypto
> 
> Turns out openbgpd can't receive BGP connections. 
> 
> The error is in the session.c file, line 148, function setup_listeners(u_int *la_cnt).
> 
> Code snippet:
> 
>               opt = 1;
>               if (setsockopt(la->fd, IPPROTO_TCP, TCP_MD5SIG,
>                   &opt, sizeof(opt)) == -1) {
>                       if (errno == ENOPROTOOPT) {     /* system w/o md5sig */
>                               log_warnx("md5sig not available, disabling");
>                               sysdep.no_md5sig = 1;
>                       } else
>                               fatal("setsockopt TCP_MD5SIG");
>               }
> 
> 
> This is wrong. Regardless of the configuration, this code activates TCP_MD5 for the socket and leaves it enabled. This is what happens:
> 
> 14:04:33.009212 IP 10.0.0.2.36610 > 10.0.0.1.179: Flags [S], seq 1941690122, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 115224 ecr 0], length 0
> 14:04:33.009267 IP 10.0.0.1.179 > 10.0.0.2.36610: Flags [S.], seq 2935503211, ack 1941690123, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 4192648161 ecr 115224,nop,nop,md5shared secret not supplied with -M, can't check - a360f2c9a9f96a582ccbabe79418105c], length 0
> 
> The daemon receiving the connection is replying with TCP_MD5, even though there's no TCP_MD5 option set in the bgpd.conf file.
> 
> Removing this code (or placing it outside of the loop, creating a temporary socket just to enable TCP_MD5 on it and using it to detect the availability of TCP_MD5) works:
> 
> 14:04:35.395447 IP 10.0.0.1.45119 > 10.0.0.2.179: Flags [S], seq 366635408, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 220116 ecr 0], length 0
> 14:04:35.395490 IP 10.0.0.2.179 > 10.0.0.1.45119: Flags [S.], seq 1226417253, ack 366635409, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 511187362 ecr 220116], length 0
> 14:04:35.395584 IP 10.0.0.1.45119 > 10.0.0.2.179: Flags [.], ack 1, win 1040, options [nop,nop,TS val 220116 ecr 511187362], length 0
> 14:04:35.396072 IP 10.0.0.1.45119 > 10.0.0.2.179: Flags [P.], seq 1:46, ack 1, win 1040, options [nop,nop,TS val 220116 ecr 511187362], length 45: BGP, length: 45
> 14:04:35.397031 IP 10.0.0.2.179 > 10.0.0.1.45119: Flags [P.], seq 1:50, ack 46, win 1040, options [nop,nop,TS val 511187362 ecr 220116], length 49: BGP, length: 49
> 14:04:35.397381 IP 10.0.0.1.45119 > 10.0.0.2.179: Flags [P.], seq 46:65, ack 50, win 1040, options [nop,nop,TS val 220116 ecr 511187362], length 19: BGP, length: 19
> 
> 
> 
> 
> Sorry for the terse report. It was very detailed, but lost.
> 
> 
> Borja.

Hello,

I'm seeing exactly the same problem with Quagga.
Quagga's bgpd also seem to always set the TCP_MD5 socket option, and newer freebsd 8.2 machines
 don't seem to be able to establish bgp sessions, probably due to the recent TCP_MD5 fixes that enabled
the TCP_MD5 checksum verification of incoming packets.

Since both daemons do this, and I guess this works fine with Quagga under Linux, I'm not sure that this is incorrect.

The tcp(4) man page states :
   "The current default behavior for the system is to respond to a system advertising this option with TCP-MD5; this may change."

the RFC states :

   Upon receiving a signed segment, the receiver must validate it by
   calculating its own digest from the same data (using its own key) and
   comparing the two digest.  A failing comparison must result in the
   segment being dropped and must not produce any response back to the
   sender.  Logging the failure is probably advisable.


Anyways, this is clearly a problem that started manifesting itself with recent FreeBSD versions, and I've
put "sysctl net.inet.tcp.signature_verify_input=0" in my sysctl.conf which seems to help restore the old behavior.

Regards,
Nikolay