netdev - Re: [RFC net-next 3/6] net: Introduce VRF device driver

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]

Date:	Wed, 8 Jul 2015 20:34:09 +0200
From:	Sowmini Varadhan <sowmini05@...il.com>
To:	David Ahern <dsa@...ulusnetworks.com>
Cc:	netdev <netdev@...r.kernel.org>, shm@...ulusnetworks.com,
	roopa@...ulusnetworks.com,
	Andy Gospodarek <gospo@...ulusnetworks.com>,
	jtoppins@...ulusnetworks.com, nikolay@...ulusnetworks.com,
	ddutt@...ulusnetworks.com,
	Hannes Frederic Sowa <hannes@...essinduktion.org>,
	Nicolas Dichtel <nicolas.dichtel@...nd.com>,
	Stephen Hemminger <stephen@...workplumber.org>,
	hadi@...atatu.com, "Eric W. Biederman" <ebiederm@...ssion.com>,
	David Miller <davem@...emloft.net>
Subject: Re: [RFC net-next 3/6] net: Introduce VRF device driver - v2

On Mon, Jul 6, 2015 at 5:03 PM, David Ahern <dsa@...ulusnetworks.com> wrote:
> This driver borrows heavily from IPvlan and teaming drivers.
>
> Routing domains (VRF-lite) are created by instantiating a device
> and enslaving all routed interfaces that participate in the domain.
> As part of the enslavement, all local routes pointing to enslaved
> devices are re-pointed to the vrf device, thus forcing outgoing
> sockets to bind to the vrf to function.
>
> Standard FIB rules can then bind the VRF device to tables and regular
> fib rule processing is followed.

Perhaps I misunderstand the design proposal here, but a switch's VRF
is essentially just a separate routing table, whose input and output interfaces
are exclusively bound to the VRF.

Can an application in the model above get visibiltiy into the (enslaved?)
interfaces in the vrf? Can an application use IP_PKTINFO to send a packet out of
a specific interface on a selected VRF? What about receiving
IP_PKTINFO about input interface?
What about setting ipsec policy for interfaces in the vrf?

> Routed traffic through the box, is fwded by using the VRF device as
> the IIF and following the IIF rule to a table which is mated with
> the VRF.
>
> Locally originated traffic is directed at the VRF device using
> SO_BINDTODEVICE or cmsg headers. This in turn drops the packet into
> the xmit function of the vrf driver, which then completes the ip lookup
> and output.
>
> This solution is completely orthogonal to namespaces and allow the L3
> equivalent of vlans to exist allowing the routing space to be
> partitioned.
--
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