Re: How to transport BFCP in the presence of NATs

[Gonzalo Camarillo <[e-mail]>]

Hi Jukka,

the idea is to use ICE for NAT traversal. So, the approach you propose
would be enough to allow using ICE to establish BFCP/TCP/UDP flows.

Thanks,

Gonzalo

On 28/07/2010 11:32 AM, 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
>>
>