On Wednesday 08 December 2010 18:15:37 Volodya wrote: > On 12/08/2010 07:35 PM, Matthew Toseland wrote: > > 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. > > I think students is the large proportion of the Freenet population, and as > such > it *is* a big concern. We want to make it as easy as possible to introduce > your > flatmates and others to Freenet. Of course, we can say "get them to use > DarkNet", but at that time they only know you. > > > 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. > > Would this open you up to a dos attack against a known IP range? Possibly and > attack that is run by the ISP to ensure that from their addresses nobody can > use > Freenet.
On a local level (single node checking its peers' IPs), no. > > > - On a seednode, limit any given IP address to a small number of > > announcements over a given period of time. This might conceivably. -------------- 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/c4eded4d/attachment.pgp>
