Re: [rtcweb] HTTP Fallback draft

Cameron Byrne <cb.list6@gmail.com> Wed, 08 August 2012 15:05 UTC

Return-Path: <cb.list6@gmail.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 9AF9A21F84F5 for <rtcweb@ietfa.amsl.com>; Wed, 8 Aug 2012 08:05:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.468
X-Spam-Level:
X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 2hgxQG3B5x4H for <rtcweb@ietfa.amsl.com>; Wed, 8 Aug 2012 08:05:31 -0700 (PDT)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB4921F8319 for <rtcweb@ietf.org>; Wed, 8 Aug 2012 08:05:30 -0700 (PDT)
Received: by lahm15 with SMTP id m15so503468lah.31 for <rtcweb@ietf.org>; Wed, 08 Aug 2012 08:05:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cloWDLE54Ky+01MXkQAgcrdwl5MjkDnkEDNoZIOuiS4=; b=ivrAFDAVPqm319hIu7tCG5JKWO1R2GXIHWvavf0DvMPo3xdj9XovXriMSqHTJBpQfm gH4Ec34jQ4CK3SmLaaf9Qe55KJR0Gz7roKfdHbf00D0VW5zZ5PlJ44CkJ3kxBGG/Wq3V 4EqVxN2OnF0Z2rzxNEr+YoHMpXwhTgK69JZu5Z7BYkdOsHjiyVNDTG9UKnkWsm3OjvKt AUjN1N+NAYF8d1JMSeEj3MqU9w/sgchjOFzIeYmK/tgRLJ3POjyPwhLJfdhB2yA6qn8y M28RLnlNrbqAbOuJpOMEZr8nxMug2kZp/srqTzXtw2zzCvxDzXF/YHzT0Y9Lt/q0oGkm 71Ig==
MIME-Version: 1.0
Received: by 10.112.101.194 with SMTP id fi2mr2669729lbb.104.1344438329213; Wed, 08 Aug 2012 08:05:29 -0700 (PDT)
Received: by 10.112.3.196 with HTTP; Wed, 8 Aug 2012 08:05:28 -0700 (PDT)
Received: by 10.112.3.196 with HTTP; Wed, 8 Aug 2012 08:05:28 -0700 (PDT)
In-Reply-To: <913383AAA69FF945B8F946018B75898A1477EDB9@xmb-rcd-x10.cisco.com>
References: <20120807180156.286e74d2@rainpc> <D5BDA7BE-FE55-47FA-99FD-1645084370B0@gmx.net> <20120807191226.5b8e7f32@rainpc> <BLU401-EAS2566333A7F4DEA0D3BFDBE593CD0@phx.gbl> <913383AAA69FF945B8F946018B75898A1477EDB9@xmb-rcd-x10.cisco.com>
Date: Wed, 8 Aug 2012 08:05:28 -0700
Message-ID: <CAD6AjGSU8mzbcdbOkgGtAms1tdHhjiuQn_NFXELwO2kjegJkCQ@mail.gmail.com>
From: Cameron Byrne <cb.list6@gmail.com>
To: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
Content-Type: multipart/alternative; boundary=f46d040169b50904a804c6c2712b
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 15:05:32 -0000

On Aug 7, 2012 11:18 PM, "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
wrote:
>
> > -----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
>

Is this thread  really about the ietf engineering a way to by-pass network
policy set by network operators?

I do not believe that is acceptable.

CB

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