[rtcweb] FW: Adopting draft-muthu-behave-consent-freshness?
"Lijing (Jessie, Huawei)" <lijing80@huawei.com> Thu, 12 September 2013 07:58 UTC
Return-Path: <lijing80@huawei.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 C028F21E808C for <rtcweb@ietfa.amsl.com>; Thu, 12 Sep 2013 00:58:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level:
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4]
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 lWHY7trlfCUv for <rtcweb@ietfa.amsl.com>; Thu, 12 Sep 2013 00:58:31 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 350AF11E8160 for <rtcweb@ietf.org>; Thu, 12 Sep 2013 00:58:31 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVI17367; Thu, 12 Sep 2013 07:58:23 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 12 Sep 2013 08:57:35 +0100
Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 12 Sep 2013 08:57:46 +0100
Received: from szxeml558-mbs.china.huawei.com ([169.254.8.31]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.007; Thu, 12 Sep 2013 15:57:41 +0800
From: "Lijing (Jessie, Huawei)" <lijing80@huawei.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] Adopting draft-muthu-behave-consent-freshness?
Thread-Index: AQHOrTfux2KRel+DmEaaqMlDUjQllpnAHbDwgAGeH0A=
Date: Thu, 12 Sep 2013 07:57:40 +0000
Message-ID: <A3045C90BB645147BC99159AA47ABAC741A14C11@szxeml558-mbs.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.171.171]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [rtcweb] FW: Adopting draft-muthu-behave-consent-freshness?
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, 12 Sep 2013 07:58:35 -0000
Hi all, As a newcomer to RTCWEB, I have some doubts after I have read the draft. 1. in "4. Solution Overview", may be it would be better to clarify when to send a STUN Binding Request(in the middle of a media session or before sending traffic, during sending traffic or only during silence periods) and which side to send the request(controlling agent or both sides)? 2. in " 7. Security Considerations", there are the following words. As when one agent receives STUN Binding Request, unlike the processing of indication message, it have to do more processes to send the Response message, I am not sure whether it is appreciate not to authenticate the source and respond directly. Is it more open to malicious attacks? "Once that connection to the remote peer has been established with ICE, the consent to continue sending traffic does not benefit from re-asserting that same username and password, so long as the senders and receiver's IP addresses remain the same (as they usually do)." Neglect my words, if my understandings are wrong. Best regards, Jessie -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus Westerlund Sent: Monday, September 09, 2013 4:37 PM To: rtcweb@ietf.org Subject: [rtcweb] Adopting draft-muthu-behave-consent-freshness? WG, This is a call for WG adoption of STUN Usage for Consent Freshness (draft-muthu-behave-consent-freshness-04). This document defines a STUN usage for consent freshness. As this requires no protocol extensions we as intended users can define this usage in our WG. Such work also matches our charter. The draft-ietf-rtcweb-security-arch-07 is normatively dependent on this STUN usage. Document: https://datatracker.ietf.org/doc/draft-muthu-behave-consent-freshness/ WG, please indicate your support or issues with adopting this document as WG item with a proposed milestone: Mar 2014 Send STUN Usage for Consent Freshness to IESG for publication as proposed standard. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
- [rtcweb] Adopting draft-muthu-behave-consent-fres… Magnus Westerlund
- Re: [rtcweb] Adopting draft-muthu-behave-consent-… Simon Perreault
- Re: [rtcweb] Adopting draft-muthu-behave-consent-… Harald Alvestrand
- Re: [rtcweb] Adopting draft-muthu-behave-consent-… Christer Holmberg
- [rtcweb] Consent freshness in the light of no-SDE… Harald Alvestrand
- Re: [rtcweb] Consent freshness in the light of no… Christer Holmberg
- Re: [rtcweb] Adopting draft-muthu-behave-consent-… Alfred E. Heggestad
- Re: [rtcweb] Adopting draft-muthu-behave-consent-… Bernard Aboba
- Re: [rtcweb] consent freshness vs. circuit breake… Bernard Aboba
- Re: [rtcweb] Adopting draft-muthu-behave-consent-… Charles Eckel (eckelcu)
- Re: [rtcweb] Consent freshness in the light of no… Martin Thomson
- Re: [rtcweb] Consent freshness in the light of no… Martin Thomson
- Re: [rtcweb] Adopting draft-muthu-behave-consent-… Martin Thomson
- Re: [rtcweb] Adopting draft-muthu-behave-consent-… Gonzalo Salgueiro (gsalguei)
- Re: [rtcweb] Adopting draft-muthu-behave-consent-… Victor Pascual
- Re: [rtcweb] Adopting draft-muthu-behave-consent-… Timothy B. Terriberry
- Re: [rtcweb] Adopting draft-muthu-behave-consent-… Eric Rescorla
- Re: [rtcweb] Adopting draft-muthu-behave-consent-… Mishra, Sanjay
- Re: [rtcweb] consent freshness vs. circuit breake… Dan Wing
- Re: [rtcweb] Adopting draft-muthu-behave-consent-… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] Adopting draft-muthu-behave-consent-… Lijing (Jessie, Huawei)
- Re: [rtcweb] Adopting draft-muthu-behave-consent-… Mishra, Sanjay
- [rtcweb] FW: Adopting draft-muthu-behave-consent-… Lijing (Jessie, Huawei)
- Re: [rtcweb] FW: Adopting draft-muthu-behave-cons… Ram Mohan R (rmohanr)
- [rtcweb] Continuing to assert username/password (… Harald Alvestrand
- Re: [rtcweb] Adopting draft-muthu-behave-consent-… Magnus Westerlund
- Re: [rtcweb] Continuing to assert username/passwo… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] Continuing to assert username/passwo… Harald Alvestrand
- Re: [rtcweb] Continuing to assert username/passwo… Tirumaleswar Reddy (tireddy)