IETF Logo Mail Archive

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

"Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com> Tue, 26 November 2013 10:34 UTC

Return-Path: <tireddy@cisco.com>
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 9C4BE1ADFDA for <rtcweb@ietfa.amsl.com>; Tue, 26 Nov 2013 02:34:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 FhhiTaCsKjYj for <rtcweb@ietfa.amsl.com>; Tue, 26 Nov 2013 02:34:12 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2E06F1ADFA0 for <rtcweb@ietf.org>; Tue, 26 Nov 2013 02:34:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1971; q=dns/txt; s=iport; t=1385462052; x=1386671652; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vYJZZ05/pJ3gn/8SeDKP1jJiKBz4Jgpozma89vvJbRA=; b=PpvvwUrKsYWlqwVT/L++mE/iQGkLYkXxB9KG5RYXOGxY9TDrLKvIlsRf YBzUZ0HwTrvhiKOGxyM6bgKY2jdtSQt4M2TH10ing4oV67AHRoNsLFPDr x3NI17JHpVuqbZpFdpaNwzNO7C34/ZCfOAZ5FkuugtYArz8tpzMf7FcJv 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFAPd3lFKtJXG8/2dsb2JhbABZgwc4U6kqkmyBKhZ0giUBAQEDAXkFCwIBCBEEAQELHQcyFAkIAgQBDQUIh2cDCQYNvyUXjGeBXjEHgyCBEwOJCo0ggxqLKYU4gyiBaAc7
X-IronPort-AV: E=Sophos;i="4.93,773,1378857600"; d="scan'208";a="287573523"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 26 Nov 2013 10:34:11 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rAQAYB0d011014 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Nov 2013 10:34:11 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Tue, 26 Nov 2013 04:34:11 -0600
From: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>, Martin Thomson <martin.thomson@gmail.com>
Thread-Topic: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00
Thread-Index: AQHO5h7F18JxZ44GPE2jRnBwqO7Il5o3GL0w
Date: Tue, 26 Nov 2013 10:34:10 +0000
Message-ID: <913383AAA69FF945B8F946018B75898A2426E369@xmb-rcd-x10.cisco.com>
References: <CEAB0083.6FBE3%rmohanr@cisco.com>, <5285E318.3090006@ericsson.com>, <BLU169-W10885AF717BCBB60830502093E60@phx.gbl>, <CABkgnnVpikDFwzfc=6CnHDOb6rmoe5-54AdYPyrbRvU34Epfig@mail.gmail.com> <BLU169-W11416B2C0D42888C078A7F493E60@phx.gbl>
In-Reply-To: <BLU169-W11416B2C0D42888C078A7F493E60@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.69.77]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org" <draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org>, "rtcweb@ietf.org" <rtcweb@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 10:34:13 -0000

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.

-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. 

v2.23.0 | Report a Bug | By Email