persistent TCP resets
Currently when the reject keyword is being used we send a single RST packet. If that is lost, ignored or discarded, the flow might just continue. Making the active response ineffective.
This is not a problem in IPS mode, where we drop as well as reset. The flow stores a drop flag and new packets coming in on that flow will also be dropped.
So in IDS mode, we need a better way of dealing with this. One way would be to set a flow flag as well and send more resets if more packets come in on the same flow.
We'd have to be careful of course. We should probably only do this on established TCP connections and on events generated by inspecting the reassembled stream and the app layer state. Otherwise the risk of us sending (loads of) RSTs based on injected packets might be too great.