[rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness

[Ted Hardie <[e-mail]>]

Howdy,

The chairs recently asked for a review
draft-ietf-rtcweb-stun-consent-freshness; Oleg was kind enough to do one.
Below is the review.

regards,

Ted


On Fri, Apr 4, 2014 at 12:40 AM, Oleg Moskalenko <[e-mail]>wrote:
Hi Ted

I went through the document and I have two things to comment:

1) This document defines a "voluntary" pattern of the browser behavior.
Nothing stops the determined attacker from taking the WebRTC code and
creating a malicious client application that ignores all proposed
connectivity checks. May be it is worth mentioning in the "Security
Considerations" section.

2) I have a feeling that the document is written with somewhat optimistic
idea about the modern IP network qualities. The proposed timeouts are
probably too small. I am hearing from our TURN server users that in modern
Wi Fi public networks that's common to observe a freeze the IP traffic for
several seconds. After that "freeze" the connectivity is restored. The
users do not want the connection to be broken during that time - they want
the video screen frozen, temporary. I had to make adjustments to the TURN
server in our recent versions so that it does not disconnects the sessions
too quickly under those conditions (when TCP is used). I have a feeling
that you may have the same complains that the browser stops transmission in
public Wi Fi networks too quickly. I'd suggest to review the wording of the
proposal (like re-transmission after 500 ms and 15 secs timeout) to make it
more tolerant for the bad IP networks (which are surprisingly are rather
common).

Overall, I think that this proposal is very useful.

Best regards,
Oleg