I don't know how widespread this file-sharing-antagonistic behavior is on the part of ISPs. From what I can tell it seems to be growing. My gut feeling is that it will get worse before it gets better.
I would like to suggest that an encryption mechanism be put in place to prevent ISPs from determining whether a connection is indeed eMule-related. I propose a two step approach.
Step One - Simple Symmetric Encryption
The first step is a very simple symmetric-only encryption. Once a connection is opened to a peer, all data is encrypted using the remote host's ID as a key. If the remote host doesn't understand the packet, then eMule can fall back to an unencrypted connection. This will defeat current throttling technology that depends on sniffing the connection for protocol data. This is not a long-term solution, however, as ISPs will be able to break this encryption fairly easily as most IDs are simply a manipulation of the end user's IP address. It will take some time before the ISPs would have the infrastructure to be able to accomplish this. Protocol identification is currently based on analyzing the first packet or two on a connection for certain byte sequences. For ISPs to adopt protocol analyzing that utilizes decryption is something that would take quite a while and could cost them a significant amount of money. Some ISPs could give up on throttling at this point as being too costly for the gain.
PROs:
- Can be implemented almost immediately - simple changes
- No changes to eMule servers are needed
- ISPs that are determined to "enforce" throttling restrictions can adapt
Step Two - Public Key Infrastructure
If ISPs do start adapting, then the second step is to use a simple public-key infrastructure. Each eMule client would generate a public/private key pair (or use their existing secure identification keys). Each eMule client then operates a ftp or http server on an open port. This server would exist only to serve up that client's public key. When one client is going to upload to another, it first downloads that client's public key. Then, a symmetric key is negotiated when the actual file transfer connection takes place. The negotiation has to be done with no fixed bytes in the packet - nothing that a protocol sniffer can identify. The first 128 bits of the first packet sent is the PK-encrypted symmetric key. The rest of that packet is encrypted with the symmetric key so that the entire contents of the packet are encrypted.
PROs:
- Unfeasable for ISPs to adapt
- Requires larger changes to eMule
- As presented above, cannot be used with firewalled clients
None of the ideas presented here will prevent an ISP from knowing you are running eMule. The only thing this will do is prevent an ISP from easily being able to determine what connections are associated with eMule. It is still possible that upon detecting eMule from your IP that an ISP could throttle your entire connection. My belief is that this is a step that ISPs wouldn't take - it's one thing to throttle one program's data, another thing to throttle the entire connection. But, it is still a possibility, and one that is not easily countered. I believe, though, that if the above is done, it will help send a message to ISPs in general, that users demand protocol/data neutral service.