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".