IETF Logo Mail Archive

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

"Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com> Wed, 27 November 2013 02:06 UTC

Return-Path: <mperumal@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 A1C251AE051 for <rtcweb@ietfa.amsl.com>; Tue, 26 Nov 2013 18:06:50 -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 A7IrOLlMnY1S for <rtcweb@ietfa.amsl.com>; Tue, 26 Nov 2013 18:06:48 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD9B1AE061 for <rtcweb@ietf.org>; Tue, 26 Nov 2013 18:06:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2613; q=dns/txt; s=iport; t=1385518003; x=1386727603; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3NB0I2CTXAN52EWuqnwQ+iXRN/caDTCFe/ll83Ifksc=; b=Uqzte8gVIhkrJX2xzgvyB8fP+Y9Lm9uREgxuonoO8lPWlfKuM3+F+smL 7Ielg5QyeiixSLee6kUXuW6bQ2tLzb2D0akc1xZWad73ov+fbcaOnm/xq f514+6NR51q+wVrz7AFEZXENbOp594L2Xik0PynHqfWOGvSLIBzp3E9Tw I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQFAMdSlVKtJXHB/2dsb2JhbABZgwc4U7o2ToEnFnSCJQEBAQQBAQE3NAsMBAIBCBEEAQELFAkHJwsUCQgCBAENBQiHeQ2/URMEjksxBwaDGoETA6ongyiCKg
X-IronPort-AV: E=Sophos;i="4.93,779,1378857600"; d="scan'208";a="287759423"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 27 Nov 2013 02:06:43 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rAR26hhR015402 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Nov 2013 02:06:43 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.34]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 26 Nov 2013 20:06:42 -0600
From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
To: Martin Thomson <martin.thomson@gmail.com>, "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
Thread-Topic: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00
Thread-Index: AQHO6tMq3kHRuwrIQkmVqlzIxQ7eZJo4UCJA
Date: Wed, 27 Nov 2013 02:06:41 +0000
Message-ID: <E721D8C6A2E1544DB2DEBC313AF54DE224363368@xmb-rcd-x02.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> <913383AAA69FF945B8F946018B75898A2426E369@xmb-rcd-x10.cisco.com> <CABkgnnU5RqbF-PPtihGU+rtuqemN9f7N7nXLB05_OpF7EmhxjQ@mail.gmail.com>
In-Reply-To: <CABkgnnU5RqbF-PPtihGU+rtuqemN9f7N7nXLB05_OpF7EmhxjQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.69.150]
Content-Type: text/plain; charset="us-ascii"
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: Wed, 27 Nov 2013 02:06:50 -0000

Are there cases where you won't do ICE but do DTLS, for WebRTC? If not, I think you can combine the best of both:
- The initial consent is established by ICE connectivity checks already.
- The receipt of any authenticated packet, including DTLS heartbeat, grants 
  you consent to send more packets.
- If you doesn't receive any packet and consent is about to expire, send a 
  STUN binding request that is comparatively less CPU intensive.

Minimal overhead overall :)

Muthu

|-----Original Message-----
|From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Martin Thomson
|Sent: Tuesday, November 26, 2013 11:43 PM
|To: Tirumaleswar Reddy (tireddy)
|Cc: draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org; rtcweb@ietf.org
|Subject: Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00
|
|These are good observations.
|
|On 26 November 2013 02:34, Tirumaleswar Reddy (tireddy)
|<tireddy@cisco.com> wrote:
|> [1] and [2] can be solved by mandating WebRTC endpoints to support consent.
|
|Yes, that would be the plan.  We would also have to force the
|inclusion of peer_allowed_to_send(1) in the extension, lest things get
|perverse.
|
|> [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.
|
|I'm thinking: a) not a concern because it's only a factor if you
|aren't sending, and b) not a concern because it's not a lot of work to
|generate an authenticated packet.  Less work I think if you are using
|AES-GCM modes.
|
|> [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.
|
|That's a good point, I'll have to check to see if we need to update
|6520, or whether just saying to avoid retransmission is sufficient.
|(I think the latter, but don't care too much.)
|
|> [5] With STUN consent, browser can find the RTT time which is not possible with OpenSSL DTLS
|heartbeat API.
|
|This is true to exactly the same extent for both forms.  Some STUN
|implementations don't allow for the sending of a single check, they
|also do the full exponential backoff thing.
|_______________________________________________
|rtcweb mailing list
|rtcweb@ietf.org
|https://www.ietf.org/mailman/listinfo/rtcweb

v2.23.0 | Report a Bug | By Email