""" 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 b) all implementations would have internal limits wrt to frame/message size 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). 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. """ _______________________________________________ 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
