Feature #1239


Best effort TCP stack

Added by JmpCallPoo . almost 10 years ago. Updated 10 months ago.

Target version:



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 open0 closed)

Is duplicate of Suricata - Task #3553: Tracking: enable GAP recovery for all TCP app-layer protocolsNewActions
Actions #1

Updated by Victor Julien almost 10 years ago

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

Actions #2

Updated by JmpCallPoo . almost 10 years ago

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.

Actions #3

Updated by Anoop Saldanha almost 10 years ago

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.

Actions #4

Updated by Andreas Herz over 8 years ago

  • Assignee set to OISF Dev
  • Target version set to TBD
Actions #5

Updated by Philippe Antoine 10 months ago

  • Status changed from New to Closed

I think this is done through #3559

Actions #6

Updated by Philippe Antoine 10 months ago

  • Is duplicate of Task #3553: Tracking: enable GAP recovery for all TCP app-layer protocols added

Also available in: Atom PDF