Re: [tram] FW: New Version Notification for draft-wang-tram-turnlite-01.txt

Hi, Oleg:

Thanks for your comments. Below is my consideration for your concern points.

> -----Original Message-----
> From: Oleg Moskalenko [mailto:mom040267@gmail.com]
> Sent: Tuesday, October 28, 2014 5:56 AM
> To: Aijun Wang
> Cc: tram@ietf.org; Liubing (Leo)
> Subject: Re: [tram] FW: New Version Notification for
> draft-wang-tram-turnlite-01.txt
> 
> 
> On Oct 26, 2014, at 8:16 PM, Aijun Wang <wangaijun@tsinghua.org.cn> wrote:
> 
> > Hi, All TRAMsters
> >
> > We have submitted one new draft that describes the lightweight TURN(we
> refer it as TURNLite later) architecture and the corresponding new STUN
> message introduced in this draft. With the TURNLite solution, CP/SP can
easily
> offload the complex and troublesome deployment of TURN servers to the
> service provider, the service provider can easily integrate the data relay
> function of TURNLite server into their current distributed deployed CGN
> devices.
> > This can be a win-win solution, and meets all the communication
scenarios
> that the current TURN solution intends to solve, but in a more simple
manner.
> 
> Actually, not all the communication scenarios of the "full" TURN can be
> achieved by the TURNLite.
> 
> The "full" TURN allows pretty high degree of the network hosts privacy. If
a
> host is using TLS/DTLS protocol for the TURN communications, then the
> network infrustructure devices are not able to determine the hosts's peer
> address. The peer information is stored (ephemerally) at the TURN server
and
> it may not be retrieved by the outside parties if the TURN server is
properly
> secured.
> 
> With the TURNLite, the communication between the parties is fully
controlled
> by the host's network infrastructure. That may be a desirable quality in
some
> limited circumstances (like in a strict corporate environment), but I am
not sure
> about the general case.

Actually, under the TURNLite solution, the communication between the parties
is fully controlled by the Application provider, not the service provider.
The service provider will only relay the packets under the instruction from
the Application provider, via the newly defined "Couple" message. The
"Couple" information is stored in also ephemerally in the CGN devices and
can be withdrawn at the requirement of the Application provider.

Considering the host privacy information, I think the most important thing
is that the service provider should not know the communication contents, not
the peer's address. If one would even want the service provider be blind to
the peer address, they can accomplish this by deploying their own "Full"
TURN server, just as you mentioned that "in some limited circumstances(like
in a strict corporate environment)", for example, the security department of
one corporation). For general host-to-host communication, the hide of peer
address is not one important factor.  

TURNLite solution supports also the TLS/DTLS protocol, the communication key
is exchanged directly between the peers. The service provider can't parse
the application layer contents between the two hosts, it just only relay the
TCP/UDP data, as that they do within the CGN devices.

Aijun

> 
> >
> > We are also eager to find other cooperators that are interested in this
topic.
> Any comments are valuable.
> >
> > Mr. Liubing has apply the timeslot to present this draft in the coming
IETF
> meeting in Holununu.
> >
> > Best Regards.
> >
> > -----Original Message-----
> > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > Sent: Monday, October 27, 2014 10:07 AM
> > To: Aijun Wang; Bing Liu; Aijun Wang; Bing Liu
> > Subject: New Version Notification for draft-wang-tram-turnlite-01.txt
> >
> >
> > A new version of I-D, draft-wang-tram-turnlite-01.txt has been
successfully
> submitted by Bing Liu and posted to the IETF repository.
> >
> > Name:		draft-wang-tram-turnlite
> > Revision:	01
> > Title:		A Lightweight TURN Architecture and Specification
(TURNLite)
> > Document date:	2014-10-27
> > Group:		Individual Submission
> > Pages:		15
> > URL:
> http://www.ietf.org/internet-drafts/draft-wang-tram-turnlite-01.txt
> > Status:
https://datatracker.ietf.org/doc/draft-wang-tram-turnlite/
> > Htmlized:       http://tools.ietf.org/html/draft-wang-tram-turnlite-01
> > Diff:
> http://www.ietf.org/rfcdiff?url2=draft-wang-tram-turnlite-01
> >
> > Abstract:
> >   This document proposes a lightweight TURN architecture which
> >   simplifies the application provider side complexity of implementing
> >   TURN server by transfering the data relay processing to the ISP
> >   infrastructure (e.g.  CGN).  To achieve this goal, a new "Couple"
> >   operation using STUN message format is also defined.
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of
submission
> until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
> >
> >
> >
> > _______________________________________________
> > tram mailing list
> > tram@ietf.org
> > https://www.ietf.org/mailman/listinfo/tram