On Wed, Aug 2, 2023 at 11:28 AM Paul Wouters <p...@nohats.ca> wrote:
> 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. > > We want to avoid fragmentation but fragmentation remains supported. EMTU_R is sent as an information to the peer that the fragmented packet has not been handled by the egress gateway. > 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. > > I think this is normal as these are two unrelated use cases/concerns. Joel was describing DSCP being used as a pseudo traffic selector. https://datatracker.ietf.org/doc/draft-mglt-ipsecme-ts-dscp/ > 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. > > > I am happy to understand why you think we do avoid reassembly. At least on our side it solves our issue. > Paul > -- Daniel Migault Ericsson
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
