Feature #1239
closed
Added by JmpCallPoo . over 10 years ago.
Updated over 1 year ago.
Description
Hello,
Is it possible to have a best effort TCP stack in suricata ?
The problem is when a single packet is lost, all the stream is broken and in the context of a keep-alived HTTP stream, this is not soo cool :(
Thank you.
@JmpCallPoo .
Related issues
1 (1 open — 0 closed)
- Subject changed from Best effort TCP stack. to Best effort TCP stack
This is not really a TCP stream engine issue, as we do continue inspection of 'raw' stream data in case of packet loss. However, the app layer parsers like HTTP are not able to handle missing data. It will be very hard to adapt those to handle missing data. In some cases it may be possible, for example in case of missing HTTP Body data, where we know the length of the body because of the content length. But in other cases missing data would mean we'd have to figure out what the missing data would mean. If we miss 16k of HTTP data to the server, did we miss a single large request? Or multiple smaller requests? I think this likely brings more problems that solutions.
I aggree that this will be a litle bit tricky with HTTP pipeline !
Maybe, it is possible to set the stream as "incertain/insecure" and continue to pass the stream to the HTTP app layer.
But in most of the cases, user will use single request, one by one, and then the stream could be "resynchronized".
In my opinion, that will be better than nothing.
The resynchronization idea is possible, yeah. We had planned to use synchronization against a PDU record boundary for an app layer protocol in another area of the engine(picking up streams midstream). The same logic can be extended here.
Of course, this will require more than some support from the parsers. For example, we will have to inform the parser, that there is a gap, and we want to sent a fresh PDU, and it will have to reset the state, etc. with whatever pending state it has from a previously parsed but broken PDU.
- Assignee set to OISF Dev
- Target version set to TBD
- Status changed from New to Closed
I think this is done through #3559
- Is duplicate of Task #3553: Tracking: enable GAP recovery for all TCP app-layer protocols added
Also available in: Atom
PDF