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

Borja Marcos borjam at sarenet.es
Mon Nov 21 13:45:00 UTC 2011


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.




More information about the freebsd-bugs mailing list