Re: Rethinking security, bursting, load management

On Friday 05 June 2009 17:53:28 Juiceman wrote:
> On Fri, Jun 5, 2009 at 10:20 AM, Matthew
> Toseland<toad-EI5O+8PHWbJeeLb3ft/[email protected]> wrote:
> > 9. Inserts of data which is not predictable by an attacker should be encouraged, where this is reasonably possible. There are strong arguments that the need to heal splitfiles is critical to good performance. Hopefully this will be reduced when we have Bloom filter sharing. If an insert is indistinguishable, there is a good chance of its remaining reasonably anonymous, even on opennet; bursts are a threat, and can perhaps be covered relatively easily. In traffic terms, an insert is similar to an answered request, unless you can trace it across the network and show that it is longer than a request. So at normal or higher, unless the user overrides a specific setting, we should seriously consider severely limiting the bandwidth usage of inserts. In practice, we already do this, by treating our inserts just like any other requests from any other peer.
> 
> I think MHK's will greatly improve splitfile reliability.  Any chance
> this can make it into 0.7.5?

No.
> 
> >
> > 10. Favouritism: How much can we prefer our own requests to others, in terms of what is feasible for the network as a whole, and in terms of what is safe? At the moment, we don't favour our requests at all, except that we generally take into account the fact that they won't generate any output usage (which can be a big factor, since usually input bandwidth is way less than output bandwidth). IMHO this is an open question. If we favour our own requests too much, opennet peers will drop us, darknet peers will refuse to answer our requests by reciprocity for us not answering theirs (assuming we implement this, which imho is a good idea eventually), and peers we do have will know our requests are local. IMHO the above reasoning does allow for us to use excess capacity for our own requests, this is bursting; in other words, as a starting point, if there are requests to send from other peers and local requests to send we treat them equally (implying for example that we don't consider far more of our queued requests than theirs), but if there are no requests to send and there is the capacity to send some more, we can send our local requests, unless we are on darknet, doing a non-identifiable insert, and are very worried about our security.
> >
> > DOCUMENTATION/ATTITUDE/GOALS CHANGES:
> >
> > 1. Opennet security sucks. Really, it does. It may be better than some of the alternatives, but it isn't vastly better. But IMHO we have the potential to achieve fairly interesting performance on opennet - not instant results, but fairly good throughput and reachability for rarer content.
> > 2. Unpredictable inserts can be reasonably secure even on opennet, provided precautions are taken and the attacker isn't too powerful.
> > 3. It is a good idea to have stuff downloading constantly, although downloading stuff you don't need will slow down the network at large.
> 
> Would a list of keys we've transferred (either requested or forwarded
> for a peer) in the past "x" hours and randomly re-requesting some
> during periods of low downloads help to disguise traffic?

Perhaps, but at a performance cost, especially given the below.
> 
> For that matter, perhaps a queue for splitfile healing that inserts
> random healing CHKs, or do we already do this?

We do insert a lot of healed CHKs.
> 
> > Bloom filter changes mean it won't be cached on your node, but it
> will be cached by reasonably nearby nodes.

_______________________________________________
Tech mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAABCAAGBQJKKVL9AAoJEHsvjZi+xPTDJccP/3313RGszUJAs1WPdH/4E7/e
Q52PIiKC8xEkfKTi3sJxBzW/IT4IZzmOseL2FzZmFbi7okZErp2Gn3Ih3McKqTwi
/H2vBOIskdn5S9ZiFTfoheYYCjn2psfCCSAgchn9jEVFJADGr4ss1cDXuDsqIOP3
gPR5QR4LvhmVEXvIDylTiovKw3vxIIU/Ibp6PFIF/RuAn2D2+KaaR/LnLn3mwBWZ
YoqnnzhfLhqJJ7zkDb9FASjme75ofJbtsNg5c1qI8DS3j9x9z1K8BJcJTA9onRcV
25R7ls6DOJh+e9LwqL5GfNxXOUR94CeqCbluTyxbzDeWBUiPPnQ6azIh+M2isBkj
KiECCKY0k3HQFB8tSMaUOG0EqxlRImSKzbAj+86XdYUPDTX13WyhIZZyA6BW/B0a
/NvTyc4HPM70Pbob4HHkl3D70uZCtLAanbYdkpYFtRVUz/5wWIAkNvwYpFaSTCes
OqwKuAsoCL3lDYPXtDXNZ2vvRTX1N7B1PQ2LAoTLinVTcRau4vokAkvym61ObW7R
kmyMwzIRETlKPmo1wELx7icT3lJD7ShnLAkRrb6HJBwxi18C594/q92WbTQq3/5F
59ieZUvV5YJRt0d6huiPYlqg/Hr+W9FUBp/t8AmV8dtAVM8uy4rMxrXPLjFydELE
Ql6NZgHc+xuEzTihgMze
=hDdq
-----END PGP SIGNATURE-----