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) |
Example
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
.