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
