Re: [rtcweb] HTTP Fallback draft

Lorenzo Miniero <> Wed, 08 August 2012 10:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 64F1C21F86B0 for <>; Wed, 8 Aug 2012 03:09:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.669
X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QvCSecwhmRAA for <>; Wed, 8 Aug 2012 03:09:30 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id EA48221F86AF for <>; Wed, 8 Aug 2012 03:09:29 -0700 (PDT)
Received: (qmail 3054 invoked by uid 89); 8 Aug 2012 10:09:27 -0000
Received: from unknown (HELO ( by with SMTP; 8 Aug 2012 10:09:27 -0000
Received: (qmail 14981 invoked by uid 89); 8 Aug 2012 10:09:27 -0000
Received: from unknown (HELO rainpc) ( by with SMTP; 8 Aug 2012 10:09:26 -0000
Date: Wed, 8 Aug 2012 12:03:18 +0200
From: Lorenzo Miniero <>
To: Bernard Aboba <>
Message-ID: <20120808120318.374ac70b@rainpc>
In-Reply-To: <BLU401-EAS2566333A7F4DEA0D3BFDBE593CD0@phx.gbl>
References: <20120807180156.286e74d2@rainpc> <> <20120807191226.5b8e7f32@rainpc> <BLU401-EAS2566333A7F4DEA0D3BFDBE593CD0@phx.gbl>
Organization: Meetecho
X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Spam-Rating: 1.6.2 0/1000/N
X-Spam-Rating: 1.6.2 0/1000/N
Cc: "" <>
Subject: Re: [rtcweb] HTTP Fallback draft
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, 08 Aug 2012 10:09:31 -0000

Hi Bernard,

answering inline,

On Tue, 7 Aug 2012 18:51:39 -0700
Bernard Aboba <> wrote:

> > We indeed met such network elements in our experience, even though most of the times it was just blind UDP filtering rather than RTP filtering per se. It sometimes was just blind port filtering but the effect was the same. This mostly happened within enterprises networks where we tried, no matter how small or large.
> [BA] this fits with my experience as well.
> > You're right. A couple of years ago we wrote a paper addressing the potential approaches for tunneling attempts (if you're interested, I can send you the link offline). In this paper we basically described, as a diagram, which incremental steps could be carried out in order to attempt a successful tunneling: 1) the first attempt is to just try port 443, without encapulating anything (e.g., ssh using 443 instead of 22);
> [BA] There are DPI boxes that will compare traffic against TLS and catch this. So if it doesn't work you can't assume that 443 is blocked by the firewall. Same with non-HTTP on port 80.

You're right, actually I didn't fully describe the approach we presented in that paper. In that approach, infact, we did made use of TLS to encapsulate the traffic to tunnel (in the paper we tunneled everything we needed, not just RTP) on 443, with or without the CONNECT. So it was not a blind piping stuff on 443 or 80 (which may still work in a few cases, though), which means that other approaches like the TURN/TLS:443 could work fine there.

> > 2) in case that doesn't work, the second attempt is to use HTTP CONNECT and then fall back to 1. for the connection that is established;
> [BA] Trying HTTP on port 443 isn't likely to work if the original non-TLS test on 443 failed. 

The CONNECT approach as we conceived it in the paper at the time actually sends an HTTP CONNECT on port 80 to request an encrypted connection towards a 443 destination. If the request is successfull, we have the same TLS stuff as in the direct approach. Or are you talking about something different?

> > 3) the third attempt (e.g., 443 is not available or the proxy acts as a MITM) is to actually encapsulate in HTTP messages, whether you do HTTP or HTTPS. In every case, the peer (either endpoint or server) must be configured accordingly of course.
> [BA] If HTTP failed earlier, HTTP encapsulation also will probably fail. It makes more sense to me to try TLS on 443.
> > What I describe in the draft is step 3, even though I guess some words to suggest steps 1 and 2 (where you'd still need to encapsulate RTP packets on top of a TCP-based protocol anyway) could be considered. As long as it looks like valid HTTP and it behaves accordingly, I think there's no reason why traversing should be impeded:
> [BA] DPI boxes aren't always up to date. For example don't expect them to understand websockets.

That's true, and that's why in the draft I proposed a more "basic" approach: that is, relying on a simpler behaviour for HTTP, chunked or not GET and POST messages, in order to look as much as possible as normal HTTP. Probably not very efficient, but more likely to be accepted by intermediaries.

> > I agree with you and I'm not really dying to do RTP over HTTP either, but if some scenarios make it impossible for use cases to work (and some firewall/NAT deployers are to blame here, probably) then a fallback mechanism is something that can be nice to have, especially if we're interested in something that "just works".
> [BA] If all the other avenues are tried first, then this would really be a last resort. Any idea how frequently it should be expected to be used? 

The ideal scenario would be "never" :)

Unfortunately, there are still cases where such an approach may be needed. I'm not sure how often this could happen, though, as it probably depends on how many deployments that enforce such limitations are out there: I'm not sure it's just prisons or military as Roman said, as you just need to properly set up a proxy like Squid to do something like that cheaply, so there could be more.


Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools