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

"Holland, Jake" <jholland@akamai.com> Tue, 20 July 2021 15:00 UTC

Return-Path: <jholland@akamai.com>
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 077933A2605 for <tsvwg@ietfa.amsl.com>; Tue, 20 Jul 2021 08:00:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level:
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=akamai.com
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 Fkdpoq-UMtre for <tsvwg@ietfa.amsl.com>; Tue, 20 Jul 2021 08:00:04 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 652273A25DD for <tsvwg@ietf.org>; Tue, 20 Jul 2021 08:00:04 -0700 (PDT)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.43/8.16.0.43) with SMTP id 16KEsDuZ002848; Tue, 20 Jul 2021 16:00:01 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=XQlQ9rRrsQUhNl8YHD4gXyHabjadjTTZyqBXrcOtaQA=; b=g5oDx5tTtGrVqj4SMuhqmwA24QDvQrVcsRpW1ekL1/xAKuraouC8/LD+U3LWlObDwIGU JQm5qrgHDMyo+Ms4ygNlnp3Un1kQE7uPNis+Mh+9FIu3JPzf3l77q1HlEATMNMhbA2e2 aIoHJF8AiP9uBP3jx7e1l3Vz3bp5jlwoqlC5ysGYG98PNHtj/ZYfuZ1xCRU2WcnZFtP0 TwRG2F1RITrPHdJXnIrdYqqE6lNM6Wp7gpkGyZKUwpKDXX+Yc0cIx56xT2TnwcMEOM0y nu1Sq45uKxjjTrH8sdZfCM8eMZ2/XOsblItpehhLQRGRsJD3gIU9h46kr1DkgRdFFLzZ XA==
Received: from prod-mail-ppoint8 (a72-247-45-34.deploy.static.akamaitechnologies.com [72.247.45.34] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 39wydwsw7t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 20 Jul 2021 16:00:01 +0100
Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.1.2/8.16.1.2) with SMTP id 16KEnsmb012888; Tue, 20 Jul 2021 11:00:00 -0400
Received: from email.msg.corp.akamai.com ([172.27.165.115]) by prod-mail-ppoint8.akamai.com with ESMTP id 39utj00ct6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 20 Jul 2021 11:00:00 -0400
Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com (172.27.165.122) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.165.124) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Tue, 20 Jul 2021 09:59:59 -0500
Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com ([172.27.165.122]) by ustx2ex-dag1mb4.msg.corp.akamai.com ([172.27.165.122]) with mapi id 15.00.1497.018; Tue, 20 Jul 2021 09:59:59 -0500
From: "Holland, Jake" <jholland@akamai.com>
To: Joseph Touch <touch@strayalpha.com>, Mark Nottingham <mnot@mnot.net>
CC: "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] UDP source ports for HTTP/3 and QUIC
Thread-Index: AQHXfRWMjZgSgvS+zUGp5ddK6XIvzKtLjGwAgAAHd4CAAEA4AA==
Date: Tue, 20 Jul 2021 14:59:58 +0000
Message-ID: <AA5B1FC1-E0E8-488F-AE2E-F21696AD0A06@akamai.com>
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>
In-Reply-To: <8235BE77-7849-49A3-A709-EB32EB039982@strayalpha.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.50.21061301
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.27.164.43]
Content-Type: text/plain; charset="utf-8"
Content-ID: <3AAEC6CBB1513D4399C6EA5FF1F8BE3B@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-20_09:2021-07-19, 2021-07-20 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 spamscore=0 bulkscore=0 mlxlogscore=999 adultscore=0 phishscore=0 malwarescore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107200093
X-Proofpoint-ORIG-GUID: AZ9abzCh04bNTiisdLO8aPUQEaanb665
X-Proofpoint-GUID: AZ9abzCh04bNTiisdLO8aPUQEaanb665
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-20_09:2021-07-19, 2021-07-20 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxlogscore=999 spamscore=0 malwarescore=0 clxscore=1011 impostorscore=0 mlxscore=0 adultscore=0 priorityscore=1501 suspectscore=0 lowpriorityscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107200093
X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.34) smtp.mailfrom=jholland@akamai.com smtp.helo=prod-mail-ppoint8
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/nLuiXGBGG7cerwOws6HnrFlIIc0>
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: Tue, 20 Jul 2021 15:00:10 -0000

From: Joseph Touch <touch@strayalpha.com>
> Date: Mon,2021-07-19 at 9:10 PM
> On Jul 19, 2021, at 8:43 PM, Mark Nottingham <mnot@mnot.net> wrote:
> Well, there’s no consensus on reserving ports as source ports
> UNLESS that is the port on which the service listens. I.e.,
> IANA ports are defined as listening ports and are thus used
> in packets emitted from that listener.

From reading the links in the original message, I didn't think
the idea here was to reserve source ports, exactly.

As I understand the proposal, it's to say "these source ports
happen to match common attack targets that are listening ports
for other protocols, and thus commonly get special handling to
help avoid reflection attacks against those servers".

> There should be no prohibition on using any port number for
> source unless a listen exists on that port.

As I understood it, it's not a prohibition on using those ports,
it's a warning that if you use them, many servers are likely to
block you and likely to continue to do so until further notice
(at least until they have a better answer deployed).

> There’s no precedence for that decision and no registry where
> those values would be indicated. 

The proposal here is to create such a registry.

Of course we don't need precedent to do something that's a good
idea, but the burden of proof is lower if there's some sense in
which there's good precedents showing how doing something like
it in the past has helped things.

I would argue there's plenty of such examples for both
"document how the internet works in practice" (especially when
it has diverged from a design from 30+ years ago that didn't
anticipate modern security issues like reflection attacks) and
for "create a registry to list things that can help people
avoid unpleasant surprises".

My main reservation here is that I'm not sure I understand why
the listening ports are special--a volumetric reflection attack
using servers for amplification would be just as effective with
random source ports as long as it can fill the pipes for the
victim's IP, wouldn't it?

I thought the real problem is that protocol design needs to
avoid generating more traffic than was sent to them before the
server has proved 2-way connectivity to someone who requested
it?  I don't quite get how blocking source ports can fill that
hole.

But with that said, it's interesting that people are doing this,
and if it's the best operational fix for *some* problem, it seems
worth documenting to me, if only selfishly so I can understand
where it's helpful.

-Jake