Thanks Victor for the reply.
Overall, my experience developing icapsuricata against libsuricata has been very positive. The integration was smooth, and the library mode behaves predictably. That said, since this is a fresh proof-of-concept and hasn’t faced high-throughput production stress yet, my feedback should be taken with a grain of salt.
To answer your question regarding pain points or structural hurdles, the most notable observation relates to data ingestion styles:
The Packet Emulation Requirement vs. Stream Ingestion
When I first approached libsuricata for purely inline content inspection (rather than L3/L4 network anomaly detection), I was initially hoping I could bypass low-level packet emulation entirely and feed raw application-layer proxy stream chunks straight into the engine.
However, because Suricata’s stream reassembly, protocol parsing, and detection matrices are tightly coupled to the state transitions of the TCP engine, packet emulation turned out to be strictly necessary. To keep StreamTcp aligned, I have to synthesize IPv4/TCP headers and manually manage sequence/acknowledgment tracking spaces.
Furthermore, I discovered that to prevent app-layer blindspots (due to internal optimizations like skipping frame inspection on non-state-changing payload updates), I have to systematically inject synthetic cross-direction ACK packets mid-stream (currently 4KB chunks) to act as evaluation/flushing triggers, alongside a final sequence-incremented FIN|ACK sweep to cleanly finalize the flow.
While this requires some emulation overhead, I realized it is an inherent requirement of the current architecture. It ensures that Suricata can perfectly handle stream reassembly, especially when signature payloads (like an HTTP response body match) happen to cross the boundaries of multiple contiguous ICAP chunks.
If a future public libsuricata API eventually exposes a purely stream-oriented or transaction-oriented ingestion interface (bypassing the need to fake a wire tap), it would be a massive win for proxy integrations. But the current packet-level injection is absolutely viable.
As a quick side note regarding configuration management: I noticed the ongoing forum discussions about libsuricata config handling, but I haven’t yet implemented or tested live-reloading the Yaml configuration or dynamically updating IDS rules from within icapsuricata. For now, it’s a static load at initialization, so I don’t have any feedback on that front just yet.
Next Steps & Deep Testing Challenges
The next items on my roadmap will provide a much more thorough test of libsuricata’s boundary limits:
- Ecosystem Integration: I am currently integrating the SSLproxy +
icapsuricata combination into my UTM firewall project (UTMFW) for extensive, multi-client HTTP/1 verification.
- Service Chaining: I plan to test SSLproxy running multiple concurrent ICAP services in series (such as passing traffic through
E2Guardian and icapsuricata sequentially).
- The HTTP/2 and HTTP/3 Frontier: This will be the real trial. Extending packet emulation and stream tracking to accommodate HTTP/2 multiplexed streams and HTTP/3 QUIC frames within an asynchronous ICAP loop is going to be complex. Seeing how
libsuricata’s app-layer parsers coordinate with emulated network frames under heavy stream multiplexing will provide excellent data for refining the public API.
- Protocol Expansion: Down the road, I want to expand this past HTTP to see how other proxy-handled protocols adapt to this model.
I’d like to hear your thoughts on how the current engine expects stream flushes, or if there are cleaner ways to signal transaction progress through libsuricata without faking many ACKs!
