Re: [midcom] updated TURN draft

Se-Chang Son <sschang@cs.wisc.edu> Wed, 05 October 2005 20:11 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENFbz-0000mi-51; Wed, 05 Oct 2005 16:11:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENCDJ-0001OG-5M for midcom@megatron.ietf.org; Wed, 05 Oct 2005 12:33:53 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03074 for <midcom@ietf.org>; Wed, 5 Oct 2005 12:33:50 -0400 (EDT)
Received: from basalt.cs.wisc.edu ([128.105.6.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENCMD-0000QY-3h for midcom@ietf.org; Wed, 05 Oct 2005 12:43:06 -0400
Received: from [128.105.185.18] (cedric.cs.wisc.edu [128.105.185.18]) by basalt.cs.wisc.edu (8.13.1/8.13.1) with ESMTP id j95GXlkv014524 for <midcom@ietf.org>; Wed, 5 Oct 2005 11:33:47 -0500
Message-ID: <4344006B.1020001@cs.wisc.edu>
Date: Wed, 05 Oct 2005 11:33:47 -0500
From: Se-Chang Son <sschang@cs.wisc.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803
X-Accept-Language: en-us, en, ko-kr
MIME-Version: 1.0
CC: Midcom <midcom@ietf.org>
Subject: Re: [midcom] updated TURN draft
References: <42E553D5.4020009@cisco.com> <1122467155.3871.23.camel@hed040-040103.research.nokia.com>
In-Reply-To: <1122467155.3871.23.camel@hed040-040103.research.nokia.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-CSL-MailScanner-Information: Please contact lab@cs.wisc.edu for more information
X-CSL-MailScanner: Found to be clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Content-Transfer-Encoding: 7bit
X-BeenThere: midcom@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: midcom.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/midcom>, <mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>, <mailto:midcom-request@ietf.org?subject=subscribe>
Sender: midcom-bounces@ietf.org
Errors-To: midcom-bounces@ietf.org

Hi all,

Since I am a newbie to TURN and it seems that no one has answered Remi's 
question below, could someone explain me how a ftp will work with TURN?
If somebody can explain how TURN supports the following scenario, she/he 
will be very appreciated.

(1) ftp client behind a NAT (i.e. TURN client) makes ftp connection 
(control connection) to a ftp server in the public network (i.e. 
external client).
(2) several ftp commands are exchanged between them
(3) ftp client calls "put a_file" in the passive mode. In other words, 
the data connection is made from the ftp server to the ftp client but 
the data is transfered in the opposite direction.

The draft says that TURN has the same effect of having address 
restricted NAT. With such type of NAT, I think the above scenario must 
be possible.

Thank you.

Remi Denis-Courmont wrote:
> 	Hello again,
> 
> I don't understand how TURN clients could receive incoming TCP
> connections with the new draft 08. Maybe I'm getting it wrong.
> 
> According to the draft, if a TCP connection is received by the TURN
> server before the TURN client made a Send Request, the connection is
> rejected. However, if the TURN client makes a Send Request before the
> TURN server receives the TCP connection, then the TURN server will try
> to establish the connection actively, instead of waiting for an incoming
> connection from the specified host.
> 
> It sounds like a vicious circle. In particular, I wonder how two TURN
> clients could establish a TCP connection between themselves with the new
> scheme.
> 
> As a side note, I'm doubtful about the use of TURN server to relay
> active TCP connections. Such connections should go through NATs without
> the help of a TURN server, and as such, not using the TURN server would
> save TURN server's bandwidth.
> 
> There doesn't even seem to be the advantage of knowing the external
> source (IP, port) tuple given the TURN server doesn't tell the TURN
> client about the used "eph[me]eral port" that it has used.
> 
> Regards,
> 

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom