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

["Ram Mohan R (rmohanr)" <[e-mail]>]

Hi Ted,

Thanks for forwarding the feedback from Oleg. Please see inline for answers


>
>
>From:  Ted Hardie <[e-mail]>
>Date:  Monday, 7 April 2014 11:50 pm
>To:  "[e-mail]" <[e-mail]>, Oleg Moskalenko
><[e-mail]>
>Subject:  [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness
>
>
>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.

Agree. A malicious browser that does not conform to this spec can do any
thing. I am not sure if we really any text to be added for that in the
draft.

>
>
>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).

Agree. We had revised a lot of text in the solution description section of
the draft (draft-ietf-rtcweb-stun-consent-freshness-02).
The text now is very generic and does not assume any specific timer
values. Please review the latest text and let us know if that looks ok.

Regards,
Ram

>
>
>Overall, I think that this proposal is very useful.
>
>
>Best regards,
>Oleg
>