Messages in this thread | | | From | Lorenzo Colitti <> | Date | Thu, 5 Nov 2020 13:52:01 +0900 | Subject | Re: [PATCH] xfrm:fragmented ipv4 tunnel packets in inner interface |
| |
On Tue, Sep 15, 2020 at 4:30 PM Steffen Klassert <steffen.klassert@secunet.com> wrote: > > In esp's tunnel mode,if inner interface is ipv4,outer is ipv4,one big > > packet which travels through tunnel will be fragmented with outer > > interface's mtu,peer server will remove tunnelled esp header and assemble > > them in big packet.After forwarding such packet to next endpoint,it will > > be dropped because of exceeding mtu or be returned ICMP(packet-too-big). > > What is the exact case where packets are dropped? Given that the packet > was fragmented (and reassembled), I'd assume the DF bit was not set. So > every router along the path is allowed to fragment again if needed.
In general, isn't it just suboptimal to rely on fragmentation if the sender already knows the packet is too big? That's why we have things like path MTU discovery (RFC 1191). Fragmentation is generally expensive, increases the chance of packet loss, and has historically caused lots of security vulnerabilities. Also, in real world networks, fragments sometimes just don't work, either because intermediate routers don't fragment, or because firewalls drop the fragments due to security reasons.
While it's possible in theory to ask these operators to configure their routers to fragment packets, that may not result in the network being fixed, due to hardware constraints, security policy or other reasons. Those operators may also be in a position to place requirements on devices that have to use their network. If the Linux stack does not work as is on these networks, then those devices will have to meet those requirements by making out-of-tree changes. It would be good to avoid that if there's a better solution (e.g., make this configurable via sysctl).
| |