Your IDS reassembly-policy map is keyed to address ranges a merger renumbered - where does an attacker get through, and what does re-deriving cost?

## What the map claims and when it stops being true A target-based reassembly configuration is a table of assertions: *hosts in this range resolve conflicting overlapping data like family X*. It is not a security policy and it grants nothing. It exists so that the sensor's reconstruction of a stream matches the reconstruction the destination will perform. Every assertion in it was true on the day it was derived, and each one is invalidated by an ordinary infrastructure event. A renumber moves ranges wholesale. A merger brings in ranges nobody in your team has ever inventoried, often overlapping with your own addressing and therefore forcing further renumbering on both sides. A re-platforming swaps builds under a range that did not move. None of these are security events, none of them notify the sensor team, and none of them cause an error - a wrong policy produces a sensor that runs happily and reconstructs the wrong bytes. ## Where the exposure actually lands The failure is not spread evenly. It concentrates on the ranges that just changed, which after an acquisition are the hosts you have the least knowledge of and the least ability to patch or rebuild. An attacker who wants a specific service does not need to defeat the sensor's rules; they need to know which stack the destination runs, which is cheap to determine from outside, and then choose the overlap that resolves differently in the two devices. Both failure directions are available: the sensor keeping bytes the host discards, and the host accepting bytes the sensor discarded. A second, quieter effect is that stale ranges also generate false positives, because a sensor imitating the wrong stack sometimes assembles an attack the host would never have seen. On a passive sensor that costs an investigation. On an inline device it costs a dropped session for a real user, and that is the version somebody escalates. ## How to re-derive it without pretending you own the estate **Prefer inventory over inference.** The authoritative answer to *what does this host run* lives in the build or configuration-management system, not on the wire. After a merger there are two such systems. Getting a periodic export from both, and generating the policy map from that export rather than editing it by hand, is what turns a one-off derivation into something that survives the next subnet move. This is the difference between a map that rots and a map that regenerates. **Use passive inference for what inventory cannot reach.** Stack families leave usable traces in traffic you already collect: initial time-to-live values cluster around well-known starting points that differ between families, and the maximum segment size, window scaling and the ordering of options in a connection opening differ by implementation. This is inference, not fact - it gives you a family, not a version - and it degrades where a middlebox rewrites options. It is still the right tool for an estate whose inventory you cannot read. **Handle the ranges the map cannot express.** Three cases defeat address keying outright and you should name them rather than pretend a policy covers them: - dynamically addressed client pools, where an address identifies a host only for the length of a lease and two builds share the pool; - addresses behind translation, where many hosts of different kinds appear as one address and no single policy is correct; - anything reached over a tunnel that terminates elsewhere, where what the sensor sees is not what the host sees. For those, content matching on reassembled streams is unreliable by construction, and the honest response is to say so and to lean on the controls that do not depend on reconstruction rather than to write a comforting entry in the table. **Set a defensible default.** For ranges you have not classified, pick the conservative family for your traffic mix and record that it is a default rather than a finding, so the next person knows which entries are knowledge and which are guesses. An unlabelled table is the reason nobody dares to change it. ## The cost, stated plainly Re-deriving is a data problem, not a sensor problem: an inventory you must obtain from another team, a passive inference pipeline for the rest, and a generation step so that the next renumber updates the map instead of silently invalidating it. The recurring part is the part that gets dropped, which is exactly why so many deployments run a map describing an estate that has not existed for years.