I am finding more and more benefits of doing 'red side' fragmentation in Ipsec worl.
One use case is given here: With red side fragmentation, any switches/routers in between security gateways of tunnels don't see fragmented packets. Due to this the cases, where some service providers' routers give less priority to the fragmented packets, don't arise.
Second use case is given here : When majority of the traffic goes on IPsec tunnels, LAG can't distribute the traffic across ports since the result traffic has same 5-tuple information. As described in the post, multiple IPsec tunnels normally get created with forceful NAT-T. All packets that are coming out of Ipsec Engine are expected to have 5 tuple information. If fragmentation is done after Encap, then the LAG would see some packets without 5-tuples. This results to uneven distribution. Hence redside fragmentation is done to ensure that LAG sees 5-tuples for all the packets.
Third use case: Avoid mis-ordering of the packets:
There could be packets which are big and small in the traffic. Big packets may get fragmented after Ipsec encapsulation if the result size exceeds the MTU of outgoing interface. Small packets may not get fragmented even after encapsulation.
Gateway receiving the Ipsec packets is expected to process them in order. Due to fragmented packets, this may not happen. Let us say that, gateway received 1st fragment of 1st packet, 2nd full packet and 2nd and also final fragment of 1st packet in that order. It is expected that the gateway processes them in the same order. But since 1st packet waits for 2nd fragment, 2nd full packet would be processed. Gateways don't stop the full packets getting processed as it may not know whether or not second fragment of the 1st packet is going to come in and also when it is going to come in.
So, this leads to packet mis-order.
This can be avoided if there are no fragments. Solution : Red side fragmentation.