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