Re: [rtcweb] HTTP Fallback draft

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Bernard Aboba
> Sent: Wednesday, August 08, 2012 7:22 AM
> To: Lorenzo Miniero
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] HTTP Fallback draft
> 
> > 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.
> 
> > 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.
> 
> > 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.

[Tiru] Firewalls with TLS Proxy capability can detect such misuse and block. we have an alternate proposal to permit UDP flows across firewall
http://tools.ietf.org/html/draft-reddy-rtcweb-stun-auth-fw-traversal-00 

> 
> > 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.
> 
> > 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?
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb