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
