From owner-freebsd-net@FreeBSD.ORG Wed Nov 23 08:30:19 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B9971065670 for ; Wed, 23 Nov 2011 08:30:19 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id CE7668FC0C for ; Wed, 23 Nov 2011 08:30:18 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so1699308bkb.13 for ; Wed, 23 Nov 2011 00:30:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=cRR9VOoTReHRaRi++FmIxX47AP2DQNVqmy8L6H1iHLI=; b=qFTtH0Dg0ydLj4oKkQLxz5BUQHcKSNGx1giTmrB4N+H83ZLslrRdvWq3Xr7v/gMcZv cVQLKZa5xniVdOanQveQFHQchXaRf7OPOTiSefPBg2d8tEGAUIzoQTfMnzN/ZU9wWA+/ g5rOddpgqPDpPwImchfKM1B8W40lDXyFf24hU= Received: by 10.204.156.219 with SMTP id y27mr22950568bkw.125.1322037016946; Wed, 23 Nov 2011 00:30:16 -0800 (PST) Received: from [192.168.254.99] ([94.185.236.184]) by mx.google.com with ESMTPS id x19sm21435938fag.5.2011.11.23.00.30.14 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Nov 2011 00:30:15 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Nikolay Denev In-Reply-To: Date: Wed, 23 Nov 2011 10:30:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <25CAC0FC-ED0F-42D5-85DC-B7270EFD9814@gmail.com> References: To: Borja Marcos X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Wed, 23 Nov 2011 12:06:36 +0000 Cc: freebsd-net@freebsd.org Subject: Re: Openbgpd incorrectly sets TCP_MD5 on the listen socket, regardless of configuration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 08:30:19 -0000 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=