Re: Blocking packets from suspicious ports
Paul Vixie <paul@redbarn.org> Mon, 02 May 2022 21:27 UTC
Return-Path: <paul@redbarn.org>
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 9241DC159A1F for <quic@ietfa.amsl.com>; Mon, 2 May 2022 14:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.956
X-Spam-Level:
X-Spam-Status: No, score=-3.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.857, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redbarn.org
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 75qZyRzVCNL0 for <quic@ietfa.amsl.com>; Mon, 2 May 2022 14:27:20 -0700 (PDT)
Received: from util.redbarn.org (util.redbarn.org [IPv6:2001:559:8000:cd::222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 809A6C159821 for <quic@ietf.org>; Mon, 2 May 2022 14:27:17 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by util.redbarn.org (Postfix) with ESMTPS id 7C90A1A2423; Mon, 2 May 2022 21:27:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=redbarn.org; s=util; t=1651526836; bh=L58EVsVXwJ7GVaYGi1LOzau4D3jtxbOP9UPBIf/c8ME=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=Xs+vHUSHVayWLNPzt/cutQFoY4UC8qwAy+e7bKMB/dG/iHuEangHy7KFGderXRgZ7 BY4vk88//Z+jfZ3VnKo/seY9JqEGcGslX3v+JRuCjqAV2L5w9CfMxsOv2GfMfO972I UgV1J7Z1ZI+3cqAbXVDyZx17wKP5V2zIHW9rQkvc=
Received: from [24.104.150.156] (dhcp-156.access.rits.tisf.net [24.104.150.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 5920F7597E; Mon, 2 May 2022 21:27:16 +0000 (UTC)
Subject: Re: Blocking packets from suspicious ports
To: Christian Huitema <huitema@huitema.net>
Cc: IETF QUIC WG <quic@ietf.org>
References: <6830cf87-e1b6-14bb-7b10-9341fdb6d941@huitema.net>
From: Paul Vixie <paul@redbarn.org>
Message-ID: <1b686f1e-912d-5c02-cf5f-a8afbdd924bb@redbarn.org>
Date: Mon, 02 May 2022 14:27:15 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/7.0.56
MIME-Version: 1.0
In-Reply-To: <6830cf87-e1b6-14bb-7b10-9341fdb6d941@huitema.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/-xiWBXiXyhQPFrq73qBzTFONjZk>
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: Mon, 02 May 2022 21:27:26 -0000
i think your concern is the mirror image of what i expect. all udp is suspicious, and not just due to ddos, think also exfil and infil. managed private networks (like family and corporate) may allow udp/443 as an exception. some of the more activist service operators will move to non-443 ports in order to make this expensive. ("defenders gonna defend.") managed public networks (like those in china and russia) certainly will not make an exception for udp/443. content they can't inspect will be criminalized, as before. managed private networks may become stateful for udp/443 flows to allow outward but deny inward, since there is not a visible "SYN" bit, as there is in tcp. state in digital systems is like heat in dynamic systems, and "state death" will be common. this just isn't the worst thing, so it will become an accepted risk. unmanaged networks (public or private) will remain transparent, which means inbound ddos is coming right on through. it's nice that a QUIC endpoint will not participate in amplification, but when other endpoints "out there" do participate, the traffic toward a victim endpoint will remain insuperable no matter what that endpoint does with the fraction of the ddos flow they actually receive. a partially managed (not fully transparent) network (public or private) can be expected to implement port-based inbound UDP blocking of the kind you describe. the set of ports will be dynamic, updated during attacks. not something to be hardcoded or "set and forget".
- Blocking packets from suspicious ports Christian Huitema
- Re: Blocking packets from suspicious ports Paul Vixie
- Re: Blocking packets from suspicious ports Willy Tarreau
- Re: Blocking packets from suspicious ports Christian Huitema
- Re: Blocking packets from suspicious ports Willy Tarreau
- Re: Blocking packets from suspicious ports Willy Tarreau
- Re: Blocking packets from suspicious ports Christian Huitema
- Re: Blocking packets from suspicious ports Carsten Bormann
- Re: Blocking packets from suspicious ports Willy Tarreau
- Re: Blocking packets from suspicious ports Carsten Bormann
- Re: Blocking packets from suspicious ports Willy Tarreau
- Re: Blocking packets from suspicious ports Carsten Bormann
- Re: Blocking packets from suspicious ports Willy Tarreau
- Re: Blocking packets from suspicious ports Christian Huitema
- Re: Blocking packets from suspicious ports Mirja Kuehlewind
- Re: Blocking packets from suspicious ports Christian Huitema