Re: NPF: fast kick

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Maxime Villard <max%m00nbsd.net@localhost> wrote:
> > Sure, but if NPF is used for deep packet inspection, analysis,
> > accounting or monitoring -- this is a desirable behaviour.  If my
> > application is observing traffic at some transient point in the
> > network, then I do not want it to drop the packets.  Even if the
> > packets are malformed, because the main purpose of such application is
> > to be packet *observer*.  NPF can operate as a *filter*, but it may as
> > well operate as an *observer*.  I am just saying -- please do not
> > disregard the latter use case and give user an option.
> 
> The kernel performs sanity checks on IP packets even before invoking NPF.
> This "accounting malformed packets" thing does not hold in the first
> place, because at several points the kernel can drop the packets before,
> and after, invoking NPF.
> 
> <...>
> 
> A real "observer" would have to be some pseudo device, to which a copy of
> the packet is given at the very entry point (L2) - in order to ensure
> that neither the kernel nor any driver has sanitized anything. Perhaps we
> already have this, I didn't really check. In all cases, NPF is never
> going to achieve that, as long as it doesn't get called before anything
> else - which will likely never happen, because it would be wrong.
> 

What kernel? :)  I think you miss the use cases such as NPF + DPDK.
It is actually a bigger user of NPF than NetBSD (at least as far as
I am aware).

Layer 2 filtering is in the plans.

> If the basic sanity checks I added in NPF (which consist, as I already
> said, in checking the return values of function calls that are _already
> there_) were to be an option, we would have to go through the ruleset
> machinery, which is exactly where bugs can happen. That wouldn't be "fast
> kick", it would be "slow, buggy kick". (heh!)

It is the main and ultimate purpose of the "ruleset machinery" -- for the
packets to go through it.  It also defines the default behaviour (to pass
or block the "rest" of the traffic).  In the perfect world, everything
ought to be passed through the ruleset inspection -- and only through it,
since that would be a simple and "clean" design.  In reality, things are
more complex and protocols are not always nice and simple.

BPF byte-code engine is an old and robust piece of code.  I think the bugs
are much more likely to be somewhere else.. :)

> Not checking the return values of the nbuf functions, just for the sake of
> some hypothetical "observer" thing that doesn't hold in the first place,
> doesn't make any sense, apart from wanting more bugs by default.

Huh?  I am not sure why do you think I suggest that.  NPF nbuf API was
added to abstract mbufs, but another purpose also to provide stronger
safety.  The return values should certainly be checked.

> <...>
> 
> So NPF's behavior should be aligned to that of the kernel; that is to
> say, NPF should ignore TCP options with uncommon lengths - which does not
> mean dropping the packet. (We can discuss about changing the kernel's
> behavior to be that of NPF, but as I said in my answer to Joerg, the
> kernel's behavior is the one that is the most "common".)

Not exactly, no.  NPF is not a host/kernel.  It is a man in the middle,
concerning packets sent by different hosts (which might have different
TCP/IP implementations and applications).  It operates based on its own
set of rules.

Let me put it this way:

- NPF should perform minimum sanity checks to be able to read the basic
L3 payload from the packet for its own operation (-- I don't think we have
a disagreement here).  However, generally, the *default rule* decides
whether unrecognizable (or malformed) packets are passed or not; this is
more or less how other packet filters work too.

- NPF should be able to operate as packet observer at L3 (and, in the 
future, at L2).  This should be a supported mode of operation, but I am
not trying to suggest that this should be the default.

- NPF ought to support additional protocol-level checks (at L3, L4 and
may as well go beyond).  However, how strict and aggressive such checks
should be is something what should be tunable.  For example, extensive
checks can protect hosts with weak or vulnerable TCP/IP stacks; but it
might also break some applications or legitimate traffic, because in
reality, not everybody on the Internet plays by the rules and standards.

-- 
Mindaugas