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.
>
>
>> 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?
>
Darren has answered this so I'm taking the rest :-)
>> 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)?
>
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".
>
>> 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?
>
> 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.
> 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. But basically ethernet filtering rules and ipfilter rules are
two sets of rules. So it may not be desirable to use "quick" for this.
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).
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.
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 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.
> ... so that the remaining "layer2" filter entries (who filters on
> explicit MAC addresses?
"family ether" rules filter on MAC addresses, and "layer2" rules
filter/NAT on IP addresses.
> ) won't be confusing.
>
> (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.
Say,
pass in family ether from any to any
pass in from any to any
------
Thanks,
Zhijun
--
#mdb -K
[0]> eri.prc.sun.com::walk staff s|::print staff_t s_email|
::grep .== Zhijun.Fu at Sun.COM|::eval <s=K|::print staff_t
Zhijun.Fu at Sun.COM, x84349
Network Virtualization & Performance Team,
Solaris Core Operating Systems
Since Jul 10,2006
[0]> :c
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080410/20a28fa3/attachment.html>
