Re: How to transport BFCP in the presence of NATs

Joerg Ott <jo@netlab.tkk.fi> Wed, 28 July 2010 12:44 UTC

Return-Path: <jo@netlab.tkk.fi>
X-Original-To: tsv-area@core3.amsl.com
Delivered-To: tsv-area@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C61D28C14E for <tsv-area@core3.amsl.com>; Wed, 28 Jul 2010 05:44:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiQfVE90HwbU for <tsv-area@core3.amsl.com>; Wed, 28 Jul 2010 05:44:12 -0700 (PDT)
Received: from smtp-4.hut.fi (smtp-4.hut.fi [130.233.228.94]) by core3.amsl.com (Postfix) with ESMTP id 5B40328C130 for <tsv-area@ietf.org>; Wed, 28 Jul 2010 05:44:11 -0700 (PDT)
Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-4.hut.fi (8.13.6/8.12.10) with ESMTP id o6SCiXGT000626; Wed, 28 Jul 2010 15:44:33 +0300
Received: from smtp-4.hut.fi ([130.233.228.94]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 29320-454; Wed, 28 Jul 2010 15:44:32 +0300 (EEST)
Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-4.hut.fi (8.13.6/8.12.10) with ESMTP id o6SCiVh1000618; Wed, 28 Jul 2010 15:44:31 +0300
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 372361E1DC; Wed, 28 Jul 2010 15:44:31 +0300 (EEST)
X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi
Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Z4dWJiqzAWba; Wed, 28 Jul 2010 15:44:27 +0300 (EEST)
Received: from ip212-238-41-39.hotspotsvankpn.com (ip212-238-41-39.hotspotsvankpn.com [212.238.41.39]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id ECFB31E1DB; Wed, 28 Jul 2010 15:44:26 +0300 (EEST)
Message-ID: <4C502601.10607@netlab.tkk.fi>
Date: Wed, 28 Jul 2010 15:43:45 +0300
From: Joerg Ott <jo@netlab.tkk.fi>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Jukka Manner <jukka.manner@tkk.fi>
Subject: Re: How to transport BFCP in the presence of NATs
References: <21082_1279540847_ZZ0L5T0065P0196R.00_10048_1279540844_4C443E6C_10048_295_1_4C443E65.2050109@ericsson.com> <4C4FF948.1080703@tkk.fi>
In-Reply-To: <4C4FF948.1080703@tkk.fi>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi
X-Mailman-Approved-At: Wed, 28 Jul 2010 05:50:23 -0700
Cc: tsv-area@ietf.org
X-BeenThere: tsv-area@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Transport Area Mailing List <tsv-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsv-area>
List-Post: <mailto:tsv-area@ietf.org>
List-Help: <mailto:tsv-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Jul 2010 12:44:14 -0000

Hi,

this should be the preferred approach rather than doing a special
version of every application protocol to also run over UDP -- which
would just be calling for trouble, IMHO.

Joerg

Jukka Manner wrote:
> Hi Gonzalo,
> 
> Would our GUT-scheme be of any help here, in the BFCP over TCP over UDP? 
> We have an implementation out for Linux that works great, and it doesn't 
> require any changes to the tunnel protocol and application. People have 
> used GUT to tunnel various problematic protocols through NATs.
> 
> http://tools.ietf.org/html/draft-manner-tsvwg-gut-02
> 
> Yet, GUT is only meant to get "challenging" protocols through a legacy, 
> old, NAT. It doesn't introduce any full-fledged NAT-traversal signaling, 
> e.g., to get a hole for an incoming flow.
> 
> cheers,
> Jukka
> 
> 
> 
> 
> On 07/19/2010 02:00 PM, Gonzalo Camarillo wrote:
>> Folks,
>>
>> BFCP (Binary Floor Control Protocol), defined in RFC 4582, runs between
>> a client and a floor control server. Generally, the floor control server
>> has a public IP address. The client establishes a TCP connection towards
>> the floor control server so that, even if the client is behind a NAT,
>> everything works.
>>
>> However, in some existing deployment scenarios the floor control server
>> functionality is implemented in an endpoint, which may be behind a NAT.
>> A typical session between two endpoints in these scenarios consist of a
>> BFCP connection and one or more media streams (e.g., audio and video)
>> between them. In this type of scenario, NAT traversal becomes a problem.
>>
>> Existing deployments implement different approaches to address the fact
>> that the floor control server is not directly reachable. One of these
>> approaches consists of transporting BFCP over UDP instead of over TCP
>> (this approach is documented in the draft below). In this way, the
>> endpoints can use ICE to find connectivity between them.
>>
>> https://datatracker.ietf.org/doc/draft-sandbakken-xcon-bfcp-udp/
>>
>> An alternative approach would be to still use TCP as a transport and use
>> ICE TCP. However, the success rate of ICE TCP is not high enough at this
>> point. Yet another alternative would be to tunnel BFCP over TCP over UDP.
>>
>> The XCON WG is aware of the guidelines given in RFC 5405 but would like
>> to ask the transport community for further guidance on this issue.
>>
>> Note that this is actually a general issue that will affect any protocol
>> for which TCP would be the natural transport but that would need to run
>> between endpoints in NATted environments. RELOAD
>> (draft-ietf-p2psip-base) would be an example of a similar protocol
>> (which currently intends to use ICE TCP).
>>
>> Given that this issue appear to be more general than BFCP and may affect
>> other protocols, we would appreciate to get input on how to proceed.
>>
>> Thanks,
>>
>> Gonzalo
>>
>