IETF Logo Mail Archive

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

"Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com> Tue, 03 December 2013 04:47 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 EC4BD1ADFC4 for <rtcweb@ietfa.amsl.com>; Mon, 2 Dec 2013 20:47:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.502
X-Spam-Level:
X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 HYlm76N5Vjbs for <rtcweb@ietfa.amsl.com>; Mon, 2 Dec 2013 20:47:27 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 40A811ADF6B for <rtcweb@ietf.org>; Mon, 2 Dec 2013 20:47:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1757; q=dns/txt; s=iport; t=1386046045; x=1387255645; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1wPeqnQVjkuaKuRVB1mmPla0UXFSh5AY9JvihOT6Tc8=; b=mxVzNbEogtLN1USJVwZKY5Yzw7qgn4cvwqNR1Nfo0jzZDFmOnrTJmdYK S6ccm6G5gh/hwwySByoGhKZ2fNAqSsi2qQIQpD8FJyUC3J6+B9jcEUKq0 FD4t0//+BLN3yD2EN+gb7bbWqI0UE2x2zlwE7bSDroUwgrlMewPhWJbGN g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAGlhnVKtJV2c/2dsb2JhbABZgweBC7hqgRoWdIIlAQEBBDo/DAQCAQgRBAEBCxQJBzIUCQgCBAENBQiHecBtF45XMQcGgxqBEwOqJ4Mpgio
X-IronPort-AV: E=Sophos;i="4.93,815,1378857600"; d="scan'208";a="3842545"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP; 03 Dec 2013 04:47:24 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rB34lNXh022754 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 04:47:24 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.34]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Mon, 2 Dec 2013 22:47:23 -0600
From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
To: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>, Christer Holmberg <christer.holmberg@ericsson.com>, Martin Thomson <martin.thomson@gmail.com>
Thread-Topic: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00
Thread-Index: AQHO60O63kHRuwrIQkmVqlzIxQ7eZJo4sw3AgABpCYD//+ogoIAI5OWw
Date: Tue, 03 Dec 2013 04:47:22 +0000
Message-ID: <E721D8C6A2E1544DB2DEBC313AF54DE22436FC23@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> <7594FB04B1934943A5C02806D1A2204B1C55D40B@ESESSMB209.ericsson.se> <913383AAA69FF945B8F946018B75898A2426EF4D@xmb-rcd-x10.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C55D48D@ESESSMB209.ericsson.se> <913383AAA69FF945B8F946018B75898A2426F209@xmb-rcd-x10.cisco.com>
In-Reply-To: <913383AAA69FF945B8F946018B75898A2426F209@xmb-rcd-x10.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [72.163.208.29]
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: Tue, 03 Dec 2013 04:47:29 -0000

|-----Original Message-----
|From: Tirumaleswar Reddy (tireddy)
|Sent: Wednesday, November 27, 2013 6:32 PM
|To: Christer Holmberg; Martin Thomson
|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
|
|> -----Original Message-----
|> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
|> Sent: Wednesday, November 27, 2013 1:32 PM
|> To: Tirumaleswar Reddy (tireddy); Martin Thomson
|> 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
|>
|> Hi,
|>
|> >>> [1] and [2] can be solved by mandating WebRTC endpoints to support
|> consent.
|> >>
|> >> I thought we were going to do that anyway - no matter what consent
|> >> mechanism we use.
|> >
|> > If DTLS based consent mechanism is picked then both peers must support DTLS
|> heartbeat and willing to exchange DTLS heartbeat request/response.
|>
|> How is that different from using ICE for consent? That also require support
|> from both peers, doesn't it ?
|
|Yes, ICE for consent also requires support from both peers.

No, there is one difference when the peer is not sending any traffic (e.g VoD):
For the STUN based mechanism, the peer is required to support only ICE-lite (or ICE) for the sender to verify consent freshness. With the DTLS based mechanism, the peer is required to support DTLS Heartbeat (RFC6520) and respond to HeartbeatRequest messages for the sender to verify consent freshness. That is asking more from legacy implementations.

Muthu

|
|-Tiru.
|
|>
|> Regards,
|>
|> Christer

v2.23.0 | Report a Bug | By Email