search

quicwg / multipath

In-progress version of draft-ietf-quic-multipath
Other
49 stars 18 forks source link

Don't use all CIDs unless rebinding is a nonconcern #231

Closed kazuho closed 1 year ago

kazuho commented 1 year ago

Closes #221. As discussed in the issue, endpoints need to retain unused CIDs, otherwise they cannot respond to NAT rebinding.

Also removes a stale statement about zero-length CID.

mirjak commented 1 year ago

I merged #225 already but resolved the conflict now

mirjak commented 1 year ago

I'm actually not sure about this statement.

First, I think the question if you should save any CIDs for NAT rebindings is independent of the multipath extension and more a general question for QUIC; yes, without multipath NAT is probably the main use case but still the sender could decide to use a new CID any time.

Second, given you have multiple paths in use, it might be less of a problem if one path breaks because of NAT. So I can well image that there might be cases where you rather use your last CID for a new path then save it for a potentially NAT rebinding on one of the existing path.

Therefor I think it is okay to mention the fact that CIDs might also be needed for NAT rebindings on existing paths but I really wouldn't use normative language here.

kazuho commented 1 year ago

@mirjak Thank you for resolving the conflicts. I forgot that I had a separate PR for that.

First, I think the question if you should save any CIDs for NAT rebindings is independent of the multipath extension and more a general question for QUIC; yes, without multipath NAT is probably the main use case but still the sender could decide to use a new CID any time.

Yes, this is a general problem. In RFC 9000, we have the following statement: An endpoint that exhausts available connection IDs cannot probe new paths or initiate migration, nor can it respond to probes or attempts by its peer to migrate. To ensure that migration is possible and packets sent on different paths cannot be correlated, endpoints SHOULD provide new connection IDs before peers migrate (section 9.5).

Maybe we should add a reference.

Second, given you have multiple paths in use, it might be less of a problem if one path breaks because of NAT. So I can well image that there might be cases where you rather use your last CID for a new path then save it for a potentially NAT rebinding on one of the existing path.

Depending on how Multipath is used, connections could become more susceptible to NAT rebindings. In QUIC v1, backup paths are expected to be established through different networks, meaning that there is low probability of multiple paths getting rebound at the same time. But in case of Multipath, one of the intended use case is to open multiple paths through the same network (so that the tunnel being built on top of QUIC serving multiple end-to-end flows can have a fair share of bandwidth against other flows). In such a use case, all paths would be affected by a single NAT device doing a rebind.

That said...

Therefor I think it is okay to mention the fact that CIDs might also be needed for NAT rebindings on existing paths but I really wouldn't use normative language here.

I think I agree that we do not need a normative clause here. I will update the PR.

kazuho commented 1 year ago

@mirjak Updated. PTAL.