On Tue, 1 Aug 2023, Daniel Migault wrote: [The quoting got mangled in Daniel's message]
If an incoming Encrypted packet is larger than the Link MTU How can than be? You mean you received an ESP or ESPinUDP that after decrypting was too large for the link you need to send the decrypted packet on? That seems really odd. I was trying to mention the very basic use of ICMP PTB here. There is no decryption at that point, that is if an IP packet IP/ESP or IP/UDP/ESP is larger than the link MTU, an ICMP PTB will be sent.
But before decryption, when using tunnel mode, you wouldn't know which interface to send the packet to, so you don't know yet if it is too big or not. So that makes me understand this use case even less.
an ICMP PTB is sent, otherwise the packet is accepted. If fragments are received, a reassembly operation happens and the packet may be too large to be built or decrypted. What is this “too large to decrypt” scenario ? Can you give more details? The reassembled packet is larger than EMTU_R for example.
EMTU_R you defined as "effective MTU to receive". As you received fragments that fit that mtu, why does it matter what the reassembled packet size is? It would only matter if you would (after successfull decryption), need to send the packet back over the same interface. My problem is that between Daniel and Joel explanations, I still haven't managed to understand the actual problem, so I have a really hard time understanding the proposed fix and whether it really would solve something. As Joe Touch wrote in January: The abstract clearly states a goal that is not achievable (of avoiding reassembly). The best way to avoid the impact of mid-tunnel fragmentation is to use IPv4 as a tunnel header the way that IPv6 would be - with DF=1. However, even so, the egress always needs to handle reasssembly as long as there is even source fragmentation. I appreciate what you WANT to do - but again, it is not possible. You have two behaviors - either use inner fragmentation (which won’t work for transit traffic where IPv4 DF=1 or any IPv6) or reduce the tunnel MTU. But the tunnel MTU is defined by EMTU_R of the tunnel egress, not EMTU_S of the tunnel ingress. If you reduce the tunnel MTU, you’re just going to end up black-holing packets arriving at the tunnel ingress. Two important points: the tunnel ingress is NOT the one that should ever send PTB back; that’s the job of the router where/if that tunnel ingress resides; second, you cannot claim to get around an ICMP black hole situation by creating a new ICMP black hole situation. Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec