Re: [rtcweb] consent freshness and ICE-lite

"Muthu Arul Mozhi Perumal (mperumal)" <> Tue, 17 July 2012 09:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9C8E421F8528 for <>; Tue, 17 Jul 2012 02:43:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.523
X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Yk07gFwtThoN for <>; Tue, 17 Jul 2012 02:43:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A35E821F8541 for <>; Tue, 17 Jul 2012 02:43:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=21964; q=dns/txt; s=iport; t=1342518251; x=1343727851; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ScMAdxSJpDyzJ+8caNTEduzBLRaMAD8+KsGyJy/JyCs=; b=T6o9rv9M4eIMhWjBwxnhB4mnZre3BPaa9d8W7POaK1Fbw13x48GfKLGv 1Q5ccgUhEpBpjU4kttJMFnyrrY78uAy6iRLZBra7JoNx4JOZ16BfynPEL sEAhGBgwy7+/7qKSdpJ4l2SDlV110+VCwqozV0QU3j1b/gq/YeWQ/nr2G 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="4.77,601,1336348800"; d="scan'208,217"; a="102551497"
Received: from ([]) by with ESMTP; 17 Jul 2012 09:44:10 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id q6H9iAlu003241 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Jul 2012 09:44:10 GMT
Received: from ([]) by ([]) with mapi id 14.02.0298.004; Tue, 17 Jul 2012 04:44:09 -0500
From: "Muthu Arul Mozhi Perumal (mperumal)" <>
To: Bernard Aboba <>
Thread-Topic: [rtcweb] consent freshness and ICE-lite
Thread-Index: AQHNY8w9W2cZs2lHjUu9YW6rsDo7W5cs7BwAgABnlgD//9wgYA==
Date: Tue, 17 Jul 2012 09:44:09 +0000
Message-ID: <>
References: <> <BLU401-EAS266337B57B89CAB7E5E2D3893DB0@phx.gbl> <> <BLU401-EAS427580C5793EC88085DA83093DB0@phx.gbl>
In-Reply-To: <BLU401-EAS427580C5793EC88085DA83093DB0@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-as-product-ver: SMEX-
x-tm-as-result: No--51.995600-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_E721D8C6A2E1544DB2DEBC313AF54DE2012D5574xmbrcdx02ciscoc_"
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [rtcweb] consent freshness and ICE-lite
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 Jul 2012 09:43:27 -0000

There are gateways that run applications like TCL and XML scripts written by users. They are typically deployed in constrained environments running trusted scripts, so generally not an issue. That doesn't however preclude a deployment where the gateway runs untrusted scripts or a browser -:)

While performing consent freshness and liveness tests are mandatory for a WebRTC browser, it is optional for a gateway, I believe.


From: Bernard Aboba []
Sent: Tuesday, July 17, 2012 11:47 AM
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: Ejzak, Richard P (Richard);
Subject: Re: [rtcweb] consent freshness and ICE-lite

Since it's a gateway not a browser, presumably it doesn't support JavaScript.  So there is no "application"  an attacker can run on the gateway, there is just (static) gateway code.

On Jul 16, 2012, at 22:43, "Muthu Arul Mozhi Perumal (mperumal)" <<>> wrote:
Right, consent is requested by the sender and granted by the receiver. While one side has granted consent for receiving on a candidate pair, the other side could have revoked it. So consent verification/freshness is unilateral.

A gateway/browser implementing ICE-lite will only be able to grant consent to send, but will not be able to request consent. So, a malicious application can use it for sending unwanted traffic.

Liveness determines continued connectivity on a candidate pair. Since the networks paths can be asymmetric, both ends need to perform the liveness test.


From:<> [] On Behalf Of Bernard Aboba
Sent: Tuesday, July 17, 2012 9:03 AM
To: Ejzak, Richard P (Richard)
Subject: Re: [rtcweb] consent freshness and ICE-lite

Consent freshness and liveness is used to assure a browser that the recipient has authorized it to
send media and that it is still there. So if a gateway wants to receive, answer Binding Requests
sent to it.

If a gateway is on the public Internet, supports ICE lite and does not send a Binding Request
to a browser, but does implement RFC 6263, then NAT bindings can be kept alive and media
should still flow.  So I think this is viable.

On Jul 16, 2012, at 18:13, "Ejzak, Richard P (Richard)" <<>> wrote:

Sections 4.2, 4.4 and 5.3 of draft-ietf-rtcweb-security-arch-03.txt have text that seems to be contradictory.  In particular, 5.3 requires support of ICE-lite at server gateways but each endpoint is described as sending ICE binding requests for ICE consent verification in 4.2 (which is it?).  4.4 also requires RTCWeb implementations to perform periodic binding requests to verify consent freshness.  Is a server gateway an RTCWeb implementation subject to this requirement?  I thought that one of the reasons the WG decided to use binding requests instead of binding indications to allow bilateral consent initiated by a single endpoint (in particular, so that an RTCWeb browser could interoperate with either a server gateway implementing ICE-lite or a non-RTCWeb endpoint not implementing the RTCWeb consent freshness procedures in such a way that only the RTCWeb browser needed to send periodic binding requests to maintain bilateral consent freshness).

Does a binding request provide unilateral or bilateral consent verification/freshness?

Is a server gateway implementing ICE-lite required to send ICE binding requests anyway for consent verification and/or consent freshness, or is it sufficient for such an implementation to indicate its own consent by just responding to received binding requests?

Do we care about compatibility with ICE compliant endpoints that do not use binding requests for consent freshness?

Does a browser treat a response to a binding request the same as a received binding request for consent freshness?

It would be helpful to have clear answers to these questions in the security architecture document.


Richard Ejzak

rtcweb mailing list<>