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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 5B1C4C10DCE for ; Sun, 15 Mar 2020 13:28:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3AB1A205ED for ; Sun, 15 Mar 2020 13:28:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728638AbgCON2o (ORCPT ); Sun, 15 Mar 2020 09:28:44 -0400 Received: from correo.us.es ([193.147.175.20]:60582 "EHLO mail.us.es" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728589AbgCON2o (ORCPT ); Sun, 15 Mar 2020 09:28:44 -0400 Received: from antivirus1-rhel7.int (unknown [192.168.2.11]) by mail.us.es (Postfix) with ESMTP id CF43F11EB29 for ; Sun, 15 Mar 2020 14:28:13 +0100 (CET) Received: from antivirus1-rhel7.int (localhost [127.0.0.1]) by antivirus1-rhel7.int (Postfix) with ESMTP id BFE63DA7B2 for ; Sun, 15 Mar 2020 14:28:13 +0100 (CET) Received: by antivirus1-rhel7.int (Postfix, from userid 99) id 9E9DDDA3C3; Sun, 15 Mar 2020 14:28:13 +0100 (CET) Received: from antivirus1-rhel7.int (localhost [127.0.0.1]) by antivirus1-rhel7.int (Postfix) with ESMTP id 456F1DA788; Sun, 15 Mar 2020 14:28:11 +0100 (CET) Received: from 192.168.1.97 (192.168.1.97) by antivirus1-rhel7.int (F-Secure/fsigk_smtp/550/antivirus1-rhel7.int); Sun, 15 Mar 2020 14:28:11 +0100 (CET) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/antivirus1-rhel7.int) Received: from us.es (unknown [90.77.255.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: 1984lsi) by entrada.int (Postfix) with ESMTPSA id 1F6D74251480; Sun, 15 Mar 2020 14:28:11 +0100 (CET) Date: Sun, 15 Mar 2020 14:28:36 +0100 X-SMTPAUTHUS: auth mail.us.es From: Pablo Neira Ayuso To: Daniel Borkmann Cc: Lukas Wunner , Jozsef Kadlecsik , Florian Westphal , netfilter-devel@vger.kernel.org, coreteam@netfilter.org, netdev@vger.kernel.org, Martin Mares , Dmitry Safonov <0x7f454c46@gmail.com>, Thomas Graf , Alexei Starovoitov , David Miller Subject: Re: [PATCH nf-next 3/3] netfilter: Introduce egress hook Message-ID: <20200315132836.cj36ape6rpw33iqb@salvia> References: <14ab7e5af20124a34a50426fd570da7d3b0369ce.1583927267.git.lukas@wunner.de> <20200313145526.ikovaalfuy7rnkdl@salvia> <1bd50836-33c4-da44-5771-654bfb0348cc@iogearbox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1bd50836-33c4-da44-5771-654bfb0348cc@iogearbox.net> User-Agent: NeoMutt/20170113 (1.7.2) X-Virus-Scanned: ClamAV using ClamSMTP Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hello Daniel, On Sat, Mar 14, 2020 at 01:12:02AM +0100, Daniel Borkmann wrote: > On 3/13/20 3:55 PM, Pablo Neira Ayuso wrote: [...] > > We have plans to support for NAT64 and NAT46, this is the right spot > > to do this mangling. There is already support for the tunneling > > But why is existing local-out or post-routing hook _not_ sufficient for > NAT64 given it being IP based? Those hooks are not coming at the end of the IP processing. There is very relevant IP code after those hooks that cannot be bypassed such as fragmentation, tunneling and neighbour output. Such transformation needs to happen after the IP processing, exactly from where Lukas is proposing. [...] > > infrastructure in netfilter from ingress, this spot from egress will > > allow us to perform the tunneling from here. There is also no way to > > drop traffic generated by dhclient, this also allow for filtering such > > locally generated traffic. And many more. > > This is a known fact for ~17 years [0] or probably more by now and noone > from netfilter folks cared to address it in all the years, so I presume > it cannot be important enough, and these days it can be filtered through > other means already. Tbh, it's a bit laughable that you bring this up as > an argument ... > > [0] https://www.spinics.net/lists/netfilter/msg19488.html Look: ip6tables, arptables and ebtables are a copy and paste from the original iptables. At that time, the only way one way to add support for ingress/egress classification in netfilter: add "devtables", yet another copy and past from iptables, that was a no-go. This is not a problem anymore since there is a consolidated netfilter framework to achieve ingress/egress classification. > > Performance impact is negligible, Lukas already provided what you > > asked for. > > Sure, and the claimed result was "as said the fast-path gets faster, not > slower" without any explanation or digging into details on why this might > be, especially since it appears counter-intuitive as was stated by the > author ... and later demonstrated w/ measurements that show the opposite. I remember one of your collegues used this same argument against new hooks back in 2015 [0], and the introduction of this hook was proven to be negligible. This patchset introduces code that looks very much the same. I can make a list of recent updates to the output path, several of them very are targeted to very specific usecases. You did not care at all about performance impact of those at all, however, you care about netfilter for some unknown reason. In my opinion, your original feedback has been addressed, it's time to move on. Thank you. [0] https://lwn.net/Articles/642414/