[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