James Carlson wrote: > Zhijun Fu writes: > >> James Carlson wrote: >> >>> If I have to say "family ether" in order to specify a rule that >>> filters L2 packets, why do I need to give this extra command? Doesn't >>> the existence of at least one "family ether" rule mean that I intend >>> to filter L2 packets as well (and thus I want interception turned on)? >>> >>> >> This behavior is consistent with ipfilter today. >> Ipfilter will not be enabled automatically when you specify an ipfilter >> rule. Today the addition of ipfilter rules will fail if ipfilter is not >> enabled, which you need to enable by using "svcadm enable ipfilter" or >> "ipf -E". >> James, Many thanks for helping review the case, my input inline... > No, it's *not* consistent. > > All that I have to do today is to add rules into /etc/ipf/ipf.conf and > then enable filtering with "svcadm enable ipfilter". I don't have to > do anything else. > > This project proposes a new mechanism -- yet another hurdle to jump -- > where I must add an "option" in the configuration file to tell the > system what the configuration file apparently already says. > > Why do I need to specify "set intercept_layer2 true;"? > > I think there's a misunderstanding here. The reason that special "set > intercept_loopback true;" magic was added to the configuration file > was that old configuration files would be mis-interpreted by ipfilter > after an upgrade. Configuration files that once didn't apply to local > traffic would suddenly start filtering that traffic unexpectedly when > the loopback filtering feature was added. > > It was an incompatible change, so we wanted to have administrators > carefully consider how to update the rules before springing the change > on them. That's why the flag is there. > OK, understood. Thank you for your explanation about this. > I see *NO* such issue at all for the new L2 rules. They don't change > the interpretation of any existing configuration files, because no > existing configuration file will have "family ether" or "layer2" > specified in it. > Agreed. L2 rules won't have the incompatible issues that loopback rules have. > Thus, the new switch isn't necessary. > I think the switch is still needed, for a different reason, so let me explain here:
Basically we have 3 options for this, * have layer 2 filtering enabled by default, so we don't need to add a new switch to enable it * disable layer 2 filtering by default, and enable it when users first adds a rule contains keyword "family ether" * disable layer 2 filtering by default, and specify "set intercept_layer2 true;" in /etc/ipf/ipf.conf to enable it, and this is the one we proposed With the 1st option, having layer 2 filtering enabled by default will have performance impact, even if there're no layer 2 rules configured, because additional processing is needed when layer 2 filtering is enabled, so this option cannot be used. With the 2nd option, we'll enable the layer 2 filtering when the first "family ether" rule is added, and disable layer 2 filtering when the last "family ether" rule is removed, this has the following issues - We need to add check for each addition/removal of "family ether" rules, for each addition/removal, we need to check whether this is the first rule added, or the last rule removed, I'm not sure whether this is desirable - Enabling layer 2 filtering involves registering hooks, today for ipfilter, both IPv4 and IPv6 hooks are registered when ipfilter is enabled, and unregistered when ipfilter is disabled; for loopback filtering, the case is the same. So I think for layer 2 filtering, registering/unregistering hooks when a rule is added/removed instead of the feature (layer 2 filtering) enabled/disabled sounds inconsistent with the existing behavior - Today, with ipfilter you need to enable the ipfilter service before you can add rules. If we follow the logic of option 2, why not we change ipfilter and let it get enabled automatically when the first ipfilter rule is added? But this is not what ipfilter behaves in neveda. I understand optioin 3 may not be a perfect solution in all aspects, but if we need a trade-off, sounds like it is a better choice than the rest. >>> Or perhaps the question is this: why would I want to have rules >>> specified as "layer2", but then specifically avoid sending some >>> packets through those rules with "ip-head" or "ip-nat"? >>> >> There are cases where users want to do IP Filtering / IP NAT in layer 2 >> only for specified ethernet addresses, so we need to use the keyword >> "ip-head" and "ip-nat", to indicate that we do IP Filtering / IP NAT in >> layer 2 only for packets matching this "family ether" rule. And there >> are customer requests for this feature. >> > > There may be such cases, but that's exactly what the existing "group" > feature in IP filter is designed to handle. It allows you to specify > that packets matching certain criteria are to be further processed by > a subset of the rules. > Right. And we're using "group" together with "ip-head". > This new "ip-head" and "ip-nat" feature does the same thing, "ip-head" does the similar thing for "head", and "ip-nat" is different. Please note the group feature is only available for IP Filtering rules today, there're no group support for IP NAT rules. So "ip-nat" is irrelevant with the "group" feature. > but less > flexibly. > >>> If I did have >>> such a case, why wouldn't I set up a "family ether" rule that >>> specifies "quick" -- so that the rest of the "layer2"-tagged rules >>> aren't examined at all? That (using "quick" instead for the reverse >>> sense) seems a lot clearer to me than "ip-head" or "ip-nat". >>> >>> >> I think "quick" means packets matching this rule will bypass the rules >> after it. >> > > That's correct. > > >> But basically ethernet filtering rules and ipfilter rules are >> two sets of rules. So it may not be desirable to use "quick" for this. >> > > I don't understand that concern. Please elaborate on how introducing > these new keywords avoids some problem. It looks to me like they do > essentially what the old keywords do -- just backwards. The rule > matching is "opt in" rather than "opt out." > I meant use "quick" here may not be desirable because the issues mentioned below. Sorry for the confusion. > >> Also, all ethernet filtering rules will be processed before all ipfilter >> rules, no matter which rule is specified earlier in the configuration >> file (or command line). >> > > Sure; understood. > > We're talking only about the way in which the "family ether" and > "layer2" rules work, which are all processed in the L2 data path. > I'm > not talking about any rules that lack those keywords. > > That's not the issue. > I was talking about using "quick" instead of "ip-head" "ip-nat" is not desirable, because the order rules listed in the configuration file may not be the same order that rules get processed, so using "quick" can be misleading. >> Say we have the following rules in ipf.conf, in the following order: >> >> (1) pass in proto tcp from 10.10.10.20/32 to 10.10.10.10/32 port = 8888 >> keep state group 10 layer2 >> (2) pass in proto tcp from 10.10.10.20/32 to 10.10.10.10/32 >> (3) rdr nge1 from 10.10.10.20/32 to 10.10.10.10/32 port = 7777 -> 10.10.10.10 >> port 8888 tcp layer2 >> (4) pass in on nge1 family ether from 0:14:4f:8d:ae:23 to any ip-head 10 >> ip-nat >> >> >> When a packet arrives at the layer 2 hook, rule (4) will be processed >> first, although it is specified last in the configuration file. In this >> case, using "quick" instead of "ip-head" and "ip-nat" will be >> mis-leading and non-intuitive, because the semantics of "quick" means >> you only bypass the rules *after* this rule. >> > > To get that same behavior with the existing keywords (removing the > need for "ip-head" and "ip-nat"), I would use: > > pass in on nge1 family ether from 0:14:4f:8d:ae:23 to any head 10 > pass in proto tcp from 10.10.10.20/32 to 10.10.10.10/32 port = 8888 > keep state group 10 layer2 > pass in proto tcp from 10.10.10.20/32 to 10.10.10.10/32 > rdr nge1 from 10.10.10.20/32 to 10.10.10.10/32 port = 7777 -> 10.10.10.10 > port 8888 tcp group 10 layer2 > Today we don't have group support for IP NAT rules in neveda. Adding group support for IP NAT rules can be a way to solve this, and using "ip-nat" is another way, and requires less changes. >> And more, with "ip-head" you can direct packets to different ipfilter >> rule groups based on ethernet addresses, this provides more flexibility, >> so we can have: >> >> pass in family ether from 0:14:4f:8d:ae:23 to any ip-head 10 >> pass in family ether from 0:14:4f:8d:ae:22 to any ip-head 20 >> pass in proto tcp from 10.10.10.20/32 to 10.10.10.10/32 port = 8888 >> keep state group 10 layer2 >> pass in proto tcp from any to any group 20 layer2 >> > > I don't think that's necessary at all. The rules would work fine > without "ip-head" (using just the existing "head" keyword) because of > the grouping rules. > I may need to think about this more. >>> I suspect that most sane rule sets will start with something like >>> this: >>> >>> pass in on nge1 family ether all ip-head ip-nat >>> >>> >> In some situation this might be true. >> As mentioned above, in cases where users want to do IP Filtering / IP >> NAT in layer 2 only for specified ethernet addresses, ethernet filtering >> rules need to include the ethernet address matching part. >> > > I'm still missing why new keywords are needed. The existing ones seem > to work just fine here. > > >>> (It seems to me that "family ether" and "layer2" are essentially the >>> same thing; they're in lieu of putting these rules in a separate >>> file.) >>> >>> >> Please see above. While putting these rules in a separate file seems >> doable, I failed to see how this can remove the need for these keywords. >> Please note that users can add rules on command line, and without >> "family ether" we have no way to distinguish ethernet filtering rules >> from ipfilter rules. >> > > Yep; understood. You'd end up with separate command line flags if you > did that, just as IPv6 does today. > > My point in saying this is that the design looks incomplete. It looks > like you've added L2 (Ethernet, really; nothing else seems to be > supported) to a single configuration file, but the equivalent work for > IPv6 hasn't been done yet, so the design is "mixed" and confusing as a > result. > As Darren has already explained, /etc/ipf/ipf6.conf was introduced as an obsolete interface for a historic reason. I fully agree that it is good and desirable to have all IPv4, IPv6 and ether rules consistent (maybe put altogether in ipf.conf), I'm just not sure if it is needed to be done in this project. As this project is only focused on layer 2 filtering and doesn't touch anything about IPv6. So probably this can be addressed via a separate bug/RFE? > All of the L2 examples you've provided use IPv4. What would happen if > I needed to add L2+IPv6 rules? Can I do that? > Sure. Just add the "layer2" keyword to the IPv6 rules, the usage is the same as IPv4 rules. :-) Thanks again, Zhijun -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080411/127160fc/attachment.html>
