tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: NPF: TCP options



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).

You can say whatever you want about the fact that NPF is not a kernel, that
NetBSD is not the only user of NPF, etc.; it doesn't alter in any way the
fact that the behavior is not the same, and that as a result the normalization
procedures can be bypassed.

So, either we fix this issue - by making NPF behave the same way as the
NetBSD kernel, which is what I suggested -, or we accept to have bypassable
normalization procedures.

Maxime

Side note: differences in behavior, are where bugs and bypasses lie. That's a
universal law of packet processing. (authored by me btw)


Home | Main Index | Thread Index | Old Index