Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Dan Wing <dwing@cisco.com>
In-Reply-To: <BLU169-W11E1423497EE1A503309E793430@phx.gbl>
Date: Mon, 19 Aug 2013 23:16:09 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <A156A84B-0824-4826-8544-980916965E91@cisco.com>
References: <20130819171507.30712.24757.idtracker@ietfa.amsl.com>,
 <52128C29.4040402@alvestrand.no>,
 <EAF548B7-09BE-4C64-AC44-4EE02EFC96F7@cisco.com>
 <BLU169-W11E1423497EE1A503309E793430@phx.gbl>
To: Bernard Aboba <bernard_aboba@hotmail.com>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt
Precedence: list

On Aug 19, 2013, at 11:02 PM, Bernard Aboba <bernard_aboba@hotmail.com> =
wrote:

> Dan Wing said:
>=20
> > 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?)"
> >=20
> > 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.
>=20
> [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. =
=20
>=20
> > 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.
>=20
> [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). =20

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=3D"dwing" sent plaintext =
between the TURN client and TURN server).

> 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.=20

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