RE: How to transport BFCP in the presence of NATs

<L.Wood@surrey.ac.uk> Mon, 19 July 2010 22:04 UTC

Return-Path: <L.Wood@surrey.ac.uk>
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 DFD7F3A6B8E for <tsv-area@core3.amsl.com>; Mon, 19 Jul 2010 15:04:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, 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 9sYSx9M1NWF1 for <tsv-area@core3.amsl.com>; Mon, 19 Jul 2010 15:04:49 -0700 (PDT)
Received: from mail72.messagelabs.com (mail72.messagelabs.com [193.109.255.147]) by core3.amsl.com (Postfix) with ESMTP id 7F1083A6B8C for <tsv-area@ietf.org>; Mon, 19 Jul 2010 15:04:49 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: L.Wood@surrey.ac.uk
X-Msg-Ref: server-15.tower-72.messagelabs.com!1279577103!8320837!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [131.227.200.43]
Received: (qmail 20136 invoked from network); 19 Jul 2010 22:05:03 -0000
Received: from unknown (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-15.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 19 Jul 2010 22:05:03 -0000
Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.14]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Mon, 19 Jul 2010 23:05:03 +0100
From: L.Wood@surrey.ac.uk
To: Gonzalo.Camarillo@ericsson.com, tsv-area@ietf.org
Date: Mon, 19 Jul 2010 23:04:57 +0100
Subject: RE: How to transport BFCP in the presence of NATs
Thread-Topic: How to transport BFCP in the presence of NATs
Thread-Index: AcsnOjxStA9UhGm7S4GlpquSpIfBxgAU0Fzg
Message-ID: <FD7B10366AE3794AB1EC5DE97A93A3730C2BF043F6@EXMB01CMS.surrey.ac.uk>
References: <4C443E65.2050109@ericsson.com>
In-Reply-To: <4C443E65.2050109@ericsson.com>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Mon, 19 Jul 2010 22:04:51 -0000

There has been much discussion of this NAT issue with DCCP and SCTP on the DCCP mailing list of late - see archives. Should they do a general UDP encap, or specific per-protocol UDP?

It's hard to care about protocols that no-one will use... the people who do care care about only their protocol, so protocol-specific encaps (which no-one will use either) are inevitable.

-----Original Message-----
From: tsv-area-bounces@ietf.org [mailto:tsv-area-bounces@ietf.org] On Behalf Of Gonzalo Camarillo
Sent: 19 July 2010 13:01
To: tsv-area@ietf.org
Subject: How to transport BFCP in the presence of NATs

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