From: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>,
 "Dan Wing (dwing)" <dwing@cisco.com>, Harald Alvestrand <harald@alvestrand.no>
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt
Thread-Index: AQHOnQACPiyyHuYBZE+f9i52g6QhP5mdXbuAgAAhmwCAAHAqgP//wRxQ
Date: Tue, 20 Aug 2013 09:36:01 +0000
Message-ID: <913383AAA69FF945B8F946018B75898A1902EBFA@xmb-rcd-x10.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>
In-Reply-To: <BLU169-W11E1423497EE1A503309E793430@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt
Precedence: list

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 Bernard Aboba
Sent: Tuesday, August 20, 2013 11:32 AM
To: Dan Wing (dwing); Harald Alvestrand
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt

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?)"
>=20
> ICE-TCP allows direct peer-to-peer communications using TCP, without a TU=
RN 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 w=
ould say ICE-TCP is a MAY. It can't be a MUST-level requirement, at least b=
y my threshold for MUST which is that interoperability is harmed or interop=
erability is impossible.

[BA] =A0While ICE-TCP will only eliminate the need for TURN over TCP in a f=
raction of NAT usage cases, the benefits can be substantial in the situatio=
ns where it does work (and is needed). =A0The most popular uses of ICE-TCP =
so far are for things like P2P chat (e.g. MSRP), application sharing and RT=
P over TCP. =A0Given that WebRTC =A0could implement MSRP over the data chan=
nel, and could handle screen sharing via RTP over UDP, =A0the case probably=
 needs to be made based on TURN-less conveyance of RTP over TCP (probably i=
n a consumer scenario only, since for enterprise the TURN server would most=
 likely be needed for firewall traversal reasons). =A0

[TR] Firewall traversal problems in Enterprise can also be resolved by usin=
g PCP-controlled Firewall without the need for TURN server and is discussed=
 in sections 3.1, 3.2 of draft http://tools.ietf.org/html/draft-penno-rtcwe=
b-pcp-00=20

--Tiru.

It's definitely not a MUST, and probably not a SHOULD either for WebRTC. =
=A0

> Most -- but not all -- of the security obtained with TURN over TLS is ach=
ieved with TURN REST (draft-uberti-behave-turn-rest and draft-uberti-rtcweb=
-turn-rest). I think the working group should consider if TURN REST satisfi=
es the requirements, or if TURN over TLS is really, really necessary.

[BA] Not sure I follow this. =A0 TURN over TLS provides confidentiality for=
 the relay addresses and also some firewall traversal benefits. =A0TURN RES=
T is trying to solve a different problem entirely (e.g. misuse of TURN cred=
entials). =A0Personally, I don't think TURN REST really minimizes the risk =
to the extent necessary, since time limiting the credentials alone won't ne=
cessarily stop an ingenious (and greedy) thief. =A0As an example, when hack=
ers gain control of a PBX they can run up shocking bills in a very short pe=
riod of time, and even if TURN charges are minimal, you'd be surprised at w=
hat Internet miscreants can do with stolen credentials within a 24 hour per=
iod. =A0So to my mind, TURN REST needs some additional bolstering to limit =
the potential financial liability, such as bandwidth limits.=A0