IESG note?, was: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol

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).
Best regards, Julian

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"<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/>
> _______________________________________________
> hybi mailing list
> hybi(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/hybi
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf