Re: [quicwg/base-drafts] Required state for retaining unacked RETIRE_CONNECTION_ID frames is unbound (#3509)

[Martin Thomson <[e-mail]>]

I think that I understand your point; thanks for your patience.

I didn't really classify it as a leak though, so the choice of words threw me a little, it's more of a lag.

Let's say that you have a pathological endpoint that sends an infinite series of NEW_CONNECTION_ID frames with Sequence Number N and Retire Prior To of (N-1).  That's legal and will never violate any limits.  But unless they maintain acknowledgments for RETIRE_CONNECTION_ID frames at a similar rate (which, to be fair should be easy as `sizeof(NEW_CONNECTION_ID) > sizeof(RETIRE_CONNECTION_ID) > sizeof(ACK)` for the same values), they could get far ahead of their peer.

I don't think that it is strictly a leak, just a lag between the connection IDs being pushed and the connection IDs being successfully retired.  Without #3547 or something else this could be problematic.  And I now understand why #3550 is really just an orthogonal refinement, though it might make other defenses less likely to be required by making `sizeof(sum(RETIRE_CONNECTION_ID))` zero in cases where an endpoint isn't using discretionary retirement.

The defense in #3553 is to make `sizeof(sum(RETIRE_CONNECTION_ID))` effectively constant, no matter how many frames need to be retired.  My main objection is really that it is a maximal design where only a minimal one is warranted.

It's probably worth pointing out that there is also the simplest defense:  If you can't keep up with RETIRE_CONNECTION_ID, stop talking to the peer that does this to you.  This is just another example from that category of abuse we don't have specific protocol mechanisms to mitigate.

-- 
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/3509#issuecomment-605779478