Because the cost is not only encryption. Each packet also triggers repeated reads and writes across the TUN device and UDP socket, and those crossings consume CPU even when crypto is efficient. When packet size stays small, the system spends proportionally more time on kernel interaction and framing than on useful transport work.
Why small packets make userspace tunnels spend more time on overhead than payload
A userspace tunnel does not pay only for encryption. It also pays for every transition between packet buffers, the TUN interface, and the UDP socket. When packets stay small, those fixed costs dominate because the system repeats the same setup, copy, and framing work far more often for each unit of useful data.
Where the time goes in the packet path
The important cost is per-packet overhead, not just per-byte work. Each packet typically has to be read from the kernel side, processed in userspace, wrapped for transport, written back out, and then handled again on the receive path. Even if the crypto primitive is efficient, the tunnel still spends CPU on scheduling, syscalls, buffer movement, and protocol handling.
That means throughput can fall even when latency looks acceptable for a single packet. Small packets reduce the amount of payload carried by each pass through the path, so the fixed cost of moving the packet is spread across fewer bytes. The result is a lower efficiency curve as packet rate rises.
Why packet rate matters more than packet size in this case
For tunnels, packets per second often matter more than megabits per second. A stream of tiny packets can keep CPU busy with repeated entry and exit from the networking stack, while a smaller number of larger packets lets the same control work amortize over much more payload. That is why a tunnel may look “slow” under chattier traffic patterns even though raw bandwidth is not saturated.
This also explains why tuning can be counterintuitive. If you focus only on crypto speed, you may miss that the bottleneck is the userspace boundary itself. The TUN device and UDP socket are each separate touchpoints, so the overhead is cumulative, and it becomes visible fastest when the workload is highly fragmented.
Risk and Threat Considerations
Small-packet traffic can create a denial-of-service style efficiency problem even without an attacker. A tunnel that handles many tiny packets can burn disproportionate CPU on syscalls, copies, and framing, which reduces headroom for legitimate traffic and makes capacity harder to predict.
Failure mechanism: The packet path keeps paying fixed per-packet costs, but the payload per packet stays too small to amortize them. That raises interrupt, syscall, and buffer-handling pressure, and the tunnel saturates on packet rate before it saturates on bandwidth.
Impact: Latency rises, throughput falls, and the tunnel can become the performance bottleneck for otherwise modest traffic volumes. In congested or bursty environments, this can also distort autoscaling, capacity planning, and incident triage because the problem presents as “slow networking” rather than a single failing component.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Userspace tunnel overhead is tied to boundary-crossing traffic handling and packet-path control. |
| Recommendation — Tune boundary controls to reduce unnecessary per-packet processing and preserve throughput. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Tunnel performance depends on efficient network-path management and traffic handling. |
| Recommendation — Monitor tunnel packet rates and capacity so small-packet workloads do not exhaust CPU. | ||
| NIST CSF 2.0 | PR.PS-01 — Configuration Management | Packet efficiency improves when tunnel and transport settings are configured to avoid avoidable overhead. |
| Recommendation — Configure tunnel transport to minimise fragmentation and repeated packet-processing overhead. | ||
Practitioner Guidance
What to measure: Track packets per second, not just bits per second, and compare CPU time spent in the tunnel path against payload volume. If CPU rises much faster than throughput, the workload is packet-rate bound rather than crypto-bound.
What to verify: Check whether the tunnel can coalesce or carry larger frames without fragmenting them elsewhere, and confirm that the sender is not generating avoidable tiny writes, control chatter, or application-level message fragmentation. If the workload is naturally chatty, treat packet rate as a first-class sizing input.
Practitioner takeaway: For userspace tunnels, the main question is usually not “Is encryption fast enough?” but “How many times per second are we paying the tunnel boundary cost?”
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
