Your inline IPS reassembles only the first megabyte of each flow to hold its latency budget — what does that give an intruder?
answer
- the engine buffers before it can match
- content stops at a byte offset
- benign prefix, payload behind it
- buffer memory times concurrent flows
- silence proves only the prefix matched nothing
basics
~20 sEverything past the first megabyte of that flow leaves uninspected, so an intruder puts the payload behind a benign prefix. The limit exists because deeper reassembly costs buffer memory on every concurrent flow and adds latency.
solid answer
~50 sA stream-reassembly depth limit means the engine buffers and matches content only up to a byte offset per flow; past that it keeps flow accounting but stops looking at bytes. So an intruder does the obvious thing — a benign, well-formed prefix in front, the payload or the staged archive behind it. The transfer completes with no alert, and no alert only proves the inspected prefix matched nothing. The limit is not a defect: deeper reassembly costs buffer memory multiplied by concurrent flows, plus added latency on every inspected flow, and the throughput figure the platform was sold on assumes the cap is on. The honest move is to set depth per traffic class rather than one global number — full depth on egress paths carrying customer data, a short prefix on bulk replication — and to instrument the truncation counter so you can state how often you hit the boundary.
go deeper
Be ready to say plainly that an inline engine inspects a prefix of a flow, not the whole thing, and that a quiet transfer only means the prefix matched nothing.
Explain why the cap exists — reassembly buffer per flow times concurrency, plus added latency — and name the second, usually smaller cap on protocol body inspection.
Show how you would set depth per traffic class instead of globally, and how you would instrument the truncation counter so the boundary is visible before an incident finds it.
Own the fact that the number is a promise: whatever inspection commitment exists in a service description must match the configured depth, and raising it is a funded capacity decision, not a config change.
## What the budget actually is An inline inspection engine cannot match a signature or run a protocol analyser against a byte it is not holding. TCP delivers a stream in segments that can arrive out of order, overlap, or be retransmitted with different content, so the engine must buffer and reassemble each direction of each flow before it can inspect content at all. That buffer is the cost. Two related caps bound it: - **Stream reassembly depth** — how many bytes per direction, per flow, the engine will reassemble and inspect before it stops tracking content. - **Protocol body limits** — how many bytes of an HTTP request or response body (or an equivalent application object) the engine will hand to detection, which is often a smaller number than the stream cap. Both are configured, both have a default, and on most platforms the default is small — a low number of megabytes at most — because the vendor's throughput figure was produced with them set that way. ## What happens at the boundary At the cap, the engine does not drop the flow and does not alert. It stops content inspection and usually keeps the cheap parts: the five-tuple, byte and packet counters, duration, and whatever it already concluded about the session. That residue is flow accounting, and flow accounting carries **no payload at all** — it can show that bytes moved and never what they were. Most engines expose a counter for streams truncated at the depth limit, and almost nobody looks at it. The direction of the claim matters and it is the thing candidates get backwards. A silent transfer proves that the inspected prefix matched nothing. It does not prove the transfer was clean, and it does not prove the engine looked. ## Why an intruder cares The boundary is a fixed, published-by-behaviour offset, and it is cheap to find from outside: send objects of increasing size and watch which ones draw a response. Once known, the moves are mechanical. - **Prefix padding.** Put legitimate, well-formed content in the first N bytes — a real document, a real page, a valid archive header — and the payload after it. - **Staged transfer.** An implant that has already collected and archived data on the victim's own hosts sends a large object; only its opening is inspected, so the archive's contents never meet a signature. - **Offset-aware chunking.** Split a transfer so that whatever would have matched never sits inside the first N bytes of any single flow. None of this requires a new technique. It requires reading a number that the defender configured and did not write down. ## The price of removing it "Raise the limit" is a purchase, not a setting. Per-flow buffer multiplied by concurrent flows is the memory line; on a shared aggregation carrying every tenant's traffic, that multiplier is large and moves with the noisiest tenant, not with the one you are trying to protect. Deeper reassembly also adds latency per flow, and latency is often the number written into a service description. An engine rated at line rate is rated with truncation on; turn it off globally and the rating no longer describes the box you own. ## What a defender does instead | Where | Sensible depth | Why | |---|---|---| | Egress to the internet, tenant data paths | Full or generous | This is where a staged transfer leaves, and payload value is highest | | Bulk replication, backup, known machine-to-machine | Short prefix | Volume dominates, content value is low, and this is what fills the buffer | | Interactive internal traffic | Moderate | Latency-sensitive, but small objects rarely reach the cap anyway | The defensible position is: know the number, set it per class rather than once globally, alert on the truncation counter rather than treating it as a statistic, and state the number in whatever document promises inspection. A ceiling you have written down is a risk somebody can accept; a ceiling nobody wrote down is a surprise delivered during an incident. One boundary worth keeping straight: this is a **configured** limit on an engine that received the traffic. It is a different failure from traffic that never reached the sensor in the first place, and the two get confused constantly in post-incident reviews.
- Nothing alerted on a 4 GB upload through that engine. What have you actually proved?That the reassembled prefix — the first megabyte in each direction — matched no rule. Beyond it you have flow accounting only: bytes, packets, duration, the five-tuple. That tells you a transfer happened and its size, never its content. Reporting 'the IPS cleared it' from that evidence is the misstatement to avoid; the honest statement is 'the inspected portion matched nothing, and the inspected portion was one megabyte'.
- Why not simply set reassembly depth to unlimited on the whole platform?Because per-flow buffer multiplied by concurrent flows is real memory, and on shared aggregation the concurrency is set by whoever is busiest, not by the traffic you care about. Deeper reassembly also adds per-flow latency, and the throughput the platform was sized and sold on assumed truncation was enabled. Unlimited depth is a capacity purchase; the usable version is generous depth on a narrow, high-value set of paths.
- How would you find out what the depth limit actually is on a platform you inherited?Read the configured value for stream reassembly and for protocol body limits — they are usually different numbers — then confirm it empirically with a benign test object carrying a known-matching string placed past the boundary. Also pull the truncation counter: if it is climbing constantly, the limit is being hit in normal operation and every alerting claim above it is weaker than the documentation says.
A guard who opens every parcel but only looks at the top layer. Pack anything you like underneath, and the parcel is recorded as inspected.
saying these in an interview costs you the question
- Reading no alert as proof the whole transfer was clean
- Assuming the engine inspects every byte it forwards
- Thinking a larger appliance removes the cap rather than moving it
- Confusing a configured depth cap with packet loss before the engine
- Believing the depth limit applies only to downloads, not uploads