I'm on the other end of the blocking side here. I actively try to block and or rate limit P2P traffic on my company LANs. We pay for bandwidth and it is many thousands of dollars extra a month to allow this, as we have over 100Mb/s worth of connectivity to the Internet.
I see the battles being played out. First it's a port range, now it can be any port. Then we were able to detect based on signatures in the unencrypted traffic so p2p was switched to SSL. Then we found out we could rate limit anything on a port other than 443 that was SSL but had an invalid certificate (with some exceptions.) So protocol obfuscation was added so we can't tell what protocol it is. But that has a pattern too. Some use bursting limits to detect this, some use packet counts to remote IP's.
There is a thought that this can be moved to UDP to bypass these restrictions due to the lack of SYN control. Plus with UDP and a remote "server", one can poke holes into any firewall and bypass inbound restrictions. But this counts on UDP being opened up outbound. While serving DNS from a local server, we could easily block UDP with a few exception sites.
My idea is to use SMTP and POP3 as additional protocols, not replacement. Using a dedicated real e-mail address for this. If I detect a very tight network such as what I have (eMule gets 1kb/s, Gnutella about 10kb/s on the open network, completely blocked on the closed network) then send my "p2p" e-mail address out to peers, and ask for theirs.
Do an initial exchange setup verify. A remote peer sends my e-mail address an e-mail to verify it can talk to me, and I send one to it. If the software verifies connectivity then packets are sent out via SMTP and downloaded via POP3. This can been over SSL if needed. This is done to prevent some innocent from getting bombarded with these mails.
The e-mails would have nothing in the headers to do pattern matching against. They would generate a very basic envelope. The subject would be completely random set of words. The body would also include a random set of words or phrases. The math behind this would be ever changing to prevent Bayesian filtering. The e-mail body (not attachment) would contain the “packet” to be transferred in lines that are between 5 and 70 characters in length. These lines would be SMTP RFC character set compliant. Each e-mail would be no more than 1Mbit in size. This would be data that is encrypted using something like AES or TwoFish and then mime encoded.
The peer I am requesting data from would send this to it's SMTP server, which would end up making it to my POP3 server. My P2P client would download the e-mail and decode it. I would send back an ACK to the peers e-mail address and await the next packet via POP3.
This would place a huge load on ISP mail servers. Most ISPs block outbound port 25, mandating the use of their SMTP servers though. If we used any other port, then packet shaping would work again.
The idea is that this would be just one of many ways to transfer data. The P2P client would try and figure out which was was the fastest by trying each method. If it finds one method is much faster than another, then it would prefer that for a period of time. If the ISP has their bandwidth shaping between the Internet and their own networks it is possible that this could bypass those filters. If you are on ISP#1 and 20 other peers are too, and you are using their mail servers, all such transfers are local and would not pass by such a bandwidth filter.
An example of an exchange;
From:
To:
Subject: One was fast not enough more time
Date: Tue, 22 Apr 2008 00:53:11 -0700
Message-ID: <12394@ru.dot>
MIME-Version: 1.0
Importance: normal
Priority: normal
This time once fast was enough blow down sky tonight. Lost ever more not as such. Could be nice review this.
ADSK3K39VK2KJN3LKC0A9DFLKJ23LKNL2K3N4K3909DFALDFK
ASLKFJ2LK3J4L2K3L2K3J490GBLAK1JH2LH509BUASDLKFJASED
9A99DLKD988323JHLKBN2LK3HJLKB09ASDFL23KHL5908GKLAA
