From owner-freebsd-net@FreeBSD.ORG Tue Oct 18 13:48:18 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3811316A41F for ; Tue, 18 Oct 2005 13:48:18 +0000 (GMT) (envelope-from jan@melen.org) Received: from foxgw.melen.org (Savi-Mel.dna.fi [83.143.60.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7055643D45 for ; Tue, 18 Oct 2005 13:48:17 +0000 (GMT) (envelope-from jan@melen.org) Received: from [2001:14b8:400:101:208:74ff:fee4:decb] ([IPv6:2001:14b8:400:101:208:74ff:fee4:decb]) (authenticated bits=0) by foxgw.melen.org (8.13.4/8.13.4) with ESMTP id j9IDm3hP029247 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 18 Oct 2005 16:48:15 +0300 (EEST) (envelope-from jan@melen.org) From: Jan Mikael Melen To: freebsd-net@freebsd.org Date: Tue, 18 Oct 2005 16:47:27 +0300 User-Agent: KMail/1.8 References: <20051018082230.GA61303@yvan.netasq.int> In-Reply-To: <20051018082230.GA61303@yvan.netasq.int> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200510181647.29627.jan@melen.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on foxgw.melen.org X-Virus-Status: Clean Subject: Re: Unique IPsec security policies 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: Tue, 18 Oct 2005 13:48:18 -0000 Hi, On Tuesday 18 October 2005 11:22, VANHULLEBUS Yvan wrote: > On Tue, Oct 18, 2005 at 10:50:24AM +0300, Jan Mikael Melen wrote: > > What I'm trying to do is that: > > 1. I create SP entry and let the kernel assign a request id for policy > > (reqid in the add is 0). This policy is a tunnel mode policy and I don't > > have the outer addresses set at this point. Only the inner addresses are > > set so I'll get the SADB_AQUIRE message with the inner addresses. > > Not sure I understood what you are exactly doing, and *why* you want > to do that... For the why part my answer would be that it's because I don't necessarily know the end-points address before hand. The keying protocol will take care of resolving the address. This is just some experimental stuff I'm working with (ref. http://www.ietf.org/internet-drafts/draft-ietf-hip-arch-03.txt). > > 2. When my keying daemon get's the acquire from the kernel I run the key > > exchange and then I send update to the SP with previously gotten reqid > > and with outer addresses but it fails and kernel prints out: > > "key_msg2sp: reqid=16384 range violation, updated by kernel." > > This message comes from the sys/netkey/key.c:1488. It's obvious when I'm > > adding a new SP entry that this check is done but when updating the SP > > shouldn't it just check that the value given in update matches the one > > assigned earlier? > > Perhaps you should just force manual reqids < IPSEC_MANUAL_REQID_MAX > when creating your SP entries. Always a possiblity but then I would have to know that wheter this value is already being used. So I would prefer that the kernel would assign the values for me, as it is obviously the one whom knows which reqids are already in use. > In one hand, you're right: when updating SP entries, it can make sense > to just ensure that the reqid is the same. > > In the other hand, as you used some automatic values while creating > the SP entry (so, in fact, as you said "I let the kernel do that > stuff"), it can be logic to not allow you to do "some non common > things" after, even if you want to update it.... If this is the case it will make atleast my life a bit harder :-) I think that not allowing the SP to updated might cause also problems with mobike. Cheers, Jan