Changeset 10165

Show
Ignore:
Timestamp:
01/10/08 03:42:18 (2 years ago)
Author:
dave
Message:

explicitly state XOR's should be peer IP-port aligned.
include proposal of 'httpo'.
massage text.

Files:
1 modified

Legend:

Unmodified
Added
Removed

  • dotorg/trunk/html/tracker_peer_obfuscation.rst

    r9851 r10165  
    22================================== 
    33 
    4 This extension extends the tracker protocol to support simple obfuscation 
     4This extends the tracker protocol to support simple obfuscation 
    55of the peers it returns, using the info hash as a shared secret between 
    66the peer and the tracker. The obfuscation does not provide any security 
    77against eavesdroppers that know the info-hash of the torrent, it does 
    8 however make it a lot harder for an eavesdropper to listen on tracker 
     8however make it a harder for an eavesdropper to listen on tracker 
    99traffic in general to pick up the responses. 
    1010 
    1111The goal is to prevent internet service providers and other network 
    12 administrators to block or disrupt bittorrent traffic in general. It 
    13 will leave the possibility to block or disrupt bittorrent traffic for 
    14 a certain torrent (given the attacker knows the info-hash). 
     12administrators from blocking or disrupting bittorrent traffic  
     13connections that span between the receiver of a tracker response and any peer  
     14IP-port appearing in that tracker response. 
    1515 
    1616The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 
    … …  
    4343same as if the ``info_hash`` was passed, except that any field that contains 
    4444peer information (such as ``peers``, ``peers6`` or any other field defined 
    45 by another extension) MUST be bit-wise XORed by the info-hash. 
     45by another extension) MUST be bit-wise XORed by the info-hash.  So that 
     46XORed peer lists can be precomputed and retained in tracker memory  
     47without sacrificing the tracker's ability to return a random subset of 
     48peers, each ip-port pair MUST be XORed independently aligned to the  
     49beginning of the infohash. 
    4650 
    4751In the case ``peers`` (or another filed containing peer info) is not a single 
    … …  
    5357----------------------- 
    5458 
     59Trackers that support obfuscation are identified in the .torrent file 
     60by the inclusion of the letter 'o' following 'http' in the URL, e.g., 
     61httpo://tracker.bittorrent.com.   
     62 
    5563A client that is configured to use this extension should always send the 
    56 ``xor_ih`` to any new tracker first. If it fails, the standard ``info_hash`` 
    57 parameter should be used instead. It is important to never send both 
    58 parameters in the same request, since that would defeat the purpose with 
    59 the shared secret (since the secret would be sent in plain text in the announce). 
     64``xor_ih`` to any tracker supporting 'o'.   Peers that do not recognize 
     65the 'httpo' will not contact that tracker.   If the tracker wishes 
     66to allow legacy peers to connect to the tracker then the announce 
     67URL should appear twice in the announce list.  Once with the 'httpo' and  
     68once with 'http'.  Even if a tracker appears twice in the announce list, 
     69if the tracker appears with an 'httpo' protocol in any announce URL, then 
     70peers that support obfuscation SHOULD NOT query the tracker without  
     71obfuscation since this would enable an attack where ISPs always discard  
     72the first tracker request. 
     73 
     74Peers SHOULD never send both infohash and XOR'd infohash 
     75parameters in the same request, since that would defeat the purpose of  
     76the shared secret. 
    6077 
    6178rationale 
    6279--------- 
    6380 
    64 The reason to XOR the info-hash with itself is because the tracker then 
    65 only needs one extra lookup table for XORed hashes. Instead of applying 
    66 a scheme where a shared secret is exchanged. This will add no computational 
    67 overhead on the tracker for the torrent lookup. 
     81By XORing the info-hash with itself the tracker is able to identify 
     82torrents without sending the plaintext infohash and without 
     83requiring an additional prior exchange of a shared secret. 
     84Where trackers now maintain mappings from infohash to the  
     85corresponding torrent's peerlist and other torrent-specific state.   
     86Trackers would need one additional mapping from XORed infohash to  
     87the existing torrent's state.   If XORed peerlists are precomputed then 
     88this method adds no computational overhead when a peer queries the 
     89tracker for a peerlist. 
     90 
     91This method requires decidedly less computational or communication 
     92overhead than SSH or similar symmetric encryption methods. 
     93 
    6894 
    6995authors