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

[Gorry Fairhurst <[e-mail]>]

On 22/07/2021 19:10, Black, David wrote:
>
> Dell Customer Communication - Confidential
>
> Hi Gorry,
>
> Quoting from the original message that Mark forwarded 
> (https://mailarchive.ietf.org/arch/msg/tsvwg/7Fbxa5NryyUzJSWesNFbAx6hs3U/ 
> <https://mailarchive.ietf.org/arch/msg/tsvwg/7Fbxa5NryyUzJSWesNFbAx6hs3U/> 
> - scroll down past Mark's initial remarks to TSVWG):
>
> > If a client chooses source ports from the ephemeral port range, this 
> shouldn't be an issue. However, some implementations (or deployments) 
> extend the source port range "downwards" to avoid exhaustion:
>
> Thanks, --David
>
I haven't quite yet understood this use case, I suspect I must have 
missed something:

Am I understanding this about a client choosing source ports, and this 
client runs out of ephemeral ports (at least within the time it can 
reuse closed ports). I can see that servers can have lots of clients, 
but what is the use-case for a QUIC client to have that many open UDP 
ports?

Gorry

> *From:* Gorry Fairhurst <[e-mail]>
> *Sent:* Thursday, July 22, 2021 11:46 AM
> *To:* Black, David; Joseph Touch
> *Cc:* Mark Nottingham; [e-mail]
> *Subject:* Re: [tsvwg] UDP source ports for HTTP/3 and QUIC
>
> [EXTERNAL EMAIL]
>
> I'm still misisng some context about the use case why a QUIC client 
> would wishes to use a source port outside the ephmeral range.
>
> Althoughit was always possible to use all ports as source port, that 
> use does not come without pain. And QUIC multiplexes data, so  what's 
> the use case for using the lower-numbered source ports?
>
> Gorry
>
> On 22/07/2021 16:05, Black, David wrote:
>
>     Hi Joe,
>
>     Let's start from a couple of aspects where we're in rough agreement:
>
>      1. "… agree with documenting the problem as a problem, but not as
>         a practice." &
>      2. " … no problem making a list of ports that people ...
>         attribute to attacks."
>
>     Someone ought to "Send Draft!" (credit to Randy Bush) that
>     contains an explanation of the problem, text to create the new
>     IANA registry that lists the ports plus some discussion of what
>     can usefully be done.  That draft's text on implications and
>     recommendations (what can usefully be done) can then be discussed
>     in detail to get to precise text that is acceptable to all (e.g.,
>     what to do about the view that attribution to attacks in the
>     second bullet may be mistaken).
>
>     Does that sound reasonable?
>
>     Thanks, --David
>
>     *From:* Joseph Touch <[e-mail]>
>     <mailto:[e-mail]>
>     *Sent:* Thursday, July 22, 2021 12:57 AM
>     *To:* Black, David
>     *Cc:* Holland, Jake; Mark Nottingham; [e-mail]
>     <mailto:[e-mail]>
>     *Subject:* Re: [tsvwg] UDP source ports for HTTP/3 and QUIC
>
>     [EXTERNAL EMAIL]
>
>     Hi, David,
>
>
>
>         On Jul 20, 2021, at 12:02 PM, Black, David
>         <[e-mail] <mailto:[e-mail]>> wrote:
>
>         Explaining as an individual, not WG chair ... TL;DR - +1 on
>         Jake's comments, his understanding matches mine.
>
>         Providing some more detail ...
>
>
>             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".
>
>
>         +1 - this is about documenting "running code" that discards
>         traffic that uses one of those UDP source ports.
>
>     There’s a hazard with this viewpoint, IMO.
>
>     It’s like observing people driving on flat tires and thinking the
>     road is bumpy.
>
>     There are two solutions:
>
>     - document existing practice and describe how road engineers can
>     redesign roads to avoid the problem
>
>     - document that driving on flat tires is incorrect and explain
>     what it impacts
>
>     I agree with documenting the problem as a problem, but not as a
>     practice. The latter viewpoint endorses it, which then means we
>     all have to accommodate that behavior.
>
>
>
>                 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.
>
>
>         I definitely agree that a new registry is wanted/warranted,
>
>     I have no problem making a list of ports that people MISTAKENLY
>     attribute to attacks.
>
>     However, those who assume that a packet is bad simply because it
>     uses one of these source ports is ITSELF incorrect. Just because
>     it works when you’re under this attack, doesn’t mean it is safe to
>     do when you’re not.
>
>     Let’s please not endorse incorrect conclusions that source port
>     has this sort of meaning.
>
>     Joe
>