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

Paul Giralt <> Wed, 13 November 2013 20:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A22D11E8107 for <>; Wed, 13 Nov 2013 12:29:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FwNcvXm+Vt5f for <>; Wed, 13 Nov 2013 12:29:30 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D5BE811E8179 for <>; Wed, 13 Nov 2013 12:29:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3675; q=dns/txt; s=iport; t=1384374570; x=1385584170; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=a/wPFVOcj6XwCmGtzziJuawvUxtYUnmynMmFPetlJXg=; b=UoVu6uCQdtr+MBLexV7pabrkPtjA6kIuvOchldCdEeYOgCC1TzIr4yjs 4uE49ILyL1jDbkHdvpSPAwrvoql7UOmHw5Ds2HNZ2TEOYx/mG0H+4ypJs BjsPxBXzRK2P4bJZCLam9QObyxJpV4rms5lSFp11sYCUr3YsGxUrMCcJ9 I=;
X-Files: signature.asc : 841
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFANrgg1KtJXG+/2dsb2JhbABZgwc4v3+BKBZ0giUBAQEDAXkFCwtGVxmHewbAO49fBxaDCoERA4lChm6HYJILgWqBXB4
X-IronPort-AV: E=Sophos; i="4.93,693,1378857600"; d="asc'?scan'208"; a="284437146"
Received: from ([]) by with ESMTP; 13 Nov 2013 20:29:28 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id rADKTPnU017373 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Nov 2013 20:29:26 GMT
Content-Type: multipart/signed; boundary="Apple-Mail=_8021EE31-83A6-4B99-8105-76C2D7D65E33"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\))
From: Paul Giralt <>
In-Reply-To: <>
Date: Wed, 13 Nov 2013 15:29:24 -0500
Message-Id: <>
References: <> <> <>
X-Mailer: Apple Mail (2.1812)
Subject: Re: [rtcweb] Usefulness of ICE-TCP (Was: Comments on draft-ietf-rtcweb-transports-01)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Nov 2013 20:29:35 -0000

On Nov 13, 2013, at 2:57 PM, <> <> wrote:

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

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