On an additional note,

>mask any p2p traffic

This phrase doesn’t mean anything whatsoever. All traffic on the internet is “p2p traffic” with enough wrappers and misdirection you COULD mask any traffic. Pragmatically, though, bittorrent is not gnutella is not napster is not fastrack is not tor is not freenet is DCC.

All of these protocols work in very, very different ways. Bittorrent can be trained to be fairly indiscernable (although, as you pointed out, a little slower than it would otherwise be) whereas masking gnutella would prove more difficult without serious modification to the software involved.

>Blocking UDP? Hardly invincible.

The torrent protocol does not use UDP for data transfer.

>No it does not.

Yes, it does. To someone snooping my traffic all they can see is that I am sending packets of “data”. They cannot reasonably (i’m sure TEH NSA has super secret quantum computers on the moon that could decrypt them in some billion years) decrypt the type of packet or what the packet contains. Now, somebody could just connect to the swarm and request the data from my client, but that is not the level at which the encryption of the protocol operates at.

>Whilst sure, theoretically, what you’re saying is correct the downside of BT being undetected is that it is so slow as to be unuseable.

It would only be slow to “get started”. Once you have connected to your peers and begin transferring data the number of connections you make and attempt are meaningless. Once my torrent client has scraped the data it needs from the tracker and finds a good set of seed/peers and connects to them successfully, everything will progress as it always does.

Blocking UDP? Hardly invincible.

“It masks what the packet is”

It masks the header. So yes in a manner of speaking that is correct.

“and the data inside the packet.”

No it does not.

“So your only solution is vague traffic analysis (that I can still get around with conservative enough settings)”

Seeing as no other common applications behave like a p2p application it doesn’t really matter just how vague traffic analysis is.

You seem to be saying that given the right settings a p2p application, ie. BT, is undetectable. Whilst sure, theoretically, what you’re saying is correct the downside of BT being undetected is that it is so slow as to be unuseable. So what would be the point?

You seem to be proposing that using settings you can mask any p2p traffic so it’s no longer detectable as such. Funny then, is it not, that these conservative settings are not used to avoid throttling then isn’t it. Actually no it isn’t – the settings would make the client unworkably slow.

>LRN2BITTORRENTS LOL

LOL. DHT + PEX + TOR…

>“We quickly built a list of all of the top torrent trackers around and got the nod from Jorke [Odolphi, Web Platform Architect Evangelist for Microsoft Australia] to add them all to the local DNS resolver and point them at a local web server containing some RickRoll scripts.”

… just got around that. DHT+PEX make actually being able to get to the tracker irrelevant. And tor lets you get new swarm information from indexers.

As for…

>Microsoft also created a script which categorized WiFi users with a ‘naughty factor’, meaning those with the greatest number of active port mappings to distinct remote hosts were identified as BitTorrent users.

… I can adjust what range of ports my client uses. I can also control how many connections it will attempt in what timespan and how many it will maintain. I can just keep rotating my MAC address until I find their limit.

>It does not provide any masking of data

Actually, yes it does. Thats the entire point. It masks what the packet is and the data inside the packet. Sure, you can still see that I’m sending “data” over whatever range of ports to peers that don’t seem “appropriate” but all you can really do is “assume” that my traffic “looks like bittorrent”.

So your only solution is vague traffic analysis (that I can still get around with conservative enough settings) and cutting me off completely if my traffic patterns are “suspect”.

On that note, however, creators of bittorrent clients should really give them more conservative default settings. And users should be more responsible with their use of the protocol. But, my point is, they didn’t actually block bittorrent. They just made it more difficult to use/forced users to be more responsible or get off.

DHT + PEX leads to connections no different to any other peer to peer connection over BT. Actually in some cases it can lead to more ports being used as each torrent instance needs to have a corresponding hash found over the network.

Encryption as used in BT = masking header data which is next to useless as far as masking BT traffic. It does not provide any masking of data or it’s origin/destination. It does not hide any ports that are being used.

In short none of the above are going to make any difference. And in this situation described in the article they were’nt worried about transfers as much as port usage.

LRN2BITTORRENTS LOL