Subject: [hybi] Maximum frame size as a security issue

From: Paul Colomiets <[email-masked]>
Date: Wed, 10 Aug 2011 01:24:07 +0300

Hi,

There is a security problem with maximum frame size. If we allow to
announce this value then we expect all implementations to be able to
obey as small frames as specified. So specifying maximum frame size of
1 byte could increase the chance of successful DOS attack. Because
small frame size means that not only traffic and memory usage will be
higher, but also for lots of implementations it probably means that
each frame will be another TCP packet.

This restriction does not apply to maximum message size, as messages
with lower size are expected to not to be sent as opposed to be broken
into pieces.

Thoughts?

-- 
Paul

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 10 Aug 2011 10:14:01 +1000

> with lower size are expected to not to be sent as opposed to be broken

Servers are unlikely to specify a max frame size that will cause a DOS
attack on themselves, so the attack vector of concern is a client
saying that it will only accept 1 byte frames and thus causing the
server to do more work to send it each message.

Servers are under no obligation to accept connections and could simply
reject connections attempted with trivially small frame sizes.   We
could even say that max frame size MUST be greater or equal to the 126
byte small frame size.

cheers

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 10 Aug 2011 08:21:35 +0200

> could even say that max frame size MUST be greater or equal to the 126

I think that this value of 126 is a good idea. It could be the default
when no frame size is specified, making it easier to build small
implementations (no FS negociation, only one-byte length). 126 is also
friendly to overloaded intermediaries that have to shrink their buffers
to save memory.

And enforcing a minimum supported frame size is comparable to what's done
with TCP : any IP implementation must support at least 576 bytes, so a
TCP stack must always be prepared to receive up to 536 bytes.

So I think we should add the following to the spec :

  Any recipient must be prepared to receive frames of up to 126 bytes.

And if we achieve consensus on max-frame-size, we could add something
like this :

  Larger frames may be sent if the recipient indicates its support using
  the max-frame-size option. Frames larger than this value will lead to
  undefined behaviour, they may randomly be accepted, dropped, or cause
  the connection to be closed. A WS agent MUST NOT send frames larger
  than the indicated max-frame-size, or 126 bytes is no max-frame-size
  is announced.

Thoughts ?

Willy

---

From: Paul Colomiets <[email-masked]>
Date: Wed, 10 Aug 2011 11:06:42 +0300

Hi,

> friendly to overloaded intermediaries that have to shrink their buffers
I don't think default value should be less than MTU. It will be waste of
traffic and processing power.

I do think that 90% of implementations should never split messages
into frames unless absolutely required (as long as about 90% of
implementations will deal with short messages, but short doesn't
mean126 bytes it's something closer to kilobytes).

-- 
Paul

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 10 Aug 2011 10:27:44 +0200

> traffic and processing power.

A path MTU is the hardest thing to find from an application point of view.
People accessing the net over PPP over modem are used to 576 bytes MTU.
Many others are used to 1500. Some others are still at 1492 due to PPPoE
headers, others are around 1380 due to VPN, etc...

It's not *that* much of a waste however, as you must not forget that this
is sent over TCP, not over plain IP. You can send 10kB in 126 bytes frames,
and the real overhead is around 80 times the WS frame header, which is 2
bytes in the absence of masking, or 6 bytes with masking enabled. The
overhead is then either 1.6 or 4.8%, which is still fairly low.

> mean126 bytes it's something closer to kilobytes).

I agree with the lack of need for splitting most of the time, especially
given that most messages will be small. Still, it makes sense to have a
default small value that must be enforced and have those supporting
larger values announce it.

Regards,
Willy