User:The8472/Comcast

From AzureusWiki

Contents 1 Initial Tests 1.1 User reports 1.2 Our own findings 1.3 What to test 1.4 Possible solutions 2 Conclusion and analysis 3 further testing 3.1 observations 3.2 conclusions 3.3 solutions

Initial Tests

User reports

• some users say encryption doesn't help
• some users say encryption does help
• some users say they don't have any problems with seeding at all

• Users report that seeding is possible when there are many peers because it'll take (something between 30 seconds to 2 minutes) time until the disconnect happens
• A wireshark log on torrentfreak indicates a disconnect directly after the bitfield. This needs further investigation (plain BT)

-> User reports generally are inconsistent

Our own findings

1. packet matching rules seem to be rather simple, although they do identify bittorrent and Az-messaging, it takes time (<= 5 minutes) to "lock onto" a connection
2. once a connection has been identified any packet belonging to the connection will result in 1-2 RST packets (to match the sequence numbers?) in both directions each. Even TCP retransmissions happening after ~40 seconds will trigger furhter RSTs
3. a new TCP connection started a bit later did not trigger new RSTs immediately (needs further investigation, try an immediate reconnect after RSTs)

• 1:1 encrypted connections seem to be stable over more than 10 minuts
• 1:N encrypted connections seem to be stable, although further testing is required due to problems with the testing instance

What to test

(see above)

• plain BT connections
• 1:N encrypted, forced, local and remote connections
• immediate reconnects

---

edit: tests done

Possible solutions

Blocking RST packets

Bad idea.

a) RSTs are sent to both ends

b) it requires OS-level magic under windoze (a standalone filter app might be the most community-friendly variant though), but easier under lunix.

Immediate, stateful reconnects

Might work, but would require support on both ends (keeping state despite TCP disconnect)

Use encryption w/o fallback on seeding

Easy to implement, would just require another checkbox and some ifs here and there, seems promising unless we can verify that encryption does not work

Request low rate return traffic

Somewhat easy to implement between peers who support extended messaging, keep-alives could be abused in classic BT, but clients might issue bans over such behavior

An alternative implementation that wouldn't require new messages or "i need return traffic"-awareness of peers would be staying at a random completion 9x% (different piece sets for diffferent peers) and contiously request chunks of the "missing" pieces to keep some return traffic up.

Conclusion and analysis

After running different tests (with only 1 comcast node at our disposal, thus we couldn't account for regional differences) we have come to the following conclusion:

The strategy to identify and jam bittorrent connections takes the following steps:

1. Mark connections which start with the bittorrent handshake
2. Wait for the bitfield on marked connections and see if it is complete (or nearly complete?), if it is go to the last step
3. Average upload/download traffic over five minutes for marked connections. If there is no downloading and much uploading continue to the last step, repeat this step otherwise
4. (Last step) For each further detected packet belonging to the marked connection send RST packets with matching sequence numbers to both involved parties and fake the source address appropriately

• step 1 is foiled by encryption
• step 2 is foiled by using alternative bittorrent messaging (such as azureus messaging) or lazy bitfield, though step 3 compensates for that
• step 3 can be foiled by generating bogus return traffic, this would be a waste of bandwidth though
• step 4 is not easy to foil since it would require support for blocking RSTs on both ends, which is unlikely to be achieved when non-blocked users don't see the immediate benefit of installing low-level firewalls or messing with iptables.

Suggestion: Extend encryption support by providing an option for encryption w/o fallback only when seeding.

Things that still need to be done

Since there are many claims that encryption does not help a user/test computer where this is (allegedly) the case would be useful to perform additional tests. It is possible that different shaping strategies are used in different regions or that the user(s) did their tests improperly.

further testing

Further tests were down with a peer where encryption didn't seem to work.

observations

• connections (even encrypted ones) are terminated when the uploading:downloading rate exceeds 10:1
• RSTs are forged as usual
• it is possible to setup a scenario where encrypted connections are not dropped, despite exceeding the 10:1 ratio. In our tests we disabled DHT and tracker announces, run only 1 torrent and obtained peers via PEX from a manually injected peer.
• even when connections started to be dropped again, connections established before dropping was triggered seem to persist

conclusions

• It seems, as noted in our initial findings, that connections have to be "marked" to be watched closer. If criteria for marking connections do not match then the connection will be left untouched no matter what
• Marking uses other criteria in addition to the BT handshake, probably tracker announces (peer lists, remaining=0 etc.), maybe unencrypted PEX (though unlikely because they don't even understand the Az-messaging format) and maybe DHT (also unlikely, but might be used to trigger a harsher heuristic in general)

solutions

Use encryption and make sure that the other criteria beyond BT-handshakes aren't matched

This would be the most user-friendly solution, but we don't know exactly how to evade the tiggering yet

Create 10

1 return traffic

There are multiple ways to do that, either via partial seeding by sending slightly sparse, different bitfields to different peers and request data you already have to keep a return flow

A custom protocol extension (one for AzMP and LTEP) that allows you to request a 10:1 return rate from the peer. Problem: no unified support for extended messaging so we'd have to rely on external peers cooperating because µT couldn't talk to Az and vice versa