James Carlson wrote:
>>> 2. You give the new rule processing as:
>>>
> [...]
>
>>> I don't understand why the ordering of operations isn't just
>>> reversed on output. Assuming the input order is correct (and it
>>> appears to me to be right), the "L2 firewall" element should be
>>> the last operation before "[OUTPUT]."
>>>
>> It could be a useful feature to combine filtering on L2 and L3
>> together, or even trigger conditional IP NAT from a L2 filtering rule,
>> though they are not supported in the current project scope, down the
>> road we may want to add it, and these features require that L2 firewall
>> to be processed before those "layer2" IP rules.
>>
>> Also, since the packet is received at MAC layer, it might be more
>> straight forward to do the parsing and matching from the MAC header,
>> as we need to parse the MAC header first anyway to locate the IP header
>> start. It also allows a simpler implementation in IPFilter but that
>> can be considered an implementation issue anyway.
>>
>> Would the above make sense?
>>
>
> I'm not sure, but I don't think any of it answers the actual question
> I had. You currently have this:
>
> [INPUT] -> L2 firewall -> "layer2" IP NAT -> "layer2" IP firewall ->
> ... -> IP NAT -> IP firewall -> { IP } -> IP firewall -> IP NAT -> ...
> -> L2 firewall -> "layer2" IP firewall -> "layer2" IP NAT -> [OUTPUT]
>
> But that's not entirely symmetric, and I don't see why. I would have
> expected it to be:
>
> [INPUT] -> L2 firewall -> "layer2" IP NAT -> "layer2" IP firewall ->
> ... -> IP NAT -> IP firewall -> { IP } -> IP firewall -> IP NAT -> ...
> -> "layer2" IP firewall -> "layer2" IP NAT -> L2 firewall -> [OUTPUT]
>
> That would be symmetric processing: we go through steps A through E on
> input, and then E' through A' on output. That's easy to understand.
>
> I don't understand doing A-E on input, and then E', D', A', C', B' on
> output, which is what you've documented. Is there a reason for this?
>
> (This is my only real sticking point right now.
Jim,
Yes I know what you're saying. :-)
I agree that it makes sense for the processing to be entirely symmetric.
The problem with that, as I understand, is it will remove future chances
to combine L2 + L3 filtering together, or trigger L3 NAT conditionally
from L2 filtering rules.
(forgive me about the invented keywords below as it is just an example,
and won't be provided in this project)
For input, we might want to do something like below in the future:
#pass in family ether from 11:22:33:44:55:55 to any l2-head 100
#pass in proto tcp from any to any l2-group 100 layer2
For output, we might want to do something similar:
#pass out family ether from 66:55:44:33:22:11 to any l2-head 200
#pass out proto tcp from any to any l2-group 200 layer2
(the same for combining L2 filtering + "layer2" L3 NAT)
To do this, we need the L2 firewall to be processed earlier
than "layer2" IP firewall (and "layer2" IP NAT), for
both INPUT and OUTPUT, as otherwise we don't know whether
a "layer2" IP firewall/NAT rule should be processed or not
if we do E -> D -> C -> B -> A for output, as the rules
can be conditional which depend on the L2 firewall rules,
which haven't be processed at that time.
Is there actual problems in your mind that could be caused by
the current "not entirely symmetric" approach?
Thank you,
Zhijun
--
#mdb -K
[0]> eri.prc.sun.com::walk staff s|::print staff_t s_name|
::grep .== zhijun |::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/20081211/b99971a5/attachment.html>
