Feature #1239: Best effort TCP stack - Suricata - Open Information Security Foundation

Actions

Copy link

Feature #1239

closed

Best effort TCP stack

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

Status:

Closed

Priority:

Normal

Assignee:

OISF Dev

Target version:

TBD

Effort:

Difficulty:

Label:

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)

Actions

Copy link

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

Copy link

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

Copy link

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

Copy link