ice-lite or not to lite?

[Alex Cohn]

I have a media server with a public IP in the cloud and on the face of it I can use ice-lite for the server offer (video and audio). The question is whether switching to ice-lite will give me some advantage it terms of handshake time, performance, server load, whatever…

My server is not intended to connect to multiple clients in parallel, but there are multiple server instances sharing the same public IP (with different UPD port ranges). My clients are native iOS and Android apps, which both receive and send both video and audio.

Thanks,

Alex Cohn

[Sean DuBois]

ice-lite does provide some advantages. The improvements will not be substantial,

probably not worth it. 

If your server is running in `ice-lite` it  will do less work. Instead of doing all the processing 

required by a controlled ICE Agent, it will just respond to traffic. You will see less server load from this.

I would measure how much reduction in resource usage (network and CPU) this gets you. I don't expect much.

Your ICE state will move to `connected` quicker.  Moving to `connected` quicker will not reduce

how quickly you see video though. When ICE Agents are connecting they can still exchange data, as long as

 authentication has succeeded. 

If enabling `ice-lite` is just a flag I would turn it on and measure. Otherwise your time is probably better spent elsewhere :)

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/7f287650-0bb3-4a10-a5e9-f93392131659n%40googlegroups.com.

[Roman Shpount]

There are no benefits to ice-lite except ice-lite being easier to implement. There are no CPU savings that you can measure. The setup time is longer. Most importantly, with ice-lite, your media server is not getting consent from the remote party to send media. This means that if your signaling is compromised in any way, your server can be used for DOS attacks. In other words, ice-lite is not recommended, and full ice implementation should always be preferred. 

[Sean DuBois]

> setup time is longer
What makes the setup time longer?

> your server can be used for DOS attacks

Interesting I didn't consider the DOS, how would that work?

If I send a UDP packet with a spoofed src the ice-lite agent would send
a packet to the spoofed src. If the WebRTC server is the DTLS Client it
may also send a DTLS Client Hello to the spoofed src. Is any
amplification possible beyond that?

How does compromised signaling play into this? I could abuse a ICE lite
server with this today.

> There are no CPU savings that you can measure

ice-lite agent do not generate connectivity checks or run state
machines. It isn't a lot of work, but depending on someones workload it
could matter!

-----

Should we discourage/remove ice-lite from WebRTC implementations? If it
fundamentally has flaws (like the DOS) it is probably worth convincing
Open Source ICE limitations to deprecate it :)

> >> <https://groups.google.com/d/msgid/discuss-webrtc/7f287650-0bb3-4a10-a5e9-f93392131659n%40googlegroups.com?utm_medium=email&utm_source=footer>
> >> .

> >>
> >
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/56ca9691-cbd3-4b45-85e5-48534690e3cdn%40googlegroups.com.

[Roman Shpount]

On Wednesday, August 17, 2022 at 3:51:06 PM UTC-4 se...@pion.ly wrote:

> setup time is longer
What makes the setup time longer?

If you are dealing with the original RFC 5245 implementation, then aggressive ICE nomination will be disabled. If the client is on public IP,  the server waits for the client to start the ICE negotiation, which delays it by half a round-trip.

> your server can be used for DOS attacks

Interesting I didn't consider the DOS, how would that work?

If I send a UDP packet with a spoofed src the ice-lite agent would send
a packet to the spoofed src. If the WebRTC server is the DTLS Client it
may also send a DTLS Client Hello to the spoofed src. Is any
amplification possible beyond that?

 

I think SDES is still supported by at least some of the servers, which will definitely result in traffic multiplication. Requiring DTLS should prevent this.

How does compromised signaling play into this? I could abuse a ICE lite
server with this today.

 

SDP still needs to be sent to the media server. This implies compromised signaling. 

> There are no CPU savings that you can measure
ice-lite agent do not generate connectivity checks or run state
machines. It isn't a lot of work, but depending on someones workload it
could matter!

Considering the number of ICE packets processed, it should not matter in comparison with the load generated even by simple network processing of RTP. If the server is doing encryption, ICE processing should be negligible.

Should we discourage/remove ice-lite from WebRTC implementations? If it
fundamentally has flaws (like the DOS) it is probably worth convincing
Open Source ICE limitations to deprecate it :)

It is already discouraged.

Please see https://datatracker.ietf.org/doc/html/rfc8445#appendix-A:

ICE allows a lite implementation to have a single IPv4 host candidate and several IPv6 addresses.  In that case, candidate pairs are selected by the controlling agent using a static algorithm, such as the one in RFC 6724, which is recommended by this specification. However, static mechanisms for address selection are always prone to error, since they can never reflect the actual topology or provide actual guarantees on connectivity.  They are always heuristics. Consequently, if an ICE agent is implementing ICE just to select between its IPv4 and IPv6 addresses, and none of its IP addresses are behind NAT, usage of full ICE is still RECOMMENDED in order to provide the most robust form of address selection possible.

Same thing in the original specification https://datatracker.ietf.org/doc/html/rfc5245#appendix-A:

It is important to note that the lite implementation was added to this specification to provide a stepping stone to full implementation.  Even for devices that are always connected to the public Internet with just a single IPv4 address, a full implementation is preferable if achievable.  A full implementation will reduce call setup times, since ICE's aggressive mode can be used. Full implementations also obtain the security benefits of ICE unrelated to NAT traversal; in particular, the voice hammer attack described in Section 18 is prevented only for full implementations, not lite.

It is a good idea to read both of those references to see why lite implementations should be avoided. Supporting both implementations in the same library makes no sense, except for testing purposes.

[Alex Cohn]

Thanks a lot. The RFC definitely makes it clear.

Alex Cohn

[Michal Śledź]

FYI, aggressive nomination was removed in RFC 8445 which obsoletes RFC 5245

https://www.rfc-editor.org/rfc/rfc8445.html#section-21

[Nils Ohlmeier]

Which then raises the question if there are any 8445 implementations out there (yet)?