Certainly, there are cases we must not reuse CIDs. If the client is aware that it’s gonna send packets on a new path from a new local address, then it’s forbidden by RFC9000 to reuse CIDs on the new path (… "An endpoint MUST NOT reuse a connection ID when sending from more than one local address -- for example, when initiating connection migration as described in Section 9.2 or when probing a new network path as described in Section 9.1" ....).
In the case of MPQUIC enabled, clients must use different CIDs on different paths as it is aware of multiple local addresses, which aligns with RFC9000. But, should an MPQUIC server always rotate CIDs when detecting NAT rebinding events on paths? If the answer is yes, as every CID has its own packet number space, it would increase the complexity of implementation. > On Sep 27, 2023, at 02:30, Christian Huitema <[email protected]> wrote: > > There was quite a bit of discussion about the usage of CID in the context of > QUIC Multipath, which uses CID to identify paths. The basic rules for > managing incoming packets are: > > 1) Packet arrives with a new CID: > - if same four tuple as an existing path, treat as CID renewal > - if different four tuple, process as new path > 2) Packet arrives with already used CID: > - if same four tuple as an existing path, process on that path. > - if different four tuple, process NAT rebinding as new path > > If client would keeps sending packets with the same CID and different IP > addresses, it will cause a lot of "NAT rebinding", causing a lot of overhead > on the server. Servers may well treat that as an attack and drop the > connection. > > -- Christian Huitema > > On 9/26/2023 10:25 AM, Eric Kinnear wrote: >> That said, if the server notices that the client is coming from a different >> address and using the same destination CID, which would not be allowed if >> the client knew that it was using a different network path, it’s nice if it >> does change CID. This provides a signal to a client that a NAT rebinding may >> have occurred, and the client might choose to take action on that in some >> way. >> Since you’re allowed to change CID at any time on the same path, there’s no >> need for additional text that explicitly allows this, but the most >> straightforward implementation that just says “yup, you’re on a different >> remote address, I’ll use a different CID” and doesn’t check whether the >> remote peer rotated CID is likely the best answer. >> Thanks, >> Eric >>> On Sep 25, 2023, at 8:37 PM, Willy Tarreau <[email protected]> wrote: >>> >>> On Tue, Sep 26, 2023 at 11:04:40AM +0800, "???(Personal)" wrote: >>>> Is it allowed for a server to reuse the current CID when it notices a NAT >>>> rebinding? I wonder if the text ("...., in which case it MAY continue to >>>> use >>>> the current connection ID with the new remote address while still sending >>>> from the same local address.") indicates that the server can reuse the >>>> current CID? >>> >>> If the spec says "MAY", then yes, it's allowed to. >>> >>> Willy >>>
