Re: Blind reset Attack using SYN in NPF

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Apr 6,  8:53, Greg Troxel wrote:
} Emmanuel Nyarko <emmankoko519%gmail.com@localhost> writes:

     Somewhat behind on my e-mail (especially list e-mail), but...

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

     Is npf used in any other operating system?  Is there a reasonable
likelyhood that it will be used in any other operating system?  If the
answer to either of those questions is positive, then it should be
portable.  If not, then it should be considered to be NetBSD only.  There
are always compromises with things being portable, even if it is just a
bunch of "#if" in the code.  I'm certainly not saying that there is no
value in being portable, but if it is de facto non-portable, there is
no point in paying the price.

} 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.
} 
}-- End of excerpt from Greg Troxel