IP Payload Compression (IPComp) is a protocol that allows compressing the content of IP packets. It's defined in RFC 3173.
It may be combined with IPsec to provide compression before encryption (making up for some of the overhead introduced by IPsec itself). To use it both peers have to support it and it must be negotiated during IKE. strongSwan currently only supports DEFLATE as compression algorithm.
When debugging connections that use IPComp on Linux there are some things to be aware of.
For packets smaller than a certain threshold the kernel does not do any compression (e.g. default-sized pings for IPv4). To handle uncompressed packets in tunnel mode the kernel will implicitly create an IPIP tunnel besides the actual IPComp SAs. These IPIP states can be seen in
ip xfrm state with
proto 4. For IPv6 the kernel also creates such states -
proto 41 - but since the compression threshold is relatively low and IPv6 packets are naturally larger even default-sized pings are compressed. These IPIP tunnels also have an impact on the firewall rules that are installed with leftfirewall=yes (some issues were fixed with 5.1.2 and for IPv6 with 5.4.0) or manually, as IPIP traffic has to be allowed explicitly in the INPUT chain.
Due to how the six states (IPsec, IPComp, IPIP, in- and outbound each) are used, the traffic counters (bytes, packets) seen in
ip -s xfrm state might look a bit confusing at first:
- For outbound traffic the IPIP state is not used, instead all traffic directly goes through the outbound IPComp and IPsec SAs. The kernel will simply not perform any compression for small packets (the byte and packet counters of the IPComp SA are still increased, though). The thresholds are statically defined in
net/xfrm/xfrm_algo.cfor each compression algorithm. For deflate it is 90 bytes.
- For the inbound traffic, on the other hand, the traffic counters for the IPComp SAs are accurate and only count actually decompressed traffic. The other packets pass through the implicitly created IPIP tunnel, increasing its traffic counters.
So on carol the packet and byte counts for all six states are as follows:
|ESP out||173||2||The larger ping request got highly compressed as it basically contains the same data repeated over and over|
|IPComp out||8296||2||Only one packet of these actually gets compressed|
|IPIP out||0||0||Not used|
|IPComp in||8212||1||For the compressed ping reply|
|IPIP in||84||1||For the uncompressed ping reply|
The IPComp/IPsec packet processing in the kernel may be visualized as follows:
len < threshold +---------+ no header +---------+ outbound--->|IPComp SA|----------------->| ESP SA |---> +----+----+ +----+----+ | /----------\ | len >= threshold +------->| compress |--------+ IPComp header \----------/ added +---------+ +---------+ <--------+--------| IPIP |<---| ESP SA |<---inbound | +---------+ +----+----+ | +---------+ | +--------|IPComp SA|<--------+ IPComp header +---------+ found