On Wed, Jul 05, 2006 at 03:13:38PM -0400, Evan Daniel wrote: > On 7/5/06, Matthew Toseland <toad at amphibian.dyndns.org> wrote: > >> > >> It seems to me that creating 30 months worth of tokens on node > >> creation is a bit much. I would suggest either fewer tokens created > >> initially or create them more often. I think the number created > >> initially should approximately match the number that will be used by a > >> single insert, so that on average a new user can insert one SKK when > >> they create their node. > > > >Sure, numbers are subject to negotiation. I was thinking that we'd have > >one created per link per month but changed my mind at the last minute to > >one per node per month; obviously 30 on creation is too high. > > Is it too high? How many tokens would the average insert use up > (across the whole network)? I was thinking it was about right, but > that you might want to create new ones faster (1/week?). I think a > node should be created with about the same number of tokens as an > insert would use up.
One insert of an SKK, which might be a redirect to a USK freesite, uses one token (on each hop). Not everyone would want to use this mechanism. > > BTW, suppose my node recieves an insert, and it has no output tokens > for the best routing destination, but has them for the second-best > one. Does it queue or does it misroute? What if the queue is long, > and it's only recieving one token per 6 mos from that link (ie that > link has 6 peers and is generating 1/mo)? It queues. And the queues are of limited duration, so when they are full it rejects them. > > >> > >> Having created my SKK, how do keep it intact? Do I have to > >> periodically reinsert it? > > > >You insert it, as a redirect to a USK. Then you can use the USK updating > >mechanisms. > > Right, that's what I was assuming. (At the moment you can't make a redirect to a USK, but this will be fixed in time). > > >> It seems to me that if the nodes on the > >> network keep swapping locations, but the SKK can't follow its ideal > >> location while keeping propLevel = 2, that SKKs will eventually end up > >> in the wrong place even if they are frequently requested. > > > >No, the new store mechanisms require that frequently fetched keys are > >randomly reinserted. So it should propagate to its correct storage > >location. > > Do these reinserts use up SKK tokens? Fair point. Do we want to randomly reinsert SKKs? I'm not sure how we'd integrate this... Although coalescing would help obviously. > > >> Also, it seems to me that I should have the option of setting my node > >> to always return my SKK keys from its local store even if it is in the > >> wrong location (obviously a security / performance tradeoff). This > >> lets me maintain the health of my SKK a little better than just be > >> reinserting it. > > > >If everyone does this, then the limits on SKKs will not work - at least > >not for popular ones. > > What limits do you mean, exactly? I don't understand what popularity > has to do with it. Popular SKKs could be propagated from cache to cache to cache, thus bypassing the scarcity mechanisms I just outlined. The problem with this is that there are ways to make keys popular that don't make them useful. > > >> Another idea to prevent attacks on SKKs: When a node requests an SKK > >> and gets it (either local or non-local request), before it caches the > >> SKK it should try to retrieve it from all its other peers, as opposed > >> to just the optimal routing peer it asked first. If the different > >> peers return different answers, it should refuse to cache any of them. > >> I believe this would force an attacker to spend valuable tokens to > >> mount a viable attack as opposed to just setting up several nodes to > >> return bogus SKK results and hope they will be cached. > > > >I have been thinking mostly in terms of preventing spamming rather than > >preserving integrity. It is unlikely that your peers will have the SKK; > >but integrity should be reasonable, while not 100% guaranteed (it cannot > >be guaranteed for any human readable type), just as it is for KSKs now. > > > >> And by > >> intentionally misrouting, it may make it be not good enough for an > >> attacker to be in the right portion of the key space -- he would need > >> several nodes in the right place in topologically distant pieces of > >> the network. > > > >Eh? > > Suppose I'm connected to a node that wants to attack an SKK. I > recieve a request for the key; I send it on to him; he returns a fake > answer. I decide that I should cache the result. But first, I ask my > other peers for the same SKK. Since I'm sending the request in the > wrong direction, odds are decent it takes a much more circuitous path > to reach a node that has it. Doubtful. Your peers are near you, they'll use a path close to the one you'd use. > This means that the odds the request > finds the original key instead of the attacker's version go up. If > one of the requests comes back with a different key, I don't cache the > key. I would still answer requests for that key in the normal fashion > -- routing the best way I know how, thus returning the attacker's key > -- but whoever the attacker is (my peer or the other one), I at least > don't help him. Hmmm. > > Perhaps this is a bad idea though, since it lets an attacker attempt > to DOS the key more easily. > > >> There should probably be a fairly low limit on the bucket size for > >> peers input queues; this should help solve the problem of how I > >> allocate tokens to a new connection by just keeping some spares > >> around. > > > >Indeed. > >> > >> Also, it might be wise to reserve a few of our output tokens for > >> locally generated requests, so as to prioritize them. Say I'm > >> connected to 6 nodes, so maybe I reserve my last 3 output tokens for > >> local inserts. I'm down to 3 output tokens, and an insert comes > >> along. I then queue it until I have 4 output tokens available, and I > >> have an output token available for the node I want to send it on to. > > > >I think this would be counterproductive. It might have security issues, > >but even if not, output tokens are specific to a particular node, which > >may not be the node we want to route to. > > It likely has security issues. If we don't have an output token for > the node we wanted to route to, then oh well, we send it along anyway > and they queue it until we get a new token from them. Nah, we queue it. They can't if their queue is full. > Since tokens > are a valuable commodity, I'd like to use tokens I'm given on inserts > I care more about; this is designed to bias things in that direction a > bit. > > Evan -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20060706/cd5c0eb9/attachment.pgp>
