Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
"Avasarala, Ranjit (NSN - IN/Bangalore)" <ranjit.avasarala@nsn.com> Wed, 17 July 2013 09:07 UTC
Return-Path: <ranjit.avasarala@nsn.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0B821F9E39 for <rtcweb@ietfa.amsl.com>; Wed, 17 Jul 2013 02:07:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1SN0mIJ5hEn for <rtcweb@ietfa.amsl.com>; Wed, 17 Jul 2013 02:07:04 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id EE90E21F9E13 for <rtcweb@ietf.org>; Wed, 17 Jul 2013 02:07:03 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r6H96tDd028834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 17 Jul 2013 11:06:55 +0200
Received: from SGSIHTC002.nsn-intra.net ([10.159.225.19]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r6H95kfu011010 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 11:06:54 +0200
Received: from SGSIHTC006.nsn-intra.net (10.159.225.23) by SGSIHTC002.nsn-intra.net (10.159.225.19) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 17 Jul 2013 17:05:55 +0800
Received: from SGSIMBX001.nsn-intra.net ([169.254.1.242]) by SGSIHTC006.nsn-intra.net ([10.159.225.23]) with mapi id 14.03.0123.003; Wed, 17 Jul 2013 17:05:54 +0800
From: "Avasarala, Ranjit (NSN - IN/Bangalore)" <ranjit.avasarala@nsn.com>
To: "ext Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
Thread-Topic: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
Thread-Index: AQHOgiT6JQEMzVPeD0imnIi9kp/qUZloXWjAgAAJRoCAAAceUIAAG3TAgAAKkwA=
Date: Wed, 17 Jul 2013 09:05:54 +0000
Message-ID: <E54AEADE791D51469F45E7FBB9643915090C97@SGSIMBX001.nsn-intra.net>
References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <E721D8C6A2E1544DB2DEBC313AF54DE224198182@xmb-rcd-x02.cisco.com> <51E513BF.2040405@viagenie.ca> <E721D8C6A2E1544DB2DEBC313AF54DE224199A15@xmb-rcd-x02.cisco.com> <51E536C1.1080507@viagenie.ca> <E721D8C6A2E1544DB2DEBC313AF54DE224199D69@xmb-rcd-x02.cisco.com> <51E544BC.6000608@viagenie.ca> <E54AEADE791D51469F45E7FBB9643915090BC6@SGSIMBX001.nsn-intra.net> <E721D8C6A2E1544DB2DEBC313AF54DE22419B715@xmb-rcd-x02.cisco.com> <E54AEADE791D51469F45E7FBB9643915090BF4@SGSIMBX001.nsn-intra.net> <E721D8C6A2E1544DB2DEBC313AF54DE22419BC0C@xmb-rcd-x02.cisco.com>
In-Reply-To: <E721D8C6A2E1544DB2DEBC313AF54DE22419BC0C@xmb-rcd-x02.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.225.118]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 7866
X-purgate-ID: 151667::1374052015-00002EAE-4FBC3191/0-0/0-0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jul 2013 09:07:08 -0000
My comments inline <Ranjit> Regards Ranjit -----Original Message----- From: ext Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com] Sent: Wednesday, July 17, 2013 2:16 PM To: Avasarala, Ranjit (NSN - IN/Bangalore) Cc: rtcweb@ietf.org Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt |If many public STUN servers and call servers that implement STUN or ICElite |functionalities, are not expected to support I should have said they have no role to play. It is similar to peer-to-peer ICE connectivity checks -- those checks don't go through public STUN or call servers at all. [Ranjit] But there can be scenarios where RTCWebBrowsers do talk to WebRTC Gateways which could be co-located with call handling servers. Then it won't make sense to have this feature. The difference between ICE connectivity checks and consent freshness checks is that the former is performed before session establishment and the later is performed after session establishment. [Ranjit] Why do you need to check consent of the peer after session is established? Ideally I should check consent before session establishment. If the peer does not want to receive traffic, then session itself should not be established. |then who would have interest to support this functionality? RTCWEB browsers and browser-like platforms. [Ranjit] browser may implement, but it would be very customized one. I do not think the intermediate entities would want to support. |Ideally getting consent for receiving traffic or call should be part of signaling. |I do not think using STUN is appropriate. ICE already does that. You think it is inappropriate? [Ranjit] I am saying that using STUN for consent check is not appropriate as STUN has other dedicated functionality to do - like connectivity checks, keep alives, etc. Also in cases of Symmetric NATs where STUN fails, TURN is needed. Then the proposed feature would anyway fail. Muthu |-----Original Message----- |From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:ranjit.avasarala@nsn.com] |Sent: Wednesday, July 17, 2013 12:16 PM |To: Muthu Arul Mozhi Perumal (mperumal) |Cc: rtcweb@ietf.org |Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt | |Hi Muthu | |If many public STUN servers and call servers that implement STUN or ICElite functionalities, are not |expected to support, then who would have interest to support this functionality? Ideally getting |consent for receiving traffic or call should be part of signaling. I do not think using STUN is |appropriate. | |Regards |Ranjit | | | | |-----Original Message----- |From: ext Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com] |Sent: Wednesday, July 17, 2013 12:07 PM |To: Avasarala, Ranjit (NSN - IN/Bangalore) |Cc: rtcweb@ietf.org; behave@ietf.org |Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt | |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:ranjit.avasarala@nsn.com] ||Sent: Wednesday, July 17, 2013 11:19 AM ||To: Muthu Arul Mozhi Perumal (mperumal) ||Cc: rtcweb@ietf.org; behave@ietf.org ||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: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext Simon Perreault ||Sent: Tuesday, July 16, 2013 6:34 PM ||To: Muthu Arul Mozhi Perumal (mperumal) ||Cc: rtcweb@ietf.org; behave@ietf.org ||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 ||rtcweb@ietf.org ||https://www.ietf.org/mailman/listinfo/rtcweb
- [rtcweb] FW: I-D Action: draft-muthu-behave-conse… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Simon Perreault
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Simon Perreault
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Avasarala, Ranjit (NSN - IN/Bangalore)
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Avasarala, Ranjit (NSN - IN/Bangalore)
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Eric Rescorla
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Avasarala, Ranjit (NSN - IN/Bangalore)
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Simon Perreault
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Eric Rescorla
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Avasarala, Ranjit (NSN - IN/Bangalore)
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu… Avasarala, Ranjit (NSN - IN/Bangalore)