MIME-Version: 1.0
In-Reply-To: <EAF548B7-09BE-4C64-AC44-4EE02EFC96F7@cisco.com>
References: <20130819171507.30712.24757.idtracker@ietfa.amsl.com>
 <52128C29.4040402@alvestrand.no>
 <EAF548B7-09BE-4C64-AC44-4EE02EFC96F7@cisco.com>
Date: Mon, 19 Aug 2013 19:54:45 -0400
Message-ID: <CAD5OKxtB5K2+33UKandrKn_fe6XY6FO_VWAptfcLqvOQ1MCufw@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Dan Wing <dwing@cisco.com>
Content-Type: multipart/alternative; boundary=001a11c38c8234236304e455aa15
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt
Precedence: list

--001a11c38c8234236304e455aa15
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Aug 19, 2013 at 7:20 PM, Dan Wing <dwing@cisco.com> wrote:

>
> On Aug 19, 2013, at 2:20 PM, Harald Alvestrand <harald@alvestrand.no>
> wrote:
> Section 2.2,
> "   o  TURN, including TURN over TCP [[QUESTION: and TURN over TLS]],
>       [RFC5766]."
>
> 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.
>

It is useful to support TURN over TLS for two reasons:

1. To hide the remote party IP address in TURN allocations from anybody who
is monitoring the local IP connection
2. To traverse restrictive firewalls that only allow HTTP/HTTPS connections
by placing a TURNS server on port 443

I would think that for those two reasons TURN-TLS should be MUST implement.
_____________
Roman Shpount

--001a11c38c8234236304e455aa15
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Aug 19, 2013 at 7:20 PM, Dan Wing <span dir=3D"ltr">&lt;<a href=3D"mail=
to:dwing@cisco.com" target=3D"_blank">dwing@cisco.com</a>&gt;</span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
On Aug 19, 2013, at 2:20 PM, Harald Alvestrand &lt;<a href=3D"mailto:harald=
@alvestrand.no">harald@alvestrand.no</a>&gt; wrote:<br>
Section 2.2,<br>
&quot; =A0 o =A0TURN, including TURN over TCP [[QUESTION: and TURN over TLS=
]],<br>
=A0 =A0 =A0 [RFC5766].&quot;<br>
<br>
Most -- but not all -- of the security obtained with TURN over TLS is achie=
ved with TURN REST (draft-uberti-behave-turn-rest and draft-uberti-rtcweb-t=
urn-rest). =A0I think the working group should consider if TURN REST satisf=
ies the requirements, or if TURN over TLS is really, really necessary.<br>
</blockquote></div><br></div><div class=3D"gmail_extra">It is useful to sup=
port TURN over TLS for two reasons:<br><br></div><div class=3D"gmail_extra"=
>1. To hide the remote party IP address in TURN allocations from anybody wh=
o is monitoring the local IP connection<br>
</div><div class=3D"gmail_extra">2. To traverse restrictive firewalls that =
only allow HTTP/HTTPS connections by placing a TURNS server on port 443<br>=
<br></div><div class=3D"gmail_extra">I would think that for those two reaso=
ns TURN-TLS should be MUST implement.<br>
</div><div class=3D"gmail_extra"><div>_____________<br>Roman Shpount</div>
<br></div></div>

--001a11c38c8234236304e455aa15--