On 7/5/06, Matthew Toseland <toad at amphibian.dyndns.org> wrote: > On Wed, Jul 05, 2006 at 12:59:10PM -0400, Evan Daniel wrote: > > I think I like the concept. I assume the basic goal is to create a > > more stable version of KSKs? So that I can create the SSK "evand" and > > have some hope that it will continue to point to my freesite / > > freemail address etc? > > KSKs are reasonably stable. The problem is they are squattable. > > > > 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. 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)? > > > > 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. > > > 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? > > > > 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. > > > > 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. 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. 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. 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
