On Friday 03 December 2010 14:09:04 Matthew Toseland wrote: > When a new opennet node is created, we create 40 ConnectionTokens. > > A ConnectionToken is basically just a public/private keypair. > > In order to validate the tokens and thus be able to use them, we ask 5 > seednodes to sign our tokens. The seednodes require CAPTCHAs or some similar > basic scarcity mechanism that can be dealt with during the installation > process (one CAPTCHA per node, to sign the whole batch of tokens). Unlike WoT > CAPTCHAs, these can be generated once for each challenge, with limits on how > many can be sent per connection and IP address (no more than N over period > T). These limits could perhaps be shared between the seednodes, possibly > stored on Freenet in a similar mechanism to what is described below. CAPTCHAs > would also have a time limit, to make it harder to reuse them or farm them > out. Also, we can use any kind of centralised or networked captcha - for > instance, the OCR-of-ancient-texts form - because the seednodes are not even > pretending to be invisible. If you need to be invisible you need to use > darknet, period. > > To actually use our tokens: > - When we connect to a node, we present a ConnectionToken, with its initial > validation. > - Every X period, each node we are connected to issues a challenge. This is > just a random nonce (with an appropriate prefix), plus the current time and > our current IP address. We sign it using the token and return it. The token > is then inserted, to two separate locations (for robustness). If the inserts > collide, we disconnect and remove the node from our peers list.
There are some serious complications with handoff, but these can be solved: At time T, node M (the potential attacker) is connected to node A. It successfully path folds through another node, to get node B, which it wants to connect to. M completes connection setup with B, and sends it its connection token. B looks this up and determines that M needs to disconnect from A first. All this requires is a signature from A, using a temporary key created by A when it connected, which was included in the insert. M obtains this and relays it to B. A stops traffic to M and disconnects once it has sent the signature, and B accepts the connection and starts routing to M, without doing an insert. The disconnection certificate must include the challenge from the new peer, otherwise they could be reused. This means that the first connection must still be open in some sense, until the next time slot, or until it sends us a disconnection certificate, whichever is sooner. Hence if we lose the connection with no warning, we have to wait until the next slot. However, if we drop the connection from the LRU, or if it drops us from the LRU, we maintain a tenuous connection until either the next time slot plus a small delta to compensate for poor clock sync (at which point we would no longer need a disconnection certificate), or when we have a disconnection certificate. It is not possible to chain disconnection certificates: If we are dropped twice within a time unit, we have to wait for the next one. However, T will be equal to the opennet grace period (the period after connection during which a node can answer requests but is not dropped from the bottom of the LRU since it might not have completed any yet), so we will not normally be dropped twice within one time period. It would alternatively be possible to use a multiple-return mechanism such as used with the IP address based limiting. In this case, the node we are connected to would insert the disconnection certificate to the same slot. A node which we connect to could then look it up, and accept that we are free to reconnect. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20101203/2769e21d/attachment.pgp>
