Re: [quicwg/base-drafts] Client connection IDs are broken (#2844)

[Kazuho Oku <[e-mail]>]

@igorlord 
> This discussion is about not arbitrarily forbidding something that is useful. 

Thank you for the clarification. Assuming that we can give clients the freedom coalesce multiple connections onto a single 5-tuple, I do not have a strong argument against giving servers some wiggle room.

> I am puzzled why you think it is "complex", though.
> 
> Is it that much more complex to do
> 
> `connection = by_4tuple[pkt.4tuple()] ? : by_cid[pkt.cid()];`
> 
> than
> 
> `connection = by_cid[pkt.cid()];`

I think it is more complex than that.

The approach you are describing can be modeled as a daisy-chain of two QUIC servers.

What would the server do if there is no corresponding state for a short header packet that you receive, neither in `by_4tuple` nor `by_cid`?

The server needs to send a stateless reset. But because the server cannot tell if the packet were to be identified by the 4-tuple or the CID (because you no longer have state!), the server needs to send two stateless reset packets, one generated using the 4-tuple as the key, and the other generated using the CID. However, simply doing that could lead to an amplification attack (as we know, the amount of data (or packets) the server can send as a reset needs to be smaller than the amount of data that the server has received).

This _might_ be a problem htat we want to solve. But is it worth spending the time of the WG to discuss such thing? I'm not sure.

And I'm not sure if this is the only problem that exists in the proposed design.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2844#issuecomment-515657133