Subject: [rtcweb] Usefulness of ICE-TCP (Was: Comments on draft-ietf-rtcweb-transports-01)

From: <[email-masked]>
Date: Wed, 13 Nov 2013 19:43:30 +0000

Hi,

See below. 

Harald Alvestrand wrote:
> 
> On 11/13/2013 07:57 PM, Simon Perreault wrote:
> > Le 2013-11-13 13:44, Harald Alvestrand a écrit :
> >>> All this relies on the possibility that a TCP peer-to-peer
> >>> connection could be successfully established where a UDP one
> >>> couldn't. IMHO this is very unlikely to happen in practice. So
> >>> unlikely in fact that any possible gain over just falling back on a
> >>> TURN relay wouldn't be worth the additional implementation cost.
> >>
> >> Simon, do you have any numbers on that - how many calls will be going
> >> to servers on the Internet versus how many calls will be going
> >> peer-to-peer?
> >
> > Not sure what you mean.
> >
> >> The argument being given only applies to the client-to-gateway
> >> usecase
> >
> > My point only applied to peer-to-peer connections, not peer-to-server.
> > If we're discussing peer-to-server, then I wonder why we're discussing
> > that at all.
> 
> Because we agreed to include server-based systems in section 3.4 of the use
> cases and requirements" document?
> 
> I think we have WG consensus that client-to-server based use cases, while
> less important than browser-to-browser use cases, are still important.
> 

Right. Some amount of WebRTC endpoints will definitely be gateways or central entities such as conference servers. I have no idea what portion of sessions would be like that, but I don't it will an insignificant amount since there is a lot of interest to gateway WebRTC to various "legacy" VoIP and video conferencing systems.  So I think those are important use cases. 

Typically gateways and conf server endpoints would be reachable by TCP. The question is thus how often a  "normal" (browser or mobile app) endpoint would be in a network where UDP is blocked but direct outgoing TCP connections are allowed. In that case ICE-TCP would be optimal way for that endpoint to connect with a gateway/server endpoint. TURN over TCP would solve the same case but is less optimal.

So unless people have data that shows that "UDP blocked but direct TCP allowed" is in itself a very rare setup (this is a question, I don't know that either), I think ICE-TCP is definitely worthwhile for a WebRTC endpoint to support. 

TURN (over TCP) will still be needed in many cases involving two "normal" endpoints, and there I agree ICE-TCP has little success. 

Regards,
	Markus

---

From: Paul Giralt <[email-masked]>
Date: Wed, 13 Nov 2013 14:54:17 -0500

> So unless people have data that shows that "UDP blocked but direct TCP allowed" is in itself a very rare setup (this is a question, I don't know that either), I think ICE-TCP is definitely worthwhi…

This is actually a very common firewall configuration for enterprise customers. Outbound TCP is allowed but UDP is blocked (even if UDP is initiated from the inside). 

-Paul

---

From: Simon Perreault <[email-masked]>
Date: Wed, 13 Nov 2013 14:58:10 -0500

Le 2013-11-13 14:43, [email-masked] a écrit :
> So unless people have data that shows that "UDP blocked but direct TCP allowed" is in itself a very rare setup (this is a question, I don't know that either)

A data point: I was a user on such a network not long ago. It was an 
enterprise network and the enterprise in question is one that regularly 
sends people to IETF meetings. The firewall device (which is of a kind 
that is fairly common in enterprise networks) could not do stateful UDP 
connection tracking, so they just decided to block everything. Outbound 
TCP was allowed.

> I think ICE-TCP is definitely worthwhile for a WebRTC endpoint to support.

I get it now. Yes, for client-server connections, ICE-TCP makes sense. 
For peer-to-peer, not so much.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: <[email-masked]>
Date: Wed, 13 Nov 2013 19:57:30 +0000

Hi Paul,

> >
> > So unless people have data that shows that "UDP blocked but direct TCP
> allowed" is in itself a very rare setup (this is a question, I don't know that
> either), I think ICE-TCP is definitely worthwhile for a WebRTC endpoint to
> support.
> 
> This is actually a very common firewall configuration for enterprise
> customers. Outbound TCP is allowed but UDP is blocked (even if UDP is
> initiated from the inside).
>

Yes. UDP is blocked for sure and so is inbound TCP, so only outbound TCP is usable. However in many enterprises direct outbound TCP is not allowed but connection need to be made via an HTTP proxy. Do you (or someone else) have an estimate how often *direct* outbound TCP connections actually work?

Markus

---

From: Paul Giralt <[email-masked]>
Date: Wed, 13 Nov 2013 15:29:24 -0500

> Yes. UDP is blocked for sure and so is inbound TCP, so only outbound TCP is usable. However in many enterprises direct outbound TCP is not allowed but connection need to be made via an HTTP proxy.…

If I had to guess it's a significant number of both cases. There is probably a majority (> 50%) overall that allow both TCP and UDP, but at least a good 30% are more restrictive to some degree. The very security-concious customers (think banks and other financial institutions as well as large retailers and even universities) usually leverage proxies, but there are also plenty of large enterprises that allow TCP but block UDP. In these cases, a direct outbound TCP connection would be allowed, at least on a well-known port number (e.g. 80, 443). I think for the case of ICE-TCP, however, we'd have to also think about how many would allow an outbound TCP connection to any ephemeral TCP port number. 

In the past, customers had been more concerned about stopping the bad guys from getting in, but not as worried about people on the inside getting out. Now customers are becoming increasingly worried about compromised hosts leaking information out of the network and are taking steps to restrict what kinds of things hosts can do going out, hence I think you will see these kinds of restrictions increase, not decrease. 

As a data point, Cisco's internal network allows outbound TCP only to pretty much any port number but does not allow outbound UDP (and uses WCCP to pass HTTP traffic through Ironport transparent web proxies for security filtering). 

-Paul

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 14 Nov 2013 01:56:54 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Thursday, November 14, 2013 1:28 AM
> To: Paul Giralt (pgiralt)
> Cc: [email-masked]
> Subject: Re: [rtcweb] Usefulness of ICE-TCP (Was: Comments on draft-ietf-
> rtcweb-transports-01)
> 
> Hi Paul,
> 
> > >
> Yes. UDP is blocked for sure and so is inbound TCP, so only outbound TCP is
> usable. However in many enterprises direct outbound TCP is not allowed but
> connection need to be made via an HTTP proxy. Do you (or someone else) have an
> estimate how often *direct* outbound TCP connections actually work ?

I have seen various deployments where customers use split-tunneling and have firewalls deployed in the Branch office itself. In those deployments *direct* outbound TCP connections are permitted. UDP traffic is blocked by default but allowed because of Firewall SIP ALG.

-Tiru.

> 
> > -Paul
> 
> Markus
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb