From owner-freebsd-net@FreeBSD.ORG Wed Aug 10 13:57:15 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 D8CF916A41F; Wed, 10 Aug 2005 13:57:15 +0000 (GMT) (envelope-from ck-lists@cksoft.de) Received: from mx11.cksoft.de (mx11.cksoft.de [62.111.66.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1A7143D45; Wed, 10 Aug 2005 13:57:14 +0000 (GMT) (envelope-from ck-lists@cksoft.de) Received: from vesihiisi.cksoft.de (unknown [192.168.64.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mx12.cksoft.de (Postfix) with ESMTP id 52333B85B; Wed, 10 Aug 2005 15:57:14 +0200 (CEST) Received: from vesihiisi.cksoft.de (localhost [127.0.0.1]) by vesihiisi.cksoft.de (Postfix) with ESMTP id 26E301EB5; Wed, 10 Aug 2005 15:57:12 +0200 (CEST) Received: by vesihiisi.cksoft.de (Postfix, from userid 1000) id EF1411EAC; Wed, 10 Aug 2005 15:57:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by vesihiisi.cksoft.de (Postfix) with ESMTP id E754D1EAB; Wed, 10 Aug 2005 15:57:08 +0200 (CEST) Date: Wed, 10 Aug 2005 15:57:08 +0200 (CEST) From: Christian Kratzer X-X-Sender: ck@vesihiisi.cksoft.de To: Jeremie Le Hen In-Reply-To: <20050810134523.GK45385@obiwan.tataz.chchile.org> Message-ID: <20050810154817.A97974@vesihiisi.cksoft.de> References: <1123040973.95445.TMDA@seddon.ca> <200508091104.06572.zec@icir.org> <42F8A487.67183CA6@freebsd.org> <200508091737.32391.zec@icir.org> <42F8D8ED.11A196FC@freebsd.org> <20050809211537.GX45385@obiwan.tataz.chchile.org> <42F9E1FB.3ECF023E@freebsd.org> <20050810144407.F97974@vesihiisi.cksoft.de> <42F9F9BF.879994D2@freebsd.org> <20050810151547.X97974@vesihiisi.cksoft.de> <20050810134523.GK45385@obiwan.tataz.chchile.org> X-Spammer-Kill-Ratio: 75% MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on vesihiisi.cksoft.de Cc: freebsd-net@freebsd.org, Marko Zec , Andre Oppermann Subject: Re: Stack virtualization (was: running out of mbufs?) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christian Kratzer List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2005 13:57:16 -0000 Hi, On Wed, 10 Aug 2005, Jeremie Le Hen wrote: > On Wed, Aug 10, 2005 at 03:30:32PM +0200, Christian Kratzer wrote: >>>> And of course IPv6 for jails is something that could propably be solved >>>> in a very clean way using virtual ip stacks as in Marcos patch. >>> >>> I'll cook something up that uses interface groups and then you can judge >>> whether it meets you needs or not. It would be more lightwigth than having >>> a full network stack per jail. >> >> Yes I can imagine Interface groups coming in handy in firewall setups. >> You will propably not be able to provide clean semantics for INADDR_ANY >> with anything but a dedicated virtual stack. >> >> A full network stack per jail provides the same semantics as in an >> environment without jails and all the security of clean separation. >> A little overhead for security is something I am very willing to pay ;) > > Both approach will require the ability to prevent jailed processes to > do certain actions on their virtual interface/stack, such as adding a > new IP address, because it has a noticable impact on the real network. > > I think this could be the job of the MAC framework (although I must > admit that I never played with this), but I'm a little bit scared about > the administrative overhead this would introduce for managing jails. yes a jail with its own ip stack could mess up a network as much as a separate machine on the same network could today. Virtual network stacks would primarily bring clean separation and consistent semantics to jails for cases where we require multiple IPv4, IPv6 ips and other protocols. This would be a good thing. One reason multiple IPv4 and especially IPv6 have been missing from jails is propably because the current very simple concept (converting all binds to inaddr_any to the jails ip) does not scale. Interface groups would not help in this area. As to inhibiting a jail from changing its stack so as not to disturb the network. This would indeed need to be addressed perhaps through a mac framework of some kind. Greetings Christian -- Christian Kratzer ck@cksoft.de CK Software GmbH http://www.cksoft.de/ Phone: +49 7452 889 135 Fax: +49 7452 889 136