On Wednesday 02 Jan 2013 23:40:08 Matthew Toseland wrote: > On Wednesday 02 Jan 2013 18:54:45 Matthew Toseland wrote: > > On Friday 28 Dec 2012 13:34:26 Arne Babenhauserheide wrote: > > > Am Montag, 24. Dezember 2012, 21:11:55 schrieb Robert Hailey: > > > > With that being said, the scarce resource (in theory) would be location > > > > (detectable by network address), because an attacker simulating many > > > > nodes > > > > would likely have them in a very confined space (like a server closet > > > > or a > > > > few buildings here-and-there), and could not spoof a wildly different > > > > location because it would interfere with routing. > > > > > > Except if he just bought some time on one of the million-computer botnets > > > for > > > doing the attack. > > > > Yes, I'm putting that sort of thing in the "expensive attacks" box. > > > > > > But aside that: If we can marry your idea with transport plugins, that > > > might > > > be an option to create scarcity at least for some transports. Freenet > > > could > > > then prefer scarce transports over abundant transports - if available. > > > > Maybe. > > > > Even without rewiring the internet, we have several resources we can use > > that provide at least some level of scarcity that we can maybe throttle by: > > - CAPTCHAs > > - IP addresses > > - ASN lookup of IP addresses. > > > I have lots of detailed ideas on this, will post shortly when I can get them > together in a usable form. The limiting factor is it's hard to distinguish > between "attacker creates 5000 nodes on a single AS" versus "slashdot causes > lots of newbies on a single AS". We can still improve a lot on the status quo > though. > MAJOR ATTACKS FOR OPENNET (stuff we could maybe limit by tinkering with announcement etc) - Announce to chosen location. Component of many easy attacks, e.g. MAST, some published stuff. - Create lots of (malicious) nodes cheaply/quickly. That probably means a single datacentre/host, i.e. on the same AS. - Connect to all/many nodes but only with a few connections each. (With tunnels this is useless) - Surround targeted nodes. (Not necessarily all nodes) - DoS attack against announcement. - Dominate the keyspace/topology and thus control a large proportion of tunnels etc.
ESSENTIAL STUFF: Threadless announcement. (But keep some limits) Depth first announcement. General debugging of announcement. Automatic seednode collection. IMPORTANT STUFF: Collection of stats by Autonomous System Number on individual seednodes. ASN limiting of peers on opennet nodes. (Better than country limiting, but maybe we should offer that too) Basic seednode capture prevention. (TODO I will send another mail / file a bug with details) LOAD MANAGEMENT FOR ANNOUNCEMENTS: Look into estimating the network's capacity for announcement and then rejecting announcements over that limit. Consider measures against DoS from a single AS; prefer other AS's if there is a sudden spike on only one AS, or something. SUPER-SEED ARCHITECTURE: This is not worth considering until we have made some serious progress on protecting inserts - either some form of tunneling, or pre-insert/reveal. And it's a lot of work for limited improvements in security, so we should really put some serious effort into darknet first. To make significant further progress, we need seednodes to be significantly more powerful. This means making opennet somewhat more centralised, like a more traditional superpeer architecture. It means the seednodes each know all the IPs that have announced, for example. It might also require more manual supervision, as detecting attacker clusters automatically is probably hard, especially given slashdottings (this is similar in principle to the IP range blocking tools people sometimes use). Each opennet node would initially have to ask the seednodes to (collectively) create a Bootstrapping Certificate. This includes the node's location (randomly chosen by the seednodes), and a timestamp. A node can only announce if it has a BC. And it can only announce through the seednodes, via an Announcement Certificate. This is fairly complex and will eventually run into scalability problems. The coordination traffic should be relatively limited though; it partly depends on how many seednodes we have and how many seednodes are involved in creating identities. However there are some big advantages: - Prevent nodes from easily announcing to chosen locations. - Limit both creations and announcements by IP, across ALL seednodes. (currently you can announce a few times per IP per seed) - We can require a CAPTCHA for initial bootstrapping. (slight increase in cost/inconvenience for attacker) - We may be able to detect and limit DoS attacks from a single ASN, e.g. exploiting dynamic IPs. Obviously we should tell users what's happening if we reject their announcements. - We may be able to detect and limit mass creation of nodes from a single ASN for attacks (e.g. connecting to all nodes, controlling the keyspace). - Even malicious seednodes cannot easily violate these limits. - Individual nodes can use the cert timestamp to avoid being surrounded by newly created nodes, regardless of IP address, forcing attackers to run nodes for longer if they want to surround targets. Combined with limiting by ASN this makes surrounding large numbers of nodes significantly more expensive. A further evolution: Seednodes randomly probe nodes that have announced to establish their uptime, by a challenge routed to their location. They must respond by connecting to the seednode from their known IP address. Nodes must revalidate with the seednodes (i.e. prove their IP address to 2 seednodes) when they change IP address. This makes major attacks (e.g. surrounding a lot of nodes) use significantly more resources: - Attacker must create nodes in advance. (from above) - Attacker must use many AS's to surround nodes. (from above) - Attacker's nodes must have reasonable uptime, and be assimilated into the network (as challenge reaches them). - Attacker's nodes must have unique IP addresses. Hence he more or less has to run real nodes - even if he can cheat a lot by having e.g. common datastores. Plus, we know more or less how many nodes are online in each AS, rather than having to rely entirely on rate limits. And the average uptime too. Which makes detecting attacker clusters easier, although clearly attackers can hide if they're willing to spend enough, and to improve network performance while they're at it! And of course, this does nothing against botnets. How do you prevent an attacker who can run a substantial botnet from surrounding your node on opennet? You can't. But at least it's illegal and expensive.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
