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

Joseph Touch <touch@strayalpha.com> Tue, 20 July 2021 04:10 UTC

Return-Path: <touch@strayalpha.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 3A61F3A0DCF for <tsvwg@ietfa.amsl.com>; Mon, 19 Jul 2021 21:10:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 ol67hgx8BSs4 for <tsvwg@ietfa.amsl.com>; Mon, 19 Jul 2021 21:10:13 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 1E2303A0DCE for <tsvwg@ietf.org>; Mon, 19 Jul 2021 21:10:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=9komrDYPyo7RMaIdM1mamZ+6ZjMj18QG0Rw2XUPfuEY=; b=ttW+eLn7ORxh5DPt0WKw6HE7IX UX94qtIMEBgMDPglnO+1eHPhDrC0T9c6AqjTOnEfZZ3JDdwckPkTb9Wr/gVTOyog3aB+boN1Xs5wA PMGH4CP+FMHR9KWZWX+SQA1sD9vVGzQoPA9tmNMcldyzDPzCgfpx2OF5IDqUTcH7fvQg9+5M4L3mn +hkGLrxKlbD3yJkVg0NkAEeR0RCgu8fPWWa2/mZFBAautjB0SxWpNcV2SvV76RUc+izTN0aqlUZZM b32CuqUL2oM0K0cTLVUw9ZYOGoY2EGJ2sZJnsXMRTSfbd7GfSOqDJpa1A+j/D7tinL9w8SJ2w+F3n fJB/Mdtw==;
Received: from cpe-172-114-237-88.socal.res.rr.com ([172.114.237.88]:62004 helo=smtpclient.apple) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <touch@strayalpha.com>) id 1m5h54-003Yzi-Ji; Tue, 20 Jul 2021 00:10:11 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_D1D968F0-1736-4630-A3DF-DE10CDBBFC21"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
From: Joseph Touch <touch@strayalpha.com>
In-Reply-To: <16CD883B-9561-41A5-97E0-43EF3618333C@mnot.net>
Date: Mon, 19 Jul 2021 21:10:05 -0700
Cc: tsvwg@ietf.org
Message-Id: <8235BE77-7849-49A3-A709-EB32EB039982@strayalpha.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>
To: Mark Nottingham <mnot@mnot.net>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/uaFoVn2Kd74JrTfs4f9fSAEijh8>
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 04:10:19 -0000

Hi, Mark,

> On Jul 19, 2021, at 8:43 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 
> Hi Joe,
> 
>> On 20 Jul 2021, at 1:15 pm, Joseph Touch <touch@strayalpha.com> wrote:
>> 
>> Hi, Mark,
>> 
>> All ports are permitted as *source* ports. They are not assigned by IANA nor do any have special meaning, AFAICT.
>> 
>> Port values have meaning most specifically in socket pairs; they are assigned/reserved by IANA and have meaning for a RFC793-style socket ONLY when there is a corresponding RFC793-style listen listen that allows the source port to float AND when there is no more specific binding to a socket pair.
> 
> And yet, we have text like this in RFC5905:
> 
>> dstport: UDP port number of the client, ordinarily the NTP port
>   number PORT (123) assigned by the IANA.  This becomes the source port
>   number in packets sent from this association.

This is consistent with my definition above. See notably the definition for srcport, which is 123 only in symmetric mode (which makes sense - both sides can receive requests).

> and this in RFC6762:
> 
>> A compliant Multicast DNS querier, which implements the rules
>   specified in this document, MUST send its Multicast DNS queries from
>   UDP source port 5353 (the well-known port assigned to mDNS)

It is sending from the port on which it listens, as noted in the remainder of that paragraph:
   , and MUST
   listen for Multicast DNS replies sent to UDP destination port 5353 at
   the mDNS link-local multicast address (224.0.0.251 and/or its IPv6
   equivalent FF02::FB).

I.e., it is sending from a server. 

>> This suggests we should neither create a registry nor document this approach, to avoid either giving the impression of endorsing this behavior.
> 
> I don't follow. 
> 
>> At best, we should document why this behavior is incorrect and should be avoided.
> 
> Based upon the preliminary discussions we've had on the QUIC list, I don't think there's consensus to do that.

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.

There should be no prohibition on using any port number for source unless a listen exists on that port. There’s no precedence for that decision and no registry where those values would be indicated. 

Joe