Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Tue, 26 November 2013 11:14 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E6A1ADFA0 for <rtcweb@ietfa.amsl.com>; Tue, 26 Nov 2013 03:14:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.552
X-Spam-Level:
X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bssPWyMQZ8BC for <rtcweb@ietfa.amsl.com>; Tue, 26 Nov 2013 03:14:46 -0800 (PST)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 602EB1AE1B2 for <rtcweb@ietf.org>; Tue, 26 Nov 2013 03:14:46 -0800 (PST)
Received: from [10.225.15.120] (unknown [194.95.73.101]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id A16081C0C0692; Tue, 26 Nov 2013 12:14:44 +0100 (CET)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <913383AAA69FF945B8F946018B75898A2426E369@xmb-rcd-x10.cisco.com>
Date: Tue, 26 Nov 2013 12:14:43 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <49668FCC-875C-4567-946C-4D6C759B9EA4@lurchi.franken.de>
References: <CEAB0083.6FBE3%rmohanr@cisco.com>, <5285E318.3090006@ericsson.com>, <BLU169-W10885AF717BCBB60830502093E60@phx.gbl>, <CABkgnnVpikDFwzfc=6CnHDOb6rmoe5-54AdYPyrbRvU34Epfig@mail.gmail.com> <BLU169-W11416B2C0D42888C078A7F493E60@phx.gbl> <913383AAA69FF945B8F946018B75898A2426E369@xmb-rcd-x10.cisco.com>
To: Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>
X-Mailer: Apple Mail (2.1510)
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, "draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org" <draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org>
Subject: Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 26 Nov 2013 11:14:49 -0000

On Nov 26, 2013, at 11:34 AM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>; wrote:

> Hi Bernard,
> 
> Yes, this needs to be discussed further. With DTLS, there is no need to send consent checks if authentic SRTP/SRTCP packets are being received.  we may also want to compare DTLS heartbeat mechanism with STUN consent. Some of my observations:
> 
> [1] Remote peer may or may not support DTLS heartbeat. 
> [2] DTLS heartbeat can only be sent if remote peer accepts heartbeat request. 
> 
> [1] and [2] can be solved by mandating WebRTC endpoints to support consent.
> 
> [3] DTLS heartbeat seems to be more CPU intensive than STUN consent (Generating arbitrary content (payload and padding 40 bytes), encrypting it). Though this may not a concern since heartbeat will only be sent when authenticated packets are not received.
> 
> [4] DTLS heartbeat doubles the timer value at each retransmission but with STUN consent retransmission is repeated every 500ms. There seems to be no application level control on the retransmission mechanism used by OpenSSL DTLS implementation. 
> 
> [5] With STUN consent, browser can find the RTT time which is not possible with OpenSSL DTLS heartbeat API. 
> 
> [4] and [5] need enhancement in OpenSSL.
As you say: This is just an implementation issue of one particular implementation, not an issue with the protocol itself...

Best regards
Michael
> 
> -Tiru.
> 
> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] 
> Sent: Thursday, November 21, 2013 12:02 AM
> To: Martin Thomson
> Cc: Magnus Westerlund; draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org; rtcweb@ietf.org; Eric Rescorla
> Subject: RE: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00
> 
>> I think that it's at least in good enough shape to put up for wider discussion.
>> http://tools.ietf.org/html/draft-thomson-rtcweb-consent-00
>> 
>> Overall, I think that this is cleaner. The main advantage is that any
>> authenticated data counts toward refreshing consent. That means zero
>> overhead in many common cases.
> 
> [BA] I have to agree that it is worth discussing, particularly given the potential for zero additional overhead. 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>