On 04/28/11 20:55, Stefan Håkansson LK wrote:
Wouldn't it be possible to abstract this away for the web developer? I.e. the
send method should, like for WebSockets, not have a max size. Instead the
sending UA would be responsible for chopping up (the receiving UA for
re-assembling) the message into packets not larger than the minimum path MTU.
Depending on the UA (and how integrated with the IP stack of the device it is)
different levels of implementation sophistication could be used (e.g. max 576
byte, or select 576/1280 depending on IP version, or even using MTU path
discovery to find out max size).
Yes, we could reimplement UDP's defragmentation mechanism at the higher level.
There are a few things to keep in mind if you do that (for instance, there's a
well known resource exhaustion attack where an attacker sends you the first
part of UDP packets and never sends you the rest of it, until you run out of
reassembly buffers, and of course the chance of losing a packet goes up
significantly when all the fragments need to make it in order to achieve
correct reassembly).
The attacker in this case would be a (hacked) browser as the web developer can
do no such thing. Of course larger data chunks increases the risk of not
getting it over. This may be problematic: how can you explain this to the web
developer in an understandable way?
The attacker can be anyone who is able to convince your web browser to
make a PeerConnection to a machine they control. The attacker isn't
limited to running web browsers that obey protocol.
The defense is well known - you simply limit the number of reassembly
buffers, and throw away packets that haven't been reassembled for a
while when you run out of buffers to reassemble them in. And the defense
can be implemented wholly within the browser - no need to explain it to
a web developer.
It's just one example of things one has to think about when implementing
this kind of thing.
