Re: [rtcweb] HTTP Fallback draft

"Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com> Tue, 07 August 2012 21:23 UTC

Return-Path: <tireddy@cisco.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC86E11E80DC for <rtcweb@ietfa.amsl.com>; Tue, 7 Aug 2012 14:23:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.149
X-Spam-Level:
X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3hauduEuUZ5 for <rtcweb@ietfa.amsl.com>; Tue, 7 Aug 2012 14:23:55 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 319A011E809B for <rtcweb@ietf.org>; Tue, 7 Aug 2012 14:23:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6540; q=dns/txt; s=iport; t=1344374632; x=1345584232; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LIqzsjxfOMyMmNuDMm+u2l2nwUPZgWiD0A06UrLqwDU=; b=ctDWebRJv4qAoRlOP3LrKM8Gtg8hnt0CtbfgEOrBVJmg6Yk6IWkuXm8X f1bZh8vopErMnaPwq3GeVCewJNr39DHJ48nReISgHf4+6dT5XusF3WWdc 6ExKMSRxrpiIM8GwtszI8wBdjNl1fKF2EgJn6ActHvDhkJg/qxTyEulVE E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAGGGIVCtJV2d/2dsb2JhbABFhXyyeHKBB4IgAQEBAwEBAQEPARARIRkLDAQCAQgRBAEBAQICBh0DAgICJQsUAQgIAgQBDQUIGodcAwYGC5sVjRmTSIEhiQpkhU4yYAOjboFmgl8
X-IronPort-AV: E=Sophos;i="4.77,728,1336348800"; d="scan'208";a="106341897"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 07 Aug 2012 21:23:51 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q77LNpQf017989 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Aug 2012 21:23:51 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0298.004; Tue, 7 Aug 2012 16:23:51 -0500
From: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
To: Lorenzo Miniero <lorenzo@meetecho.com>, =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= <ibc@aliax.net>
Thread-Topic: [rtcweb] HTTP Fallback draft
Thread-Index: AQHNdLbePFtYWCPhFk+Ws7zgJPkdgJdO4KUAgAAJYQCAACeYgIAABZ6A//++iUA=
Date: Tue, 7 Aug 2012 21:23:50 +0000
Message-ID: <913383AAA69FF945B8F946018B75898A1477E8D5@xmb-rcd-x10.cisco.com>
References: <20120807180156.286e74d2@rainpc> <D5BDA7BE-FE55-47FA-99FD-1645084370B0@gmx.net> <20120807191226.5b8e7f32@rainpc> <CALiegf=zd5DaLbsPH6RU=jiSa0qv9rf+=r68FAn1Av-fpQP6Gg@mail.gmail.com> <20120807215415.00bebaa7@rainpc>
In-Reply-To: <20120807215415.00bebaa7@rainpc>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.69.132]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19090.004
x-tm-as-result: No--57.104600-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] HTTP Fallback draft
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Aug 2012 21:23:56 -0000

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Lorenzo Miniero
> Sent: Wednesday, August 08, 2012 1:24 AM
> To: Iñaki Baz Castillo
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] HTTP Fallback draft
> 
> Hi Iñaki,
> 
> 
> On Tue, 7 Aug 2012 21:34:09 +0200
> Iñaki Baz Castillo <ibc@aliax.net> wrote:
> 
> > Hi Lorenzo, sorry for opening another thread about this (I didn't
> > check my unread emails before reading the draft). Please see comments
> > inline:
> >
> 
> 
> No harm done, don't worry!
> 
> 
> >
> > > Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
> >
> > >> Just to be clear, I don't have objections regarding your draft. I
> just would like to understand what motives people to run everything
> over HTTP (besides using HTTP features, which you don't really do).
> >
> > Honestly I don't like the "all-over-http" vision. Admins filtering
> > traffic other than HTTP or HTTPS will also do their best efforts for
> > filtering specific traffic over HTTP, and IMHO making specifications
> > to run protocolos over HTTP legitimizes those hateful filtering
> > techniques.
> >
> 
> 
> I'm not a fan either, believe me :)
> 
> That said, as I said in another post I still think that, if
> RTCWEB/WebRTC is going to be deployed in browsers, they'll expect it to
> work in all the places where all other web applications do. Many
> proprietary protocols that do real-time communication implement
> tunneling somehow, or pretend to do so, which means something in line
> with that is needed for RTCWEB as well.
> 
> 
> >
> >
> >
> >
> > 2012/8/7 Lorenzo Miniero <lorenzo@meetecho.com>om>:
> >
> > > 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".
> >
> > That's the problem (IMHO): if we make all to work over HTTP then some
> > day telcos providers will just offer HTTP (as "Internet") and we'll
> > need to study a new OSI model in which the lowest layer is called
> > "HTTP".
> >
> 
> 
> Which is close enough to the hourglass draft Hannes mentioned in his
> post, I'm afraid. I can't but agree with you, but, again, if we have
> use cases and we want to have them working in as many topologies as
> possible, something must be done.
> 
> 
> > BTW: I sitll don't understand which is the advantage of using RTP
> over
> > HTTPS in comparison to TURN over TLS:443. Does is exist?
> >
> 
> 
> If we talk about a simple comparison, I'm sure TURN:TLS:443 performs
> much better than RTP over HTTPS, or at least, over the simple approach
> I documented in the draft at least (even though I tried to keep the
> overhead as little as possible). Comparing them is probably not fair,
> though, as they address two different scenarios: that's why HTTP would
> be just a fallback, and not something you'd use when you have
> alternatives.
> 
> Referring to the steps I described in my previous answer to Hannes,
> TURN:TLS:443 is probably the most useful option for scenarios 1 and 2,
> that is, where you can just pipe what you want on port 443 and be sure
> it will be ignored by the proxy. If the proxy checks what's going on,
> though, that may not be as easy. The proxy may be acting as a MITM for
> HTTPS, as Roman described, or just doing some traffic monitoring with
> anomaly detection or something like that: faking to be HTTPS is not
> going to work in that case, since the proxy may just see it's not HTTP
> at all, or may just understand it's not what it claims to be because it
> doesn't behave as it should; HTTP connections have a usually quite
> simple pattern (e.g., much more traffic going in one direction than the
> other and never at the same time), something that would be very
> different in a TURN connection instead.

Hi Lorenzo -

Enterprise Firewalls do have TLS Proxy that inspect TLS traffic. This is usually done to detect malware, content filtering, Data leakage Prevention, port misuse, Application visibility etc. So sending RTP traffic over HTTPS/HTTP can be detected and blocked if policy mandates it. 

--Tiru.

> 
> Lorenzo
> 
> >
> > Regards.
> >
> >
> > --
> > Iñaki Baz Castillo
> > <ibc@aliax.net>
> 
> 
> --
> Lorenzo Miniero, COB
> 
> Meetecho s.r.l.
> Web Conferencing and Collaboration Tools
> http://www.meetecho.com
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb