netdev - Re: [RFC PATCH 00/29] net: VRF support

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, 11 Feb 2015 09:42:09 +0200
From:	Shmulik Ladkani <shmulik.ladkani@...il.com>
To:	roopa <roopa@...ulusnetworks.com>
Cc:	David Ahern <dsahern@...il.com>, netdev@...r.kernel.org,
	ebiederm@...ssion.com, Dinesh Dutt <ddutt@...ulusnetworks.com>,
	Vipin Kumar <vipin@...ulusnetworks.com>,
	Nicolas Dichtel <nicolas.dichtel@...nd.com>,
	hannes@...essinduktion.org, Eyal Birger <eyal.birger@...il.com>
Subject: Re: [RFC PATCH 00/29] net: VRF support

On Mon, 09 Feb 2015 07:54:50 -0800 roopa <roopa@...ulusnetworks.com> wrote:
> On 2/5/15, 10:10 PM, Shmulik Ladkani wrote:
> > On Thu, 05 Feb 2015 15:12:57 -0800 roopa <roopa@...ulusnetworks.com> wrote:
> >> We have been playing with ip rules to implement vrfs. And the blocker
> >> today is that we cannot bind a socket to a vrf (routing tables in this
> >> case).
> >
> > One option would be using SO_MARK sockopt on that socket, and have an ip
> > rule which matches this mark to point to your table.
> > I don't know your exact use-cases, but you can play around with that
> > idea.
> 
>   yes, SO_MARK and 'ip rule fwmark'  is an option to bind tx from a socket
> to a table. But, There are more things that will be needed on the rx side.
> and at this point we are not considering netfilter marking of the 
> ingress packets so haven't been following this option

In the past we've implemented small-scale L3 segmentation using multiple
tables, without using netfilter marking.

We've used 'iif' rules for rx (as application knows its interface-to-vrf
mapping, it may provision 'iif' rules to point to the appropriate table).
For locally originated traffic, SO_MARK and 'mark' rules were used.

An 'ingress-netdevice to mark' mapping would make such solution less
awkward, but one might claim such mapping is not generic as it leaks
application specific knowledge and logic into the network stack.

Also, the downside of using multiple-tables based solution might
probably be lack of scalability, as the amount of ip rules in such a
scheme grows linearily with number of L3 segments.

Regards,
Shmulik
--
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