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

[Joseph Touch <[e-mail]>]

Hi, David,

> On Jul 23, 2021, at 9:05 AM, Black, David <[e-mail]> wrote:
> 
> > This is the core Issue though. So we have a problem where people generate spoofed traffic.
> > 
> > And some patterns of that traffic can be identified by how they use source ports.
>  
> In the cases of interest for this discussion, the source ports are real not spoofed.

Correct me if I’m not tracking:

A- some people send spoofed packets as attacks
B- the packets have one thing in common - use of particular source ports
C- so others have started to filter based on those source ports
D- which means legitimate uses of those ports are now blocked

Assuming that tracks:

(C) has made the leap that “correlation” becomes “cause”, so now it’s not just being under attack, but merely looking at the port that is considered an attack to be blocked

This is no different than the RST attacks on TCP, as follows:

A- some people sent spoofed RSTs all over the sequence space as attacks
B- the packets have one thing in common - being RSTs
C- so there was a proposal to block RSTs not at a single correct location in the receive window
D- which means legitimate transmissions of RSTs are now blocked (and that everyone had to change their TCP, making it more complex).

This is a common IETF fallacy:

A. Some people do X
B. There is a correlation between X and Y (not cause and effect)
C. Others interpret X as bad, leaping from correlation to cause and effect
D. We all have to deal with it (complexity)

We need to stop this at step C and declare THAT the problem.

Joe