>>>> While the "MAY" doesn't specify a requirement, it seems like it would be >> helpful to implementers in light of the exhaustion/DoS possibilities >> presented by huge frames and fragmentation. I would even argue that it > > Why should that impose exhaustion/DoS possibilities? > > A WS impl. offering a streaming API has no problem. > A WS impl. offering a frame-based API can fail as soon as the buffered amount > for a frame exceeds some limit. > A WS impl. offering a message-based API can fail as soon as the total > buffered amount for the message exceeds some limit. > > All of these seem pretty straight forward. Where is the attack surface?
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. >> should be a "SHOULD". >>>> >>> I am Ok with changing MAY to SHOULD. >> >> I'm assuming from your response below that you're OK with going to MUST >> as well? > > I'm not sure: does this refer to 10.4. Implementation-Specific Limits? > > So you suggest an implementation MUST impose limits on frame size AND > message size? > > If that is your suggestion (which I hope not, since it's .. breathtaking), I > really would > welcome a broad discussion within the WG .. > > There was a long and heated debate about announcing frame-size limits and > related error codes. > Never (as far as I know) was there discussion about limiting message size. I would say that message size is probably the MUST. Note, though, that a limit on message size implies a limit on frames; since messages are made of frames, any individual frame can't exceed the message limit. I would also be OK with carving out an exception for streaming, but there it should be noted that the app on the receiving end of the streaming should implement similar limits. --Richard _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
