1*4882a593Smuzhiyun.. SPDX-License-Identifier: GPL-2.0 2*4882a593Smuzhiyun 3*4882a593Smuzhiyun===== 4*4882a593SmuzhiyunIPsec 5*4882a593Smuzhiyun===== 6*4882a593Smuzhiyun 7*4882a593Smuzhiyun 8*4882a593SmuzhiyunHere documents known IPsec corner cases which need to be keep in mind when 9*4882a593Smuzhiyundeploy various IPsec configuration in real world production environment. 10*4882a593Smuzhiyun 11*4882a593Smuzhiyun1. IPcomp: 12*4882a593Smuzhiyun Small IP packet won't get compressed at sender, and failed on 13*4882a593Smuzhiyun policy check on receiver. 14*4882a593Smuzhiyun 15*4882a593SmuzhiyunQuote from RFC3173:: 16*4882a593Smuzhiyun 17*4882a593Smuzhiyun 2.2. Non-Expansion Policy 18*4882a593Smuzhiyun 19*4882a593Smuzhiyun If the total size of a compressed payload and the IPComp header, as 20*4882a593Smuzhiyun defined in section 3, is not smaller than the size of the original 21*4882a593Smuzhiyun payload, the IP datagram MUST be sent in the original non-compressed 22*4882a593Smuzhiyun form. To clarify: If an IP datagram is sent non-compressed, no 23*4882a593Smuzhiyun 24*4882a593Smuzhiyun IPComp header is added to the datagram. This policy ensures saving 25*4882a593Smuzhiyun the decompression processing cycles and avoiding incurring IP 26*4882a593Smuzhiyun datagram fragmentation when the expanded datagram is larger than the 27*4882a593Smuzhiyun MTU. 28*4882a593Smuzhiyun 29*4882a593Smuzhiyun Small IP datagrams are likely to expand as a result of compression. 30*4882a593Smuzhiyun Therefore, a numeric threshold should be applied before compression, 31*4882a593Smuzhiyun where IP datagrams of size smaller than the threshold are sent in the 32*4882a593Smuzhiyun original form without attempting compression. The numeric threshold 33*4882a593Smuzhiyun is implementation dependent. 34*4882a593Smuzhiyun 35*4882a593SmuzhiyunCurrent IPComp implementation is indeed by the book, while as in practice 36*4882a593Smuzhiyunwhen sending non-compressed packet to the peer (whether or not packet len 37*4882a593Smuzhiyunis smaller than the threshold or the compressed len is larger than original 38*4882a593Smuzhiyunpacket len), the packet is dropped when checking the policy as this packet 39*4882a593Smuzhiyunmatches the selector but not coming from any XFRM layer, i.e., with no 40*4882a593Smuzhiyunsecurity path. Such naked packet will not eventually make it to upper layer. 41*4882a593SmuzhiyunThe result is much more wired to the user when ping peer with different 42*4882a593Smuzhiyunpayload length. 43*4882a593Smuzhiyun 44*4882a593SmuzhiyunOne workaround is try to set "level use" for each policy if user observed 45*4882a593Smuzhiyunabove scenario. The consequence of doing so is small packet(uncompressed) 46*4882a593Smuzhiyunwill skip policy checking on receiver side. 47