The internet is built from tiny, fast-moving fragments. IPv4 fragments, IPv6 fragments, and TCP segments are like torn pages that arrive out of order, and every receiving stack has to piece them back together into a coherent story. But what happens if two pieces overlap, or if the same data shows up a little differently in two places? That seemingly small discrepancy can create a gaping hole in security: the very systems meant to watch for trouble—Network Intrusion Detection Systems (NIDS) and the host OS—themselves may disagree on what the data actually contains. In that gap, attackers can hide payloads, or spoof alarms, with potentially real consequences for a network’s safety and reliability.
That’s the core tension explored in a rigorous study conducted by a team of French researchers from Inria, ANSSI, and IMT Atlantique. Their work pushes beyond old, hand-crafted tests and asks a hard question: do modern OS reassembly policies—how an operating system pieces fragments back together—line up with how today’s popular NIDS reassemble and interpret the same traffic? If not, overlaps become a stealthy route for evasion or misdetection. The researchers’ answer is nuanced and worrisome: reassembly policies are not static, and the landscape is messier than many defenders assume. This matters because misalignments can persist across different protocols (IPv4, IPv6, and TCP) and across major security observers (Snort, Suricata, Zeek). The study’s findings even produced a CVE against one of the major systems, underscoring that these aren’t purely academic concerns.
The work comes out of a collaboration anchored in France, with Inria in Rennes leading the technical exploration, and ANSSI (the national cyber defense agency) and IMT Atlantique lending crucial perspectives. The lead authors—Lucas Aubard, Johan Mazel, Gilles Guette, and Pierre Chifflier—together map a path from abstract modeling to concrete test results, linking theory to practice in a way that feels urgent for anyone running or defending a network today.
The Overlap Problem: fragments as a hidden mismatch engine
Fragmentation is a long-standing feature of how networks cope with varying link capacities. IP fragments—in both IPv4 and IPv6—and TCP segments allow data to be split, carried along different paths, and reassembled at the destination. In an ideal world, every reassembly would be unique and predictable. In reality, however, there are many ways to reconstitute the same data, and overlaps between chunks are a natural outcome of how packets are split and transmitted. The paper emphasizes a troubling point: RFCs do not forbid overlaps in some contexts, and in practice, implementations differ on what to do when overlaps occur. That difference is exactly the kind of divergence attackers can exploit to hide malicious payloads from a watcher while it remains visible to a target host.
To visualize the problem, imagine two cooks assembling a dish from overlapping recipe fragments. If one cook favors one overlapping piece and another cook favors the other, the final dish can taste different depending on who’s tasting. In network terms, a NIDS might see one payload; the target host might reassemble to reveal something else. If the NIDS is relying on its own reassembly policy to detect an attack, but the host OS uses a different policy, a payload can slip past the watcher undetected or, conversely, trigger alarms that aren’t actually indicative of danger on the host itself.
Historically, a handful of researchers highlighted ambiguities that could lead to evasions or misdetections. Ptacek and Newsham flagged the problem decades ago, and later work explored a range of overlap sequences. But past efforts often focused on specific protocols or on manual, case-by-case test design. The new work makes a decisive move: it formalizes overlap types in a way that makes testing exhaustive, and it places OS policies side by side with NIDS policies to see where the misalignments really live.
Modeling overlaps with Allen’s interval logic: exhaustiveness as a design goal
One of the paper’s technical strengths is its use of Allen’s interval algebra, a formal system for describing relationships between time intervals. The researchers repurpose this spatio-temporal logic to the byte ranges and arrival times of packet chunks. In practical terms, this lets them categorize every possible overlap into a finite set of relations, and then test each relation in a structured, repeatable way. The result is an exhaustive catalog of overlap scenarios, not a hand-picked subset that might miss a vulnerability.
There are nine overlapping relations in Allen’s framework (plus a few non-overlapping ones). The authors map these to concrete fragmentation cases in IP and TCP, so they can say with confidence which overlaps have been tested and which remain to be explored. The goal isn’t to present a single “hack” but to build a complete, testable picture of how real-world reassembly policies behave when the data streams are not clean and perfectly aligned. The Allen-based modeling thus provides a rigorous backbone for what many practitioners had been implicitly assuming: that overlaps either don’t matter or are handled consistently. The study challenges that assumption in a meaningful, testable way.
Beyond elegance, the modeling has a practical payoff: it enables researchers and security teams to reason about coverage, not just cleverness. If a NIDS engineer wants to prove their system resists overlap-based evasion, they now have a complete test space they can audit against, rather than an assortment of ad hoc experiments that might miss critical edge cases.
What the experiments reveal: a moving target and a fragile alignment
The researchers tested a broad set of real-world actors: modern operating systems (Windows, Linux, SunOS/Solaris, FreeBSD/OpenBSD) and three widely deployed NIDS (Snort, Suricata, and Zeek). They looked at IPv4, IPv6, and TCP reassembly policies, in both a “multiple” testing mode (where overlaps interact across chunks) and a focused “single” mode (where a single overlap is examined in isolation). The results are nuanced and revealing.
First, OS reassembly policies are not static. Windows and Linux have evolved their IPv4 reassembly behavior in the multiple-testing mode, and Linux has shown shifts in IPv6 handling too. In contrast, TCP reassembly policies have remained comparatively steady over time. The upshot is that the landscape is dynamic: a policy that seems robust today might drift in a future OS update, and what mattered a few years ago may no longer apply to the present state of the world.
Second, NIDS policies show only partial alignment with OSs. Snort and Suricata, both of which allow policy configurability, tend to mirror some OS behaviors but not all. Zeek, which uses a single, non-configurable policy, often diverges from several OS families. The practical consequence is clear: even if a NIDS is configured to track a monitored host’s OS policy, there will be gaps where overlaps yield mismatches between what the host processes and what the NIDS analyzes. In a few notable cases, the study found enough mismatch to enable insertion or evasion techniques against NIDS-in-the-loop traffic. A CVE (CVE-2024-32867) was assigned for Suricata’s BSD-related misassemblies surfaced by these tests, underscoring that these gaps aren’t theoretical curiosities but real vulnerabilities with public-facing implications.
To ground the results, the researchers compared NIDS outputs directly with OS reassembly outcomes for each test case. They quantified how often a given NIDS would agree with a sample OS policy on a set of overlap relations. The picture is sobering: even in carefully designed environments, there are dozens—sometimes more than a dozen across IPv4, IPv6, and TCP—where reassembly decisions diverge. Some combinations yield evasion opportunities (the NIDS misses a malicious payload that the host sees), others yield insertion opportunities (the NIDS flags something that the host does not or vice versa). The net effect is a map of where defenders should be especially vigilant and where configuration choices matter most.
Why this matters now: the risk is real, and the fix is nuanced
Security is, at its core, a game of alignment. If the attacker can cause the NIDS to misinterpret traffic relative to the host, the whole system’s effectiveness erodes. The study makes clear that the gap between OS reassembly and NIDS reassembly is not a solved problem from a bygone era; it is an ongoing tension that evolves with OS updates and with the evolution of NIDS capabilities themselves. The practical risk is twofold. On one hand, an evasive payload can slip past a detector that relies on careful reassembly to identify suspicious patterns. On the other hand, an insertion attack can corrupt the NIDS’ processing, triggering false positives, wasting security analysts’ time, or provoking unnecessary responses that degrade network performance and user experience.
How should defenders respond? The authors argue for two complementary lines of defense. First, NIDS should make reassembly policies configurable and maintain a rigorous policy-management process. Since OS reassembly policies shift over time, defenders need a mechanism to keep the watcher in sync with the host under surveillance. Second, there should be an emphasis on testing in a single, context-agnostic mode that captures the host’s actual reassembly behaviors. In practice, that means mapping IP addresses to a host’s OS policy, or moving toward a flow-based policy approach rather than tying reassembly decisions to individual IP fragments. The goal is to reduce the risk that a detector’s view of traffic diverges meaningfully from what the host actually processes.
The paper’s authors also call for a broader, more systematic adoption of exhaustive overlap testing. Their Allen-based framework provides a blueprint for coverage that can be extended to more OS versions, more NIDS, and more nuanced network scenarios, including the impact of NIC offloading and middleboxes that can drop or reassemble fragments in flight. In short, this is not a one-off audit; it’s a framework for ongoing vigilance in a moving target landscape.
A human-centered note: who did this and why it matters to all of us
Behind the technical vocabulary lies a human-centered impulse: the desire to know that the wires and packets that connect us are being watched with honesty and rigor. The study is anchored in the work of researchers from Inria in Rennes, with key contributions from ANSSI in Paris and IMT Atlantique. The lead researchers—Lucas Aubard, Johan Mazel, Gilles Guette, and Pierre Chifflier—bring together a blend of systems thinking, formal modeling, and empirical testing that makes the results feel both robust and actionable. When they say that reassembly policies evolve over time, they are not just noting a quirk of software; they’re pointing to a dynamic security ecology in which defenders must continually reassess what they can safely trust and how they measure that trust.
There’s also a broader lesson for the cyber security community: the temptation to treat protocol behaviors as fixed can be dangerous. RFCs provide a map, but the terrain—how real systems implement those guidelines in production—often looks different. The authors’ insistence on exhaustiveness and cross-checking across OSes and NIDS is a reminder that complexity, not simplicity, is the friend of resilience in network security. It’s a call to humility as practitioners build detection pipelines, and to agility as engineers adapt to a landscape where a single misalignment can be exploited in dark corners of the internet.
Looking ahead: what comes next in the battle over fragment certainty
What happens after a study like this isn’t a single breakthrough but a shift in how the field thinks about defense-in-depth. The authors’ framework invites more researchers to extend exhaustiveness to other protocol variants, to additional operating systems, and to new generations of NIDS. It also nudges practitioners toward practical changes—prioritizing single-mode reassembly tests for baseline alignment, investing in policy configurability, and embracing flow-based reassembly policies that are less brittle in the face of shifting OS behavior.
On the front lines, organizations can take concrete steps: audit current NIDS configurations against their host OS realities, implement more robust reassembly policy mappings, and adopt ongoing, automated testing routines that keep pace with OS updates. In a world where a single fragment can carry a payload or trigger a cascade of misinterpretations, ensuring that the “way data is put back together” is common between systems isn’t just a niche concern; it’s a basic requirement for trustworthy digital infrastructure.
In short, the study reframes a quiet, technical dispute as a central security question: when overlaps happen, do we all see the same truth? The answer, at least for today, is: not always. And that discrepancy matters—because in the subtle math of bytes and checksums, reality is whatever the reassembled data says it is.
