Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt

["Muthu Arul Mozhi Perumal (mperumal)" <[e-mail]>]

Ranjit,

|Many publicly available STUN servers or those that are part of Call servers
|may not support this.

Public STUN servers and call servers are not expected to support this.

|Can't there be some other neutral mechanism to query peer's consent - through 
|signaling?

No. That signaling between the JS and the web server could be anything (SIP or XMPP or proprietary or whatever) and the browser has no control over it.

Muthu

|-----Original Message-----
|From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:[e-mail]]
|Sent: Wednesday, July 17, 2013 11:19 AM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: [e-mail]; [e-mail]
|Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
|
|Hi Muthu
|
|Though using STUN request/response may be good for querying about consent, I feel it is overloading
|the functionality of STUN. Many publicly available STUN servers or those that are part of Call servers
|may not support this.
|
|Can't there be some other neutral mechanism to query peer's consent - through signaling?
|
|
|Regards
|Ranjit
|
|
|
|-----Original Message-----
|From: [e-mail] [mailto:[e-mail]] On Behalf Of ext Simon Perreault
|Sent: Tuesday, July 16, 2013 6:34 PM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: [e-mail]; [e-mail]
|Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
|
|Le 2013-07-16 14:43, Muthu Arul Mozhi Perumal (mperumal) a écrit :
|> |> |>    Liveness timer: If no packets have been received on the local port in
|> |> |>    Tr seconds, the WebRTC browser MUST inform the JavaScript that
|> |> |>    connectivity has been lost.  The JavaScript application will use this
|> |> |>    notification however it desires (e.g., cease transmitting to the
|> |> |>    remote peer, provide a notification to the user, etc.).
|> |> |
|> |> |This seems to me like it will not fulfill the goal set in the abstract:
|> |> |"to ensure that a malicious JavaScript cannot use the browser as a
|> |> |platform for launching attacks". If the JavaScript is free to ignore the
|> |> |notification from the browser, then it has no security benefits. If you
|> |> |want to reach that goal, the browser needs to forcefully stop transmitting.
|> |>
|> |> That goal is fulfilled by the consent checks -- the browser would stop transmitting everything on
|> |that candidate pair, including liveness checks, if there is a consent failure.
|> |
|> |That's not what the draft says. It says that the browser "notifies" the
|> |JS app. It needs to say that the browser MUST stop sending.
|>
|> No. That section is about liveness check and its intention is just notify the JavaScript of a
|potential connectivity loss. It is when the consent check fails the browser actually stops sending
|everything. Does the draft need more text on the distinction between consent and liveness tests?
|
|Ah! No, you're right, and the text is already perfectly clear about
|this. No need to change. I was just confused.
|
|> |> |>    When not actively sending traffic on a nominated candidate pair,
|> |> |>    performing consent freshness does not serve any purpose from a
|> |> |>    security perspective.
|> |> |
|> |> |I don't understand what this means. Why is the "security perspective"
|> |> |important here? Aren't we concerned about keepalives?
|> |>
|> |> You mean one could use keepalives (Binding indications) for launching attacks, so consent
|freshness
|> |would be required for sending them as well?
|> |
|> |No.
|> |
|> |This is a section about keepalives. I just don't understand this
|> |sentence, and I don't understand why it talks about security.
|>
|> Ok, let me elaborate:
|> - Consent freshness is not necessary when the browser is not sending any
|>   traffic on a candidate pair.
|> - If the browser is not performing consent freshness on a candidate pair
|>   for the above reason, it performs ICE keepalives (or RTP keepalives) to
|>   refresh NAT bindings.
|>
|> Of course, the browser could continue performing consent freshness even when it is not sending any
|other traffic on that candidate pair and skip ICE keepalives.
|
|Ah, ok I understand with your explanation. It makes sense. There should
|be a way to reformulate the text to make it clearer.
|
|Thanks,
|Simon
|_______________________________________________
|rtcweb mailing list
|[e-mail]
|https://www.ietf.org/mailman/listinfo/rtcweb