Re: OOB Reply Delivery Protocol v3

Quoting zlatinb <[email protected]> from ml.gnutella.dev-forum:
:> 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?

I think that if you don't have immediate needs for a value, then you
should write in the specs that the "SO" key in queries SHOULD be empty
for now but that implementations should not choke if it is not (to preserve
future, yet unforeseen, expansions).

Note that whatever you stuff in a query, there is a hard limit of 256 bytes.
This is enforced by all GTKGs out there and maybe others.  I myself used
to limit it to 160 bytes on my own node, but I use 180 nowadays. (anything
bigger than that is just insane, even with dynamic querying).

:>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"

I would say "at most 16-byte lengths".  For a session-private key,
using anything bigger is just not reasonable anyway.  And if you have
that much hidden state to persist, well, you're abusing the protocol.

:>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.

Yes, I realize that now, thanks for expliciting.  GTKG will now
honour "NP" when supplied, so all is well.

: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.

OK, please keep us up to speed.

Raphael