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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 97958C5517A for ; Mon, 9 Nov 2020 19:39:57 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2FB85206A1 for ; Mon, 9 Nov 2020 19:39:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="KViylsvx"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="QPGXaCvV" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2FB85206A1 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=b3/UUpnDkLB5jySxO0MTapLX03un08jxNkhJBsWBML8=; b=KViylsvxr7kN0tQOU8fajSCAt 5/eRvoV6fafwORSMbDo39mGgRIL8HoHs++q4DWYnJ06FCzTWVp7kjv3PpKRQWvaToN9Ovdj5nf7xo yW/VMfHLB+wItTeiIWY8GwdvSrxOOSKWU4Ww2xeEwHTqm7iMoSuE4+ZIOSJo6ZQjWV3ft3Jh0j8XU uCGeUKKiMrgA+st0gq8tE1LuRqHIXrCeTup+Zv/fRLajUROk/bY61Ldp4E3PhvEJ77VekcXClK44T O8F5YsN55ayItGPThTnG320WWQGFr++6kkxQrUC4CiNd5ej9Q2nrXImhBV94EiKUC3Tb4YCmeKgKb 5GRpxyiWg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kcCzs-000654-EE; Mon, 09 Nov 2020 19:38:36 +0000 Received: from mail-il1-x141.google.com ([2607:f8b0:4864:20::141]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kcCzp-00063u-6T for linux-arm-kernel@lists.infradead.org; Mon, 09 Nov 2020 19:38:34 +0000 Received: by mail-il1-x141.google.com with SMTP id g7so9378481ilr.12 for ; Mon, 09 Nov 2020 11:38:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k8+EMc4+ZzXJqSUvzL7W5Ni2fcnDgXtP+EcVau6OBrM=; b=QPGXaCvVRB4KlRGmWhDbpfdbGn0ZC8kDinWCv2x+JjrJI6PBwoifTda0X4VKf0rNxQ G5f1FH27nqN/xBqw4zPvuraKnoNs0119PH5Heq2ppu/7EDCFk0nx0e/UQH7St5Jyp2Y+ HIUq6T9oY6yloWEntf74siPKEd6n/qnVKbzM0A/ZiDBKevfaRPikMMkh3VtAfnmFEr3v B1M9cwtK8iHS0GXtivOLEs9X4osprzrKbe5U54/Vs4hicBCtMTmZVDx0rWX9QXher2ip pM6IrJuAtFPR717tRAZeWwiPNDB8Mb2uK6IhnaEJl1n+zPiUdkYuxf5yNEiL5w5T2gkH JhOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=k8+EMc4+ZzXJqSUvzL7W5Ni2fcnDgXtP+EcVau6OBrM=; b=ZwPwVF0sWSeEde+kB/F8jhKMocIBxZeQakkyFv8ZaMc1fVzd6bbCiZhwXcj1f3nVTC hxZhSw6rwS+5sXfdRvegYuY3WSM/8LpBv4aAEc1G6Z/ObyktLGILzCErLhcOUQDlOtRa 5ric3/Ir1J2Lu6UvLcoxMfGAnklgkc3kHj7m+Qok76vaZu1pd7LAFEWAQVV7Z8Y2NE86 JjYAwzCLi44gajnfyNPqp8MMovZxho4az60hcc3Qn5rE4jw12MX4J8nSt4I8EllffI0/ NzpTEvPNz2+28lfmQMG/N2X0Z2SWFQWqWO9KCvpf2/v3hjY4O+BlQdaVtD89d2jL4SZ3 wLNg== X-Gm-Message-State: AOAM5327+myNDuFEM08KNjXTeuuE6pZ5tDYthsKFOm0h/yNq+Qzq1zRE qaUp8sR14hNV4e47ANuGh3EMa9bGHYFLRegrT+LVSg== X-Google-Smtp-Source: ABdhPJw0MeG4P26hzsMF6D4SWQfdhHemZQG3avMmoyM+7Vf54D1B9HL4wVsscgX4reE8l0z4nuZgBbBlWbHxr9kgPTQ= X-Received: by 2002:a92:9e8b:: with SMTP id s11mr10932147ilk.61.1604950709307; Mon, 09 Nov 2020 11:38:29 -0800 (PST) MIME-Version: 1.0 References: <20200909062613.18604-1-lina.wang@mediatek.com> <20200915073006.GR20687@gauss3.secunet.de> <20201109095813.GV26422@gauss3.secunet.de> In-Reply-To: <20201109095813.GV26422@gauss3.secunet.de> From: =?UTF-8?Q?Maciej_=C5=BBenczykowski?= Date: Mon, 9 Nov 2020 11:38:16 -0800 Message-ID: Subject: Re: [PATCH] xfrm:fragmented ipv4 tunnel packets in inner interface To: Steffen Klassert X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201109_143833_328698_C3D08731 X-CRM114-Status: GOOD ( 31.87 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Herbert Xu , mtk81216 , Linux NetDev , lkml , Hideaki YOSHIFUJI , linux-mediatek@lists.infradead.org, Jakub Kicinski , Matthias Brugger , Alexey Kuznetsov , Greg Kroah-Hartman , "David S . Miller" , linux-arm-kernel@lists.infradead.org, Lorenzo Colitti Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Nov 9, 2020 at 1:58 AM Steffen Klassert wrote: > > On Thu, Nov 05, 2020 at 01:52:01PM +0900, Lorenzo Colitti wrote: > > On Tue, Sep 15, 2020 at 4:30 PM Steffen Klassert > > 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). > > When we setup packets that are sent from a local socket, we take > MTU/PMTU info we have into account. So we don't create fragments in > that case. > > When forwarding packets it is different. The router that can not > TX the packet because it exceeds the MTU of the sending interface > is responsible to either fragment (if DF is not set), or send a > PMTU notification (if DF is set). So if we are able to transmit > the packet, we do it. > > > 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. > > We can not really do anything here. If a flow has no DF bit set > on the packets, we can not rely on PMTU information. If we have PMTU > info on the route, then we have it because some other flow (that has > DF bit set on the packets) triggered PMTU discovery. That means that > the PMTU information is reset when this flow (with DF set) stops > sending packets. So the other flow (with DF not set) will send > big packets again. PMTU is by default ignored by forwarding - because it's spoofable. That said I wonder if my recent changes to honour route mtu (for ipv4) haven't fixed this particular issue in the presence of correctly configured device/route mtus... I don't understand if the problem here is locally generated packets, or forwarded packets. It does seem like there is (or was) a bug somewhere... but it might already be fixed (see above) or might be caused by a misconfiguration of device mtu or routing rules. I don't really understand the example. > > > 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). > > We should not try to workaround broken configurations, there are just > too many possibilities to configure a broken network. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel