Re: UDP source ports for HTTP/3 and QUIC

[Martin Thomson <[e-mail]>]

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.

HOWEVER, the challenge there is that the exact set of port numbers could be volatile.  That memcached is a problem is well known and so we can reasonably exclude it for the foreseeable future, but we don't know if other protocols might become a source of DoS.  We might hope that new protocols adopt designs with more rigorous DoS prevention inherent to them (like QUIC), making this less likely, but we can't guarantee it.  Baking a list into an RFC seems like it might need careful consideration.