- 1A rated interface is not an encrypted-throughput guarantee. Port speed describes I/O capability; it does not prove IPsec processing capacity.
- 2Packet rate can matter as much as bit rate. A fixed amount of work is performed for each packet, while cipher work also grows with bytes processed.
- 3Tunnel scale and traffic scale are different dimensions. An idle SA consumes state; an active SA consumes state plus data-plane and often cache resources.
- 4Offload must be evaluated as a complete data path. Moving cipher operations does not remove bottlenecks in lookup, replay protection, memory, I/O, or scheduling.
- 5A credible test reports the envelope, not one peak. Minimum packet size, IMIX, MTU, directionality, latency percentiles, loss, tunnel count, rekey, and failover all belong in the result.
A Security Gateway can have a fast network interface and still fail to deliver predictable encrypted throughput. The reason is simple: IPsec performance is a pipeline outcome, not a port-speed specification. Packet parsing, security-policy and Security Association (SA) lookup, encryption and authentication, anti-replay state, memory movement, routing, and egress all have to keep pace at the same time.
Do not buy a “Gbps” number. Buy a demonstrated performance envelope across packet sizes, tunnel counts, bidirectional traffic, rekey events, failover, and the security features you will actually enable.
5G does not create one universal traffic profile. A RAN transport link may carry large user-plane packets, bursts of small control packets, real-time flows, encapsulation overhead, and many concurrent tunnels. The dangerous condition is therefore not “5G traffic” in the abstract — it is the combination of high packet rate, sustained utilization, state scale, and strict latency or loss objectives.
Hardware acceleration can materially expand capacity, but it is not a magic line-rate switch. It helps only when the software data path, accelerator queues, memory subsystem, NUMA placement, NIC I/O, SA distribution, and control plane are engineered as one system. The correct question is not “Does the appliance have acceleration?” It is “What does the complete gateway sustain under our traffic model — and how was that result measured?”
01 · First, Define the Security Boundary Correctly
In mobile networks, IPsec protects selected network-domain interfaces when transport cannot otherwise be trusted. 3GPP specifications describe Network Domain Security at the IP layer[4] and allow a Security Gateway (SEG/SecGW) to terminate IPsec tunnels[1] in relevant deployments. The exact interfaces and mandatory-versus-optional protections depend on architecture, release, and deployment assumptions[5]; a blanket statement that every RAN-to-core packet is always encrypted would be inaccurate.
At a practical boundary, the SecGW authenticates peers, applies security policy, terminates or originates IPsec SAs, enforces anti-replay protection, and forwards permitted traffic toward the core or RAN. IKEv2 commonly manages authentication and SA establishment[3]; ESP supplies confidentiality and/or integrity for protected packets[2]. This creates both a control-plane scaling problem and a data-plane scaling problem.
A SecGW is not merely a “bigger VPN.” Its design target is a mobile-network trust boundary with many peers, sustained traffic, deterministic operations, and carrier-grade availability.
02 · Why the Datasheet Number Breaks Down
A headline throughput figure is normally measured under a particular set of conditions. Change the packet size, cipher suite, number of SAs, traffic direction, enabled features, core count, or loss criterion, and the result can change sharply. Without the test conditions, “100 Gbps IPsec” is not a reproducible engineering claim.
Packet rate changes the work per gigabit
IPsec processing contains both per-packet work and per-byte work. Per-packet work includes classification, policy/SA lookup, descriptor handling, sequence-number and replay-window processing, and enqueue/dequeue operations. Cryptographic computation and memory movement also scale with the number of bytes. This is why neither “cost is per packet” nor “cost is per byte” is sufficient by itself.
Sustained load exposes queueing
As offered load approaches the capacity of any pipeline stage, queues deepen. Average latency can remain deceptively acceptable while tail latency rises; once buffers fill, drops follow. The delivered-throughput curve may plateau, but it does not inherently “dip.” A decline can occur because of overload behavior, cache thrashing, thermal or frequency effects, retransmissions, or measurement method — but it must be observed, not assumed (see Figure 1).
03 · The Real Bottleneck Is the Whole IPsec Pipeline
The familiar “CPU versus hardware” story is useful but incomplete. Modern software paths may already use CPU cryptographic instructions, vectorized libraries, batching, kernel bypass, or smart-NIC capabilities[6]. Conversely, a platform with a dedicated accelerator can still miss its target if packets are copied too often, queues are poorly balanced, or SA state lands on the wrong NUMA node.
Where capacity is commonly lost
◆Ingress and parsing
NIC receive queues, burst handling, encapsulation, fragmentation, checksum work, and packet classification can limit packet rate before crypto begins.
◆Policy and SA lookup
Large policy databases, cache misses, hashing behavior, and uneven flows can make a high tunnel count materially different from a single-tunnel benchmark.
◆Cryptography
Cipher and integrity operations consume CPU cycles or accelerator capacity. Algorithm choice, key size, direction, and batch size change results.
◆State and ordering
Sequence numbers, anti-replay windows, inbound verification, and per-SA ordering can constrain parallelism and create hot SAs.
◆Memory and interconnect
Packet copies, cache pressure, DMA, PCIe bandwidth, NUMA placement, and accelerator queue contention can erase theoretical gains.
◆Egress and services
Routing, QoS, ACLs, NAT where applicable, telemetry, logging, and NIC transmit scheduling still consume resources.
High CPU is evidence of saturation, not proof that software cryptography alone is the cause. Inspect per-core use, queue depth, drops, accelerator utilization, memory/NUMA counters, NIC statistics, and SA distribution together.
04 · What Hardware Acceleration Actually Changes
Acceleration exists on a spectrum, not a switch. CPU instruction sets accelerate primitive operations while the application still runs on general-purpose cores. Optimized multi-buffer libraries process several operations in parallel. Lookaside accelerators accept crypto jobs and return results, introducing queueing and DMA considerations[8]. Inline-capable NICs may apply IPsec closer to the packet I/O path. Each model changes the resource budget and software architecture differently.
Power efficiency needs the same discipline
Power should be reported as a system measurement — not merely an accelerator specification. Compare watts at idle and at defined encrypted loads, then calculate useful protected throughput per watt. Include the server, NICs, accelerator, memory, and cooling assumptions. A platform that reaches a peak result only with many underutilized cores may look fast but remain operationally inefficient.
05 · A 5G-Relevant Validation Method
The goal of a proof of concept is to map the operating envelope, including the point where service objectives stop being met. Run a matrix instead of a single “hero” test, and retain the raw configuration and results so another team can reproduce them.
Define the deployment model. Specify protected interfaces, topology, active/standby or active/active behavior, expected peers, routing, MTU, QoS, and all enabled security functions.
Build a traffic model. Use minimum-size stress, one or more fixed sizes, a documented IMIX, and an application-representative mix. Include uplink/downlink asymmetry and burst behavior where relevant.
Sweep scale independently. Test throughput across active SA counts and also test many idle tunnels. Include a hot-SA case and a broadly distributed-flow case.
Exercise lifecycle events. Measure IKE establishment rate, concurrent rekeys, peer churn, certificate validation, policy updates, and recovery after restart.
Measure service quality. Report offered load, delivered goodput, packet loss, mean and p50/p95/p99 latency, jitter, reorder events, CPU/core use, accelerator use, memory, NIC/queue counters, and watts.
Test failure behavior. Validate node or link failure, state synchronization, tunnel continuity, convergence time, overload protection, and any fallback from hardware to software processing.
Minimum results to require in any report
Set a maximum offered load only where loss and latency remain inside the service objective. “Line rate” with unacceptable drops or tail latency is not a passing result.
06 · Warning Signs in Production
- Headroom disappears at busy hour. Delivered goodput flattens while queue depth, tail latency, or drops rise.
- One direction underperforms. Inbound anti-replay, verification, flow distribution, or queue placement may be limiting the receive path.
- A few tunnels dominate. Aggregate capacity looks healthy, but hot SAs overload individual cores or serialized state paths.
- Rekeys create periodic degradation. Control-plane bursts, accelerator session updates, or poor staggering collide with peak traffic.
- Failover changes the envelope. The surviving node lacks N+1 capacity, SA state is incomplete, or traffic rehashing becomes uneven.
- Watts rise faster than protected capacity. Core scaling is inefficient, or the data path is missing acceleration, locality, or batching opportunities.
These symptoms should trigger profiling, not an automatic hardware purchase. The remediation might be acceleration — but it might also be NUMA affinity, queue rebalancing, a better crypto library, fewer packet copies, MTU correction, SA sharding, or policy/logging changes.
07 · How to Evaluate a Carrier-Grade SecGW
A purpose-built gateway should be assessed as a secure, available network function — not only as a crypto benchmark. Ask vendors to demonstrate performance with configurations that match your deployment.
GSMA NESAS[7] can contribute evidence about product development and lifecycle security assurance; it is not an IPsec performance certification. Keep security assurance and performance validation as separate workstreams — then require both to pass.
08 · The Nybsys Aegis Design Question
For Aegis Security Gateway, the strongest position is not simply “hardware acceleration is faster.” It is that the gateway is engineered around the actual SecGW operating envelope: large distributed peer populations, sustained encrypted traffic, predictable service under load, operational visibility, and efficient deployment at a mobile-network trust boundary.
Any published comparative claim — throughput, tunnel scale, latency, power, or advantage over conventional gateways — should appear beside a concise test disclosure: compared products or baseline class, hardware and software versions, cipher suite, packet mix, active tunnel count, traffic direction, enabled features, loss/latency threshold, test duration, and power boundary. That disclosure converts marketing language into evidence an architect can trust.
Bring Us Your Traffic Model, Not a Benchmark Request
Bring Nybsys your expected packet mix, tunnel count, availability model, and service objectives. The right demonstration is not a canned peak-throughput run — it is a reproducible test of your intended operating envelope.
Explore Nybsys Aegis Security Gateway →Conclusion
IPsec does not fail under 5G load because the standard is inadequate or because every mobile packet is small. It fails when one stage of a stateful packet-processing system runs out of sustainable capacity — and the test plan fails to reveal that limit before deployment.
The practical answer is disciplined system engineering: characterize packet rate as well as bit rate; separate SA scale from active-traffic scale; understand what is accelerated; balance CPU, memory, NIC, queues, and accelerator resources; measure tail latency and loss; and validate rekey and failover at load. When a SecGW passes that test, its performance claim becomes an operating fact rather than a datasheet promise.
Frequently Asked Questions
Why doesn't a gateway's rated interface speed guarantee IPsec throughput?+
Because the interface only describes I/O capability. Encrypted throughput is set by the slowest sustained stage of the whole pipeline — parsing, policy/SA lookup, cipher and integrity work, anti-replay state, memory movement, and egress. If any of those saturates before the port does, throughput plateaus regardless of the rated line speed.
Is small-packet traffic really harder for IPsec than large-packet traffic?+
Usually, yes — but for a precise reason. IPsec has fixed per-packet work (classification, lookup, sequence and replay handling, queueing) plus per-byte work (cipher, integrity, memory movement). At the same bit rate, small packets multiply the per-packet events — 64-byte packets at 10 Gbps demand roughly 23× the packet operations of 1,500-byte packets — while ESP overhead also consumes proportionally more of each small packet.
Does hardware acceleration guarantee higher IPsec throughput?+
It can — conditionally. Acceleration raises capacity when crypto is the limiting resource and the complete data path is balanced: accelerator queues, DMA, PCIe and NUMA placement, SA distribution, and fallback paths all engineered together. It does not guarantee line rate, constant latency, or linear scaling across all packet sizes and tunnel counts.
How do I diagnose whether software crypto is my IPsec bottleneck?+
Correlate telemetry rather than trusting one counter. High CPU is evidence of saturation, not proof of a software-crypto cause. Look at per-core utilization, queue depths, drop counters, accelerator utilization, memory and NUMA statistics, NIC counters, and per-SA distribution together — then profile before purchasing.
What test conditions make an IPsec throughput result credible and reproducible?+
The test conditions that make it reproducible: packet size or exact IMIX, cipher suite and MTU, active and configured SA counts, traffic direction and flow distribution, loss and p50/p95/p99 latency, features enabled, platform configuration, steady-state duration, and the power measurement boundary.
Does GSMA NESAS certify IPsec performance?+
No. NESAS provides security assurance evidence about a vendor's development and product lifecycle processes. It says nothing about IPsec throughput. Treat security assurance and performance validation as separate workstreams and require both.
References
- IETF RFC 4301 — Security Architecture for the Internet Protocol. Defines the IPsec architecture, SPD/SAD model, and processing rules. datatracker.ietf.org/doc/html/rfc4301
- IETF RFC 4303 — IP Encapsulating Security Payload (ESP). Specifies ESP encapsulation, overhead, sequence numbers, and anti-replay behavior. datatracker.ietf.org/doc/html/rfc4303
- IETF RFC 7296 — Internet Key Exchange Protocol Version 2 (IKEv2). Governs authentication, SA establishment, and rekeying at the control plane. datatracker.ietf.org/doc/html/rfc7296
- 3GPP TS 33.210 — Network Domain Security; IP network layer security. Defines NDS/IP and the Security Gateway (SEG) role at network-domain boundaries. 3gpp.org/DynaReport/33210.htm
- 3GPP TS 33.501 — Security architecture and procedures for the 5G System. Specifies 5G security architecture, including transport protection assumptions. 3gpp.org/DynaReport/33501.htm
- DPDK Programmer's Guide — Cryptography and Security libraries. Documents software data-path, cryptodev, and inline-security programming models. doc.dpdk.org/guides/prog_guide/
- GSMA NESAS — Network Equipment Security Assurance Scheme. Security assurance for vendor processes — cited here as assurance, not performance, evidence. gsma.com/security/network-equipment-security-assurance-scheme
- Intel QuickAssist Technology documentation. Example of a lookaside crypto-acceleration model and its integration considerations. intel.com — QuickAssist Technology overview