Date: Wed, 23 Nov 2011 10:30:24 +0200 From: Nikolay Denev <ndenev@gmail.com> To: Borja Marcos <borjam@sarenet.es> Cc: freebsd-net@freebsd.org Subject: Re: Openbgpd incorrectly sets TCP_MD5 on the listen socket, regardless of configuration Message-ID: <25CAC0FC-ED0F-42D5-85DC-B7270EFD9814@gmail.com> In-Reply-To: <EE636279-E758-44EA-B5B7-23D66D799E20@sarenet.es> References: <EE636279-E758-44EA-B5B7-23D66D799E20@sarenet.es>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 21, 2011, at 3:29 PM, Borja Marcos wrote:
>=20
> (Sent to freebsd-bugs as well, copied here for discussion, if needed)
>=20
>=20
>=20
>=20
> =09
> Sorry for the brief report and the scarce details. The f****ing form =
insists on rejecting the captcha after one hour writing a report.=20
>=20
> So, in short:
>=20
> If TCP_MD5 is available on the system,
> options IPSEC
> options TCP_SIGNATURE #include support for RFC 2385
> device crypto
>=20
> Turns out openbgpd can't receive BGP connections.=20
>=20
> The error is in the session.c file, line 148, function =
setup_listeners(u_int *la_cnt).
>=20
> Code snippet:
>=20
> opt =3D 1;
> if (setsockopt(la->fd, IPPROTO_TCP, TCP_MD5SIG,
> &opt, sizeof(opt)) =3D=3D -1) {
> if (errno =3D=3D ENOPROTOOPT) { /* system =
w/o md5sig */
> log_warnx("md5sig not available, =
disabling");
> sysdep.no_md5sig =3D 1;
> } else
> fatal("setsockopt TCP_MD5SIG");
> }
>=20
>=20
> This is wrong. Regardless of the configuration, this code activates =
TCP_MD5 for the socket and leaves it enabled. This is what happens:
>=20
> 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
>=20
> The daemon receiving the connection is replying with TCP_MD5, even =
though there's no TCP_MD5 option set in the bgpd.conf file.
>=20
> 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:
>=20
> 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
>=20
>=20
>=20
>=20
> Sorry for the terse report. It was very detailed, but lost.
>=20
>=20
> 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=3D0" in my sysctl.conf =
which seems to help restore the old behavior.
Regards,
Nikolay=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25CAC0FC-ED0F-42D5-85DC-B7270EFD9814>