Mobility: Peer reflexive candidates

[lgrahl]

Consider a host that just changed its network and got a new globally reachable address (IPv6 or no NAT). If that host now sends connectivity checks from its new address to the other peer's remote address, then the remote peer will pick it up as a peer reflexive candidate and the connection can just continue to work. Correct?

If yes: Perhaps we can add it as a note that this is already possible if the peer who changes its network is not behind a NAT or an overly restrictive firewall. Does the candidate need to be signalled eventually for the consent freshness mechanism? If no: Can we make it work and add it to the NV requirements?

[nils-ohlmeier]

This question appears to imply that ICE has some kind of continuous gathering going on. Which is NOT the case. Once ICE has connected (or failed) the ICE agent will/should ignore new network interfaces (unless/until you do an ICE restart).

[aboba]

@nils-ohlmeier I think this can be concluded from RFC 8445, Section 9:

The following actions can be accomplished only by using an ICE restart (the agent MUST use ICE restarts to do so):

o Change the destinations of data streams. o Change from a lite implementation to a full implementation. o Change from a full implementation to a lite implementation.

Only way I could see it working is if the end-of-candidate indication was not conveyed, in which case draft-ietf-ice-trickle Section 15 might apply. It doesn't specifically talk about peer reflexive candidates though (e.g. they aren't really "conveyed").

15. Subsequent Exchanges and ICE Restarts

    Before conveying an end-of-candidates indication, either agent MAY convey subsequent candidate information at any time allowed by the using protocol. When this happens, agents will use [rfc5245bis] semantics (e.g., checking of the Username Fragment and Password combination) to determine whether or not the new candidate information requires an ICE restart.

    If an ICE restart occurs, the agents can assume that Trickle ICE is still supported if support was determined previously, and thus can engage in Trickle ICE behavior as they would in an initial exchange of ICE descriptions where support was determined through a capabilities discovery method.

[lgrahl]

I would not like to limit ourselves to what is standardised for ICE as of today.

ICE restarts are moot in a break before make scenario if signalling is required. Because signalling is in 99,9% of the cases also affected by the loss of a previous network path. ICE has the potential to solve this (without relay). If one establishes a new path, I don't see why it can't be used. That limitation seems artificial.

[nils-ohlmeier]

@lgrahl feel free to re-open the IETF ICE WG (about to be closed). But what you desire here is a protocol which can dynamically switch over to new interfaces on the fly. I'm pretty sure if someone would implement something like this he/she would face lots of problems with the streams switching widely back and forth between interfaces between devices with multiple path between them. I'm not saying is not solvable, but it's quite a bit harder problem then what ICE is designed to solve.

[lgrahl]

Not claiming that this is low hanging or anything but...

Doesn't webrtc.org already do on-the-fly path switching? I'm certain I've seen the native stack switch from WiFi to mobile on iOS devices when WiFi dies, without requiring explicit signalling. The only thing that would be different is that one would discover a new path and add that to the list of potential paths for failover.

[aboba]

@lgrahl The fruit is so low hanging that it has already been picked.

Prior to nomination, on-the-fly switching via new candidates/pairs is supported in existing standards. However, after nomination pairs (and candidates) are pruned, so to go beyond TURN mobility, a mechanism is needed to gather additional candidates or renominate pruned candidates. ORTC supports the former via IceGatherer.gather(), and webrtc.org (via WebRTC-ICE) supports the latter via IceTransport.gather() but either of these API extensions requires ICE protocol functionality that is beyond what is defined in RFC 8445 or Trickle ICE. Unfortunately, the Ortc lib and webrtc.org libraries don't extend ICE in exactly the same way.

So the functionality you are asking for is already implemented in existing libraries and supported (though not particularly well defined) in W3C API specifications and yet at the same time, is not standardized in the IETF ;(

[the8472]

Couldn't this be done on the transport level instead? MP-TCP is deployed on some android devices and MP-QUIC is an IETF draft. Adding and signalling additional endpoints is done by a userspace daemon that reacts to network changes such as roaming between wifi and mobile.

[juberti]

@the8472 it would be much easier to do this in ICE with QUIC running atop ICE as a virtual transport. As @aboba says, almost all the stuff we need is already there.