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. > > The location we insert a ConnectionToken to will depend on the hash of the > pubkey and the time (quantised to the period X). The original token signature > is checked, and so are the validation signatures. Hence these cannot be > forged to boot a node off the network. > > Up to this point, we have created scarcity in simultaneous connections: For > the price of solving a few CAPTCHAs, plus limits on IP address reuse, the > announcee gains the ability to use 40 connections. > > We can then add two more layers: > > 1. We can limit by IP address overall. > > We route the inserts by IP+time, rather than (or as well as) by hash+time. > Since every node involved can verify the validation signatures, there is no > serious danger of spam attacks. We allow a certain, limited number of > collisions - given an authority and a size limit, it is safe and reasonable > to allow a single slot to return multiple results. > > A possible attack would be obtaining a bunch of tokens and then inserting > tokens with a bogus IP address to deny access to a specific IP address or IP > range. One way to deal with that would be forcing the inserter to prove > posession of the IP address, e.g. by getting several seednodes to sign a > dated certificate. This would mean more load on seednodes, and traffic to the > seednodes every time you change IP address, but it would be small, and > traffic to the seednodes every time you change IP is pretty much the reality > already. > > Whether we want to limit by larger ranges is another question. It's possible > but there are worries that if Freenet is popular on a specific ISP, there > might be a legitimate reason for many people being on the same IP range? > > 2. We can require hashcash for renewals. > > Hashcash is problematic because slow computers and fast computers differ by a > large factor in their abilities. However, if an attacker can obtain lots of > CAPTCHA solutions relatively cheaply, it would be useful to have an ongoing > cost for each announced identity. Even if that ongoing cost is relatively > small it could be costly if the attacker is trying to overwhelm a large > network. > > So the proposal is that initially we allow the node to connect just on the > strength of the CAPTCHA, but after a certain time period we require a > hashcash solution. This could be based on the identity hash, but it would > probably be better if it was issued by the currently connected peer. It would > be included in the insert, and would include the time of issuance with a > fixed deadline for completion. It would be provably solvable (e.g. H(A | X) > last N bits = Y, find X), and ideally would involve enough branching that > GPUs don't help much. If the node changes connections, it would not go away, > because the node would look up the previous insert and see the puzzle there. > The deadline could be adjusted automatically for downtime: We don't want to > make life more difficult for low-uptime nodes. We would use a TUK-style > request, similar to what is proposed for IP addresses, to find the last such > insert for the identity. > > > Longer-term question: Can this help to solve the problem of WoT introduction > without using CAPTCHAs? We could have the seednodes mint blind coins, > possibly using scarcity in IPs and hashcash as well e.g. requesting a coin on > the basis of a token? Interesting idea, but there is probably a simpler > solution: We could assume the anti-Sybil mechanism described above works, and > use exactly the same mechanism proposed for darknet: Each connection can > generate one introduction token or Scarce SSK per X period per link. Which > gives us an unspammable space which can be used for introduction to the WoT > or DNS-style services. > Basically the problem with IP-based limiting is that people share IP addresses (especially students and eastern europeans), that this will get worse as IPs run out, and with IPv6 it will be more difficult to limit it, and that at a higher level (limiting by /24's and /16's), we don't know what the normal pattern will be, especially during slashdottings, and there will sometimes be clusters of users on the same ISP etc.
So maybe this is a dead end, although we can do some very basic local limits - As Ian originally suggested, if we have two peers in the same /16, dump both of them. - On a seednode, limit any given IP address to a small number of announcements over a given period of time. -------------- 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/20101208/7f656dfc/attachment.pgp>
