Re: Blind reset Attack using SYN in NPF

[Greg Troxel <gdt%lexort.com@localhost>]

Emmanuel Nyarko <emmankoko519%gmail.com@localhost> writes:

> RFC 5961 implements mitigations against Blind reset Attack using RST, SYN or data.
>
> It is already handled in NetBSD TCP stack. 

It is not mentioned in tcp(4).  (I realize users should read the
sources. :-)

> A tasklist indicate it to be handled in NPF But will it be ideal to
> also implement in NPF ?  Maybe I think to be extra security in that
> NPF doesn’t even let potential attacks get to our network stack.

I think we're going to need to make a new list of things to do and think
about each one; 2019 was a long time ago.  (As an aside, I think this
needs to be independent of any particular corporate
recruiting/sponsorship program; I see the "NetBSD projects page" as
problematic.)

First, we need to be clear about whether npf is portable with NetBSD as
the primary user or if it is NetBSD only.  I think we should think of it
as portable.

npf does connection state tracking, and decides if packets should be
accepted.  However, it does not, so far as I know, have a practice of
sending acks, resets, etc. that the host did not, at least for
connections intended to be allowed (vs rejecting attempts for blocked
ports).  Adding RFC5961 support would look like implementing those rules
in the "is this packet allowed to pass this TCP state entry" code, but
an in-window RST needs to passed to the host stack for it to generate
the ack.  Generating it in npf means it won't work with TCP MD5, and
just feels like too much complexity for no real gain.

So I'd say this should be dropped from the todo list, unless someone can
explain what should be done, how it would work, and why it's a good
idea.

There are certainly plenty of things that need doing that are far more
important.

We could also have a final section "things to consider if they make
sense" and list it there.  But if we don't get rationale on this list
now, I think that's just noise.