On 30/03/14 17:24, Steve Dougherty wrote: > On 03/28/2014 09:40 AM, Matthew Toseland wrote: >> (From FMS) >> >> On 28/03/14 08:18, wh@lr6fIgwYWLgplBDB9HzOSGhPuO5QH2X82LTZ5qMpuf4 wrote: >>> toad-notrust@h2RzPS4fEzP0zU43GAfEgxqK2Y55~kEUNR01cWvYApI wrote : >>> >>>> [pay-for-opennet proposal] >>> This surely adds a lot of bureaucracy, >> No, this is all automated, of course. And not necessarily much more >> centralised than opennet is now. >>> so may I ask what would be the benefits of having this? >> Security. See below for details, sorry for not making this clear. >>> I don't think you can "push" people >>> into darknet mode. It's likely they would use darknet if they just >>> knew other people running Freenet. By charging them money, the few >>> users Freenet has might me scared away for good. Because of this, >>> I'd expect this to dramatically decrease the number of opennet peers, >>> so the remaining ones would have to bear a much bigger load. >> Nobody who is already using opennet would have to pay. This is a >> one-time fee for creating a new opennet core node. So it might mean that >> some newbies don't become full opennet nodes; it shouldn't result in >> losing a lot of existing nodes. > So this is about solidifying the network more? Would this prevent > existing malicious nodes from moving around to do MAST? Yes. Your node identity includes your location. This is created by the seednodes randomly. During the transition period we would have another mechanism to get an identity with your current location, subject to e.g. IP based limiting. So once you have an identity you can't move around. You can only announce to the location your identity includes. >> And if you can't pay you can use transient mode. Which probably isn't >> much less secure than opennet is now! >>> I'd be glad to see improvements for Freenet being able to handle >>> more load on a single peer first. >> IMHO the main reason for Freenet being so slow on fast nodes is that the >> average node is still quite slow - so you are limited by your peers. >> This proposal allows for us to impose performance requirements on core >> opennet nodes. > I think this is a place where we want to tread very carefully. These > kinds of policy changes could alter the landscape of the network and > community. You mean specifically raising the minimum requirements for routing opennet nodes? I would have thought most of the filesharers would be overjoyed? Or paying for joining? >>> But maybe I just missed what pay-for-opennet is all about to begin >>> with, then someone please enlighten me. >> The main purpose is security (there are some side benefits, such as >> money, and such as being able to keep out excessively slow nodes). Sorry >> for not making this clear, it was late, it seemed an interesting idea... >> >> All powerful attacks on opennet rely on Sybil attacks. That is, creating >> a large number of nodes. This is ridiculously cheap for any plausible >> attacker, because IP addresses, CAPTCHAs, bandwidth, CPU and everything >> else is cheaper for an attacker than for a newbie with a lowest common >> denominator computer. This is *ALSO TRUE FOR TUNNELS*: Tunnel creation >> has similar issues. Both are solved by darknet but not everyone can / >> wants to use darknet. >> >> This proposal basically solves Sybil attacks, making almost all the >> important attacks on Freenet much harder, and making secure tunnel setup >> possible. > Is the main part of this proposal that's working against Sybil the > payment and resource requirements to be a core opennet node? I wouldn't > expect an additional $5 per node to make things prohibitively expensive > for a well-funded malicious entity. That's the fundamental question. How much does it cost to run a node? How long will an attacker want to run a node for? If we implement e.g. IP-based limits, how much does that cost an attacker? ($1.50/mo/IP on the cloud provider I saw)
My (optimistic in our favour) calculation of ~ $2500/month works out to $20/month/node. But I suspect it could be a lot cheaper than that, especially on larger scales, e.g. I used more servers than needed due to IP addresses, disk speed issues and transfer limits. You can get "unlimited" deals remarkably cheaply. But IMHO there is likely to be some throttling and/or unofficial limiting behind the scenes, so just because you can get a rack with a gigabit port cheaply doesn't necessarily mean you can pump out 36MB/sec on it continually, especially if you are technically breaching the terms and conditions by doing p2p on it. Now, about resource requirements ... The interesting attacks here: - Short term MAST (and related statistical attacks e.g. if we do initial random routing): The attacker needs to create new locations quickly and cheaply, ideally targeted ones (so if he can't choose a location he'll need to create more than he needs), to move to a particular part of the network, or to surround it. The actual number of nodes he needs to run may be relatively small. Hence the original pay-for-opennet proposal: Make creating a (random) location costly. If we ensure that only nodes with a proven track record of performance (or at least bandwidth) route high HTL requests or participate in tunnels, we can slow down MAST significantly. (Inspired by the "don't route high HTL requests to newbies" anti-fast-MAST proposal). - Comprehensive surveillance (e.g. connect to every node over the long term): Here the cost is *running nodes*. If we require nodes to have good performance on regular opennet in order to route high HTL requests or participate in tunnels, we can substantially increase costs; an attacker may try to "cheat" in various ways otherwise. Increasing resource requirements may well improve performance too. My initial, crude attempt at this was just to say lets increase the resource requirements for running a routing opennet node, and have everyone else transient. Now I think it may be worth thinking about a two tier system - even if the "inner tier" is simply "nodes with enough uptime and performance to participate in tunnels without them breaking too quickly to be usable". There are some interesting options: - Require good uptime and bandwidth for opennet nodes. In the pay-for-opennet proposal; increases costs of maintaining lots of nodes, avoids some possible cheats, may improve performance, may mesh well with stronger padding requirements when traffic is low. - Require good uptime and bandwidth (demonstrated) for opennet nodes which route high HTL requests. Slows down MAST considerably (but only against "stupid" users e.g. reinserting CHKs), easy to implement, but distorts routing. - Require good uptime and bandwidth (demonstrated on regular opennet) for "core" opennet nodes, i.e. 2 tier system. Filesharers tend to propose this; historically I have opposed it as more centralised. - Require good uptime and bandwidth (demonstrated on opennet) for nodes that participate in tunnels. We will need to implement this eventually for performance reasons if we have long lived tunnels, which we need for security unless performance improves radically (and for non-realtime Mixmaster-style tunnels for inserts too). So design it in from the start. We need to be careful that it doesn't restrict routing too much; e.g. ShadowWalker has its own lookup mechanism / topology. The last point (tunnels are a privilege for good nodes) is probably the best, although it may be worth looking at two tier systems (the second AND third points). E.g. could we use low uptime nodes for storage without exposing high HTL requests to them? We probably wouldn't be able to do Bloom filter sharing given they are low uptime, unless we have some redundancy+coordination scheme. Any of these risk DoS attacks to get rid of non-attacker nodes, of course. We can't avoid the last one, but how to deal with selective DoS attacks is a problem that is discussed in papers on tunnels. Most of these can be implemented on the single node level or in a more robust (but slightly centralised) way, e.g. using a hard to forge node identity from bootstrapping, and signatures or shadow nodes, to track a node's performance wherever it ends up connected to. So it still works best if there is a nonzero cost (of some kind, not necessarily $) for creating an identity. Some attacks involve creating lots of identities in advance and then only using a few of them when you need them to keep the running costs down. Again we need a cost per identity creation for it to work well, but requiring a track record (thus both time and bandwidth) will help. Preventing an attacker from running many nodes simultaneously on the same IP address (as opposed to limiting how fast he can create identities on a given IP) may help too, but this depends on IP scarcity. > The motivation behind this idea makes sense - try to make opennet more > secure. However, my reaction to this proposal is negative, and the > reaction I've been hearing from the community is negative as well. > Having to pay to join the (core opennet) network seems like a > significant thought barrier, and I'd much prefer to be able to tell > people about Freenet without having to mention that they need to pay $5 > to get better / decent performance. It seems like a significant > philosophical shift for the project. Unfortunately security is hard. People's intuitive assumptions are frequently utterly wrong (for example, look at how many people around here can't get their head around darknet). Similarly, the two meanings of free (gratis and libre) are frequently incompatible; gmail is free because Google harvests your private mail contents to target advertising, for example. If there's an infrastructure cost, or an anti-spam cost, somebody pays, and if it's not you then it's probably the bad guys, who want a return. However you may be right. It's more important that we implement some form of tunneling, raising the barrier from the attacker needing ~ 1% of the network to ~ 20% of the network, and that we make darknet work really well (after solving critical usability issues such as the client layer). Then it'd be worth looking into IP-based Sybil protection - if there is any point, which is far from clear - and maybe think about resource requirements. The basic economic questions are 1) How much does it cost an attacker to run a node, in bulk? And how long does he need to run them for? 2) How much is a user prepared to pay to join? Would enough users be prepared to pay anything? Reducing from $5 probably doesn't help much. Also there are dirty tricks we could use such as using Gmail accounts, phone numbers / text messages, hardware tokens etc but IMHO they are probably not a good idea. The ratio between the two determines whether it's worth thinking about pay-for-joining-opennet. E.g. if you can't implement a 100 peer node for less than $1/month then a $5 join fee probably doesn't make sense. An important related question: How much do IP addresses cost? Can we exclude IPv6-only users? What about carrier NATs? Can we limit by any other granularity?
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
