How much of ICE do we want to specify?

[huitema]

ICE is a rather complex protocol, but the underlying ideas are simple:

• Assume an established channel over which the peer can coordinate
• Endpoints are behind NAT. If they send a packet towards a destination IP and port, they often cannot predict the exact source IP and port.
  • But with the help of STUN servers and possibly UPNP or NAT-PMP, try to predict the IP+port at which they can be reachable through the local set of NATs
  • Of course this is guesswork.
• Each endpoint communicates the set of plausible IP + port numbers pairs to the peer over the signalling channel
• Each of the endpoints send a set of probes to these guessed port numbers
  • Many of these probes will not make it, because of firewall rules such as only accepting incoming traffic on an IP and port if there was some outgoing traffic in the same direction,
  • but the hope is that there will be that out of the set of packets sent by each endpoint, there will be at least one in which the guessing worked.
• If one of the probe made it through, confirm that to the peer. There is now a workable peer-to-peer path.
• In no probe arrives, then fall back to a proxy of some kind, for example using TURN.

There are additional complexities:

• sending probes has side effects. For example, sending too many probes forces the local NAT to create as many mapping context, and some of these NAT only support a small set of simultaneous mapping. Thus, the strategy of sending 256 packets from each side and relying on the birthday paradox may not be the best.

• sending list of IP addresses has privacy issues, especially when disclosing addresses behind the NAT, so consider using some substitute, e.g, a randomized Bonjour name.

• tricking a peer to send a bunch of messages to random addresses can obviously be used in DOS attacks

Which means we do not have just one message, but rather 3 or 5:

• An address message, "here is my list of addresses", sent over the signalling channel, which in our case could be a proxied QUIC connection.
• A probe message, sent to one of the candidate peer address+port, which could be very similar to a PATH_CHALLENGE
• A probe response, which could be very similar to a PATH_RESPONSE
• Maybe an address response, as in "I see your packet as coming from IP=A, Port=P", by which the endpoint could learn how its own address is seen by the peer.
• Maybe some synchronization message, as in "try me now", because the port opening only works well if both endpoints send their packets within a short interval.

We can debate whether the probing should use existing frames (e.g. PATH_CHALLENGE) or a new ICE frame, but we would have to explain that these ICE frames are sent on the probed paths, just like path challenge.

Since this is a rather complex issue, it might be simpler to start with the scenario in which there is an existing proxied connection between the two endpoints, and we are merely trying to migrate the traffic to a direct path.

[huitema]

NAT rebinding can happen at either end, and will break the "peer-to-peer" path. It might make sense to start from Multipath QUIC, with one path through the proxy and another for the peer-to-peer shortcut.

Multipath is currently limited to establishment of new paths by the client. If peer-to-peer defines an Address Advertisement frame, the multipath-enabled server could use it to tell the client to establish another "preferred" path.

[marten-seemann]

@huitema Are you suggesting to drop ICE entirely? I agree that ICE is quite complex, and I've spent a fair amount of time reading the RFCs, and I'm not sure I've fully understood it... However, I also don't want to reinvent the wheel. It seems like ICE already solves all the points you list in the first two lists of your post. Where do you see the simplification coming from when dropping ICE for our own home-grown protocol?

---

It might make sense to start from Multipath QUIC, with one path through the proxy and another for the peer-to-peer shortcut.

This definitely should work well with Multipath QUIC (that actually should be a design goal of this protocol), but I'd prefer to not make it a requirement, if we can avoid it. RFC 9000 allows keeping several paths alive, and endpoints could keep the proxied connection alive (by regularly sending probing packets) after they've migrated to a direct path. On the other hand, this is probably not what the proxy wants: It wants to free up resources as quickly as possible. How does ICE handle this?

NAT rebinding can happen at either end, and will break the "peer-to-peer" path.

Do we have any numbers on how often NAT rebindings actually happen, and if they can be avoided by more aggressive keep-alives? Given the trouble endpoints have gone through to establish a hole-punched connections, it might be justified to invest more into keeping the NAT binding alive (e.g. send a PING frame at least every 5s or so). It would be nice if we could base this kind of recommendation on data though.

[huitema]

I think supporting both RFC9000 and Multipath is more complex than just doing multipath alone. I also think that starting from multipath allows for incremental development, such as, after having a multipath capable proxy connection. Maybe for example, test local discovery first, then traversal of IPv6 stateful firewall, then add discovery of NATed addresses.

[marten-seemann]

https://github.com/marten-seemann/draft-seemann-quic-nat-traversal/pull/11 completely changed how this draft uses ICE. I believe this resolves this issue.