162306a36Sopenharmony_ci.. SPDX-License-Identifier: GPL-2.0 262306a36Sopenharmony_ci 362306a36Sopenharmony_ci===== 462306a36Sopenharmony_ciIPsec 562306a36Sopenharmony_ci===== 662306a36Sopenharmony_ci 762306a36Sopenharmony_ci 862306a36Sopenharmony_ciHere documents known IPsec corner cases which need to be keep in mind when 962306a36Sopenharmony_cideploy various IPsec configuration in real world production environment. 1062306a36Sopenharmony_ci 1162306a36Sopenharmony_ci1. IPcomp: 1262306a36Sopenharmony_ci Small IP packet won't get compressed at sender, and failed on 1362306a36Sopenharmony_ci policy check on receiver. 1462306a36Sopenharmony_ci 1562306a36Sopenharmony_ciQuote from RFC3173:: 1662306a36Sopenharmony_ci 1762306a36Sopenharmony_ci 2.2. Non-Expansion Policy 1862306a36Sopenharmony_ci 1962306a36Sopenharmony_ci If the total size of a compressed payload and the IPComp header, as 2062306a36Sopenharmony_ci defined in section 3, is not smaller than the size of the original 2162306a36Sopenharmony_ci payload, the IP datagram MUST be sent in the original non-compressed 2262306a36Sopenharmony_ci form. To clarify: If an IP datagram is sent non-compressed, no 2362306a36Sopenharmony_ci 2462306a36Sopenharmony_ci IPComp header is added to the datagram. This policy ensures saving 2562306a36Sopenharmony_ci the decompression processing cycles and avoiding incurring IP 2662306a36Sopenharmony_ci datagram fragmentation when the expanded datagram is larger than the 2762306a36Sopenharmony_ci MTU. 2862306a36Sopenharmony_ci 2962306a36Sopenharmony_ci Small IP datagrams are likely to expand as a result of compression. 3062306a36Sopenharmony_ci Therefore, a numeric threshold should be applied before compression, 3162306a36Sopenharmony_ci where IP datagrams of size smaller than the threshold are sent in the 3262306a36Sopenharmony_ci original form without attempting compression. The numeric threshold 3362306a36Sopenharmony_ci is implementation dependent. 3462306a36Sopenharmony_ci 3562306a36Sopenharmony_ciCurrent IPComp implementation is indeed by the book, while as in practice 3662306a36Sopenharmony_ciwhen sending non-compressed packet to the peer (whether or not packet len 3762306a36Sopenharmony_ciis smaller than the threshold or the compressed len is larger than original 3862306a36Sopenharmony_cipacket len), the packet is dropped when checking the policy as this packet 3962306a36Sopenharmony_cimatches the selector but not coming from any XFRM layer, i.e., with no 4062306a36Sopenharmony_cisecurity path. Such naked packet will not eventually make it to upper layer. 4162306a36Sopenharmony_ciThe result is much more wired to the user when ping peer with different 4262306a36Sopenharmony_cipayload length. 4362306a36Sopenharmony_ci 4462306a36Sopenharmony_ciOne workaround is try to set "level use" for each policy if user observed 4562306a36Sopenharmony_ciabove scenario. The consequence of doing so is small packet(uncompressed) 4662306a36Sopenharmony_ciwill skip policy checking on receiver side. 47