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

["Roy T. Fielding" <[e-mail]>]

I sent this originally in March, before the last call, but I see
that it still applies for draft-ietf-hybi-thewebsocketprotocol-13.

If draft-ietf-hybi-thewebsocketprotocol-13 is approved, please
add an IESG note to the effect of:
=========
   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
   intermediaries that may be routing, authenticating, filtering,
   or verifying traffic on those ports.  The sole reason for using
   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.

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

Cheers,

Roy T. Fielding                     <http://roy.gbiv.com/>

Begin forwarded message:

> From: "Roy T. Fielding" <[e-mail]>
> Date: March 29, 2011 5:23:33 AM PDT
> To: Server-Initiated HTTP <[e-mail]>
> Cc: [e-mail]
> Subject: reuse of port 80/443 in hybi
> 
> I am finding it difficult to participate in hybi in any meaningful
> way due to the very poor assumption that websockets traffic should
> use the same ports as Web traffic.  Apparently, this "decision" was
> made on the basis of hums at an in-person WG meeting and the chairs
> believe it to be consensus (and thus quash any discussion that has
> apparent consensus due to the extent to which people keep bringing
> up old issues).  It might even make some sense, given the name of
> this working group.
> 
> Unfortunately, it is a fatal error.  The rest of the protocol
> discussion is predicated on it, and enormously complex, for the
> sole reason of that initial error in design.  More the pity.
> It assumes that the network infrastructure that currently
> monitors and balances traffic over 80/443 is going to instantly
> adapt to TCP-over-HTTP, as opposed to treating it like a denial
> of service attack.
> 
> Browsers are fully capable of opening up new ports in firewalls
> simply by concerted use of open standards.  Many other applications
> do so without this painful corruption of existing protocols. Yes,
> it takes time (but not as much time as one would think).  Yes,
> there will be some companies that forcibly block some ports,
> just like there are some companies that forcibly block HTTP
> sites like facebook.com.  That is their right.  If the protocol
> is safe to use, it will be deployable over time.  If not, then
> it shouldn't make the Web situation worse by increasing the
> amount of packet filtering at firewalls.
> 
> So, I don't think the hybi work is worth continuing.  The rest of
> the protocol decisions simply don't matter -- any of the already
> deployed proprietary hacks are better by default because they
> are no worse than hybi and don't have the imprimatur of the IETF.
> I'd rather develop a protocol that works with network administration
> rather than against it.
> 
> I only ask that an IESG note be added to the final specification
> to the effect that this protocol knowingly misuses the Internet
> for the sake of bypassing organizational security.  Be honest and
> let the admins make their own decisions.
> 
> 
> Cheers,
> 
> Roy T. Fielding                     <http://roy.gbiv.com/>