> >>>> 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
Such an implementation is simply broken. > 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. Why? One can simply fail the connection. How can a peer force one exhaust memory if one doesn't want to? And who wanted to deliberately exhaust memory? The only reason I can think of this might happen is because the implementation has no safeguards built in. > >> 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. This might trigger a long debate. Just 1 example: an intermediary (an implementation in the sense of 10.4) imposes a message size limit of 64k for whatever reasons. Result: endpoints will be need to invent another layer on top of WS to fragment app messages into WS messages. Please not. Intermediaries can fragment/coalesce (in the absence of active extension or when extension is active which allows and is understood by intermediary), but it MUST process messages of any size. > > 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
