From owner-freebsd-net@freebsd.org Tue Jun 12 14:02:13 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2165110159A3 for ; Tue, 12 Jun 2018 14:02:13 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A112D85436 for ; Tue, 12 Jun 2018 14:02:12 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from mr185083 (mr185083.univ-rennes1.fr [129.20.185.83]) by mx.zohomail.com with SMTPS id 1528812127399721.915737760727; Tue, 12 Jun 2018 07:02:07 -0700 (PDT) Date: Tue, 12 Jun 2018 16:02:03 +0200 From: Patrick Lamaiziere To: FreeBSD Net Subject: Re: 11.2-RC1 setkey invalid spi ? Message-ID: <20180612160116.58df4001@mr185083> In-Reply-To: <20180612143447.697681c5@mr185083> References: <20180612143447.697681c5@mr185083> X-Mailer: Claws Mail 3.15.1 (GTK+ 2.24.31; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 14:02:13 -0000 Le Tue, 12 Jun 2018 14:34:47 +0200, Patrick Lamaiziere a =C3=A9crit : Hello I change the subject because this is not at all related to bird. > I'm trying Bird 2 on FreeBSD 11.2 using tcp md5 signature for BGP > connections. >=20 > Bird2 has an option to set the needed ipsec SA/SP but here this does > not work. >=20 > The first entry (0.0.0.0 129.20.128.78) is correct but the second one > (129.20.128.78 0.0.0.0) has an invalid spi field (should be 0x1000). > The spi value changes each time bird runs so it looks uninitialized. >=20 > # setkey -D > 129.20.128.78 0.0.0.0 > tcp mode=3Dany spi=3D131144976(0x07d11d10) reqid=3D0(0x00000000) > A: tcp-md5 32626770 2d313421 > seq=3D0x00000000 replay=3D0 flags=3D0x00000040 state=3Dmature=20 > created: Jun 12 14:15:50 2018 current: Jun 12 14:24:31 > 2018 diff: 521(s) hard: 0(s) soft: 0(s) > last: hard: 0(s) soft: 0(s) > current: 0(bytes) hard: 0(bytes) soft: 0(bytes) > allocated: 0 hard: 0 soft: 0 > sadb_seq=3D1 pid=3D49180 refcnt=3D1 > 0.0.0.0 129.20.128.78 > tcp mode=3Dany spi=3D4096(0x00001000) reqid=3D0(0x00000000) > A: tcp-md5 32626770 2d313421 > seq=3D0x00000000 replay=3D0 flags=3D0x00000040 state=3Dmature=20 > created: Jun 12 14:15:50 2018 current: Jun 12 14:24:31 > 2018 diff: 521(s) hard: 0(s) soft: 0(s) > last: hard: 0(s) soft: 0(s) > current: 0(bytes) hard: 0(bytes) soft: 0(bytes) > allocated: 0 hard: 0 soft: 0 > sadb_seq=3D0 pid=3D49180 refcnt=3D1 Well I can reproduce this problem by using setkey(8) : /etc/ipsec.conf add 129.20.128.78 129.20.128.149 tcp 0x1000 -A tcp-md5 "secret"; add 129.20.128.149 129.20.128.78 tcp 0x1000 -A tcp-md5 "secret"; # setkey -D No SAD entries. # setkey -f /etc/ipsec.conf # setkey -D 129.20.128.149 129.20.128.78 tcp mode=3Dany spi=3D106079004(0x0652a31c) reqid=3D0(0x00000000) A: tcp-md5 73656372 6574 seq=3D0x00000000 replay=3D0 flags=3D0x00000040 state=3Dmature=20 created: Jun 12 15:57:28 2018 current: Jun 12 15:57:36 2018 diff: 8(s) hard: 0(s) soft: 0(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=3D1 pid=3D5405 refcnt=3D1 129.20.128.78 129.20.128.149 tcp mode=3Dany spi=3D4096(0x00001000) reqid=3D0(0x00000000) A: tcp-md5 73656372 6574 seq=3D0x00000000 replay=3D0 flags=3D0x00000040 state=3Dmature=20 created: Jun 12 15:57:28 2018 current: Jun 12 15:57:36 2018 diff: 8(s) hard: 0(s) soft: 0(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=3D0 pid=3D5405 refcnt=3D1 spi field looks wrongs :( That works fine on FreeBSD 10.3 Same problem on a FreeBSD 11.1-STABLE #1 r326391: Thu Nov 30 12:07:50 CET 2017=20 Regards.