An inline sensor normalizes overlapping fragments so an attacker's traffic has one meaning - what does that cost you?

## The alternative to predicting is removing the choice A passive sensor guesses how the destination will reassemble ambiguous input. An in-path device does not have to guess: it can reassemble the traffic itself, decide the ambiguity, and forward a single interpretation. The destination then has nothing to resolve differently, because it never receives the conflicting input. Typical normalizing actions include holding fragments and forwarding one complete, non-overlapping datagram; discarding or rewriting segments whose overlapping content conflicts with what was already forwarded; enforcing the validity rules a strict receiver would apply, such as rejecting bad checksums and out-of-window data; and stripping options and framing that add nothing but ambiguity. The payoff is real: the classes of evasion that depend on the two devices disagreeing simply stop existing for everything that passes through, and the address-range policy map shrinks to whatever remains outside the device's coverage. That is the argument for doing it, and it is a good one. ## Line one: state, and an attacker who knows it Reassembling means buffering. The device must hold partial fragment sets and out-of-order segments until they complete or time out, per flow, for everything crossing it. That memory is finite and its size is now an attack surface: an adversary who opens a large number of incomplete reassemblies, each cheap to start and never finished, is spending almost nothing to consume something the defender bought. Whatever the device does when that memory fills - evict, time out early, stop reassembling and forward, or stop forwarding - is a decision that gets made under load whether or not anybody chose it in advance. ## Line two: position, and who owns the outage A passive sensor that dies stops producing detections. An in-path device that dies stops production traffic. Every millisecond it adds is added to real user requests, and every maintenance window on it is a maintenance window on the service behind it. That changes the conversation from a security one to an availability one, and it forces the failure posture into the open: on overload or crash, does traffic pass unexamined or does it stop? Both answers are defensible and neither is free. Fail-open keeps the business running and means the control is absent exactly when someone is pushing hard on it. Fail-closed keeps the guarantee and turns a device fault into a customer-visible outage. This must be decided, written down and owned before the rollout, not discovered during one. ## Line three: breakage, and the exception list that follows Strictness has collateral. Traffic that the destination would have happily accepted can be dropped by a normalizer applying a stricter rule than the endpoint does. Reassembling and forwarding also interacts with path sizing: a device that reassembles fragments must either re-fragment on the way out or drop what will not fit the next link, and where the do-not-fragment bit is set that becomes a visible failure for a flow that previously worked. Tunnelled and encapsulated traffic, which already carries reduced usable packet size, is the usual first casualty. The organisational consequence is the familiar one: each break produces an exception, each exception is added to a bypass list, and within a couple of years there is a set of ranges that skip normalization for reasons nobody recorded. The exception list is the real long-term cost, because it is the part that quietly grows. ## Line four: what you can still see, and what you record Normalization only helps for traffic that crosses the device and whose framing it can act on. Encrypted payloads are unaffected in substance: you can normalize the transport carrying them and still learn nothing about the content. Where the transport framing is itself inside the encryption, there is no ambiguity for a middle device to remove and nothing for it to reassemble on the application's behalf. Traffic that does not traverse the device - anything staying within a segment behind it - is untouched. And the recording changes: what a downstream capture or a subsequent investigation sees is the normalized stream, not what the sender emitted. That is usually acceptable, but it means the device's own view is the only place the original ambiguity ever existed, and if you want that evidence you have to decide to keep it. ## How to argue it in an interview Say yes to normalization as a way of collapsing a class of evasion, then price it: buffered state that an attacker can target cheaply, an in-path failure and latency point, an explicit and owned overload posture, and an exception list that will grow. A candidate who presents it as a free upgrade over prediction has only seen the first half of the trade.