Multipath TCP Implementors workshop,Saturday 24th July

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

RE: How to transport BFCP in the presence of NATs

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 <at> ietf.org [mailto:tsv-area-bounces <at> ietf.org] On Behalf Of Gonzalo Camarillo
Sent: 19 July 2010 13:01
To: tsv-area <at> 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

RE: How to transport BFCP in the presence of NATs

> -----Original Message-----
> From: tsv-area-bounces <at> ietf.org [mailto:tsv-area-bounces <at> ietf.org] On
> Behalf Of Gonzalo Camarillo
> Sent: Monday, July 19, 2010 5:01 AM
> To: tsv-area <at> 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. 

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

Re: How to transport BFCP in the presence of NATs

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
>

--

-- 
Jukka MJ Manner, Professor, PhD.  Phone:  +358+(0)9+451 2481
Aalto University                  Mobile: +358+(0)50+5112973
Department of Communications      Fax:    +358+(0)9+451 2474
and Networking (Comnet)           Office: G320a (Otakaari 5A)
P.O. Box 13000, FIN-00076 Aalto   E-mail: jukka.manner <at> tkk.fi
Finland                           WWW:    www.comnet.tkk.fi

Re: How to transport BFCP in the presence of NATs

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

Re: How to transport BFCP in the presence of NATs

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

Re: How to transport BFCP in the presence of NATs

On Wednesday, July 28 2010, "Joerg Ott" wrote to "Jukka Manner, tsv-area <at> ietf.org" saying:

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

Do you mean specifically GUT, or generally something that allows tunneling
of TCP over UDP?  Other options in that space would be some sort of
peer-to-peer Teredo, or draft-baset-tsvwg-tcp-over-udp.  Each of these makes
different choices about the tradeoff between generality and overhead, and
it's not clear to me which would be the best option for this functionality.

The concern for BFCP specifically is that these ideas are all currently, at
best, individual author drafts, which would need not only to be standardized
but also to have documents written defining their use in SDP <proto> fields
and ICE candidate addresses.

Given how long this discussion has been going on already, I don't think
anyone imagines this would be a quick process.  The community that uses BFCP
is running into problems with peer-to-peer TCP communication in their
currently deployed networks, and the feeling among much of this community is
that progressing draft-sandbakken-xcon-bfcp-udp would be a much more
expedious process than getting consensus on a generic TCP-over-UDP
mechanism.

That said, I agree that having a general mechanism would be greatly
preferable, and going forward we'd be much better off if we starting having
serious discussions of this mechanism rather than having to revisit this
problem for all the protocols that come along in the future.  (And if it
does manage to progress quickly, but BFCP-over-UDP bogs down or runs into
trouble, the question of how to transmit BFCP could be revisited.)

--

-- 
Jonathan Lennox
lennox <at> cs.columbia.edu / jonathan <at> vidyo.com

RE: How to transport BFCP in the presence of NATs

Very well put. I agree.

Cheers,
Charles

> -----Original Message-----
> From: tsv-area-bounces <at> ietf.org [mailto:tsv-area-bounces <at> ietf.org] On
Behalf Of lennox <at> cs.columbia.edu
> Sent: Wednesday, July 28, 2010 8:45 AM
> To: Joerg Ott
> Cc: tsv-area <at> ietf.org
> Subject: Re: How to transport BFCP in the presence of NATs
> 
> On Wednesday, July 28 2010, "Joerg Ott" wrote to "Jukka Manner,
tsv-area <at> ietf.org" saying:
> 
> > 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.
> 
> Do you mean specifically GUT, or generally something that allows
tunneling
> of TCP over UDP?  Other options in that space would be some sort of
> peer-to-peer Teredo, or draft-baset-tsvwg-tcp-over-udp.  Each of these
makes
> different choices about the tradeoff between generality and overhead,
and
> it's not clear to me which would be the best option for this
functionality.
> 
> The concern for BFCP specifically is that these ideas are all
currently, at
> best, individual author drafts, which would need not only to be
standardized
> but also to have documents written defining their use in SDP <proto>
fields
> and ICE candidate addresses.
> 
> Given how long this discussion has been going on already, I don't
think
> anyone imagines this would be a quick process.  The community that
uses BFCP
> is running into problems with peer-to-peer TCP communication in their
> currently deployed networks, and the feeling among much of this
community is
> that progressing draft-sandbakken-xcon-bfcp-udp would be a much more
> expedious process than getting consensus on a generic TCP-over-UDP
> mechanism.
> 
> That said, I agree that having a general mechanism would be greatly
> preferable, and going forward we'd be much better off if we starting
having
> serious discussions of this mechanism rather than having to revisit
this
> problem for all the protocols that come along in the future.  (And if
it
> does manage to progress quickly, but BFCP-over-UDP bogs down or runs
into
> trouble, the question of how to transmit BFCP could be revisited.)
> 
> --
> Jonathan Lennox
> lennox <at> cs.columbia.edu / jonathan <at> vidyo.com