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

From: Ted Hardie <[email-masked]>
Date: Mon, 7 Apr 2014 11:20:05 -0700

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 <[email-masked]>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

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 11 Apr 2014 10:16:00 +0000

Hi Ted,

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

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

>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