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

["Black, David" <[e-mail]>]

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