From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2D55BC43381 for ; Sun, 17 Mar 2019 23:59:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0470F2086A for ; Sun, 17 Mar 2019 23:59:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727425AbfCQX7a (ORCPT ); Sun, 17 Mar 2019 19:59:30 -0400 Received: from michel.telenet-ops.be ([195.130.137.88]:46904 "EHLO michel.telenet-ops.be" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726229AbfCQX73 (ORCPT ); Sun, 17 Mar 2019 19:59:29 -0400 Received: from [10.2.2.197] ([141.135.125.133]) by michel.telenet-ops.be with bizsmtp id pBzT1z00H2soW7906BzTVA; Mon, 18 Mar 2019 00:59:27 +0100 Message-ID: <5C8EDF7F.2010100@mail.wizbit.be> Date: Mon, 18 Mar 2019 00:59:59 +0100 From: Bram Yvahk User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: netdev@vger.kernel.org CC: steffen.klassert@secunet.com, herbert@gondor.apana.org.au, davem@davemloft.net Subject: [ipsec/xfrmi] fragmentation of IPv4 packets Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org After running into some issues with VTI code (see my VTI patches) I decided to take a peek at the xfrmi code. I believe it has the same problems as the VTI code for which I submitted patches. I was planning on testing this with latest kernel but so far I've not yet been able to do so... Only reason why I'm already submitting this message is because there is a 'Linux IPsec workshop' next week. Two issues that I believe exist: - 'xfrmi_xmit2': for an IPv4 packet the DF bit is not checked --> it will send a 'ICMP_FRAG_NEEDED' in response to a packet that is too big but does not have the 'DF' bit set. I believe proper behavior is to fragment the packet See also: [PATCH ipsec/vti 1/2] vti: fragment IPv4 packets when DF bit is not - 'xfrmi6_err': this is not able to handle a ICMPv6 in response to a fragmented IPv6 ESP packet. It uses iph->nexthdr which will be set to 'NEXTHDR_FRAGMENT' which is unhand led in the code. (It expects IPPROTO_ESP/_AH/_COMP) See also: [PATCH ipsec/vti 2/2] vti6: process icmp msg when IPv6 is fragmented