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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5C561CCA473 for ; Mon, 27 Jun 2022 17:22:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236186AbiF0RWK (ORCPT ); Mon, 27 Jun 2022 13:22:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39464 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234714AbiF0RWJ (ORCPT ); Mon, 27 Jun 2022 13:22:09 -0400 Received: from mail.netfilter.org (mail.netfilter.org [217.70.188.207]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 907CBE083; Mon, 27 Jun 2022 10:22:08 -0700 (PDT) Date: Mon, 27 Jun 2022 19:22:05 +0200 From: Pablo Neira Ayuso To: Wei Han Cc: kadlec@netfilter.org, fw@strlen.de, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, netfilter-devel@vger.kernel.org, coreteam@netfilter.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] netfilter: xt_esp: add support for ESP match in NAT Traversal Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, Jun 24, 2022 at 08:05:30PM +0800, Wei Han wrote: > On Thu, Jun 23, 2022 at 09:36:41PM +0200, Pablo Neira Ayuso wrote: [...] > > > + } else { > > > + return false; > > > + } > > > + } else if (proto == IPPROTO_ESP) { > > > + //not NAT-T > > > + eh = skb_header_pointer(skb, par->thoff, sizeof(_esp), &_esp); > > > + if (!eh) { > > > + /* We've been asked to examine this packet, and we > > > + * can't. Hence, no choice but to drop. > > > + */ > > > + pr_debug("Dropping evil ESP tinygram.\n"); > > > + par->hotdrop = true; > > > + return false; > > > + } > > > > This is loose, the user does not have a way to restrict to either > > ESP over UDP or native ESP. I don't think this is going to look nice > > from iptables syntax perspective to restrict either one or another > > mode. > > > This match original purpose is check the ESP packet's SPI value, so I > think the user maybe not need to pay attention that the packet is > ESP over UDP or native ESP just get SPI and check it, this patch is > only want to add support for get SPI in ESP over UDP.And the iptables rules like: > "iptables -A INPUT -m esp --espspi 0x12345678 -j ACCEPT" This rule would be now allowing UDP traffic to go through, even if the user does not need it. An explicit policy entry to allow NAT-T would be preferred. There is another issue, although I suppose there is a standard UDP port for this, user might decide to select a different one, in that case, this would break. And I don't see an easy way to allow user to select the UDP port in the iptables case.