Re: [tsvwg] UDP source ports for HTTP/3 and QUIC

Mark Nottingham <mnot@mnot.net> Sun, 25 July 2021 02:29 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983173A0F2E for <tsvwg@ietfa.amsl.com>; Sat, 24 Jul 2021 19:29:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=C6TzKt55; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HeT7Yc8g
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BzrECrTa7YZ for <tsvwg@ietfa.amsl.com>; Sat, 24 Jul 2021 19:29:34 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 347483A0F2F for <tsvwg@ietf.org>; Sat, 24 Jul 2021 19:29:33 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id F29DF5C0125; Sat, 24 Jul 2021 22:29:32 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sat, 24 Jul 2021 22:29:32 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=l 4CR36ESEX3bIBZqIor32uu0KcMlW2YR47Az5jeg79E=; b=C6TzKt55z8cWYtz3N k54kGP0Jzf69mRCQZMhKAXcNAlaQuldUzXnkb/Gxz5Fz4bReqZ+gkNMAccZ2Vqvo 9a9UpSCOH3XxH+Uuek39Cd5gy0hnzGJUzShuLLgxl/woNI3f7F1sm15fyvRp410T YlNPLvhwI82SmCJOUhDEWnFEUd30J0rel9tCq+oTK4VBbTJLkqtwWe7tGFX/rB6j RdrZFzikAllc9pDalFZJpLUXTLIgFyksuB1rw8RvmYpPNADbey/DmFUVh5oyDzQI dRhQuEZFjfeuNrspsdjk2QwcZb5lGoCgK5EojQqzDPTu21UVmq7vZj5I7UPHf5id 7xLUg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=l4CR36ESEX3bIBZqIor32uu0KcMlW2YR47Az5jeg7 9E=; b=HeT7Yc8g2sofIKRRZqUeYaWIC+YMhNWASh1JLpy2IeGeYLWTrVvvX7J9V nNi2P7oDEXmrUvEk6hpIA5ufyhz5G/bAVPj2N6XWxYkrW1MzDdDZFU2k2be35qO4 4y2heKMzWtndR653dBblcHXEkZLEeOddXI+GU5TDydlofpoRxYRRxaZcYWPGjVdq 2wuzvdL08MJ6cHdnOdW1Fpozwlr0abwflxhi7PIQs6IjACV7/izENxPBYUvs3vUj G/Ymc8o5tA3Gu3rIyNtSnlvKvnkiwF4KzwSdDH6tR6My62YyUexuFDRveXdQpUCV GSrLW68WTg/aU//XFKTvvOagak1CQ==
X-ME-Sender: <xms:isz8YF0WbfDAfQsNsnqwhJnYP4LspU90oqtv594F1HJyP-ZwV_UH2g> <xme:isz8YMEvPOymfMwyJttgCMxsVi6r8fGPP_15hMv1O0VlbXY8CH2i2ry-matbNnP0N JYhc4fhNhI0EpTYLw>
X-ME-Received: <xmr:isz8YF4T1ANujEUY0lCQdrOVn4HcSsuXSRhJxiuIahPdjnoZsa5he09mw5UQtj3r8cQXL1sIRAthd0LlWD12HQklEMoJx-9sqCzKWt2stUDRomk5sVhYFkvi>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrgedugdehgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepteefleffjeffhfehheeffeegudelgfeujedukeeigedvgeehffefvdehffeileek necuffhomhgrihhnpehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght
X-ME-Proxy: <xmx:isz8YC0fPs5fH-H8PLqus3qcNGXMDpfgHXTetSUCVNHPTAlIunFrqA> <xmx:isz8YIF4NaB4-5I0QdRNQMROqSMh-93Kj36RLECThrEUdlUljaL0Rw> <xmx:isz8YD_R2rbdpCrgS5PthoUWNz-s9cGzd2WAVGG_qfe706Cm8zqrig> <xmx:jMz8YEiE5q_LZ_qaNYMySF7HvI43-chPVa1QUwvOUsDu8DGov1GwoQ>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 24 Jul 2021 22:29:29 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <2E46FC3A-95B1-4D7A-B070-B4F83FC4CAA5@strayalpha.com>
Date: Sun, 25 Jul 2021 12:29:27 +1000
Cc: "Black, David" <David.Black@dell.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <89D7112F-F33B-45BB-AAF7-FB9B95FCB73D@mnot.net>
References: <3985895D-D420-4995-831E-332E33693B79@mnot.net> <CF409524-96F3-412A-A8DB-E4EFFDD9F4E7@mnot.net> <E62515E7-38FD-4197-8CF0-2D196FB6D6C4@strayalpha.com> <16CD883B-9561-41A5-97E0-43EF3618333C@mnot.net> <8235BE77-7849-49A3-A709-EB32EB039982@strayalpha.com> <AA5B1FC1-E0E8-488F-AE2E-F21696AD0A06@akamai.com> <MN2PR19MB4045E5063CE13DDE39D5BE8683E29@MN2PR19MB4045.namprd19.prod.outlook.com> <9263482C-2E0A-46F0-9351-B63C0E3B53E0@strayalpha.com> <MN2PR19MB40450ACCE13E4A335FF929A483E49@MN2PR19MB4045.namprd19.prod.outlook.com> <C28BAF21-2C9D-41FF-93A7-E73684E671CE@strayalpha.com> <DM6PR19MB404259513409648A5CF97A3383E59@DM6PR19MB4042.namprd19.prod.outlook.com> <2E46FC3A-95B1-4D7A-B070-B4F83FC4CAA5@strayalpha.com>
To: Joseph Touch <touch@strayalpha.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/M87vgcc9CRFiyRjljsVlsMUDqGc>
Subject: Re: [tsvwg] UDP source ports for HTTP/3 and QUIC
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 25 Jul 2021 02:29:40 -0000


> On 25 Jul 2021, at 3:58 am, Joseph Touch <touch@strayalpha.com> wrote:
> 
> Hi, David,
> 
>> On Jul 23, 2021, at 9:05 AM, Black, David <David.Black@dell.com> wrote:
>> 
>> > This is the core Issue though. So we have a problem where people generate spoofed traffic.
>> > 
>> > And some patterns of that traffic can be identified by how they use source ports.
>>  
>> In the cases of interest for this discussion, the source ports are real not spoofed.
> 
> Correct me if I’m not tracking:
> 
> A- some people send spoofed packets as attacks
> B- the packets have one thing in common - use of particular source ports

No, it's more like

A - some people identify services that allow reflection attacks (often, with a significant amplification factor)
B - those services often use specific source ports

> C- so others have started to filter based on those source ports
> D- which means legitimate uses of those ports are now blocked
> 
> Assuming that tracks:
> 
> (C) has made the leap that “correlation” becomes “cause”, so now it’s not just being under attack, but merely looking at the port that is considered an attack to be blocked
> 
> This is no different than the RST attacks on TCP, as follows:
> 
> A- some people sent spoofed RSTs all over the sequence space as attacks
> B- the packets have one thing in common - being RSTs
> C- so there was a proposal to block RSTs not at a single correct location in the receive window
> D- which means legitimate transmissions of RSTs are now blocked (and that everyone had to change their TCP, making it more complex).
> 
> This is a common IETF fallacy:
> 
> A. Some people do X
> B. There is a correlation between X and Y (not cause and effect)
> C. Others interpret X as bad, leaping from correlation to cause and effect
> D. We all have to deal with it (complexity)
> 
> We need to stop this at step C and declare THAT the problem.

That may be the problem from your perspective, but from the perspective of people operating services on the Internet, it definitely isn't. 

And there is already a precedent of a sort for that view in BCP38:

"""
   Similar attacks have been attempted using UDP and ICMP flooding.
   The former attack (UDP flooding) uses forged packets to try and
   connect the chargen UDP service to the echo UDP service at another
   site.  Systems administrators should NEVER allow UDP packets destined
   for system diagnostic ports from outside of their administrative
   domain to reach their systems.
"""

It may be helpful to get some security and ops area input on this discussion, since it touches both of them pretty directly.

Cheers,



--
Mark Nottingham   https://www.mnot.net/