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

[Gorry Fairhurst <[e-mail]>]

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:
>
>   * "… agree with documenting the problem as a problem, but not as a
>     practice." &
>   * " … 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]>
> *Sent:* Thursday, July 22, 2021 12:57 AM
> *To:* Black, David
> *Cc:* Holland, Jake; Mark Nottingham; [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
>