Re: NPF: TCP options

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

Maxime Villard <max%m00nbsd.net@localhost> wrote:
> Answering in this thread now, to prevent further confusions.
> 
> Le 13/03/2018 à 00:23, Mindaugas Rasiukevicius a écrit :
> >> 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.
> 
> It sounds like you didn't understand my point.
> 
> I'm saying that the TCP-options behavior in the NetBSD kernel and NPF is
> not the same. There is a divergence. Since there is a divergence, it is
> possible to bypass the normalization procedures on TCP options (and along
> with that, to lead to possibly unexpected behavior).

So what?  You talk about differences in behaviour, but you fail to explain
the reasons why any of this matters.  The packet filter may be configured
to operate only at layer 3 and whatever happens at TCP would be completely
irrelevant.

Let me repeat again: it is the NPF *rules* (well, overall configuration)
which ultimately decide what is passed and what is blocked.  Not a bunch
of if-statements you arbitrarily sprinkle before them.  If you want to
introduce something like NPC_L4ERR and give the user an option (possibly
even enabling it by default) to block the packets with malformed (or not
conforming to the standards or "the kernel") L4 payload -- brilliant,
please do!  However, do not hardcode these decisions before the rules.
The ruleset/configuration has a purpose.. this should be quite obvious.

-- 
Mindaugas