Date: Wed, 23 Nov 2011 11:10:57 +0100 From: Borja Marcos <borjam@sarenet.es> To: Nikolay Denev <ndenev@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: Openbgpd incorrectly sets TCP_MD5 on the listen socket, regardless of configuration Message-ID: <5D60470E-CB00-4804-80BA-2866DE455F5B@sarenet.es> In-Reply-To: <25CAC0FC-ED0F-42D5-85DC-B7270EFD9814@gmail.com> References: <EE636279-E758-44EA-B5B7-23D66D799E20@sarenet.es> <25CAC0FC-ED0F-42D5-85DC-B7270EFD9814@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 23, 2011, at 9:30 AM, Nikolay Denev wrote: > 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. But this is not the behavior I'm seeing with other BGP implementations for FreeBSD: Quagga or Bird. If I enable the TCP MD5 support in the kernel, I can't make OpenBGPD work *unless* I enable TCP MD5 for OpenBGP. This is the difference. I have TCP MD5 enabled in the kernel, but I have *not* set TCP MD5 for the BGP configuration. Telnet to bird: As you can see, I send a SYN, replies with SYN+ACK, etc. The connection goes on. 10:58:24.772799 IP 10.0.0.1.39653 > 10.0.0.2.179: Flags [S], seq 2862267556, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 299847 ecr 0], length 0 10:58:24.773165 IP 10.0.0.2.179 > 10.0.0.1.39653: Flags [S.], seq 3040081633, ack 2862267557, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 2720641681 ecr 299847], length 0 10:58:24.773217 IP 10.0.0.1.39653 > 10.0.0.2.179: Flags [.], ack 1, win 1040, options [nop,nop,TS val 299847 ecr 2720641681], length 0 10:58:24.773826 IP 10.0.0.2.179 > 10.0.0.1.39653: Flags [P.], seq 1:46, ack 1, win 1040, options [nop,nop,TS val 2720641682 ecr 299847], length 45: BGP, length: 45 10:58:24.873634 IP 10.0.0.1.39653 > 10.0.0.2.179: Flags [.], ack 46, win 1040, options [nop,nop,TS val 299858 ecr 2720641682], length 0 10:58:26.869066 IP 10.0.0.1.39653 > 10.0.0.2.179: Flags [P.], seq 1:6, ack 46, win 1040, options [nop,nop,TS val 300057 ecr 2720641682], length 5: BGP, length: 5 Telnet to OpenBGPD: Note that tcp md5 has not been enabled in the bgpd.conf file. As you can see, I start a normal telnet to port 179, and its SYN+ACK has an md5 signature. 11:06:09.171925 IP 10.0.0.1.43701 > 10.0.0.2.179: Flags [S], seq 3593070548, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 346287 ecr 0], length 0 11:06:09.172292 IP 10.0.0.2.179 > 10.0.0.1.43701: Flags [S.], seq 4229135593, ack 3593070549, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 98634819 ecr 346287,nop,nop,md5shared secret not supplied with -M, can't check - 00000000000000000000000000000000], length 0 11:06:12.163527 IP 10.0.0.2.179 > 10.0.0.1.43701: Flags [S.], seq 4229135593, ack 3593070549, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 98634819 ecr 346287,nop,nop,md5shared secret not supplied with -M, can't check - 00000000000000000000000000000000], length 0 11:06:12.163672 IP 10.0.0.1.43701 > 10.0.0.2.179: Flags [S], seq 3593070548, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 346587 ecr 0], length 0 11:06:12.163848 IP 10.0.0.2.179 > 10.0.0.1.43701: Flags [S.], seq 4229135593, ack 3593070549, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 98634819 ecr 346587,nop,nop,md5shared secret not supplied with -M, can't check - 00000000000000000000000000000000], length 0 Telnet to Quagga: As it can be expected, it replies to a SYN without MD5 signature with a SYN+ACK without a MD5 signature. 11:08:51.439839 IP 10.0.0.2.61150 > 10.0.0.1.179: Flags [S], seq 1550805830, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 235210 ecr 0], length 0 11:08:51.439944 IP 10.0.0.1.179 > 10.0.0.2.61150: Flags [S.], seq 1912625633, ack 1550805831, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 2065055119 ecr 235210], length 0 11:08:51.440943 IP 10.0.0.2.61150 > 10.0.0.1.179: Flags [.], ack 1, win 1040, options [nop,nop,TS val 235210 ecr 2065055119], length 0 11:08:53.550765 IP 10.0.0.2.61150 > 10.0.0.1.179: Flags [P.], seq 1:6, ack 1, win 1040, options [nop,nop,TS val 235421 ecr 2065055119], length 5: BGP, length: 5 11:08:53.551056 IP 10.0.0.1.179 > 10.0.0.2.61150: Flags [F.], seq 1, ack 6, win 1040, options [nop,nop,TS val 2065055330 ecr 235421], length 0 11:08:53.552381 IP 10.0.0.2.61150 > 10.0.0.1.179: Flags [.], ack 2, win 1040, options [nop,nop,TS val 235421 ecr 2065055330], length 0 11:08:53.552408 IP 10.0.0.2.61150 > 10.0.0.1.179: Flags [F.], seq 6, ack 2, win 1040, options [nop,nop,TS val 235421 ecr 2065055330], length 0 11:08:53.552484 IP 10.0.0.1.179 > 10.0.0.2.61150: Flags [.], ack 7, win 1040, options [nop,nop,TS val 2065055330 ecr 235421], length 0 Interestingly, OpenBGPD only fails in this scenario in the passive role. In active role it has no problem. Borja.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5D60470E-CB00-4804-80BA-2866DE455F5B>