Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt

"Tirumaleswar Reddy (tireddy)" <> Tue, 20 August 2013 09:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 150F411E81B0 for <>; Tue, 20 Aug 2013 02:09:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9y9Yt+-Gj5iE for <>; Tue, 20 Aug 2013 02:09:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 98C0611E81FE for <>; Tue, 20 Aug 2013 02:09:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4177; q=dns/txt; s=iport; t=1376989765; x=1378199365; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7rD5C/fYJ7Kyc48yfro3dl+2GrM3wwSuzDfz/4ZNc4c=; b=meUWn+cExKf2CZdlGV9BO6NZe28+v5UVFzaFpIpUtC0h1MKU3bIB8wRd 9lLcPyHvSpEWclA+UqRXwi0Uz5pdqUKAdw9TEpJv8LeQgl4sWIF0keUxU rvOTKE9rsjdOEAGt0IU/MwFsos0mArcTnpIvadLJUs240VNbhCPCA+v3F 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.89,918,1367971200"; d="scan'208";a="249371517"
Received: from ([]) by with ESMTP; 20 Aug 2013 09:09:24 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r7K99OYA002848 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 Aug 2013 09:09:24 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Tue, 20 Aug 2013 04:09:23 -0500
From: "Tirumaleswar Reddy (tireddy)" <>
To: "Dan Wing (dwing)" <>, Bernard Aboba <>
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt
Thread-Index: AQHOnQACPiyyHuYBZE+f9i52g6QhP5mdXbuAgAAhmwCAAHAqgIAAA9eA//+7DVA=
Date: Tue, 20 Aug 2013 09:09:23 +0000
Message-ID: <>
References: <>, <>, <> <BLU169-W11E1423497EE1A503309E793430@phx.gbl> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Aug 2013 09:09:45 -0000

> -----Original Message-----
> From: [] On Behalf Of
> Dan Wing (dwing)
> Sent: Tuesday, August 20, 2013 11:46 AM
> To: Bernard Aboba
> Cc:
> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt
> On Aug 19, 2013, at 11:02 PM, Bernard Aboba <> wrote:
> > Dan Wing said:
> >
> > > Section 2.2,
> > > "In order to deal with firewalls that block all UDP traffic, TURN over
> > > TCP MUST be supported. (QUESTION: What about ICE-TCP?)"
> > >
> > > ICE-TCP allows direct peer-to-peer communications using TCP, without a
> TURN server doing TCP-to-UDP interworking. I would say the industry has less
> experience with ICE-TCP than with ICE or with TURN-over-TCP, and because of
> the less experience and because ICE-TCP is arguably an *optimization*, I would
> say ICE-TCP is a MAY. It can't be a MUST-level requirement, at least by my
> threshold for MUST which is that interoperability is harmed or
> interoperability is impossible.
> >
> > [BA]  While ICE-TCP will only eliminate the need for TURN over TCP in a
> fraction of NAT usage cases, the benefits can be substantial in the situations
> where it does work (and is needed).  The most popular uses of ICE-TCP so far
> are for things like P2P chat (e.g. MSRP), application sharing and RTP over
> TCP.  Given that WebRTC  could implement MSRP over the data channel, and could
> handle screen sharing via RTP over UDP,  the case probably needs to be made
> based on TURN-less conveyance of RTP over TCP (probably in a consumer scenario
> only, since for enterprise the TURN server would most likely be needed for
> firewall traversal reasons).  It's definitely not a MUST, and probably not a
> SHOULD either for WebRTC.
> >
> > > Most -- but not all -- of the security obtained with TURN over TLS is
> achieved with TURN REST (draft-uberti-behave-turn-rest and draft-uberti-
> rtcweb-turn-rest). I think the working group should consider if TURN REST
> satisfies the requirements, or if TURN over TLS is really, really necessary.
> >
> > [BA] Not sure I follow this.   TURN over TLS provides confidentiality for
> the relay addresses and also some firewall traversal benefits.  TURN REST is
> trying to solve a different problem entirely (e.g. misuse of TURN
> credentials).
> TURN REST solves misuse of credentials and significantly reduces ability to do
> traffic analysis of the TURN client by someone sniffing between the TURN
> client and TURN server (username="dwing" sent plaintext between the TURN
> client and TURN server).

TURN REST resolves the problem of third party authorization but does not address other problems like TURN server deployed in Enterprise for auditing purpose (which requires first party authentication - username needs to sent over TURN over TLS).


> > Personally, I don't think TURN REST really minimizes the risk to the extent
> necessary, since time limiting the credentials alone won't necessarily stop an
> ingenious (and greedy) thief.  As an example, when hackers gain control of a
> PBX they can run up shocking bills in a very short period of time, and even if
> TURN charges are minimal, you'd be surprised at what Internet miscreants can
> do with stolen credentials within a 24 hour period.  So to my mind, TURN REST
> needs some additional bolstering to limit the potential financial liability,
> such as bandwidth limits.
> I expect something like a bandwidth limit is something that can be encoded
> into the TURN REST username that is coordinated between the WebRTC server and
> its cooperative TURN server.  It might be better to encode that properly,
> rather than by overloading bits of the username.  But perhaps a more elegant
> solution, rather than bandwidth limits, could be engineered.
> -d
> _______________________________________________
> rtcweb mailing list