Re: RFC: Disable defered bridge hooks by default

[Tom Eastep <teastep@shorewall.net>]

[-- Attachment #1: Type: text/plain, Size: 3427 bytes --]

Philip Craig wrote:
> Patrick McHardy wrote:

> 
>> But you can do your iptables matching, mark matching packets
>> and filter on the mark within ebtables.
> 
> I haven't thought about this too much, but for a high-level tool,
> the rules can theoretically be too complicated for this to be feasible.
> The worst case will be to perform all the possible matches that are
> supported by iptables but not ebtables, and encode the result of all
> of these into the mark.  And even if this can be optimized, I can
> imagine the code to do it being quite complex.
> 

The proposed solution requires high-level tools to have two completely
different paradigms for filtering traffic; one for when the output
device is a bridge and the packet is locally-generated (and possibly
when the input device is not the same bridge -- I'm still not clear on
that point) and the other is applied everywhere else. In one case,
filtering rules are contained in the filter table and use standard
filter targets -- in the other case, they must be placed in the mangle
table and use the MARK target. That, in and of itself, is a ugly change
for Shorewall which has a nice uniform structure for generating
filtering rules.

I think that the mark values can be optimized down to two fwmark bits
per Shorewall zone. If the first bit is set, traffic is allowed to the
zone; if the other bit is set, the traffic is not allowed (our users
lose the ability to use the REJECT target since ebtables can only ACCEPT
or DROP). Two separate bits are required so that Shorewall can detect
packets that don't match any rules and hence are subject to the
applicable user-specified policy (MARK isn't terminating).

In Shorewall, there needs to be a few more fwmark bits reserved to
indicate if and at what level the packet should be logged if it is
dropped and a similar number of bits to indicate if and at what level
the packet should be logged if it is accepted. And finally, a few more
fwmark bits will need to be allocated to indicate the contents of the
log-prefix. From what I gather, ebtables doesn't support ULOG so that
form of logging won't be available.

Shorewall supports 'actions' which are essentially user-defined filter
chains; actions can be invoked in other filtering rules (a --jump to the
action chain results). With --physdev-out limited as proposed, actions
must generate either a filter table chain or a mangle table chain or
both (the mangle table chains must be tailored for each destination zone
in the rules where the action is invoked since the mark values are
dependent on the destination zone in the invoking rule). Shorewall today
needs to tailor the chain based on the invoking context and that part of
the code is complex and error prone.

The original support for bridge-port based filtering was added to
Shorewall in a weekend, including the documentation (I can only work on
Shorewall off hours). To maintain even reduced support for this feature
will require considerably more effort and will result, I fear, in a less
maintainable product.

In summary, I think that the complexity is probably manageable but this
is really ugly ...

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]