ietf
[Top] [All Lists]

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

2011-09-02 04:52:50
Doesn't a WEBSOCKET client required a backend WEBSOCKET server to do handshaking and authentication to even allow it in the first so? If so, whose network management constraint is it bypassing?

Roy T. Fielding wrote:
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" <fielding(_at_)gbiv(_dot_)com>
Date: March 29, 2011 5:23:33 AM PDT
To: Server-Initiated HTTP <hybi(_at_)ietf(_dot_)org>
Cc: iesg(_at_)iesg(_dot_)org
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/>

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>