Re: UDP source ports for HTTP/3 and QUIC

[Willy Tarreau <[e-mail]>]

On Thu, Jul 15, 2021 at 11:20:19AM +1000, Martin Thomson wrote:
> Thanks for raising this Mark.  (Limiting my reply to QUIC, because I think this is more specific to that group.)
> 
> On Thu, Jul 15, 2021, at 10:20, Mark Nottingham wrote:
> > Overall, the chance of collision (i.e., a client or a NAT choosing a 
> > blocked source port) is quite low, but at Internet scale it'll happen, 
> > leading to the client needing to open a new connection, thereby adding 
> > perceived latency. 
> 
> What is going to happen in many cases is that QUIC will be disabled in
> addition to having high latency for that connection.
>  
> > My question is whether there's a need for more coordination -- e.g., a 
> > very short RFC outlining such ports, to help bring this to folks' 
> > attention (especially in the NAT crowd)?
> 
> So this isn't easy.  I think that it is good you raise this either way.  From
> the client side, some greater determinism around this would be good, for the
> above reasons if nothing else.  We don't currently have a source port
> blocklist and we will need to add that.
> 
> Because this isn't entirely under our control as a client, us knowing doesn't
> really provide a complete solution.  To that end, I am inclined to say that
> an informational RFC is a good idea.  Ideally, NAT and cgNAT will avoid these
> ports also and an RFC does tend to reach people.

I don't imagine a single second that those random unprivileged ports will be
avoided. They were randomly picked and will be difficult to exclude from NAT
ranges. By the time implementors have a solution to exclude them, they will
probably not be used anymore and others will happen.

I think that we must at least specify that privileged ports (<1024) must
always be blocked because under no circumstances valid HTTP traffic should
be emitted from such ports which are normally reserved for services. And
for the rest we should rather caution that many UDP services are highly
vulnerable to reflection attacks because there's no such thing as a
distinction from a request packet and a response packet like in TCP,
and that along QUIC's life new popular services will occasionally pop up
and will cause trouble.

The most important for implementors is to be able to quickly validate a
QUIC packet and make sure that no response is ever sent if it cannot be
decoded. This will only lead to CPU usage and nothing more. Sadly, if
we'd had a short protocol identifier at the very beginning of each
packet (e.g. even a 8-bit or 16-bit field), it would have become extremely
difficult to make other protocols match it in their responses and it
wouldn't have been an issue at all. But we don't have this so the packets
will at least have to be parsed.

Willy