James Carlson wrote: >Darren Reed writes: > > >>This case will extend PSARC/2005/334, by adding the ability to intercept >>packets in MAC layer using the PFHooks infrastructure. >> >> > >Very minor nit: case title doesn't quite match the contents. I was >excited to see the name, because I'm working on MAC layer interception >... until I read that it was just a PFHooks extension for layer 2. > >
What were you expecting that you didn't find? I'm curious... >>Users can use ipf(1M) to add ethernet filtering rules in addition to IP >>filtering rules, the ethernet filtering rules are marked with "family ether". >>Unlike IPv6, no special command line switch is required to load ethernet >>rules. And by default, ethernet rules should be put in /etc/ipf/ipf.conf. >> >> > >That seems strange. > >We currently have /etc/ipf/ipf.conf for IPv4 and the undocumented >/etc/ipf/ipf6.conf for IPv6. Why wouldn't we have /etc/ipf/ipfl2.conf >(or some such) for L2-specific rules? > >Or if "family ether" is a good way to do this, why wouldn't we have >"family inet" and "family inet6" and get rid of /etc/ipf/ipf6.conf? > >What's the intended direction? > > Eventually, the use of ipf.conf and ipf6.conf can be merged, but the operation of merging the configurations isn't as simple as: cat ipf.conf ipf6.conf Use of sed to insert "family inet" and "family inet6" would be required. There are some rules, such as these: pass in all block out all that carry no protocol or version information in them. Thus in a rule set that says this: block in all pass in on bge0 family ether from any to 12:34:56:78:9a:bc pass in on bge0 from any to 1.2.3.4 the "block in all" is applied to both IPv4 and ethernet traffic. >>The layer 2 filtering functionality is disabled by default, to enable it, >>add the following line to the top of ipf.conf: >> >>set intercept_layer2 true; >> >> > >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)? > > Because there are rules that will instantly apply to ethernet (see above), it is highly likely that there will be an adverse impact on networking if it was just enabled automatically. Although the suggestion about turning it on automagically if there are "family ether" rules present does hold some water. >>To distinguish IP filter/NAT rules intended to be processed in layer 2 >>from the rest of ipfilter rules, an additional keyword "layer2" is added. >>Those ipfilter rules to be processed in layer 2 are marked with "layer2", >>so these rules won't be processed again when packets goes up to IP. >> >> > >If I have rules that have "layer2" set, then why do I need to specify >"ip-head" or "ip-nat" in the "family ether" filter? Shouldn't any >rules with "layer2" set just _automatically_ match? > > There is a bunch of extra work required to make the packet suitable for filtering against IP rules and the "ip-head" tells ipfilter when to do that work and start doing some layer 3 comparisons. >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"? 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". > > Again, it is a function of joining the filtering of two different layers together. I don't think it is very clear if the ruleset goes: pass in on bge0 family ether .... pass in on bge0 proto tcp ... and for ipfilter to magically morph the ethernet packet into an IP packet between those rules. Darren
