[whatwg] MTU Size PeerConnection send method (was RE: PeerConnection feedback)
Harald Alvestrand
harald at alvestrand.no
Thu Apr 28 23:29:03 PDT 2011
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.
>
>
More information about the whatwg
mailing list