Re: Report: feat negot state

[Eddie Kohler <kohler@cs.ucla.edu>]

Hi guys!

Andrea Bittau wrote:
> good.  only 2 queues:  one for "pending changes" and one for confirms.  You
> might have wondered why i had a "confirm" inside the pending change queue
> itself, and then a seperate confirm queue.
> 
> Basically, because i coded server priority features first, and then
> non-negotiable.  With NN features, you need to send confirms even for stuff you
> don't know about [or something like that] so i didn't know where to shove the
> confirm =D

I don't quite understand this.  If you don't know about the feature, then how 
can you tell whether it is NN?

> Anyway, it's much better like this [i was planning to do it at some point, but i
> just "died"]
>  
>  
>  	/* Check if nothing is being changed. */
> -	if (ccid_nr = new_ccid_nr)
> +	/* XXX handle multibyte values */
> +	if (ccid_nr = *val)
>  		return 0;
> 
> 
> ccid can only be 1 byte.  kill comment.  assert(len = 1);

It is worth pointing out here that ALL server-priority features specified in 
DCCP so far use one byte values.  So I'd just hold off implementing multi-byte 
SP features.

> +	rc = dccp_feat_change(dmsk, DCCPO_CHANGE_L, DCCPF_ACK_RATIO,
> +			      &dmsk->dccpms_ack_ratio, 1, gfp);
> 
> ack ratio is 2 bytes i think.

Yep.

> 1) Merge it
> 2) I'll try to re-write the multi-byte feature support patch.  I believe this is
>    important functionality which is missing.

For NN features, yes.

> So now feature negotiation is moved into the minisock stuff.  I don't know what
> it means exactly, but i think the minisock stuff is the socket created upon
> receiving a SYN... i.e. a half open connection.  The idea is to keep as little
> state as possible in order to avoid SYN floods and other lame dos attacks.
> 
> While I was writing feature negotiation, I spotted quite a nice dos attack.
> Actually, probably it sucks, but here it is.
> 
> The idea is that when you send a REQUEST, you can include your CHANGE options.
> The server will RESPOND with the various CONFIRM options.  Here are the nice
> implications of this:
> 
> * The server must remember which CONFIRMs it sent.  [In fact, the previous code
>   was bugged because of this I think---it would remember the features of ALL
>   clients in a single socket... anyway.]
> 
>   This means that the server must not trash memory, it has to hold some state,
>   and potentially even setup those options.  E.g. it might have to load a CCID,
>   etc etc.

The Init Cookie option lets the server package up all that state, send it to 
the client, and forget it.  The server might still have to load a CCID, but 
that doesn't worry me -- we only have 3 CCIDs.

> * The server must actually calculate the CONFIRMS.  With server priority, the
>   calculation works as follows:  Given preference list C and S of the client and
>   server respectively, the winning value is the first value which appears in S
>   and also in C.
> 
>   Basically:
> 
>   for each s in S
>     for each c in C
>       if (s = c)
>         w00t();

It's not that bad.  (1) All feature negotiation options are limited to 252 
bytes of feature value at most.  (2) All current SP features are one-byte 
valued.  So you can do this.

     uint32_t bitmap[8] = { 0, 0, 0, 0, 0, 0, 0, 0 }; // 256 bits
     for each c in C
       turn on corresponding bit in bitmap;
     for each s in S
       if corresponding bit in bitmap is true
         w00t();

O(n^2) -> O(n).

For multi-byte SP features (if they ever exist), this trick doesn't work, but 
the DOS is less serious, since the maximum preference list length is 1/2 (1/3, 
1/4...) as long.

E