An attacker resends a TCP segment with different data - why can an IDS and the server rebuild different requests, and what must you configure per host?

## The ambiguity is in the standard, not in the attack TCP presents a byte stream, but it moves that stream as segments carrying sequence numbers. Retransmission is normal and expected, so a receiver routinely gets bytes it already has. The specifications tell a receiver how to handle duplicate data; they do not settle what a receiver must do when the duplicate covers the same sequence range but contains *different bytes*. That case should never happen on a healthy network - and it is trivial to produce on purpose, because the attacker is the sender and can write whatever it likes into its own segments. IP fragmentation carries the identical hole. Fragments are placed by offset, and two fragments can claim overlapping offset ranges with conflicting content. Again the standard does not name a winner. ## The stacks resolved it differently and kept the difference When implementers filled the gap, they filled it in incompatible ways. Broadly there are three behaviours: - **keep what arrived first** - the original bytes stand, later overlapping data is discarded; - **let later data overwrite** - the most recent copy replaces what was held; - **break the tie by offset** - prefer the fragment or segment starting at the lower offset, falling back to arrival order when the starts are equal. Sensor configuration gives these families the names of the operating systems they were observed to match, because they were derived by testing real stacks rather than read out of any vendor document. That is worth knowing, but memorising the list is not the point of the question and an interviewer will not reward reciting it. The point is that the behaviour is a property of *the destination host*, not of the protocol, so it is not derivable from the packets themselves. ## Why the sensor is the one that suffers An IDS is not the destination. It watches from several hops upstream, and it must produce a single reconstruction of the stream before any content decision can be made. It has three bad options: pick one behaviour globally and be wrong for part of the estate; hold every plausible reconstruction at once and pay for the memory and the false alerts; or be told, per address range, which behaviour to imitate. The third is what real deployments do, and it is where the price lives. The attacker's move follows directly. Send the harmless bytes in one segment, the attack bytes in an overlapping one, and time or order them so that the sensor's rule for resolving the overlap and the server's rule select different content. The sensor sees a request that matches nothing. The server sees the request the attacker meant to send. No exploit was needed against the sensor - only a correct guess about which stack the destination runs, and that is cheap to obtain. Note that this does not require the attacker to be on the path or in the middle of anything. They are the client. They control their own transmission, including sending overlapping data that no normal stack would ever emit. ## What the per-range map actually asserts, and how it rots The reassembly-policy map is a table saying *this address range reassembles like family X*. It is an assertion about the operating systems living at those addresses, and it was true on the day someone derived it from an inventory. It rots in ordinary, unexciting ways: - a subnet is renumbered and the range now holds a different build; - a dynamically addressed client range holds two builds at once, and an address does not identify a host for longer than a lease; - an address translation device hides many hosts of different kinds behind one address, and a map keyed to addresses cannot express that at all; - two estates merge and one of them has no inventory you can read. Nobody is funded to re-derive it after every move, which is why it is common to find a sensor whose map has quietly described the wrong estate for years. ## The claim direction to get right An alert raised on reassembled content proves that *the sensor's reconstruction* contained the pattern. It does not prove the destination assembled the same bytes, and the absence of an alert does not prove the destination did not. Once you accept that the reconstruction is a prediction, the correct posture follows: treat the policy map as a maintained assertion about the estate, and treat any range you cannot classify as a range where content matching is unreliable.