Giant WebSocket messages are a new vector, however. The only point here is to point out the new vector and recommend healthy implementation practices. It's an implementation recommendation, not an interoperability concern.
Wouldn't you agree that HTTP servers would be less vulnerable to SlowLoris if they imposed limits on the number of HTTP headers of the length of time that a request must take? All I'm suggesting is that this document suggest similar good habits. --Richard On Sep 6, 2011, at 1:37 PM, Iñaki Baz Castillo wrote: > 2011/9/6 Richard L. Barnes <[email protected]>: >> In all of these examples, the implementation is imposing "some limit" (the >> streamer just has an effective zero limit). The exhaustion/DoS >> possibilities arise when an implementation doesn't enforce a limit -- just >> keeps growing the buffer as long as frames keep coming. That's the reason >> for making the recommendation for "some limit" a MUST instead of a MAY -- if >> you don't enforce some limit, then someone on the other end can force you to >> accept unlimited data. > > This is not a good argument. Think in HTTP. I can send an HTTP request > with "infinite" headers to a HTTP server expecting that the server > would buffer all of them and suffer of DoS. See: > > http://ha.ckers.org/slowloris/ > > And note that HTTP protocol does NOT provide something like "HTTP > headers max size" negotiation at all. It's up to the HTTP server to > determine whether to consider incoming request as a DoS or not and act > according. > > And what I've explained aslo applies to any other headers-based text > protocol and others (SIP, XMPP, FTP....). > > > > -- > Iñaki Baz Castillo > <[email protected]> _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
