Considerations for Adjustments of Encapsulating Security Payload (ESP) Trailer

Introduction IPsec is widely used to provide security for IP communications. It can adapt to various scenarios with the two protocols of AH and ESP and the two modes of tunnel and transport. For example, IPsec can create a secure tunnel between two gateways to protect traffic between sites, such as between an enterprise's branch and its headquarters and between data centers. IPsec has an impact on forwarding performance due to the increased overhead of encryption and decryption processing of IP packets. Hence, the performance improvement of IPsec has been a significant concern in the industry, especially in the above scenarios where the original traffic rate is considerably high. There have been some different approaches to address the performance issues of IPsec. One is to use more efficient cryptographic algorithms. For example, using the AES-GCM algorithm provides the same level of security as the AES-CBC algorithm but is more efficient. Another is to use cryptographic hardware acceleration. Hardware accelerators use specialized hardware to perform encryption and decryption operations (other operations of IPsec remain being implemented by software). MACsec is a Layer 2 security protocol that provides security for networks like data centers and enterprise networks. Since the requirement of hop-by-hop deployment, MACsec is more complex to deploy when compared to IPsec, but it has the distinct advantage of high forwarding performance, which can even reach the line rate. One important reason is that the entire MACsec process (not just encryption and decryption processing) is implemented by hardware. Similarly, utilizing hardware to implement the whole IPsec process is also an effective means to improve IPsec performance. However, the position of the ESP trailer in the IPsec ESP-encapsulated packets poses a new overhead challenge for implementing IPsec in hardware.

Problem Statement Implementing IPsec in hardware is an ideal way to improve performance, but it is also expensive. Not to mention the cost of designing and manufacturing the hardware, IPsec ESP imposes additional costs on the hardware due to its protocol design. The IPsec ESP protocol places the Next Header and Padding in the ESP trailer at the end of the packet. Based on the current design, after processing the plain text of the IPsec ESP packet ( ESP Header and the content before ), the (receiving) hardware can't use the manner of "decrypting and then transmitting" to deal with the Payload Data. It must cache the decrypted payload because it doesn't know how to reorganize the packet header before the payload, until it gets the Next Header and Padding information from the ESP trailer. For example, in the ESP tunnel mode, the EtherType field in the Ethernet frame should be set according to whether the inner packet is IPv4 or IPv6. In another example, in the ESP transport mode, the length field in the IP header should be adjusted according to the Padding length. Such a requirement for caching payload is at a considerable cost to the hardware chip, including increased chip area and packet processing latency. A larger chip area means greater power consumption, which is not eco-friendly and not in line with the current trend towards green energy efficiency.

Possible Solution Suppose the Next Header and Padding information can be obtained immediately after processing the ESP Header, even in the cipher text. In that case, the hardware can perform all operations sequentially without additional caching. The possible solutions to accomplish this goal are listed below.

Simplified Next Header Judgment in ESP Tunnel Mode In ESP tunnel mode, the inner payload is usually an IPv4 or IPv6 packet, and the first byte of both types of packets indicates the IP protocol version (4 for IPv4, 6 for IPv6). Therefore, instead of determining the protocol type of inner payload based on the Next Header field in the ESP trailer, one possible solution is to decrypt the first byte after the ESP Header and determine whether the inner payload is IPv4 or IPv6 based on the value of that byte. However, the ESP protocol describes the behavior of sending and discarding the dummy packet in support of traffic flow confidentiality. The dummy packet is generated by the sender by randomly generating a payload and discarded by the receiver by recognizing the value of 59 in the Next Header field. Since the payload is randomly generated, the value of its first byte maybe 4 or 6, which will cause the receiver to misjudge when this simplified Next Header judgment method is used. In an enterprise or data center network scenario, the two gateways usually do not send the dummy packet after establishing an ESP tunnel. Therefore, this simplified judgment is a relatively practical solution in these scenarios. To be on the safe side, adding a new negotiation between the two gateways can be considered, i.e., to negotiate not sending dummy packets when creating a Child SA in IKEv2 .

Adjust ESP Packet Format Another solution is to change the ESP packet format by moving the ESP trailer's position to right after the ESP Header, still retaining encryption on the ESP trailer.

New ESP Packet Format For the consideration of compatibility, the IPsec peers need to explicitly negotiate the use of this new ESP format when creating the Child SA. This solution works not only for ESP tunnel mode but also for ESP transport mode. However, accordingly, it has more changes to the protocol.

Security Considerations TBD

IANA Considerations TBD