netdev - Re: [RFC net-next 0/3] Proposal for VRF-lite

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5576DC4E.6060206@6wind.com>
Date:	Tue, 09 Jun 2015 14:30:06 +0200
From:	Nicolas Dichtel <nicolas.dichtel@...nd.com>
To:	Thomas Graf <tgraf@...g.ch>,
	Shrijeet Mukherjee <shm@...ulusnetworks.com>
CC:	hannes@...essinduktion.org, dsahern@...il.com,
	ebiederm@...ssion.com, hadi@...atatu.com, davem@...emloft.net,
	stephen@...workplumber.org, netdev@...r.kernel.org,
	roopa@...ulusnetworks.com, gospo@...ulusnetworks.com,
	jtoppins@...ulusnetworks.com, nikolay@...ulusnetworks.com
Subject: Re: [RFC net-next 0/3] Proposal for VRF-lite

Le 09/06/2015 12:15, Thomas Graf a écrit :
> On 06/08/15 at 11:35am, Shrijeet Mukherjee wrote:
> [...]
>> model with some performance paths that need optimization. (Specifically
>> the output route selector that Roopa, Robert, Thomas and EricB are
>> currently discussing on the MPLS thread)
>
> Thanks for posting these patches just in time. This explains how
> you intent to deploy Roopa's patches in a scalable manner.
>
>> High Level points
>>
>> 1. Simple overlay driver (minimal changes to current stack)
>>     * uses the existing fib tables and fib rules infrastructure
>> 2. Modelled closely after the ipvlan driver
>> 3. Uses current API and infrastructure.
>>     * Applications can use SO_BINDTODEVICE or cmsg device indentifiers
>>       to pick VRF (ping, traceroute just work)
>
> I like the aspect of reusing existing user interfaces. We might
> need to introduce a more fine grained capability than CAP_NET_RAW
> to give containers the privileges to bind to a VRF without
> allowing them to inject raw frames.
>
> Given I understand this correctly: If my intent was to run a
> process in multiple VRFs, then I would need to run that process
> in the host network namespace which contains the VRF devices
> which would also contain the physical devices. While I might want
> to grant my process the ability to bind to VRFs, I may not want
> to give it the privileges to bind to any device. So we could
> consider introducing CAP_NET_VRF which would allow to bind to
> VRF devices.

If I understand correctly, all existing applications should also be modified
if I want to run them into a VRF/MRF (see my previous email)?

ssh, dhcp, httpd, etc should be runnable per MRF without modifications of
their source code. So, it becomes a netns. What's about an IKE dameon?

It makes sense to have both: netns and MRF ; each can have their own logics
of VRF-like behavior depending on how a VRF is defined by the end users.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html