Optimize NanoSec IPsec
This section discusses optimizing the NanoSec IPsec for better performance and security. It includes recommendations on buffer padding and MTU adjustments to handle additional headers and minimize packet fragmentation, essential for maintaining efficient network operations.
Buffer padding
TrustCore SDK recommends adding a buffer pad when allocating memory for outbound IP buffers (see Table 6). IP stacks generally have a single point for allocating IP buffers. Typically, 65 bytes of pad should suffice for transport mode, and 85 bytes for tunnel mode. If an outbound packet is to be protected, which requires ESP/AH/IP headers to be added, then the packet size increases.
For cases where the TCP/IP stack performs fragmentation after IPsec outbound processing (as discussed in Bump in the Stack (BITS) Insertion), packets get fragmented if their size exceeds the MTU, which is detrimental to network operation. To avoid such fragmentation, adjust the MTU to an appropriate smaller value.
The MTU setting can also be used to eliminate the possibility of fragmentation by the TCP/IP stack (such as, for Below Binary Stack (BBS) Implementation). For such cases, the MTU should be set to the maximum packet size.
The table below shows that ESP with authentication increases the packet size by 37 bytes (53 bytes if AES is used for encryption); AH plus ESP requires an additional 49 bytes (65 for AES). In addition, if tunnel mode is applied then an outer IP header of 20 bytes is also added. Due to this packet size increase, the MTU should be decreased accordingly so that the upper transport layer does not pass down a packet that could be larger than the original allowable MTU.
Header Type | Header Size | ICV Size (for SHA1 and MD5) | Encryption Size | Max Encryption Trailer Size | Total |
|---|---|---|---|---|---|
AH | 12 | 12 | 24 | ||
ESP | 8 | 8 | 9 | 25 | |
ESP-AES | 8 | 16 | 17 | 41 | |
ESP with authentication | 8 | 12 | 8 | 9 | 37 |
ESP-AES with authentication | 8 | 12 | 16 | 17 | 53 |
ESP_NULL | 8 | 12 | 2 | 22 | |
IP (tunnel) | 20 | 20 |
Packet processing context
Moving all incoming packet handling from the interface driver (interrupt service routine) to a kernel or application thread context greatly improves IPsec processing performance. If IPsec is too busy decrypting and checking data integrity within the context of an interface driver, packets may be lost and require retransmission.
For hardware accelerators, packet processing should be moved outside the context of any interrupt service routines because most hardware accelerators use interrupts to notify when cryptographic operations have completed. For more information about working with hardware accelerators, see Is Hardware Acceleration Supported?.