RE: How to transport BFCP in the presence of NATs

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Gonzalo Camarillo
> Sent: Monday, July 19, 2010 5:01 AM
> To: [e-mail]
> 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. 

ICE TCP would do a TCP simultaneous-open ("SO") which can work in some NAT
environments, without needing to resort to building the application over
UDP.  If relying on hole punching (that is, an outgoing TCP SYN), the
environment depends on the OS and depends on the NAT.  With a TCP-based
connectivity check (like what ICE does), it can be better than building the
application over UDP.  See "P2PNAT" in
http://saikat.guha.cc/pub/imc05-tcpnat.pdf.  However, I don't know how well
TCP SO works with typical enterprise firewalls and typical enterprise NATs,
which I suppose is the primary place we would see BFCP.

> 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.

Using an ICE-like mechanism to determine which IP addresses work, and (of
those addresses) which works best (e.g., shortest path, least encapsulation
overhead) seems to provide the best union of pragmatism (making it work)
while still following IETF guidance (including "use TCP instead of UDP,
where possible").

Q: how quickly does the signaling channel with the BFCP server need to
be established?  

> 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).

I can tell that UPnP IGD / NAT-PMP would not be suitable, because BFCP is
used in enterprise networks where UPnP IGD / NAT-PMP are not available in
enterprise-class routers.

-d


> 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