Re: [quicwg/base-drafts] No need for RCID if the peer increases Retire Prior To (#3550)

[Kazuho Oku <[e-mail]>]

@ianswett 
> Thanks for reminding me @kazuho I think this text mitigates that issue:
"An endpoint MUST NOT provide more connection IDs than the peer's limit. An endpoint that receives more connection IDs than its advertised active_connection_id_limit MUST close the connection with an error of type CONNECTION_ID_LIMIT_ERROR."

That text does not mitigate the issue, because te the endpoint that sends RCID, a CID becomes inactive when (or before when) it sends the RCID frame carrying that CID for the first time.

When the peer receives that RCID frame, it peer is allowed to provide a new CID before sending an ACK, or before that ACK is being received by the peer.

> However, if a peer sends a NCID and doesn't increase Retire Prior To in this case, then it's unclear which RETIRE_CONNECTION_ID frame(s) were received. In that case, is it ever clear which RETIRE_CONNECTION_ID frames were received? I'm not sure #3547 actually solves this, or just makes it much less likely?

IIUC, the defense in #3547 is that the endpoint is allowed (recommended) to cease sending RCID frames carrying some CIDs under extreme circumstances. This approach will work regardless of an attack (at the theoretical cost of having interoperability problems, though it would be unlikely assuming that each endpoint would track sufficient number of CIDs being retired).

> I'm starting to think we need a max_connection_id in RETIRE_CONNECTION_ID(or a separate MAX_CONNECTION_ID frame) as a flow control style mechanism to solve this fully?

I share the view that that is the cleanest way of fixing the issue.

-- 
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/pull/3550#issuecomment-605540981