IPsec

本文件介紹了一些已知的IPsec極端情況，在真實世界的生產環境中部署各種IPsec配置時需要牢記這些情況。

1. IPcomp

   較小的IP資料包在傳送方不會被壓縮，並且在接收方進行策略檢查時會失敗。

引用自RFC3173

2.2. Non-Expansion Policy

 If the total size of a compressed payload and the IPComp header, as
 defined in section 3, is not smaller than the size of the original
 payload, the IP datagram MUST be sent in the original non-compressed
 form.  To clarify: If an IP datagram is sent non-compressed, no

 IPComp header is added to the datagram.  This policy ensures saving
 the decompression processing cycles and avoiding incurring IP
 datagram fragmentation when the expanded datagram is larger than the
 MTU.

 Small IP datagrams are likely to expand as a result of compression.
 Therefore, a numeric threshold should be applied before compression,
 where IP datagrams of size smaller than the threshold are sent in the
 original form without attempting compression.  The numeric threshold
 is implementation dependent.

當前的IPComp實現確實符合規範，但在實踐中，當向對等方傳送未壓縮的資料包時（無論資料包長度是否小於閾值，或者壓縮後的長度是否大於原始資料包長度），在檢查策略時會丟棄該資料包，因為該資料包符合選擇器，但不是來自任何XFRM層，即沒有安全路徑。 這樣的裸資料包最終不會到達上層。 當使用不同的有效負載長度 ping 對等方時，使用者會發現結果更加混亂。

一種解決方法是，如果使用者觀察到上述情況，請嘗試為每個策略設定“級別使用”。 這樣做會導致小資料包（未壓縮）跳過接收方側的策略檢查。