On Thu, Sep 6, 2012 at 10:17 AM, Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
> Hi,
>
> On Wed, Sep 05, 2012 at 06:36:29PM -0700, Ansis Atteka wrote:
>> On Fri, Aug 31, 2012 at 6:11 PM, Ansis Atteka <aatteka@xxxxxxxxxx> wrote:
>> > This patch allows conntrackd to open CT Netlink sockets into a given
>> > network namespace. Channel sockets (e.g. UDP) would still be opened into
>> > the same namespace where conntrackd was started.
>> >
>> > The only binary this patch affects is conntrackd. All other binaries (e.g.
>> > conntrack, nfct) would still operate in the same namespace where they were
>> > started.
>> >
>> > To make use of this patch:
>> > 1. create a network namespace: "ip netns add the_ns"
>> > 2. add "NetlinkNamespace /var/run/netns/the_ns" line to the conntrackd.conf
>> > file inside General {...} section.
>>
>> Wanted to provide more details about this patch and also bump it up
>> for attention.
>>
>> Basically, what it does is allows conntrackd to open Conntrack Netlink
>> sockets into a different namespace than where Channel Sockets were
>> opened.
>
> I see.
>
>> This isolation brings benefits to:
>> 1. security, because the channel socket (and management interface) will
>> reside in a different namespace. They won't be exposed to the traffic
>> that traverses the namespace;
>> 2. flexibility, because arbitrary IP addresses could be used inside that
>> namespace for Connection Tracking purposes. No need to worry that
>> there might be overlapping IP addresses with the Management interface;
>
> I don't understand this second benefit, could you develop the idea a
> bit more?
My point was that network administrator could assign arbitrary IP
addresses and routing rules inside the namespace, without worrying
that they might conflict with management IP address and/or routes.
I guess this is not that important in static setup where IP addresses
are configured only once and left the way they are.
>
>> 3. scalability w.r.t. namespaces, because all the namespaces would
>> end up using a single management interface and IP address in the root
>> namespace. There wouldn't be need to maintain a dedicated
>> management interface and IP address inside every namespace.
>>
>> Also this patch would prepare soil for my next patches, that would
>> ease connection state synchronization for virtualized networks even more:
>> 1. allow single conntrackd instance to synchronize multiple namespaces;
>> 2. add configuration dynamically to conntrackd (without restarting
>> the daemon).
>
> Those seem interesting to have, definitely.
>
> My plan is to release conntrack-tools 1.4.0 by the time Linux kernel
> 3.6 is released since it contains a major milestone (user-space
> helper support), that will be quite soon.
>
> We can schedule this for some 1.6.0 release. So I can keep these
> namespace changes in some branch until they are merged to master.
>
> I'd start by point 2 then go back to the namespace support, but it's
> up to you.
Yes, that seems to be the right sequence to do that.
Thanks,
Ansis
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
