Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions

Christer Holmberg <> Thu, 20 November 2014 16:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BA5E11A1B29 for <>; Thu, 20 Nov 2014 08:29:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RmEl6q828JgI for <>; Thu, 20 Nov 2014 08:29:03 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 94E741A1AE3 for <>; Thu, 20 Nov 2014 08:29:00 -0800 (PST)
X-AuditID: c1b4fb30-f79e66d000000ff1-1a-546e16ca1af2
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id DD.98.04081.AC61E645; Thu, 20 Nov 2014 17:28:58 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Thu, 20 Nov 2014 17:28:58 +0100
From: Christer Holmberg <>
To: Martin Thomson <>, "Ram Mohan R (rmohanr)" <>
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions
Thread-Index: Ac/yEUlFgzg9keX0RtqfGQOICUeeIwMelQGAAS/qitAASiGsAAAFh1AAABTZMDA=
Date: Thu, 20 Nov 2014 16:28:58 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM+Jvje4psbwQgws3zC2unfnHaLG8awej xdp/7ewOzB5Tfm9k9dg56y67x5IlP5kCmKO4bFJSczLLUov07RK4Mr5272csuCZYsWXtJvYG xjmCXYycHBICJhL3l19hgbDFJC7cW8/WxcjFISRwhFGi6csEFghnCaNE3+MO1i5GDg42AQuJ 7n/aIA0iAjESl6fvZwSxmQXUJe4sPscOYgsL5Eu0Hp3EDlFTIHG64QwjhO0n8b/xJpjNIqAq 0bb/B5jNK+ArsenabUaIXYuYJM69gUhwCgRKHNxzmAnEZgS67vupNUwQy8Qlbj2ZzwRxtYDE kj3nmSFsUYmXj/+xQthKEotuf2YCuZlZQFNi/S59iFZFiSndD9kh9gpKnJz5hGUCo9gsJFNn IXTMQtIxC0nHAkaWVYyixanFSbnpRkZ6qUWZycXF+Xl6eaklmxiBEXVwy2+DHYwvnzseYhTg YFTi4TWIzA0RYk0sK67MPcQozcGiJM678Ny8YCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M Em3qV6crVP75axIkvbTNgvNZ4d3WiZom5pcfXu478j0y2T5P+5hwpkGa9Ar+es59bySX/T6y boZQ8qNHWzmnHrIrT7z69MvxN5OmTfj4wnyNzi6Hq1NvPf++Pynnz493Cxdb3Myp3i5ziudD 0hre/p0y5+fXlX1KXhK6l98ysJ2Fj9+lrubxFiWW4oxEQy3mouJEAD3ap1CJAgAA
Cc: "" <>
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions
X-Mailman-Version: 2.1.15
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: Thu, 20 Nov 2014 16:29:11 -0000

Hi Martin,

>It is really hard following these threads, but it looks like this is being over-thought.
>"This document defines what it takes to obtain, maintain, and lose consent to send. Consent 
>to send applies to a single 5-tuple. What applications choose to do with this information is not 
>described in this document."
>Add that to the introduction perhaps. We run the risk of expanding scope otherwise.

I agree that we don't need to specify application behaviour. But, I think we do need to be clear regarding the impacts on the transport/ICE layer, when/if/how it can be later re-used etc.

>As for the question of re-acquisition of consent, I think that we should keep it simple. For this:
>"After consent is lost for any reason, the same ICE credentials MUST NOT be used on the affected 5-tuple again. 
>That means that a new session, or an ICE restart at least, is needed to obtain consent to send."

My question is how/if the consent lost impacts "normal" ICE (STUN keep-alives etc), transport layer heartbeats etc.

Also, as the entity may still receive media on the 5-tuple, that also means it still have to respond to incoming STUN requests etc.

I think that should be clear in the draft. 

>I think that we should consider a keep alive as application data, and subject to rules of consent.
>The text should note that firewall and NAT bindings could be lost, instead.

I am ok with such approach, as long as we document it :)

What about DTLS heartbeats, and other information sent on the transport layer? I ASSUME the entity will maintain those, as it still may receive media