On Sep 12, 2011, at 5:33 AM, Tobias Oberstein wrote: > > """ > 10.4. Implementation-Specific Limits > > Implementations MUST impose implementation-specific limits on > otherwise unconstrained inputs, e.g. to prevent denial of service > attacks, to guard against running out of memory, or to work around > platform-specific limitations. In particular, a malicious endpoint > can try to exhaust its peer memory by sending either a single big > frame (e.g. of size 2**60), or by sending a long stream of small > frames which are a part of a fragmented message. In order to protect > from this implementations SHOULD impose limit on frame sizes and the > total message size after reassembly from multiple frames. > """ > > This text seems to suggest that > > a) sending large frames or large messages is seen as a DoS attack and discouraged It isn't always (neither is sending a GET request as a frame payload), but it can be used that way. > b) all implementations would have internal limits wrt to frame/message size All implementations *do*. Storage is finite. > > IMHO, this is misleading. > > Implementations with a frame-based API likely don't have limits regarding > total message size. Implementations with a streaming API likely don't have > limits regarding frame size (besides the protocol imposed limit of 2 ^63 octets). In that case, the burden is just passed to the recipient of the stream. I would be OK with text calling this out as an exception. > Why are those implementations required to impose limits? Does not make sense. > > Also, sending large frames/messages is not a DoS attack, but a valid use of WS. > When the receiving peer is incapable of processing the frame/message, it > should protect itself, but the sender isn't the one to blame for those limits. > > I'd like to suggest something more neutral: > > """ > Implementations which have implementation- and/or platform-specific > limitations regarding the frame size or total message size after reassembly > from multiple frames MUST protect against exceeding those limits. > > Exceeding implementation/platform specific limits on otherwise unconstrained > inputs could be used by a malicous peer to mount a DoS attack or exhaust > the peers memory. > """ The qualification in the first sentence is not really meaningful -- every host has finite storage. If my laptop were at the office on a nice fat pipe, you could fill the hard disk in a couple of hours; servers typically operate on much thinner margins. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
