Re: [rtcweb] HTTP Fallback draft

"Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com> Wed, 08 August 2012 06:18 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 48BC611E8132 for <rtcweb@ietfa.amsl.com>; Tue, 7 Aug 2012 23:18:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.174
X-Spam-Level:
X-Spam-Status: No, score=-10.174 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, 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 KkEcYYrPOCEt for <rtcweb@ietfa.amsl.com>; Tue, 7 Aug 2012 23:18:28 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7D01011E80AD for <rtcweb@ietf.org>; Tue, 7 Aug 2012 23:18:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tireddy@cisco.com; l=3309; q=dns/txt; s=iport; t=1344406708; x=1345616308; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=e+bi1nbENmre5ci3j8JOAdDCM6omXroKKnvLBhJN1ts=; b=fZvhvoUm+07hK36DT39dKIjJ+jL5Eh6p50sCOP9ZeQeXmg9hVMFzH12c M5u8VED3aw78QCAmtcNxXuFP7JUsieja6TZ1qhwcnUQ4L2HXnukgfdNDq /c3+fNqnz9yuB/16vOMzk9TV1enI7bk/4FuozstqkWAXBV14j/7DHeo8s I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAOcDIlCtJV2d/2dsb2JhbABFuWyBB4IgAQEBAwEBAQEPASctBwsMBAIBCBEEAQELFAkHJwsUCQgCBAENBQgah2UGC5pYoEOLD4YAYAOWXI0SgWaCXw
X-IronPort-AV: E=Sophos;i="4.77,730,1336348800"; d="scan'208";a="109459656"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 08 Aug 2012 06:18:28 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q786IQQR031869 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Aug 2012 06:18:27 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0298.004; Wed, 8 Aug 2012 01:18:27 -0500
From: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>, Lorenzo Miniero <lorenzo@meetecho.com>
Thread-Topic: [rtcweb] HTTP Fallback draft
Thread-Index: AQHNdLbePFtYWCPhFk+Ws7zgJPkdgJdO4KUAgAAJYQCAAJERgP//9WQg
Date: Wed, 8 Aug 2012 06:18:27 +0000
Message-ID: <913383AAA69FF945B8F946018B75898A1477EDB9@xmb-rcd-x10.cisco.com>
References: <20120807180156.286e74d2@rainpc> <D5BDA7BE-FE55-47FA-99FD-1645084370B0@gmx.net> <20120807191226.5b8e7f32@rainpc> <BLU401-EAS2566333A7F4DEA0D3BFDBE593CD0@phx.gbl>
In-Reply-To: <BLU401-EAS2566333A7F4DEA0D3BFDBE593CD0@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.85.136]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19092.004
x-tm-as-result: No--55.020500-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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: Wed, 08 Aug 2012 06:18:29 -0000

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