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

["Rodney W. Grimes" <[e-mail]>]

Hello Joe, Mark, etc,

  I have to support Joe's possition here, there have never been
this restriction placed on source address ports by the IETF or IANA,
even though most implementations do impose them.

  It would, in my opinion, be a mistake to try and impose this now.

Regards,
Rod Grimes

> Hi, Mark,
> 
> > On Jul 19, 2021, at 8:43 PM, Mark Nottingham <[e-mail]> wrote:
> > 
> > Hi Joe,
> > 
> >> On 20 Jul 2021, at 1:15 pm, Joseph Touch <[e-mail]> 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
-- 
Rod Grimes                                                 [e-mail]