[Bro-Dev] Looking on feedback on PACF/reaction framework

[Robin Sommer]

On Thu, Jun 19, 2014 at 15:21 -0400, you wrote:

> - I believe Rule$target should be of type Target and not TargetType (which
> is undefined).

Ack.

> - Some other options to consider for EntityType:
>     * Subnet
>     * MAC address
>     * User? (I believe some devices allow filtering based on user, if they
> authenticate via VPN, 802.1X or something similar)

Ack, as well.

For subnets, we could even just use them generally instead of
addresses, and specify addresses as /32. 

User is an interesting thought.

One general question for the API is how much to standardize. A plugin
can always just extend the RuleType if it has a specific cability no
one else has. My hunch would be going with a small set initially
that's likely supported by a majority of systems we're going to
interface to.

> - Should Rule have both orig and resp Entity fields? i.e. I could see a use
> case for filtering traffic from an IP, to it, or both.

Yes. Or alternatively, we could add ORIG and RESP to the EntityType
instead?

> - More generally, should Rule have an optional BPF? Perhaps this is one of
> the use cases of arg_str.

I'm reluctant to use BPF, for two reasons. One is that it's having
some low-level problems, like VLANs etc. But more importantly, it's
very generic and hence hard to map device capabilities. Basically it
would only be supported by devices which indeed have full BPF
capabilities; and other than host-based implementations filtering with
libpcap that's probably not many (or, alternatively: Bro itself would
need to do the filtering, which is kind of counterprodutive).

I see the rules more as an (almost) lowest common denominator in terms
of expressing filters that a range of devices can support efficiently.
>From that perspective, I would rather aim to identify specific use
cases ("drop IP") than provide a generic filter language. 

That said, I can see some hybrid in the future where we provide more
complex filters than just simple entities, as long as they do map
easily to a range of hardware. Asim has been looking at that for a bit
already. For now we're going with the simple model for his work
though.

Robin

-- 
Robin Sommer * Phone +1 (510) 722-6541 *     robin at icir.org
ICSI/LBNL    * Fax   +1 (510) 666-2956 * www.icir.org/robin