On Wed, 23 Feb 2022, Harold Liu wrote:
Recently we ran into a real problem in some IPsec use case - In customer application scenarios, ESP packets are fragmented, which causes many problems - Including performance problems, device resource problems, and even traffic loss (In customer use case, it is IPsec over NAT scenarios so ESP packets are encapsulated by UDP. Therefore, except for the initial fragment that contains complete UDP header, other fragments can only indicate UDP protocol in the IP address, but do not have UDP header. Therefore, they may be incorrectly identified by other applications and captured - The fragmented IP payload is regarded as a UDP header. ESP cannot be reassembled and the package is lost).
When this happens, the application should be missing its packets, eg TCP or UDP and could reduce its MTU based on that as well. In other words, why would we want a second mechanism to do this, where these two mechanisms could end up fighting.
The below announcement is that draft. We would like to work with the community to improve and clarify tech draft.
Some concerns: - What if a malicious entity able to filter on path would "fragment" the packet into tiny bits. It would reduce the MTU of the IPsec link to unhealthy size. There should be a minimum defined - As paths over the internet change, this draft can kick in to reduce the size, but I see no method to go back to a larger size once the path between the endpoints recovers again. - How does this interact with ESP padding ? - I can see applications just sending a 1200 MTU request "just to make it always work", which basically means a few years down the line, everyone ends up with reduced MTU. This is what happened with IPsec/L2TP where the ppp interface is basically 1200 everywhere. Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
