Re: [hybi] IESG note?, was: Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard

Willy Tarreau <w@1wt.eu> Sat, 03 September 2011 19:41 UTC

Return-Path: <w@1wt.eu>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4002F21F89BA; Sat, 3 Sep 2011 12:41:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.087
X-Spam-Level:
X-Spam-Status: No, score=-4.087 tagged_above=-999 required=5 tests=[AWL=-2.044, BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
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 JByp0o09QeiN; Sat, 3 Sep 2011 12:41:57 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC8D21F89CC; Sat, 3 Sep 2011 12:41:56 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p83JhN6l019230; Sat, 3 Sep 2011 21:43:23 +0200
Date: Sat, 03 Sep 2011 21:43:23 +0200
From: Willy Tarreau <w@1wt.eu>
To: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <20110903194323.GA19164@1wt.eu>
References: <20110711140229.17432.23519.idtracker@ietfa.amsl.com> <5355F3EF-DD59-4D3C-9578-84043A3B8E90@gbiv.com> <4E620772.9090900@gmx.de> <4E6228F9.2030108@gmx.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4E6228F9.2030108@gmx.de>
User-Agent: Mutt/1.4.2.3i
Cc: "Roy T. Fielding" <fielding@gbiv.com>, Server-Initiated HTTP <hybi@ietf.org>, ietf@ietf.org, iesg@iesg.org
Subject: Re: [hybi] IESG note?, was: Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Sep 2011 19:41:57 -0000

Hi Julian, Roy,

On Sat, Sep 03, 2011 at 03:17:45PM +0200, Julian Reschke wrote:
> Like that...:
> 
>    The WebSocket protocol is designed with an assumption that
>    TCP port 80 or 443 will be used for the sake of tunneling raw
>    socket exchanges over HTTP.  The result is a convoluted and
>    inefficient exchange of hashed data for the sake of bypassing
> 
> s/convoluted and inefficient/complex/
> 
>    intermediaries that may be routing, authenticating, filtering,
>    or verifying traffic on those ports.  The sole reason for using
> 
> s/sole//
> 
>    ports 80 and 443, and hence requiring the hashed data exchange,
>    is because many organizations use TCP port blocking at firewalls
>    to prevent unexpected network traffic, but allow the HTTP ports
>    to remain open because they are expected to be used for normal
>    Web request traffic.  WebSocket deliberately bypasses network
>    management constraints in order to enable Web application
>    developers to send arbitrary data though a trusted port.

The way I'm reading this seems to imply that the masking is there in
order to bypass intermediaries, which is absolutely not the case,
quite the opposite instead. The masking was introduced to avoid
getting stuck on supposedly buggy intermediaries that would search
for a valid HTTP request or response past the message boundaries.

The masking uses a low complexity precisely in order to make it
easy for intermediaries to decode the stream at a low cost. Also,
and quite importantly, being able to reuse the existing security
infrastructure is important (user authentication, accounting,
URL filtering, malware site blocking, etc...). The success of BOSH
or XHR precisely comes from the fact that there is no need to
reinvent new security models, new products, to train admins,
etc... What is deployed works.

>    Naturally, the WebSocket protocol does not have the same network
>    characteristics as HTTP.  The messages exchanged are likely to
>    be smaller, more interactive, and delivered asynchronously over
>    a long-lived connection.  Unfortunately, those are the same
>    characteristics of typical denial-of-service attacks over HTTP.
>    Organizations deploying WebSockets should be aware that existing
>    network equipment or software monitoring on those ports may need
>    to be updated or replaced.

The communication pattern is no different than what's done with
existing bidirectional communications over HTTP such as BOSH. It's
even close to XHR in that there may be an avalanche of small packets.

I agree it is important to insist on the traffic pattern, but I don't
think we should be too much alarmist either considering that people
already deploy equivalent mechanisms today.

Last, the protocol design was made with the goal of making it work
over raw TCP later. It's already split in two parts, the handshake
and the data framing. The framing can be reused over any established
connection and masking may be disabled simply by clearing one bit.

I would personally find it more fair to introduce the design by saying
something like this :

   The WebSocket protocol is designed to supersede existing bidirectional
   communication protocols which use HTTP as a transport layer to benefit
   from existing infrastructure (proxies, filtering, authentication). Such
   existing protocols were implemented as trade-offs between efficiency and
   reliability because HTTP was not initially meant to be used that way.
   WebSocket tries to address all of these goals in the same environment,
   and as such is designed to work over ports 80 and 443 as well as to
   support HTTP proxies and intermediaries, even if this implies some
   complexity specific to these environments. The way it is designed
   does not limit it to HTTP and future implementations may make use of
   simpler handshake over a dedicated port without revinventing everything.
   This last point is important to keep in mind because the traffic patterns
   of interactive messaging does not much match standard HTTP traffic and
   may induce unusual loads on some components.

Regards,
Willy