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

[Mark Nottingham <[e-mail]>]

> On 25 Jul 2021, at 3:58 am, Joseph Touch <[e-mail]> wrote:
> 
> 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

No, it's more like

A - some people identify services that allow reflection attacks (often, with a significant amplification factor)
B - those services often use specific 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.

That may be the problem from your perspective, but from the perspective of people operating services on the Internet, it definitely isn't. 

And there is already a precedent of a sort for that view in BCP38:

"""
   Similar attacks have been attempted using UDP and ICMP flooding.
   The former attack (UDP flooding) uses forged packets to try and
   connect the chargen UDP service to the echo UDP service at another
   site.  Systems administrators should NEVER allow UDP packets destined
   for system diagnostic ports from outside of their administrative
   domain to reach their systems.
"""

It may be helpful to get some security and ops area input on this discussion, since it touches both of them pretty directly.

Cheers,



--
Mark Nottingham   https://www.mnot.net/