Re: Re: OOB Reply Delivery Protocol v3

> 1. In the query, there is only the GGEP block with an EMPTY "SO" key,
right?

Yes, the "SO" (Secure OOB) key in the query is empty.  Although we prefer to
not enforce that by protocol; implementors should be free to put some value
there, and the protocol should just require the presence of the key.  Or we
could reserve the value of that field for future use.  What do you think?

>2. I was thinking a key of 4 bytes to be sufficiently compact and yet
>virtually impossible to guess, given that it is decided on a per claiming
>basis (i.e. different for each LIME11v3 message the querying servent
>sends). Do you agree with that?

Its really a vendor-specific thing; we'd really like to leave it up to the
implementors.  Since GTKG will drop any key longer than 16 bytes, how about
the following wording:

"Implementors are free to impose limits on the size of the security token
but they should support at least 16-byte lengths"

The reason behind that is that one can use the token to offload state which
would otherwise be kept in memory.  For example, LimeWire will tentatively
use 5-byte tokens, where the first byte is the number of results requested
in the LIME/11v3 and the rest a MAC of various things including that
number.  This way we won't need to keep state how many results we requested
from the host in question.

>So I don't see why it's important to support NP at all

The reason is to shut off a protocol version that we discover may be
broken.  A perfect example is the exploited presented on the wiki (credit
Christian).  If a leaf has a connection to one old and one new ultrapeer,
when they issue the query they can insert NP for OOBv2 and make sure that
only the ultrapeer supporting OOBv3 proxies.  That way the leaf can protect
itself somewhat from the exploit.

Please keep in mind that the whole DoNotProxy thing is still up in the air
for OOBv3.  We're definitely going to implement some way for leaves to
disable proxying, but it may not involve ggep extensions at all, so you can
ignore that part of the proposal for the moment.

zab


[Non-text portions of this message have been removed]