Re: OOB Reply Delivery Protocol v3

(If you get this email twice blame yahoo groups.. or gmail)

> 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