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

[Peter Saint-Andre <[e-mail]>]

On 9/3/11 4:54 AM, Julian Reschke wrote:
> Hi,
> 
> I believe that almost everything Roy says below is non-controversial; if
> we can tune the language to be less offensive it might fit well into the
> Introduction (and not require an IESG Note to get into the document).

Indeed, it would be best if the WG could come to consensus on text,
rather than having the IESG impose something. Willy Tareau proposed text
that might fit the bill:

###

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.

###

IMHO it would be good to include a reference to RFC 6202 in the first
sentence.

Peter, as responsible AD

> On 2011-09-01 21:55, 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"<[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/>