[whatwg] [hybi] WebSockets: UDP

[Mark Frohnmayer]

On Thu, Jun 10, 2010 at 12:35 PM, Erik Möller <emoller at opera.com> wrote:
> Regarding the discussions on at what level the API of a UDP-WebSocket should
> be: One of the most important aspects to remember are that for this to be
> interesting to application developers we need all the browser vendors to
> support this feature in a compatible way. Therefore it doesn't seem
> reasonable to standardize and spec a higher level network API akin to RakNet
> / Torque Socket and hope all vendors will be willing to spend the (quite
> large amount of) resources required for their own implementation of TCP over
> UDP, bandwidth throttling etc. In our opinion we're much better off
> standardizing a minimal UDP-like socket. For most application developers it

TorqueSocket is not in the same category as RakNet or OpenTNL -- the
point of the TorqueSocket effort was to find the web equivalent of a
minimal UDP'ish socket (understanding of course that it would be in
the context of a connected packet stream).  RakNet and OpenTNL provide
higher level data guarantees, RPC, object state replication, etc.
TorqueSocket is a simple send/recv packet protocol - it does no TCP
over UDP or bandwidth throttling.

>
> As discussed the following features/limitations are suggested:
> -Same API as WebSockets with the possible addition of an attribute that
> allows the application developer to find the path MTU of a connected socket.
> -Max allowed send size is 65,507 bytes.

I'd recommend doing some real-world testing for max packet size.  Back
when the original QuakeWorld came out it started by sending a large
connect packet (could be ~8K) and a good number of routers would just
drop those packets unconditionally.  The solution (iirc) was to keep
all packet sends below the Ethernet max of 1500 bytes.  I haven't
verified this lately to see if that's still the case, but it seems
real-world functionality should be considered.

> Some additional points that were suggested on this list were:
> -Key exchange and encryption
>  If you do want to have key exchange and encryption you really shouldn't
> reinvent the wheel but rather use a secure WebSocket connection in addition
> to the UDP-WebSocket. Adding key exchange and encryption to the
> UDP-WebSocket is discouraged.

If WebSocket supports an encrypted and unencrypted mode, why would the
real-time version not support data security and integrity?

>
> -Client puzzles to reduce connection depletion/CPU depletion attacks to the
> handshake.
>  If the goal is to prevent DOS attacks on the accepting server this seems
> futile. Client puzzles only raises the bar ever so slightly for an attacker
> so this is also discouraged.

Client puzzles allow the host to allocate zero resources for a pending
connection until it knows that the source address of the client
request is valid and that the client has done some work; you could
still take a similar (though not client computationally expensive)
approach by having the host hash the client identity (IP/port) with a
server-generated secret.  Any approach that allocates memory or does
work on the host without verifying the client source address first is
vulnerable to a super-trivial DOS attack (connection depletion before
even any bandwidth overwhelm).

>
> -Packet delivery notification to be a part of the API.
>  Again this is believed to be better left outside the UDP-WebSockets spec
> and implemented in javascript if the application developer requires it.

I'd propose that doing this in the javascript level would result in
unnecessary extra overhead (sequence numbering, acknowledgements) that
could easily be a part of the underlying protocol.  Having implemented
multiple iterations of a high-level networking API, the notification
function is a critical, low-overhead tool for making effective
higher-level data guarantees possible.

Regards,
Mark