Re: Blocking packets from suspicious ports

Willy Tarreau <w@1wt.eu> Wed, 04 May 2022 13:09 UTC

Return-Path: <w@1wt.eu>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADE32C15948C for <quic@ietfa.amsl.com>; Wed, 4 May 2022 06:09:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8P4HHx8wWWn3 for <quic@ietfa.amsl.com>; Wed, 4 May 2022 06:09:15 -0700 (PDT)
Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 92E8AC159483 for <quic@ietf.org>; Wed, 4 May 2022 06:09:15 -0700 (PDT)
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 244D980d027202; Wed, 4 May 2022 15:09:08 +0200
Date: Wed, 04 May 2022 15:09:08 +0200
From: Willy Tarreau <w@1wt.eu>
To: Carsten Bormann <cabo@tzi.org>
Cc: Christian Huitema <huitema@huitema.net>, Paul Vixie <paul=40redbarn.org@dmarc.ietf.org>, IETF QUIC WG <quic@ietf.org>
Subject: Re: Blocking packets from suspicious ports
Message-ID: <20220504130908.GF26036@1wt.eu>
References: <20220503032335.GB20878@1wt.eu> <e8c90e2b-e0f1-82ca-8243-2b41412de513@huitema.net> <20220504040937.GA25251@1wt.eu> <c29d88ab-20f2-45d3-6398-bbc5be8e7246@huitema.net> <20220504065344.GA26036@1wt.eu> <098A8520-0935-4D13-875C-97EBB50CB347@tzi.org> <20220504082319.GD26036@1wt.eu> <862758CC-03FC-413C-B8E3-79F9F93EDB30@tzi.org> <20220504094135.GE26036@1wt.eu> <8A254ADB-F8BE-453E-AD47-9C44DA46A6A9@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <8A254ADB-F8BE-453E-AD47-9C44DA46A6A9@tzi.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/DXhB2tkJAyMgxhMUwUrs_xZhTgg>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 May 2022 13:09:16 -0000

On Wed, May 04, 2022 at 12:41:54PM +0200, Carsten Bormann wrote:
> On 2022-05-04, at 11:41, Willy Tarreau <w@1wt.eu> wrote:
> > 
> > 32768..61000 (the default range on Linux).
> 
> Right.
> 
> So I'm fully aware that this is no longer as clean-cut as it used to be.
> 
> My question was less about the situation that we have, but whether it would
> make sense to move forward to a more common, more clear-cut situation.
> 
> Transition of course is left as an exercise to the reader, but as features
> like this would be used for losing packets under attack only, there is a lot
> more leeway than for other global changes of the network.

I don't see what else can be done except reminding that 1024-65535 is
where the essential of the valid web traffic comes from. It's not possible
to shrink it because the port ranges usually apply both to TCP and UDP and
for TCP it's already scarce for some components which would extend it much
beyond 16 bits if that were possible :-/

Just my two cents,
Willy