On Mon, May 12, 2014 at 6:56 AM, Michael Rogers <[email protected]>wrote:
> This was a successful strategy - for a while. Some types of spam > disappeared, but others quickly reappeared as the spammers realised we > were blocking them via IP addresses and file hashes, both of which > were easy to change as fast as we could block them (once per hour, by > the end) using scripted could instances. > I assume that means "cloud instances"? How would an attacker spontaneously spin up random IPs in a huge block? Even for something like EC2 I don't think you can pull up new IPs on demand (but I haven't tried). > Q: What if you are leaching merely because there are so many > > seeders? A: Rather than fully blocking incoming connections from > > leachers on the list, just require that they share data with you > > first before sharing any with them. Because they only way you get > > onto the list in the first place is to have first downloaded some > > data, you should always have some data to share. > > A newcomer downloads their first piece and gets listed; now they can > only download from peers that want that one piece. What if there are > no such peers in the swarm, or the newcomer can't find them? Do peers > have to download pieces they don't want from listed peers just to test > them? What's their incentive to do so? > The latter -- I'm proposing that even a seeder would require an inbound connection on the blocked IP list to provide one block of valid data before the seeder responds with any data. The primary incentive is to avoid sending data to a copyright enforcer (on the assumption that the enforcer would never send you a block of valid data) and thus avoid getting a takedown notice (on the assumption that the enforcer won't attempt to takedown an IP that hasn't shared out data with it). The secondary incentive is to improve the health of the swarm overall by requiring everybody to upload. Granted, that doesn't really help the seeder as they have already the content, but a swarm that requires *some* degree of sharing just has more capacity than one that doesn't. > Amazon EC2 has some enormous IP ranges. Maybe create a second block > list of addresses that aren't allowed to contribute to the first block > list? ;-) > Agreed, if it's easy to get a new IP, then this whole argument falls apart. But I think this argument is largely true. Based on the EC2 docs: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html "By default, all AWS accounts are limited to 5 EIPs, because public (IPv4) Internet addresses are a scarce public resource. We strongly encourage you to use an EIP primarily for load balancing use cases, and use DNS hostnames for all other inter-node communication." Granted, Amazon clearly *can* do this: "If you feel your architecture warrants additional EIPs, please complete the Amazon EC2 Elastic IP Address Request Form. We will ask you to describe your use case so that we can understand your need for additional addresses." The question is whether they'd allow a copyright enforcer to do this. And even if they do, the total number of elastic IPs is likely smaller than the total number of torrent users at any point in time. -david
_______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
