Re: [Nbd] [PATCH] doc: Document maximum message length during option haggling

[Alex Bligh <alex@...872...>]

On 11 May 2016, at 22:43, Wouter Verhelst <w@...112...> wrote:

> On Wed, May 11, 2016 at 02:51:20PM -0600, Eric Blake wrote:
>> In my mind, a DoS is an attack where someone can tie up a long-running
>> process to the exclusion of others.  A client can DoS a server (make the
>> server do so much work it can't accept other clients), but how does a
>> server DoS a client (the client isn't trying to accept other
>> connections)?  I considered using the same wording in both places, until
>> I realized that DoS doesn't make as much sense from server back to
>> client. But if you're okay with the term in both directions, then I
>> don't mind using it for consistency.
> 
> It's also not a term that makes much sense in the client->server
> direction if you're *only* thinking about request sizes, imo. DoS means
> "the server can't talk to other clients anymore". A large request means
> the server gets tied up reading a lot of data (or writing a lot of
> data), and yes, preventing a large request allows for *some* mitigation
> of a DoS attack.  Then again, a client that *really* wants to DoS a
> server can just send three 32MiB requests rather than one 96MiB request,
> and have the same effect. Actually, you're likely to get servers dealing
> with requests in parallel into more trouble by sending a large number of
> small requests than by sending a small number of large requests.
> 
> As such, I'm not convinced that tying our feed in this manner is going
> to buy us much of anything.

I agree we should tie our feet as little as possible. But I think a
much higher limit (I suggested 1MB is reasonable).

This is because I think there is value in being able to be able to write code
like this both server side and client side.

    uint32_t len;
    read ( ..., &len, sizeof(len));
    if (len > DOS_LENGTH) {
        error;
    }
    buf = malloc(len);
    read ( ..., buf, len);

If you don't have a maximum size of a reply server->client, then you
can't safely write that code.

I don't think the '3 requests' scenario is the same, because there you
can process the requests serially, rather than attempt to allocate
an enormous amount of memory.

Note here Eric is talking about the *option haggling* stage, not the
read/write stage.

-- 
Alex Bligh