Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux

xfrm: Add file to document IPsec corner case

Create Documentation/networking/ipsec.txt to document IPsec
corner issues and other info, which will be useful when user
deploying IPsec.

Signed-off-by: Fan Du <fan.du@windriver.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>

authored by

Fan Du and committed by
Steffen Klassert
b3c6efbc 776e9dd9

+38
+38
Documentation/networking/ipsec.txt
··· 1 + 2 + Here documents known IPsec corner cases which need to be keep in mind when 3 + deploy various IPsec configuration in real world production environment. 4 + 5 + 1. IPcomp: Small IP packet won't get compressed at sender, and failed on 6 + policy check on receiver. 7 + 8 + Quote from RFC3173: 9 + 2.2. Non-Expansion Policy 10 + 11 + If the total size of a compressed payload and the IPComp header, as 12 + defined in section 3, is not smaller than the size of the original 13 + payload, the IP datagram MUST be sent in the original non-compressed 14 + form. To clarify: If an IP datagram is sent non-compressed, no 15 + 16 + IPComp header is added to the datagram. This policy ensures saving 17 + the decompression processing cycles and avoiding incurring IP 18 + datagram fragmentation when the expanded datagram is larger than the 19 + MTU. 20 + 21 + Small IP datagrams are likely to expand as a result of compression. 22 + Therefore, a numeric threshold should be applied before compression, 23 + where IP datagrams of size smaller than the threshold are sent in the 24 + original form without attempting compression. The numeric threshold 25 + is implementation dependent. 26 + 27 + Current IPComp implementation is indeed by the book, while as in practice 28 + when sending non-compressed packet to the peer(whether or not packet len 29 + is smaller than the threshold or the compressed len is large than original 30 + packet len), the packet is dropped when checking the policy as this packet 31 + matches the selector but not coming from any XFRM layer, i.e., with no 32 + security path. Such naked packet will not eventually make it to upper layer. 33 + The result is much more wired to the user when ping peer with different 34 + payload length. 35 + 36 + One workaround is try to set "level use" for each policy if user observed 37 + above scenario. The consequence of doing so is small packet(uncompressed) 38 + will skip policy checking on receiver side.