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

Gorry Fairhurst <> Tue, 20 July 2021 14:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E8E513A251F; Tue, 20 Jul 2021 07:40:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LmvfttwXUdTT; Tue, 20 Jul 2021 07:39:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3363C3A251D; Tue, 20 Jul 2021 07:39:56 -0700 (PDT)
Received: from GF-MBP-2.lan ( []) by (Postfix) with ESMTPSA id 6DCDD1B0022D; Tue, 20 Jul 2021 15:39:20 +0100 (BST)
Cc: Joseph Touch <>, Mark Nottingham <>, "" <>
References: <> <> <> <> <>
From: Gorry Fairhurst <>
Message-ID: <>
Date: Tue, 20 Jul 2021 15:39:20 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------BCC596C91430ED0C0213FD9B"
Content-Language: en-GB
Archived-At: <>
Subject: Re: [tsvwg] UDP source ports for HTTP/3 and QUIC
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Jul 2021 14:40:03 -0000

This is just a short note to say that I think this topic **IS** in the 
scope of tsvwg.

IETF transport protocols do utilise source ports in various ways, 
(RFC6437; RFC6438; RFC8086; etc) e.g.:

- as a part of IP fragmentation processing in the net and at endpoints;
- can be used a part of forwarding, QoS classification; and tunnel 
- as a part of load balancing ( ECMP etc);
- randomised src ports as a method of mitigating off-path data insertion 
attack at receivers;

Some protocols have specified the src port as a part of their spec.  
Some relevent BCPs are RFC8085; RFC6056. I'd expect recommendations to 
on-path devices to *NOT* be specific to QUIC, and devices don't know 
which traffic is QUIC; Endpoints at the transport also might not know 
which traffic is QUIC.

Please do discuss the use of source ports here on the tsvwg list, 
especially if there is new thinking on how source ports of QUIC should 
be used and/or should be managed.

Best wishes,

Gorry Fairhurst
(as a TSVWG Chair)

On 20/07/2021 05:10, Joseph Touch wrote:
> Hi, Mark,
>> On Jul 19, 2021, at 8:43 PM, Mark Nottingham < 
>> <>> wrote:
>> Hi Joe,
>>> On 20 Jul 2021, at 1:15 pm, Joseph Touch < 
>>> <>> 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 ( 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