Fan Du | b3c6efb | 2013-12-16 18:47:50 +0800 | [diff] [blame] | 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 |
Olivier Gayot | bb38ccc | 2018-06-04 12:07:37 +0200 | [diff] [blame] | 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 larger than original |
Fan Du | b3c6efb | 2013-12-16 18:47:50 +0800 | [diff] [blame] | 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. |