From patchwork Sun Mar 17 23:37:55 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bram Yvakh X-Patchwork-Id: 1057625 Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=mail.wizbit.be Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 44MwzM4hzFz9s47 for ; Mon, 18 Mar 2019 10:50:07 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727529AbfCQXpS (ORCPT ); Sun, 17 Mar 2019 19:45:18 -0400 Received: from 87-237-14-1.powered-by.benesol.be ([87.237.14.1]:40845 "EHLO wizbit.localdomain" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727109AbfCQXpR (ORCPT ); Sun, 17 Mar 2019 19:45:17 -0400 X-Greylist: delayed 438 seconds by postgrey-1.27 at vger.kernel.org; Sun, 17 Mar 2019 19:45:16 EDT Received: from mx.wizbit.be (localhost [127.0.0.1]) by wizbit.localdomain (Postfix) with ESMTP id 27B276003; Mon, 18 Mar 2019 00:37:57 +0100 (CET) From: Bram Yvahk To: steffen.klassert@secunet.com, herbert@gondor.apana.org.au, davem@davemloft.net Cc: netdev@vger.kernel.org Subject: [PATCH ipsec/vti 0/2] Fragmentation of IPv4 in VTI Date: Sun, 17 Mar 2019 23:37:55 +0000 Message-Id: <1552865877-13401-1-git-send-email-bram-yvahk@mail.wizbit.be> X-Mailer: git-send-email 1.8.4 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org We've experienced an issue with VTI when the path-mtu is smaller than the size of the "client" packet. What happens: IPv4 packet from the client (i.e. another system in the LAN) attempts to transmit some data; IPv4 header shows that 'DF' bit is not set but still the client receives ICMPv4 "need-to-frag" message [which the client does not expect and ignores]. Example: $ ping -s 1300 -M dont -c5 192.168.235.2 PING 192.168.235.3 (192.168.235.3) 1300(1328) bytes of data. From 192.168.236.254 icmp_seq=1 Frag needed and DF set (mtu = 1214) From 192.168.236.254 icmp_seq=2 Frag needed and DF set (mtu = 1214) From 192.168.236.254 icmp_seq=3 Frag needed and DF set (mtu = 1214) From 192.168.236.254 icmp_seq=4 Frag needed and DF set (mtu = 1214) From 192.168.236.254 icmp_seq=5 Frag needed and DF set (mtu = 1214) --- 192.168.235.3 ping statistics --- 5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 3999ms This is addressed in the first patch of this series. (I don't fully like some parts of this patch but I'll submit my remarks as a reply to the patch) When testing the changes with an IPv6 tunnel (and with vti6) another issue/edge case popped up. Assume: client sends a IP packet with a size of 1500 bytes. After encrypting this packet [and wrapping it in ESP] it obviously is too large to transmit as a single IPv6 packet and therefor two fragmented IPv6 packets are transmitted. However: when the packet size is larger then the (not yet known) path-mtu then a 'ICMPV6_PKT_TOOBIG' is received. The problem: the ip6_vti error handler ('vti6_err') does not expect that the original packet was a fragmented IPv6 packet --> it does not process the 'PKT_TOOBIG' and continues in sending packets that are too big. This is addressed in the second patch. Bram Yvahk (2): vti: fragment IPv4 packets when DF bit is not set vti6: process icmp msg when IPv6 is fragmented net/ipv4/ip_vti.c | 43 +++++++++++++++++++--------- net/ipv6/ip6_vti.c | 83 +++++++++++++++++++++++++++++++++++++++++------------- 2 files changed, 92 insertions(+), 34 deletions(-)