Thanks for all the feedback! I'll address multiple points made in the thread so far.
Multipath: I'd like this extension to work well with QUIC Multipath, and I don't see anything that would prevent that. However, I don't think it needs anything multipath-specific, and can run on top of a RFC 9000 stack just as well. In specific: 1. RFC 9000 already allows a client to simultaneously probe an arbitrary number of paths, and to keep them alive (by sending probing packets). The only thing that multipath adds here is the capability to send / receive on multiple paths at the same time, but a NAT won't even be able to distinguish between these scenarios. 2. Multipath doesn't allow the server to initiate a new path: as in RFC 9000, path initiation is solely the client's responsibility. A NAT traversal solution will need to define a way for the server to send a hole punching packet either way. Who's initiating the migration: When we designed QUIC, we concluded that server-initiated migration creates a lot of corner cases, especially around the simultaneous initiation of new paths. It might also open up new attack scenarios. The draft therefore doesn't change that logic: All probing of new paths is driven by the client. That’s why we need to sure that the the QUIC client's ACE agent ends up being the controlling agent (it is my understanding that the controlling agent is responsible for the probing of new paths). That being said, the draft should probably go into more detail regarding NAT rebindings that might happen on the server's NAT. QUIC Address Extension: This seems useful for nodes that don’t need to rely on ICE for their address discovery, e.g. p2p applications that are running continuously. They cut then piggy-back address discovery on top of connections they’re establishing anyways. In fact, I have deployed something very similar, with the address requests happening at the application layer. Who’s responsible for path selection? Martin is making a good point here (and wrote a really interesting ICE / DTLS draft 10 years ago, thank you for sharing!). In mode 1, I’d imagine that ICE runs to completion before the QUIC handshake starts, so it would be ICE’s responsibility to select the path. In mode 3, it makes sense to have the QUIC layer decide which of the paths to use, as it probably knows more about the application’s needs than ICE. On Tue, 18 Jul 2023 at 18:55, Martin Thomson <[email protected]> wrote: > Hi Marten, > > I did a little thinking about this problem a fair while back, see > https://datatracker.ietf.org/doc/html/draft-thomson-rtcweb-ice-dtls-00 > > That's closer in truth to your mode 3. That is, it collapses the > protocols. And of course there are properties of DTLS that ensure that > this is less than ideal, whereas QUIC might be better suited to the sorts > of tweaks that connectivity checking demands. > > In particular, it is worth thinking about carefully here is how much > QUIC's path validation logic is duplicative of parts of ICE and whether > that is overhead that can be saved. > > As for the non-collapsed versions, you might need to be clearer about > which part of the stack is responsible for path selection. In mode 1, this > is not particularly clear. If you think of classic ICE, you essentially > have ICE being responsible for path selection (especially with the > continuous ICE versions) and the flow that you initiate on top of it is > ignorant of path changes. That will interact somewhat poorly with a > protocol like QUIC that expects to be more involved in that process. It's > worse in mode 2, which might be quite confusing with the two layers > interacting as they do. That could stand to be made much clearer. > > Cheers, > theonewithan"i" > > On Mon, Jul 10, 2023, at 22:20, Marten Seemann wrote: > > I just submitted a new draft that describes how to do NAT traversal > using QUIC: > > https://datatracker.ietf.org/doc/draft-seemann-quic-nat-traversal/ > > > > The document defines 3 distinct modes. The first mode is the simplest > > one, first running ICE to completion to find a suitable path between > > two nodes, and then establishing a QUIC connection on that path. > > The other two modes use a proxied QUIC connection to do the ICE > > signaling (potentially using one of the protocols defined by the MASQUE > > WG), and then make use of QUIC connection migration to migrate to a > > better / direct path. > > > > This is an early draft version, and I wouldn’t be surprised if it > > wasn’t actually implementable, most likely due to my limited > > familiarity with ICE. I’d appreciate feedback if the general direction > > makes sense. > > > > Cheers, > > Marten > >
