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, 21 Nov 2007 16:56:02 +0100
From:	Balazs Scheidler <bazsi@...abit.hu>
To:	Patrick McHardy <kaber@...sh.net>
Cc:	David Miller <davem@...emloft.net>, panther@...abit.hu,
	jengelh@...putergmbh.de, netdev@...r.kernel.org,
	netfilter-devel@...r.kernel.org
Subject: Re: [PATCHv6 0/3] Interface group patches


On Wed, 2007-11-21 at 01:25 +0100, Patrick McHardy wrote:
> David Miller wrote:
> > From: Laszlo Attila Toth <panther@...abit.hu>
> > Date: Tue, 20 Nov 2007 14:52:12 +0100
> > 
> >> Jan Engelhardt írta:
> >>> On Nov 20 2007 14:14, Laszlo Attila Toth wrote:
> >>>> This is the 6th version of our interface group patches.
> >>>>
> >>>> The interface group value can be used to manage different interfaces
> >>>> at the same time such as in netfilter/iptables.
> >>> I take it you could not use...?
> >>> 	iptables -i iif1 -j dosomething
> >>> 	iptables -i iif2 -j dosomething
> >> This kind of usage requires static interface names. But there are 
> >> dynamic interfaces such as ppp, where the actual name is not always 
> >> known or sometimes they exist sometimes not. It is difficult to use 
> >> iptables this way, and every ifup/ifdown requires change in the iptables 
> >> ruleset (donwload it, modify and upload to the kernel). It may be too slow.
> > 
> > This is actually not true these days.
> > 
> > When network devices are created user events are generated and the
> > user can rename the device however they like using a mapping table of
> > any kind.
> > 
> > And at such point the problem you present doesn't actually exist, you
> > can know what the device will be named.
> > 
> > And if rule loading dynamically is slow, we should fix that instead of
> > creating infrastructure and interfaces we don't actually need.
> 
> 
> I actually like this feature. Matching on names in iptables
> has always been one of the major bottlenecks, taking
> (according to my last measurement, which is some time ago)
> about 1-2% of the total performance. This is of course in
> large parts because the interface match is present on *every*
> rule, but still some way to logically group interfaces seems
> useful to me, not only for iptables, but also for routing rules,
> traffic classifiers, af_packet sockets etc.
> 
> I'm working on the incremental ruleset changing API BTW :)
> One of the changes will be that interface matching is not
> a default part of every rule, and without wildcards it will
> use the ifindex. But since the cost of this feature seems
> pretty low, I don't see a compelling reason against it.

We are also using interface groups from userspace applications (hence
the netlink notification). 

ppp comes up, an interface is created according to the pppd
configuration, which then assigns the interface to the given group.
another application (a proxy based firewall in our example) listens to
this notification and binds to the new interface as well.

-- 
Bazsi

-
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ