Re: [hybi] Review of draft-ietf-hybi-thewebsocketprotocol-13

[Tobias Oberstein <[e-mail]>]

> >>>> 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