From owner-freebsd-security Mon Aug 23 0:53:35 1999 Delivered-To: freebsd-security@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 4210915764 for ; Mon, 23 Aug 1999 00:53:23 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id QAA29580; Mon, 23 Aug 1999 16:53:09 +0900 (JST) To: "Jordan K. Hubbard" Cc: freebsd-security@FreeBSD.ORG In-reply-to: jkh's message of Sun, 22 Aug 1999 20:42:46 MST. <4726.935379766@localhost> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: IPsec/IPv6 From: itojun@iijlab.net Date: Mon, 23 Aug 1999 16:53:09 +0900 Message-ID: <29578.935394789@coconut.itojun.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> Bah, so FreeBSD will be InSecureBSD ? Well, so long as the ITAR bear >> stands around making grizzly noises at people, it seems. >I wouldn't count on that. As far as I can tell, what's holding KAME >integration up is the fact that they're not done merging with INRIA >yet. A news about NRL/INRIA/KAME merging (unified-ipv6). unified-ipv6 project has been in big trouble with manpower, design differences. Recently situations changed for all of us so here's the decision we have made. NRL decided to concentrates on IPsec (because in US not much interest in IPv6 than IPsec - people in US are lucky about IPv4 address space, it seems). INRIA will be doing future researches on top of KAME code. KAME agreed to add some knobs that helps INRIA to do their experiment. So, it is planned that KAME will have an alias: "unified-ipv6". KAME team is trying to ship KAME/OpenBSD and KAME/BSDI4 during this month or next month (September). KAME September 30th STABLE kit will officially have "unified-ipv6" alias on it. It is now okay to merge KAME code into FreeBSD, I believe. If you do not feel ready, I'll be visiting FreeBSDCon so let's talk about it there (but will cause 2 month delay from now). The biggest problem is how to keep mutiple repositories in sync. KAME (= unified-ipv6) code shares most of IPv6 code among *BSD platforms. If FreeBSD repository is modified after import, and that conflicts with content in KAME repository, we can't merge that back in. So I would like to suggest FreeBSD project to refrain from changing IPv6 part too much, for certain amount of time (*). Rather, please send diffs to KAME. >Once that happens, I'm more than happy to continue to lean on >Justice Maryln Patel's decision on crypto as free speach in the S.F. >Bay Area region. We've already talked to our lawyer, he said it >looked legit to him, and so we've been shipping crypto on our CDs for >over a year now. I even announced it back then, to almost no audience >reaction whatsoever. It seems that people like to get more excited >about the prospect of something being closed than it being opened >up. :) It now happened, so please contact Mr. Patel:-) KAME team really needs your suggestions on how to integrate crypto part. In case of NetBSD/KAME integration, we did like this: - place IPsec core part and AH part into cvs.netbsd.org (in US) - place ESP part and crypto algorithms (DES, Blowfish and whatever in cvs.fi.netbsd.org (in finland) We need some tricky symbolic link, or makefile/config hack for this separated repository (NetBSD has makefile and config hack). itojun (*) As a side note: actually, KAME and unified-ipv6 has been experiencing big trouble sharing IPv6 code among *BSD, due to FreeBSD's variable renaming like ifa_list (ifa_link on others) or time_second (why FreeBSD couldn't reuse time.tv_sec to hold this? I don't get it). I'd like propose to fix those back to more standard ones (ifa_link or time.tv_sec) for portability among *BSD. If you are okay, those changes will come with FreeBSD/KAME integration. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message