Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
"Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com> Thu, 18 July 2013 10:28 UTC
Return-Path: <mperumal@cisco.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 687DD21E80CB for <rtcweb@ietfa.amsl.com>; Thu, 18 Jul 2013 03:28:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.466
X-Spam-Level:
X-Spam-Status: No, score=-10.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 TPnXVIx1KQdA for <rtcweb@ietfa.amsl.com>; Thu, 18 Jul 2013 03:28:53 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1359921E80C8 for <rtcweb@ietf.org>; Thu, 18 Jul 2013 03:28:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10861; q=dns/txt; s=iport; t=1374143333; x=1375352933; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=nqHELum5M6wvmEf+/2651Cu9Ve5zkjw27doWclXsolE=; b=Idl2NqAQfUQnfHdTAIpIH9/P2PXrj0O8yP/Zk8WMz+PIyBpkSo6jcBY9 uHt99tWcHyfKB+JNDQbeR5QzBlo2Zcpot36yBaHvW9l9O/ObG5RziNVem wLzcOp9RP1HDL/IPE/BpZAOec3Y5qhnrjxGJirFgQv9H7TucFBouURFu8 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Aj0FAM7B51GtJXG+/2dsb2JhbABagwY0UMA+gQ8WdIIjAQEBAQMBAQFrCwwEAgEIEQQBAQsdBycLFAgBCAIEDgUIE4d1DLZRBI9JBisHBoMHbgOIb6A6gVmBOYFoBQI5
X-IronPort-AV: E=Sophos;i="4.89,692,1367971200"; d="scan'208";a="236383016"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 18 Jul 2013 10:28:52 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6IASqWs016784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Jul 2013 10:28:52 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Thu, 18 Jul 2013 05:28:51 -0500
From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
To: "Avasarala, Ranjit (NSN - IN/Bangalore)" <ranjit.avasarala@nsn.com>
Thread-Topic: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
Thread-Index: AQHOgiT6JQEMzVPeD0imnIi9kp/qUZloXWjAgAAJRoCAAAceUIAAG3TAgAAKkwCAAFNjgIABRHCQgAAS5sA=
Date: Thu, 18 Jul 2013 10:28:50 +0000
Message-ID: <E721D8C6A2E1544DB2DEBC313AF54DE22419E53C@xmb-rcd-x02.cisco.com>
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> <E54AEADE791D51469F45E7FBB9643915090C97@SGSIMBX001.nsn-intra.net> <E721D8C6A2E1544DB2DEBC313AF54DE22419C5B2@xmb-rcd-x02.cisco.com> <E54AEADE791D51469F45E7FBB9643915090FBA@SGSIMBX001.nsn-intra.net>
In-Reply-To: <E54AEADE791D51469F45E7FBB9643915090FBA@SGSIMBX001.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [72.163.208.250]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.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: Thu, 18 Jul 2013 10:28:58 -0000
|-----Original Message----- |From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:ranjit.avasarala@nsn.com] |Sent: Thursday, July 18, 2013 2:51 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 | |One more question - Would consent freshness be an additional feature as part of ICE functionality? Yes. | |Regards |Ranjit | | | |-----Original Message----- |From: ext Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com] |Sent: Wednesday, July 17, 2013 7:48 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 | ||-----Original Message----- ||From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:ranjit.avasarala@nsn.com] ||Sent: Wednesday, July 17, 2013 2:36 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 || ||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. | |An RTCWeb gateway wouldn't have to do anything fancier than what it already does for ICE connectivity |checks. | || ||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. | |See draft-ietf-rtcweb-security-arch: | |<snip> |4.4. Communications and Consent Freshness | | From a security perspective, everything from here on in is a little | anticlimactic: Alice and Bob exchange data protected by the keys | negotiated by DTLS. Because of the security guarantees discussed in | the previous sections, they know that the communications are | encrypted and authenticated. | | The one remaining security property we need to establish is "consent | freshness", i.e., allowing Alice to verify that Bob is still prepared | to receive her communications so that Alice does not continue to send | large traffic volumes to entities which went abruptly offline. ICE | specifies periodic STUN keepalizes but only if media is not flowing. | Because the consent issue is more difficult here, we require RTCWeb | implementations to periodically send keepalives. As described in | Section 5.3, these keepalives MUST be based on the consent freshness | mechanism specified in [I-D.muthu-behave-consent-freshness]. If a | keepalive fails and no new ICE channels can be established, then the | session is terminated. |</snip> | || |||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. | |You seem to be completely missing the very purpose of consent. | || |||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. | |See draft-ietf-rtcweb-security and draft-ietf-rtcweb-security. | ||Also in cases of Symmetric NATs where STUN fails, TURN is needed. Then the proposed feature would |anyway fail. | |The solution is built on top of ICE, so should work across these. | |Muthu | || ||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)