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