From: ebiederm@xmission.com (Eric W. Biederman)
To: Daniel Lezcano <dlezcano@fr.ibm.com>
Cc: "Serge E. Hallyn" <serue@us.ibm.com>,
Cedric Le Goater <clg@fr.ibm.com>, Sam Vilain <sam@vilain.net>,
hadi@cyberus.ca, Herbert Poetzl <herbert@13thfloor.at>,
Alexey Kuznetsov <alexey@sw.ru>,
viro@ftp.linux.org.uk, devel@openvz.org, dev@sw.ru,
Andrew Morton <akpm@osdl.org>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Andrey Savochkin <saw@swsoft.com>,
Ben Greear <greearb@candelatech.com>,
Dave Hansen <haveblue@us.ibm.com>,
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Subject: Re: strict isolation of net interfaces
Date: Fri, 30 Jun 2006 08:20:24 -0600 [thread overview]
Message-ID: <m1veqibu8n.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <44A517B4.4010500@fr.ibm.com> (Daniel Lezcano's message of "Fri, 30 Jun 2006 14:23:16 +0200")
Daniel Lezcano <dlezcano@fr.ibm.com> writes:
> Serge E. Hallyn wrote:
>> Quoting Cedric Le Goater (clg@fr.ibm.com):
>>
>>>we could work on virtualizing the net interfaces in the host, map them to
>>>eth0 or something in the guest and let the guest handle upper network layers ?
>>>
>>>lo0 would just be exposed relying on skbuff tagging to discriminate traffic
>>>between guests.
>> This seems to me the preferable way. We create a full virtual net
>> device for each new container, and fully virtualize the device
>> namespace.
>
> I have a few questions about all the network isolation stuff:
So far I have seen two viable possibilities on the table,
neither of them involve multiple names for a network device.
layer 3 (filtering the allowed ip addresses at bind time roughly the current vserver).
- implementable as a security hook.
- Benefit no measurable performance impact.
- Downside not many things we can do.
layer 2 (What appears to applications a separate instance of the network stack).
- Implementable as a namespace.
- Each network namespace would have dedicated network devices.
- Benefit extremely flexible.
- Downside since at least the slow path must examine the packet
it has the possibility of slowing down the networking stack.
For me the important characteristics.
- Allows for application migration, when we take our ip address with us.
In particular it allows for importation of addresses assignments
mad on other machines.
- No measurable impact on the existing networking when the code
is compiled in.
- Clean predictable semantics.
This whole debate on network devices show up in multiple network namespaces
is just silly. The only reason for wanting that appears to be better management.
We have deeper issues like can we do a reasonable implementation without a
network device showing up in multiple namespaces.
I think the reason the debate exists at all is that it is a very approachable
topic, as opposed to the fundamentals here.
If we can get layer 2 level isolation working without measurable overhead
with one namespace per device it may be worth revisiting things. Until
then it is a side issue at best.
Eric
next prev parent reply other threads:[~2006-06-30 14:23 UTC|newest]
Thread overview: 113+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-09 21:02 [RFC] [patch 0/6] [Network namespace] introduction dlezcano
2006-06-09 21:02 ` [RFC] [patch 1/6] [Network namespace] Network namespace structure dlezcano
2006-06-09 21:02 ` [RFC] [patch 2/6] [Network namespace] Network device sharing by view dlezcano
2006-06-11 10:18 ` Andrew Morton
2006-06-18 18:53 ` Al Viro
2006-06-26 9:47 ` Andrey Savochkin
2006-06-26 13:02 ` Herbert Poetzl
2006-06-26 14:05 ` Eric W. Biederman
2006-06-26 14:08 ` Andrey Savochkin
2006-06-26 18:28 ` Herbert Poetzl
2006-06-26 18:59 ` Eric W. Biederman
2006-06-26 14:56 ` Daniel Lezcano
2006-06-26 15:21 ` Eric W. Biederman
2006-06-26 15:27 ` Andrey Savochkin
2006-06-26 15:49 ` Daniel Lezcano
2006-06-26 16:40 ` Eric W. Biederman
2006-06-26 18:36 ` Herbert Poetzl
2006-06-26 19:35 ` Eric W. Biederman
2006-06-26 20:02 ` Herbert Poetzl
2006-06-26 20:37 ` Eric W. Biederman
2006-06-26 21:26 ` Herbert Poetzl
2006-06-26 21:59 ` Ben Greear
2006-06-26 22:11 ` Eric W. Biederman
2006-06-27 9:09 ` Andrey Savochkin
2006-06-27 15:48 ` Herbert Poetzl
2006-06-27 16:19 ` Andrey Savochkin
2006-06-27 16:40 ` Eric W. Biederman
2006-06-26 22:13 ` Ben Greear
2006-06-26 22:54 ` Herbert Poetzl
2006-06-26 23:08 ` Ben Greear
2006-06-27 16:07 ` Ben Greear
2006-06-27 22:48 ` Herbert Poetzl
2006-06-27 9:11 ` Andrey Savochkin
2006-06-27 9:34 ` Daniel Lezcano
2006-06-27 9:38 ` Andrey Savochkin
2006-06-27 11:21 ` Daniel Lezcano
2006-06-27 11:52 ` Eric W. Biederman
2006-06-27 16:02 ` Herbert Poetzl
2006-06-27 16:47 ` Eric W. Biederman
2006-06-27 17:19 ` Ben Greear
2006-06-27 22:52 ` Herbert Poetzl
2006-06-27 23:12 ` Dave Hansen
2006-06-27 23:42 ` Alexey Kuznetsov
2006-06-28 3:38 ` Eric W. Biederman
2006-06-28 13:36 ` Herbert Poetzl
2006-06-28 13:53 ` jamal
2006-06-28 14:19 ` Andrey Savochkin
2006-06-28 16:17 ` jamal
2006-06-28 16:58 ` Andrey Savochkin
2006-06-28 17:17 ` Eric W. Biederman
2006-06-28 17:04 ` Herbert Poetzl
2006-06-28 14:39 ` Eric W. Biederman
2006-06-30 1:41 ` Sam Vilain
2006-06-29 21:07 ` Sam Vilain
2006-06-29 22:14 ` strict isolation of net interfaces Cedric Le Goater
2006-06-30 2:39 ` Serge E. Hallyn
2006-06-30 2:49 ` Sam Vilain
2006-07-03 14:53 ` Andrey Savochkin
2006-07-04 3:00 ` Sam Vilain
2006-07-04 12:29 ` Daniel Lezcano
2006-07-04 13:13 ` Sam Vilain
2006-07-04 13:19 ` Daniel Lezcano
2006-06-30 8:56 ` Cedric Le Goater
2006-07-03 13:36 ` Herbert Poetzl
2006-06-30 12:23 ` Daniel Lezcano
2006-06-30 14:20 ` Eric W. Biederman [this message]
2006-06-30 15:22 ` Daniel Lezcano
2006-06-30 17:58 ` Eric W. Biederman
2006-06-30 16:14 ` Serge E. Hallyn
2006-06-30 17:41 ` Eric W. Biederman
2006-06-30 18:09 ` Eric W. Biederman
2006-06-30 0:15 ` [patch 2/6] [Network namespace] Network device sharing by view jamal
2006-06-30 3:35 ` Herbert Poetzl
2006-06-30 7:45 ` Andrey Savochkin
2006-06-30 13:50 ` jamal
2006-06-30 15:01 ` Andrey Savochkin
2006-06-30 18:22 ` Eric W. Biederman
2006-06-30 21:51 ` jamal
2006-07-01 0:50 ` Eric W. Biederman
2006-06-28 14:21 ` Eric W. Biederman
2006-06-28 14:51 ` Eric W. Biederman
2006-06-27 16:49 ` Alexey Kuznetsov
2006-06-27 11:55 ` Andrey Savochkin
2006-06-27 9:54 ` Kirill Korotaev
2006-06-27 16:09 ` Herbert Poetzl
2006-06-27 16:29 ` Eric W. Biederman
2006-06-27 23:07 ` Herbert Poetzl
2006-06-28 4:07 ` Eric W. Biederman
2006-06-28 6:31 ` Sam Vilain
2006-06-28 14:15 ` Herbert Poetzl
2006-06-28 15:36 ` Eric W. Biederman
2006-06-28 17:18 ` Herbert Poetzl
2006-06-28 10:14 ` Cedric Le Goater
2006-06-28 14:11 ` Herbert Poetzl
2006-06-28 16:10 ` Eric W. Biederman
2006-07-06 9:45 ` Routing tables (Re: [patch 2/6] [Network namespace] Network device sharing by view) Kari Hurtta
2006-06-09 21:02 ` [RFC] [patch 3/6] [Network namespace] Network devices isolation dlezcano
2006-06-18 18:57 ` Al Viro
2006-06-09 21:02 ` [RFC] [patch 4/6] [Network namespace] Network inet " dlezcano
2006-06-09 21:02 ` [RFC] [patch 5/6] [Network namespace] ipv4 isolation dlezcano
2006-06-10 0:23 ` James Morris
2006-06-10 0:27 ` Rick Jones
2006-06-10 0:47 ` James Morris
2006-06-09 21:02 ` [RFC] [patch 6/6] [Network namespace] Network namespace debugfs dlezcano
2006-06-10 7:16 ` [RFC] [patch 0/6] [Network namespace] introduction Kari Hurtta
2006-06-16 4:23 ` Eric W. Biederman
2006-06-16 9:06 ` Daniel Lezcano
2006-06-16 9:22 ` Eric W. Biederman
2006-06-18 18:47 ` Al Viro
2006-06-20 21:21 ` Daniel Lezcano
2006-06-20 21:25 ` Al Viro
2006-06-20 22:45 ` Daniel Lezcano
2006-06-26 23:38 ` Patrick McHardy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1veqibu8n.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=akpm@osdl.org \
--cc=alexey@sw.ru \
--cc=clg@fr.ibm.com \
--cc=dev@sw.ru \
--cc=devel@openvz.org \
--cc=dlezcano@fr.ibm.com \
--cc=greearb@candelatech.com \
--cc=hadi@cyberus.ca \
--cc=haveblue@us.ibm.com \
--cc=herbert@13thfloor.at \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sam@vilain.net \
--cc=saw@swsoft.com \
--cc=serue@us.ibm.com \
--cc=viro@ftp.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®