Re: [patch] RFC: matching interface groups
On Fri, 2006-08-04 at 12:06 +0200, Patrick McHardy wrote: Balazs Scheidler wrote: The use-case is as follows: * I have two different subsystems creating interfaces dynamically (for example pptpd and serial pppd lines, each creating dynamic pppX interfaces), * I would like to assign a different set of iptables rules for these clients, * I would like to react to a new interface being added to a specific set in a userspace application, The reasons I see this needs new kernel functionality: * iptables supports wildcard interface matching (for example iptables -i ppp+), but as the names of the interfaces used by PPTPD and PPPD cannot be distinguished this way, this is not enough, * Reloading the iptables ruleset everytime a new interface comes up is not really feasible, as it abrupts packet processing, and validating the ruleset in the kernel can take significant amount of time, * the kernel change is very simple, adapting userspace to this change is also very simple, and in userspace various software packages can easily interoperate with each-other once this is merged. The implementation: Each interface can belong to a single group at a time, an interface comes up without being a member in any of the groups. Userspace can assign interfaces to groups after being created, this would typically be performed in /etc/ppp/ip-up.d (and similar) scripts. In spirit interface group is somewhat similar to the routing protocol field for routing entries, which contains information on which routing daemon was responsible for adding the given route entry. Things to be done if you like this approach: * interface group match in iptables, * support for naming interface groups in userspace, a'la routing protocols, * emitting a netlink notification when the group of an interface changes, * possibly converting the ip link command to use NETLINK messages, instead of using ioctl() What do you think? I like it .. kind of like routing realms. For your specific case there is a possible solution already supported by the kernel, you can pre-allocate ppp devices using PPPIOCNEWUNIT, rename them and later attach to individual units in the ppp daemon using PPPIOCATTACH (I have a patch for this somewhere if you're interested). But that only works for PPP devices and the group idea looks more flexible. Thanks for liking it :) I'm going to implement a complete patch with iptables match and support for naming interface groups like routing realms and post it when I'm ready. I'd go for the more general solution as I have other interfaces not just ppp, it was just a trivial example. -- Bazsi - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] RFC: matching interface groups
Hi, Since in this scenario userspace is able to determine ppp vs pptp, could you not also do something like have an inbound_ppp and inbound_pptp chain, then jump to the appropriate chain depending on type? If you need per-interface rules, then create an inbound_pppX chain, populate it with rules, then jump to that chain if -i pppX. In ip-down, just delete the chain as well as the jump. if I understood Balazs correctly, one of the things he wanted to avoid is addition/deletion of iptables rules on every pppX interface up/down Exactly. We faced a similar problem: we wanted to not only differentiate between ppp and pptp interfaces but even between different providers connected via ppp and pptp. We ended up predefining all possible providers in the rules and differentiate between them using the ipt_condition module. This module is not very well-loved in the netfilter community but there are usecases like this where it comes in handy. Maybe this is a solution for you too. as this would require the complete chain (say, INPUT or OUTPUT) to be downloaded to userspace, modified and then again uploaded to the kernel. At least until iptables redesign to allow replacement/insertion/deletion of single rules is completed which if started at all will take quite some more time :-) Iptables operates on a per-table basis, so it is not only the INPUT or OUTPUT chain that needs to be down and uploaded, but the whole filter table. The problem with the current solution is not only speed and maintainability but also locking: if two device up/down events happen at the same time in this scenario, the tabels will become wrong until you develop some kind of userspace locking. Kind regards, Gerd - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] RFC: matching interface groups
On Wed, 2006-08-02 at 21:08 -0700, Stephen J. Bevan wrote: Balazs Scheidler writes: I would like to easily match a set of dynamically created interfaces from my packet filter rules. The attached patch forms the basis of my implementation and I would like to know whether something like this is mergeable to mainline. [snip] The implementation: Each interface can belong to a single group at a time, an interface comes up without being a member in any of the groups. You can get a similar effect by (ab)using the iflink field i.e. set the iflink to the parent interface and modify ip_tables.c:ip_packet_match to check the ifindex (or iflink if defined) for a match. An advantage of this is that it doesn't require adding any new fields and the only kernel change is to ip_tables.c:ip_packet_match (and its caller). That said, an explicit group (or zone as various firewall vendors call it) is cleaner. I could hack a solution together, but I'd prefer to do this cleanly, preferably as a patch in mainline. I would like to incorporate this functionality in our product. -- Bazsi - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] RFC: matching interface groups
On Tue, 2006-08-01 at 21:18 +0200, Sven Schuster wrote: Hi Phil, On Tue, Aug 01, 2006 at 11:46:55AM -0700, Phil Oester told us: Since in this scenario userspace is able to determine ppp vs pptp, could you not also do something like have an inbound_ppp and inbound_pptp chain, then jump to the appropriate chain depending on type? If you need per-interface rules, then create an inbound_pppX chain, populate it with rules, then jump to that chain if -i pppX. In ip-down, just delete the chain as well as the jump. if I understood Balazs correctly, one of the things he wanted to avoid is addition/deletion of iptables rules on every pppX interface up/down Exactly. as this would require the complete chain (say, INPUT or OUTPUT) to be downloaded to userspace, modified and then again uploaded to the kernel. At least until iptables redesign to allow replacement/insertion/deletion of single rules is completed which if started at all will take quite some more time :-) Iptables operates on a per-table basis, so it is not only the INPUT or OUTPUT chain that needs to be down and uploaded, but the whole filter table. And in addition, in my humble opinion the iptables ruleset should be up to the user to maintain, once some kind of automatism starts to add/remove rules on the fly, it becomes more difficult to do other changes to add independent rules to the table. For example the user needs to save the current ruleset using iptables-save, then modify the resulting file, and then load it again. If the ruleset is generated as it happens with a lot of tools, this might not be so easy. -- Bazsi - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] RFC: matching interface groups
On Tue, 2006-08-01 at 11:29 -0700, Stephen Hemminger wrote: On Tue, 01 Aug 2006 19:10:09 +0200 Balazs Scheidler [EMAIL PROTECTED] wrote: Hi, I would like to easily match a set of dynamically created interfaces from my packet filter rules. The attached patch forms the basis of my implementation and I would like to know whether something like this is mergeable to mainline. The use-case is as follows: * I have two different subsystems creating interfaces dynamically (for example pptpd and serial pppd lines, each creating dynamic pppX interfaces), * I would like to assign a different set of iptables rules for these clients, * I would like to react to a new interface being added to a specific set in a userspace application, The reasons I see this needs new kernel functionality: * iptables supports wildcard interface matching (for example iptables -i ppp+), but as the names of the interfaces used by PPTPD and PPPD cannot be distinguished this way, this is not enough, * Reloading the iptables ruleset everytime a new interface comes up is not really feasible, as it abrupts packet processing, and validating the ruleset in the kernel can take significant amount of time, * the kernel change is very simple, adapting userspace to this change is also very simple, and in userspace various software packages can easily interoperate with each-other once this is merged. The implementation: Each interface can belong to a single group at a time, an interface comes up without being a member in any of the groups. Userspace can assign interfaces to groups after being created, this would typically be performed in /etc/ppp/ip-up.d (and similar) scripts. In spirit interface group is somewhat similar to the routing protocol field for routing entries, which contains information on which routing daemon was responsible for adding the given route entry. [snip] I like the concept, but it probably needs more review. There is a bigger issue, which is how should the network device namespace exist? There are virtualization efforts, that want to virtualize it, and network device names have always lived in a parallel universe. I don't expect your patch to solve this... I have read the OLS paper on virtualization, it states that the current state of affairs is that struct net_device will be assigned to one specific namespace. As my change changes struct net_device itself, I expect to work without problems when virtualization comes, the interface group can be interpreted on a per-namespace basis. There probably will be several iptables rulesets when the time comes, one for each namespace, but again, struct net_device will be assigned to a namespace, and the proper iptables tables will be iterated based on the net_device assignment. Am I missing something? -- Bazsi - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] RFC: matching interface groups
* Balazs Scheidler wrote, On 02/08/06 08:04: On Tue, 2006-08-01 at 21:18 +0200, Sven Schuster wrote: as this would require the complete chain (say, INPUT or OUTPUT) to be downloaded to userspace, modified and then again uploaded to the kernel. At least until iptables redesign to allow replacement/insertion/deletion of single rules is completed which if started at all will take quite some more time :-) Iptables operates on a per-table basis, so it is not only the INPUT or OUTPUT chain that needs to be down and uploaded, but the whole filter table. And in addition, in my humble opinion the iptables ruleset should be up to the user to maintain, once some kind of automatism starts to add/remove rules on the fly, it becomes more difficult to do other changes to add independent rules to the table. For example the user needs to save the current ruleset using iptables-save, then modify the resulting file, and then load it again. If the ruleset is generated as it happens with a lot of tools, this might not be so easy. Even without this scenario it is not easily safe; if two interfaces chanegd at the same time, two copies of iptables would be downloaded to user space, both modified differently and the last one to be uploaded would win, the other one loosing its changes. This has bitten me and is one of my reasons for liking ipt_condition Sam - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] RFC: matching interface groups
Balazs Scheidler writes: I would like to easily match a set of dynamically created interfaces from my packet filter rules. The attached patch forms the basis of my implementation and I would like to know whether something like this is mergeable to mainline. [snip] The implementation: Each interface can belong to a single group at a time, an interface comes up without being a member in any of the groups. You can get a similar effect by (ab)using the iflink field i.e. set the iflink to the parent interface and modify ip_tables.c:ip_packet_match to check the ifindex (or iflink if defined) for a match. An advantage of this is that it doesn't require adding any new fields and the only kernel change is to ip_tables.c:ip_packet_match (and its caller). That said, an explicit group (or zone as various firewall vendors call it) is cleaner. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] RFC: matching interface groups
Hi,
I would like to easily match a set of dynamically created interfaces
from my packet filter rules. The attached patch forms the basis of my
implementation and I would like to know whether something like this is
mergeable to mainline.
The use-case is as follows:
* I have two different subsystems creating interfaces dynamically (for
example pptpd and serial pppd lines, each creating dynamic pppX
interfaces),
* I would like to assign a different set of iptables rules for these
clients,
* I would like to react to a new interface being added to a specific set
in a userspace application,
The reasons I see this needs new kernel functionality:
* iptables supports wildcard interface matching (for example iptables
-i ppp+), but as the names of the interfaces used by PPTPD and PPPD
cannot be distinguished this way, this is not enough,
* Reloading the iptables ruleset everytime a new interface comes up is
not really feasible, as it abrupts packet processing, and validating the
ruleset in the kernel can take significant amount of time,
* the kernel change is very simple, adapting userspace to this change is
also very simple, and in userspace various software packages can easily
interoperate with each-other once this is merged.
The implementation:
Each interface can belong to a single group at a time, an interface
comes up without being a member in any of the groups.
Userspace can assign interfaces to groups after being created, this
would typically be performed in /etc/ppp/ip-up.d (and similar) scripts.
In spirit interface group is somewhat similar to the routing
protocol field for routing entries, which contains information on which
routing daemon was responsible for adding the given route entry.
Things to be done if you like this approach:
* interface group match in iptables,
* support for naming interface groups in userspace, a'la routing
protocols,
* emitting a netlink notification when the group of an interface
changes,
* possibly converting the ip link command to use NETLINK messages,
instead of using ioctl()
What do you think?
kernel patch:
-
* add a numeric ID to each interface in the system, denoting its
interface group,
index df0cdd4..19a103a 100644
--- a/include/linux/rtnetlink.h
+++ b/include/linux/rtnetlink.h
@@ -736,6 +736,8 @@ enum
#define IFLA_WEIGHT IFLA_WEIGHT
IFLA_OPERSTATE,
IFLA_LINKMODE,
+#define IFLA_IFGROUP IFLA_IFGROUP
+ IFLA_IFGROUP,
__IFLA_MAX
};
diff --git a/include/linux/sockios.h b/include/linux/sockios.h
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 3fcfa9c..26849af 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -279,6 +279,11 @@ static int rtnetlink_fill_ifinfo(struct
u32 iflink = dev-iflink;
RTA_PUT(skb, IFLA_LINK, sizeof(iflink), iflink);
}
+
+ if (dev-ifgroup) {
+ u32 ifgroup = dev-ifgroup;
+ RTA_PUT(skb, IFLA_IFGROUP, sizeof(ifgroup), ifgroup);
+ }
if (dev-qdisc_sleeping)
RTA_PUT(skb, IFLA_QDISC,
@@ -459,6 +464,12 @@ static int do_setlink(struct sk_buff *sk
dev-link_mode = *((u8 *) RTA_DATA(ida[IFLA_LINKMODE - 1]));
write_unlock_bh(dev_base_lock);
}
+
+ if (ida[IFLA_IFGROUP - 1]) {
+ if (ida[IFLA_IFGROUP - 1]-rta_len != RTA_LENGTH(sizeof(u32)))
+ goto out;
+ dev-ifgroup = *((u32 *) RTA_DATA(ida[IFLA_IFGROUP - 1]));
+ }
if (ifm-ifi_index = 0 ida[IFLA_IFNAME - 1]) {
char ifname[IFNAMSIZ];
ip route patch:
---
* added a group option to ip link set to make it possible to set this
id, and a way to print this option
diff --git a/ip/iplink.c b/ip/iplink.c
index ffc9f06..e694475 100644
--- a/ip/iplink.c
+++ b/ip/iplink.c
@@ -26,6 +26,7 @@
#include string.h
#include sys/ioctl.h
#include linux/sockios.h
+#include linux/rtnetlink.h
#include rt_names.h
#include utils.h
@@ -44,6 +45,7 @@ void iplink_usage(void)
fprintf(stderr, promisc { on | off } |\n);
fprintf(stderr, trailers { on | off }
|\n);
fprintf(stderr, txqueuelen PACKETS |\n);
+ fprintf(stderr, group GROUP |\n);
fprintf(stderr, name NEWNAME |\n);
fprintf(stderr, address LLADDR | broadcast
LLADDR |\n);
fprintf(stderr, mtu MTU }\n);
@@ -174,6 +176,28 @@ static int set_mtu(const char *dev, int
return 0;
}
+static int set_group(const char *dev, int ifgroup)
+{
+ struct {
+ struct nlmsghdr n;
+ struct ifinfomsgifi;
+ charbuf[256];
+ } req;
+
+ memset(req, 0, sizeof(req));
+ req.n.nlmsg_len = NLMSG_LENGTH(sizeof(req.ifi));
+
Re: [patch] RFC: matching interface groups
On Tue, Aug 01, 2006 at 07:10:09PM +0200, Balazs Scheidler wrote: Each interface can belong to a single group at a time, an interface comes up without being a member in any of the groups. Userspace can assign interfaces to groups after being created, this would typically be performed in /etc/ppp/ip-up.d (and similar) scripts. Since in this scenario userspace is able to determine ppp vs pptp, could you not also do something like have an inbound_ppp and inbound_pptp chain, then jump to the appropriate chain depending on type? If you need per-interface rules, then create an inbound_pppX chain, populate it with rules, then jump to that chain if -i pppX. In ip-down, just delete the chain as well as the jump. Phil - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
