AGGFRAG Mode / IP-TFS (RFC 9347)

RFC 9347 defines a new Aggregation and Fragmentation Mode (AGGFRAG) for ESP and its use for IP Traffic Flow Security (IP-TFS).

This new AGGFRAG mode is like tunnel mode. But it provides facilities to aggregate smaller IP packets into a single AGGFRAG payload that’s sent in one ESP packet, as well as fragment large IP packets into multiple AGGFRAG payloads that are sent in separate ESP packets.

On top of that, IP-TFS adds Traffic Flow Confidentiality (TFC) by obscuring the size and frequency of IP traffic through fixed-size ESP packets sent at a constant rate. Compared to the classic TFC feature provided by ESP, which pads ESP packets containing a single IP packet (or just padding) to a fixed size, AGGFRAG adds the advantage that these fixed-size ESP packets may contain partial, whole, or multiple IP packets to maximize the bandwidth of the IPsec tunnel.

The Linux kernel supports the AGGFRAG mode since 6.14, strongSwan supports it since version 6.0.2. However, the Linux kernel currently only implements the basic aggregation and fragmentation features of the new mode. IP-TFS is not yet supported.

Configuration

To enable AGGFRAG mode in strongSwan, configure <child>.mode = iptfs. Currently, this mode is not enforced. So if the peer doesn’t support it, there is an automatic fallback to tunnel mode.

This mode can’t be combined with IP compression (IPComp) (<child>.ipcomp) or the classic TFC padding (<child>.tfc_padding).

There are several global settings related to IP-TFS/AGGFRAG configurable in strongswan.conf. They are located in the charon.iptfs section. Note that some settings apply only to inbound traffic (received/decrypted), while others apply only to outbound traffic (plaintext to be sent encrypted).

Key	Default	Description
charon.iptfs
drop_time	1000000	Time in microseconds to wait for out-of-order packets when processing inbound traffic (default 1 second)
reorder_window	3	Number of packets that may arrive out of order when processing inbound traffic
init_delay	0	Time in microseconds to wait for subsequent packets to aggregate together when sending outbound traffic. Only relevant if no packets are already queued to be sent
max_queue_size	1048576	Maximum number of bytes allowed to be queued for sending on the tunnel (default 1 MiB). If the queue is full, packets are dropped
packet_size	0	Maximum outer packet size (layer 3) when sending packets. The default of 0 will use the PMTU as packet size. Note that the kernel currently doesn’t pad smaller packets
accept_fragments	yes	Whether fragments of inner packets across multiple AGGFRAG payloads are accepted. This is an IKEv2 option, so if the peer doesn’t adhere to this request and still sends such fragments, they will be processed by the kernel
dont_frag	no	Force disabling fragmenting inner packets across multiple AGGFRAG payloads when sending outbound traffic (fragmentation is automatically disabled if the peer indicates that it doesn’t support handling such packets)

Key

Default

Description

charon.iptfs

drop_time

1000000

Time in microseconds to wait for out-of-order packets when processing inbound traffic (default 1 second)

reorder_window

Number of packets that may arrive out of order when processing inbound traffic

init_delay

Time in microseconds to wait for subsequent packets to aggregate together when sending outbound traffic. Only relevant if no packets are already queued to be sent

max_queue_size

1048576

Maximum number of bytes allowed to be queued for sending on the tunnel (default 1 MiB). If the queue is full, packets are dropped

packet_size

Maximum outer packet size (layer 3) when sending packets. The default of 0 will use the PMTU as packet size. Note that the kernel currently doesn’t pad smaller packets

accept_fragments

yes

Whether fragments of inner packets across multiple AGGFRAG payloads are accepted. This is an IKEv2 option, so if the peer doesn’t adhere to this request and still sends such fragments, they will be processed by the kernel

dont_frag

Force disabling fragmenting inner packets across multiple AGGFRAG payloads when sending outbound traffic (fragmentation is automatically disabled if the peer indicates that it doesn’t support handling such packets)

Example

Figure 1. strongSwan example showing the aggregation of IP packets into a single ESP packet

The net2net-iptfs test scenario shows an example of aggregating multiple small packets into a single ESP packet. Gateway moon has an AGGFRAG mode SA negotiated with gateway sun. It also has init_delay configured to wait longer for packets to aggregate. When host alice sends four pings to bob in short succession, all four ICMP requests are aggregated into a single ESP packet. Because the requests are decrypted and forwarded basically as one by gateway sun, the responses then arrive so close together that they are again aggregated into single ESP packet, even without having configured an explicit init_delay on sun.