IETF Logo Mail Archive

Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness

"Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com> Mon, 25 August 2014 17:08 UTC

Return-Path: <Raju.Makaraju@alcatel-lucent.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 2B7531A0030 for <rtcweb@ietfa.amsl.com>; Mon, 25 Aug 2014 10:08:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.567
X-Spam-Level:
X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 y8PBDIXI6cJt for <rtcweb@ietfa.amsl.com>; Mon, 25 Aug 2014 10:08:42 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F01021A0052 for <rtcweb@ietf.org>; Mon, 25 Aug 2014 10:08:25 -0700 (PDT)
Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 8A22EC98314D2; Mon, 25 Aug 2014 17:08:22 +0000 (GMT)
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s7PH8O8Z016866 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Aug 2014 13:08:24 -0400
Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.175]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Mon, 25 Aug 2014 13:08:24 -0400
From: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>
To: Roman Shpount <roman@telurix.com>
Thread-Topic: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness
Thread-Index: AQHPwITci/5CKoOiV024j3Ir7ToL8JvhiWMg
Date: Mon, 25 Aug 2014 17:08:23 +0000
Message-ID: <E1FE4C082A89A246A11D7F32A95A17828E52F290@US70UWXCHMBA02.zam.alcatel-lucent.com>
References: <CAKz0y8ws+ARTZaVRpMBcRc_mmc_8cEHdurt=nQ39xdSwtNPPRw@mail.gmail.com> <CAD5OKxs9=YPZGUzQxHkuP8KQA6iV_ntJ8PWKtyJa9tioMhBBuA@mail.gmail.com> <CAKz0y8xDcFtLFDPGBopJ5QNHh21TSxvVcEuSKRPhL6rJUqf7uQ@mail.gmail.com> <E1FE4C082A89A246A11D7F32A95A17828E52EB28@US70UWXCHMBA02.zam.alcatel-lucent.com> <CAD5OKxu7XGCTvk2R91DFzo8+H0EA8S42ZHagVNmGpHj0G5fFsg@mail.gmail.com>
In-Reply-To: <CAD5OKxu7XGCTvk2R91DFzo8+H0EA8S42ZHagVNmGpHj0G5fFsg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.16]
Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E52F290US70UWXCHMBA02z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/439uRfb7vko6eP_nrMZtPZoW2cs
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness
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: Mon, 25 Aug 2014 17:08:45 -0000


From: Roman Shpount [mailto:roman@telurix.com]
Sent: Monday, August 25, 2014 11:52 AM

On Mon, Aug 25, 2014 at 11:08 AM, Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com<mailto:Raju.Makaraju@alcatel-lucent.com>> wrote:
ICE RFC 5245 says ICE-lite clients don’t do candidate gathering+connectivity checks, it does NOT explicitly talks about NOT using STUN for other purpose like consent freshness.
Yes, consent freshness uses the same STUN messages. That should not be a reason to exclude ICE-lite clients from consent freshness checks.

ICE-lite endpoints have same security concerns as ICE-full endpoints. IMHO, independent of STUN connectivity checks, the draft should allow ICE-lite client to do consent freshness, which means the other end (ICE-full or ICE-lite) should acknowledge the STUN requests sent by ICE-lite clients. I believe this is already supported by Chrome and Firefox.

If someone goes through the trouble of implementing sending STUN bind requests needed for consent freshness, why would not they implement full ICE? Incremental work (ie state machine) is not that great.
<Raju2>
IMO, ICE gathering, connectivity checks, prioritization etc. is much more work than doing just consent checks.
ICE-lite entities (please note gateways in specific) don’t implement ICE-full because they can get away with ICE-lite due to presence of public ip. Why complicate an implementation unnecessarily?
</Raju2>

Sending consent freshness or any other STUN requests is not prohibited by ICE-lite clients, but it is not defined anywhere either. Let's not define something which has no reason to exist.
<Raju2>
IMHO, consent checks for ICE-lite have a security reason to exist; the same security reason why ICE-full clients needed it. Isn’t draft-ietf-rtcweb-stun-consent-freshness right place to define this?
</Raju2>

BR
Raju
_____________
Roman Shpount

v2.23.0 | Report a Bug | By Email