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".
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. 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. Thus, the new switch isn't necessary. > > 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. This new "ip-head" and "ip-nat" feature does the same thing, 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." > 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. > 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 > 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 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. 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? -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
