Re: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness

Christer Holmberg <> Fri, 22 May 2015 03:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 196561A90C1; Thu, 21 May 2015 20:55:12 -0700 (PDT)
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 qd5vm6H5tCLO; Thu, 21 May 2015 20:55:10 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 073571A90BB; Thu, 21 May 2015 20:55:09 -0700 (PDT)
X-AuditID: c1b4fb3a-f79ec6d000006dc0-90-555ea89be708
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id D8.6E.28096.B98AE555; Fri, 22 May 2015 05:55:07 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0210.002; Fri, 22 May 2015 05:55:06 +0200
From: Christer Holmberg <>
To: Martin Thomson <>, Bernard Aboba <>
Thread-Topic: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness
Thread-Index: AQHQk1ePQtH0SmDHm02NITW7o6QoRZ2G7maAgABv25A=
Date: Fri, 22 May 2015 03:55:06 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvre7sFXGhBs+Xylls2Pef2WLGn4nM FtfO/GO0WPuvnd2BxWPnrLvsHkuW/GQKYIrisklJzcksSy3St0vgylj46Q5bwWqeiv6JZxgb GJ9ydjFyckgImEjs2rqeFcIWk7hwbz0biC0kcJRR4vcEhS5GLiB7MaPEzAcrgIo4ONgELCS6 /2mD1IgIREg0X7nHCGIzCzhKXLyykRnEFhbwkJhy+xIzRI2nxPttN1ghbCuJm6cugs1nEVCV OD93DVgNr4CvRHfrNkaIXdMZJY4d6gIr4hQIlNi0ciGYzQh03PdTa5gglolL3HoynwniaAGJ JXvOM0PYohIvH/+DekZJYsX2S1DH6Ugs2P2JDcLWlli28DXUYkGJkzOfsExgFJuFZOwsJC2z kLTMQtKygJFlFaNocWpxcW66kZFealFmcnFxfp5eXmrJJkZgTB3c8ttqB+PB546HGAU4GJV4 eBVsYkOFWBPLiitzDzFKc7AoifN6doWECgmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamCcdq4g 65Lwtf/9Sw9dPpOTq73kO+P5r9vEqi0Yyh4/LXhRNy3lme8a6+++Bxb99XbONEmS/znLfGnb G+HeyQFrs0RVmlzM3DNv+jw4z7fj+UpWnvTwEIVubtW/mUbTjmqqN9ZrTGP4mv3m5xa3DHbF rK9Cr+6aBRrIimt8CHydqOCXMMXN9LMSS3FGoqEWc1FxIgCdPOYEigIAAA==
Archived-At: <>
Cc: "" <>, The IESG <>
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness
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: Fri, 22 May 2015 03:55:12 -0000



>> 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, is needed to obtain consent to send.
>> [BA] The second sentence does not follow from the first. RFC 5245 
>> enables sending of media once a successful ICE connectivity check has been received.
>> If multiple successful candidate pairs have been identified, why 
>> should failure of consent on one candidate pair require an ICE restart 
>> if another operational candidate pair exists?
>... is needed to obtain consent to send *on that candidate pair*.
>There was a long discussion about this point, the conclusion of which was "use it or lose it".  This captures that >conclusion.  I can't remember the details of the discussion, but I think that it wasn't a security concern but a >robustness one.

A while ago, we agreed that consent does not need to be maintained on candidate pairs that aren't currently used. That should not be seen as lost consent (i.e. if the UA wants to start sending data on the candidate pair it should not have to do ICE restart or create a  new session).

So, consent is lost if the UA sends consent requests, and does not receive a response. Consent is NOT lost if the UA stops sending consent requests (and therefor obviously will not receive a response).

Perhaps that is clear in the draft, but if people have a different understanding it may need to be clarified :)