There were several things I'd like to touch. First off, encryption won't do jack for someone you're sharing to the public. Encrypting a message for someone you don't know is still going to get to that person, but people on the way there may not know what it is.
Encryption does not provide anonymity. I'd repeat that, but you can just read it again. Pig latin is a weak form of encryption. While you can speak to someone in pig latin, they still know who you are(because they see you speaking).
Currently, entities that are trying to find illegal files on p2p networks are not sniffing traffic, they are legitimate clients. Someone who's legitimate will legitimately be able to decrypt the data you send them, regardless of whether they are good or evil.
Why is bittorrent so fast? Well, the protocol itself does not make it fast, but there are some catches to prevent upload throttling. It's the people using it that makes it fast. The idea that people who aren't uploading should have slower downloads keeps people uploading, in turn making everything faster. gnutella had 90% leeches who weren't sharing much at all. You can't trust the users to allow uploads, either. In practice, they don't. You would end up with 10% of the users supplying 80% of the data.
Locking the port down is a _bad_ _bad_ _bad_ idea. If port 1881 is always associated with high bandwidth p2p program X, then ISPs and universities will start to throttle or block traffic on port 1881. Simple as that. This is one case against random scanning for other hosts.
Second case is that random scanning is terribly inefficient, and won't work so well if you are randomly scanning ports, too. Gnutella had roots here and they were horrible.
Then again, the gnutella (limewire, bearshare, gnucleus, mutella, many others) protocol is one of the least efficient of the successful p2p networks. I've seen papers suggesting that it's theoretically only efficient up to about 100 well behaved clients. Hands on tests (tests) I've done show something about that is true. Let alone that many clients out there are not friendly and that the connection between any two nodes on the gnutella network may not be so hot, you're looking at problems. For example, someone is doing research on the amount of TCP protocol packets (non data packets used for starting and ending connections, mostly) compared to the TCP data packets (the stuff you're transferring) is in the range of 80%. edonkey and web traffic are down under 10%, really more like 2-3%, depending on the client, server, and network reliability. This is percentage of the number of packets, not percentage of data, keep in mind. However, every packet suffers from your round trip time (ping) and adds to network congestion. If everybody were running gnutella, I don't think anything else would work. I ran a gnutella client and switched ports. I was still seeing traffic on the old port for weeks. That's too much delay.
I certainly predict more waste style "community" things where you trust people and they trust people, but you don't just trust everybody. I also see encryption coming in, because it makes "detection" of the protocol much more difficult. This has nothing to do with legality. ISPs pay for bandwidth. Having a saturated upstream connection means that everybody notices things taking longer. Going to hotmail sits there for a while and then the images don't load right away, for example. People complain about that, and switch providers. If it gets to that point, they need to pay for more bandwidth. With p2p traffic being what it is, they could limit 20% of that traffic instead of buying the new T1. They could limit 80% of that traffic and people will applaud the speed at which web pages are returned. They can't throttle it if they can't detect it. They can't detect it if encryption is used in the right way. They can, however, throttle users who transfer too much data, which I see happening.
Another interesting concept would be if you built a p2p protocol that allowed you to inject packets with a spoofed source IP, but real data. Instead of giving my real IP, I could give a bogus one. The problem with this is that many providers don't allow traffic to go out if the origin doesn't make sense. If I am a router at some store, I won't let traffic go out if it says it's from an IP that isn't supposed to be in my store. On the same note, I won't let traffic in if it says the origin IP is supposed to be in my store. TCP would not work this way, but UDP and ICMP would. The host that was receiving packets wouldn't be able to tell where they came from. I don't know of any p2p programs that use UDP, and certainly none that use ICMP.
|