| 1 | <?xml version="1.0" encoding="utf-8" ?> |
|---|
| 2 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> |
|---|
| 3 | <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> |
|---|
| 4 | <head> |
|---|
| 5 | <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> |
|---|
| 6 | <meta name="generator" content="Docutils 0.5: http://docutils.sourceforge.net/" /> |
|---|
| 7 | <title></title> |
|---|
| 8 | <link rel="stylesheet" href="../css/bep.css" type="text/css" /> |
|---|
| 9 | </head> |
|---|
| 10 | <body> |
|---|
| 11 | <div class="document"> |
|---|
| 12 | |
|---|
| 13 | <div id="upper" class="clear"> |
|---|
| 14 | <div id="wrap"> |
|---|
| 15 | <div id="header"> |
|---|
| 16 | <h1><a href="../index.html">BitTorrent<span>.org</span></a></h1> |
|---|
| 17 | </div> |
|---|
| 18 | <div id="nav"> |
|---|
| 19 | <ul> |
|---|
| 20 | <li><a href="../index.html">Home</a></li> |
|---|
| 21 | <li><a href="../introduction.html">For Users</a></li> |
|---|
| 22 | <li><a href="bep_0000.html"><span>For Developers</span></a></li> |
|---|
| 23 | <!-- <li><a href="./blog">Blog</a></li> --> |
|---|
| 24 | <li><a href="../donate.html">Donate!</a></li> |
|---|
| 25 | </ul> |
|---|
| 26 | </div> <!-- nav --> |
|---|
| 27 | <!-- ### Begin Content ### --> |
|---|
| 28 | <div id="second"> |
|---|
| 29 | |
|---|
| 30 | |
|---|
| 31 | |
|---|
| 32 | <table class="rfc2822 docutils field-list" frame="void" rules="none"> |
|---|
| 33 | <col class="field-name" /> |
|---|
| 34 | <col class="field-body" /> |
|---|
| 35 | <tbody valign="top"> |
|---|
| 36 | <tr class="field"><th class="field-name">BEP:</th><td class="field-body">8</td> |
|---|
| 37 | </tr> |
|---|
| 38 | <tr class="field"><th class="field-name">Title:</th><td class="field-body">Tracker Peer Obfuscation</td> |
|---|
| 39 | </tr> |
|---|
| 40 | <tr class="field"><th class="field-name">Version:</th><td class="field-body">10891</td> |
|---|
| 41 | </tr> |
|---|
| 42 | <tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference external" href="https://svn.bittorrent.com/trac.cgi/browser/dotorg/trunk/html/beps/bep_0008.rst">2008-02-19 15:44:01 -0800 (Tue, 19 Feb 2008)</a></td> |
|---|
| 43 | </tr> |
|---|
| 44 | <tr class="field"><th class="field-name">Author:</th><td class="field-body">David Harrison <dave at bittorrent.com>, Anthony Ciani <tony at ciani.phy.uic.edu>, Arvid Norberg <arvid at bittorrent.com>, Greg Hazel <greg at bittorrent.com></td> |
|---|
| 45 | </tr> |
|---|
| 46 | <tr class="field"><th class="field-name">Status:</th><td class="field-body">Draft</td> |
|---|
| 47 | </tr> |
|---|
| 48 | <tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td> |
|---|
| 49 | </tr> |
|---|
| 50 | <tr class="field"><th class="field-name">Created:</th><td class="field-body">31-Jan-2008</td> |
|---|
| 51 | </tr> |
|---|
| 52 | <tr class="field"><th class="field-name">Post-History:</th><td class="field-body"></td> |
|---|
| 53 | </tr> |
|---|
| 54 | </tbody> |
|---|
| 55 | </table> |
|---|
| 56 | <hr /> |
|---|
| 57 | <div class="contents topic" id="contents"> |
|---|
| 58 | <p class="topic-title first">Contents</p> |
|---|
| 59 | <ul class="simple"> |
|---|
| 60 | <li><a class="reference internal" href="#announce" id="id8">Announce</a></li> |
|---|
| 61 | <li><a class="reference internal" href="#announce-response" id="id9">Announce Response</a></li> |
|---|
| 62 | <li><a class="reference internal" href="#obfuscation-method" id="id10">Obfuscation Method</a></li> |
|---|
| 63 | <li><a class="reference internal" href="#optimizations" id="id11">Optimizations</a></li> |
|---|
| 64 | <li><a class="reference internal" href="#backwards-compatibility" id="id12">Backwards Compatibility</a></li> |
|---|
| 65 | <li><a class="reference internal" href="#rationale" id="id13">Rationale</a></li> |
|---|
| 66 | <li><a class="reference internal" href="#references" id="id14">References</a></li> |
|---|
| 67 | <li><a class="reference internal" href="#example-python-code" id="id15">Example Python Code</a></li> |
|---|
| 68 | </ul> |
|---|
| 69 | </div> |
|---|
| 70 | <p>This extends the tracker protocol to support simple obfuscation of the |
|---|
| 71 | peers it returns, using the infohash as a shared secret between the |
|---|
| 72 | peer and the tracker. The obfuscation does not provide any security |
|---|
| 73 | against eavesdroppers that know the infohash of the torrent. The goal |
|---|
| 74 | is to prevent internet service providers and other network |
|---|
| 75 | administrators from blocking or disrupting bittorrent traffic |
|---|
| 76 | connections that span between the receiver of a tracker response and |
|---|
| 77 | any peer IP-port appearing in that tracker response.</p> |
|---|
| 78 | <p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", |
|---|
| 79 | "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are |
|---|
| 80 | to be interpreted as described in IETF <a class="reference external" href="http://tools.ietf.org/html/rfc2119">RFC 2119</a> <a class="footnote-reference" href="#id6" id="id7">[5]</a>.</p> |
|---|
| 81 | <div class="section" id="announce"> |
|---|
| 82 | <h1>Announce</h1> |
|---|
| 83 | <p>When using this extension, instead of passing the <tt class="docutils literal"><span class="pre">info_hash</span></tt> parameter |
|---|
| 84 | to the tracker, a <tt class="docutils literal"><span class="pre">sha_ih</span></tt> is passed.</p> |
|---|
| 85 | <p>The value of <tt class="docutils literal"><span class="pre">sha_ih</span></tt> MUST be the info-hash of the torrent, with a second |
|---|
| 86 | SHA-1 applied to it.</p> |
|---|
| 87 | <p>For example if a torrent has infohash with hex representation |
|---|
| 88 | <tt class="docutils literal"><span class="pre">aaf4c61ddcc5e8a2dabedef3b482cd9aea9434d</span></tt> then its <tt class="docutils literal"><span class="pre">sha_ih</span></tt> is |
|---|
| 89 | <tt class="docutils literal"><span class="pre">sha1(infohash)='6b4f89a54e2d27ecd7e8da5b4ab8fd9d1d8b119'</span></tt>.</p> |
|---|
| 90 | <p>The value MUST be url encoded, just like the <tt class="docutils literal"><span class="pre">info_hash</span></tt>. Thus the |
|---|
| 91 | <tt class="docutils literal"><span class="pre">sha_ih</span></tt> above when url encoded becomes |
|---|
| 92 | <tt class="docutils literal"><span class="pre">kO%89%A5N-%27%EC%D7%E8%DA%05%B4%AB%8F%D9%D1%D8%B1%19</span></tt>.</p> |
|---|
| 93 | <p>If the <tt class="docutils literal"><span class="pre">sha_ih</span></tt> is passed then the value for the <tt class="docutils literal"><span class="pre">port</span></tt> parameter |
|---|
| 94 | should be treated as a 16 bit integer and MUST be obscured as |
|---|
| 95 | described in the <a class="reference internal" href="#obfuscation-method">Obfuscation Method</a> section. Similarly if the |
|---|
| 96 | optional <tt class="docutils literal"><span class="pre">ip</span></tt> parameter is passed in the announce then its value |
|---|
| 97 | MUST also be so obscured.</p> |
|---|
| 98 | <p>This extension does not change the semantics of any parameter passed |
|---|
| 99 | in the peer's announce.</p> |
|---|
| 100 | </div> |
|---|
| 101 | <div class="section" id="announce-response"> |
|---|
| 102 | <h1>Announce Response</h1> |
|---|
| 103 | <p>If the tracker supports this extension, the response should be exactly |
|---|
| 104 | the same as if the <tt class="docutils literal"><span class="pre">info_hash</span></tt> had been passed, except that any |
|---|
| 105 | field that contains peer information (such as <tt class="docutils literal"><span class="pre">peers</span></tt>, <tt class="docutils literal"><span class="pre">peers6</span></tt> or |
|---|
| 106 | any other field defined by another extension) MUST be obfuscated as |
|---|
| 107 | described in the next section.</p> |
|---|
| 108 | <p>There are additional parameters the tracker may OPTIONALLY return. |
|---|
| 109 | These are discussed in the <a class="reference internal" href="#optimizations">optimizations</a> section.</p> |
|---|
| 110 | </div> |
|---|
| 111 | <div class="section" id="obfuscation-method"> |
|---|
| 112 | <h1>Obfuscation Method</h1> |
|---|
| 113 | <p>The values for the <tt class="docutils literal"><span class="pre">ip</span></tt> and <tt class="docutils literal"><span class="pre">port</span></tt> announce parameters, the |
|---|
| 114 | <em>returned peer list</em> and any other values that contain peer |
|---|
| 115 | information are obscured using the method described in this section.</p> |
|---|
| 116 | <p>We distinguish between the <em>tracker peer list</em> and the <em>returned peer |
|---|
| 117 | list</em>. The <em>tracker peer list</em> contains the ip-port pairs of all |
|---|
| 118 | known peers in a given torrent, i.e., those peers that have reported |
|---|
| 119 | to the tracker that they are transferring the file with a given |
|---|
| 120 | infohash. The tracker may store this peer list however it wishes. |
|---|
| 121 | The <em>returned peer list</em> contains a packed array of ip-port pairs |
|---|
| 122 | conforming to the BitTorrent protocol specification. If the swarm is |
|---|
| 123 | sufficiently large then the returned ip-port pairs constitute a subset |
|---|
| 124 | of the ip-port pairs in the <em>tracker peer list</em>.</p> |
|---|
| 125 | <p>When a parameter is obscured, it is encrypted using RC4-drop768 |
|---|
| 126 | encryption using the infohash as a shared secret and optionally |
|---|
| 127 | employing an initialization vector.</p> |
|---|
| 128 | <p>For the remainder of this document RC4 refers to RC4-drop768. In the |
|---|
| 129 | process of encryption, RC4 generates a pseudorandom string that is |
|---|
| 130 | XOR'd with the plaintext to generate the ciphertext. The receiver |
|---|
| 131 | recovers the plaintext by generating the same pseudorandom string and |
|---|
| 132 | XOR'ing it with the ciphertext. In generating the pseudorandom |
|---|
| 133 | string, the tracker and client MUST discard the first 768 bytes. The |
|---|
| 134 | next 8 bytes in the pseudorandom string are reserved for optimizations |
|---|
| 135 | discussed in the next section.</p> |
|---|
| 136 | <p>To communicate an initialization vector, the tracker includes in the |
|---|
| 137 | bencoded response the parameter <tt class="docutils literal"><span class="pre">iv</span></tt> with value set to a byte string |
|---|
| 138 | containing the initialization vector. The initialization vector can |
|---|
| 139 | be of arbitrary length and is sent in plaintext. Initialization |
|---|
| 140 | vectors can only be applied to parameters in tracker responses and NOT |
|---|
| 141 | to announces.</p> |
|---|
| 142 | <p>If the tracker sends no initialization vector then the infohash is |
|---|
| 143 | used as the RC4 key (160 bit key). If the tracker provides an |
|---|
| 144 | initialization vector then the RC4 key is generated by appending the |
|---|
| 145 | vector to the infohash and then hashing with SHA-1. The resulting |
|---|
| 146 | hash is then used as the RC4 key.</p> |
|---|
| 147 | <p>For example, given infohash <tt class="docutils literal"><span class="pre">aaf4c61ddcc5e8a2dabedef3b482cd9aea9434d</span></tt> |
|---|
| 148 | and initialization vector <tt class="docutils literal"><span class="pre">abcd</span></tt> both represented in hex, the RC4 key |
|---|
| 149 | is derived as follows:</p> |
|---|
| 150 | <pre class="literal-block"> |
|---|
| 151 | key = sha1( 'aaf4c61ddcc5e8a2dabedef3b482cd9aea9434dabcd' ) |
|---|
| 152 | </pre> |
|---|
| 153 | <p>The resulting key in hex is <tt class="docutils literal"><span class="pre">f36e9cae87cf33e07645ef5ca745a8a83469f31e</span></tt>.</p> |
|---|
| 154 | <p>It is RECOMMENDED that the tracker use the initialization vector, and |
|---|
| 155 | that it change the <tt class="docutils literal"><span class="pre">iv</span></tt> on roughly the same period as the rerequest |
|---|
| 156 | interval. The reasoning for this is contained in the rationale.</p> |
|---|
| 157 | </div> |
|---|
| 158 | <div class="section" id="optimizations"> |
|---|
| 159 | <h1>Optimizations</h1> |
|---|
| 160 | <p>The described optimizations are OPTIONAL for the tracker, but the |
|---|
| 161 | corresponding client-side MUST be implemented by clients that support |
|---|
| 162 | this extension. These optimizations hobble the strength of the RC4 |
|---|
| 163 | encryption in order to improve tracker performance. In the <a class="reference internal" href="#rationale">rationale</a> |
|---|
| 164 | section we discuss why hobbling RC4 is reasonable and in many cases |
|---|
| 165 | has negligible foreseen effect on security.</p> |
|---|
| 166 | <p>For the purpose of these optimizations we assume that the tracker |
|---|
| 167 | stores the tracker peer list for each infohash as a packed array that |
|---|
| 168 | can be copied directly into the response. We further assume that the |
|---|
| 169 | packed array is reused many times and that with each request the |
|---|
| 170 | tracker either returns the entire packed array or copies a single |
|---|
| 171 | contiguous substring from the tracker peer list into the response.</p> |
|---|
| 172 | <p>If the peerlist is represented and used as assumed then to improve |
|---|
| 173 | randomness in the set of peers handed out by the tracker, it is |
|---|
| 174 | RECOMMENDED that the tracker periodically reshuffle the peerlist with |
|---|
| 175 | period similar to the rerequest interval. After each reshuffle the |
|---|
| 176 | tracker reperforms the operations described in this section.</p> |
|---|
| 177 | <p>To reduce computation the tracker MAY cache the pseudorandom string |
|---|
| 178 | generated by RC4 and reuse it as peers arrive and depart.</p> |
|---|
| 179 | <p>The tracker MAY also cache the encrypted tracker peer list. To |
|---|
| 180 | support this the tracker MUST pass two additional parameters <em>i</em> and <em>n</em> |
|---|
| 181 | each with 32-bit integer values, except the tracker MAY omit <em>i</em> and |
|---|
| 182 | <em>n</em> when <em>i=0</em> and the <em>returned peer list</em> is the entire <em>tracker peer |
|---|
| 183 | list</em>. Whether the tracker returns <em>i</em> and <em>n</em>, the first 8 bytes of |
|---|
| 184 | the RC4 psuedorandom string are reserved for obscuring <em>i</em> and <em>n</em>. |
|---|
| 185 | We come back to this momentarily. Decryption starts by XORing from |
|---|
| 186 | <em>6i</em> bytes for ipv4 (or <em>18i</em> for ipv6) into the pseudorandom string |
|---|
| 187 | after the discarded and reserved bytes. Assuming that the tracker |
|---|
| 188 | encrypted the tracker peer list starting from the first byte after the |
|---|
| 189 | discarded and reserved bytes in the pseudorandom string then <em>i</em> also |
|---|
| 190 | corresponds to the <em>ith</em> ip-port pair in the tracker peer list.</p> |
|---|
| 191 | <p>So that the client and the tracker do not have to generate an |
|---|
| 192 | arbitrarily long pseudorandom string to support large swarms, we |
|---|
| 193 | assume the tracker bounds the length of the pseudorandom string and |
|---|
| 194 | reports the length in ip-port pairs as the value to parameter <em>n</em>. <em>n</em> |
|---|
| 195 | excludes reserved and discarded bytes. We RECOMMEND that <em>n</em> be equal |
|---|
| 196 | to the length of the tracker peer list or random but within constant |
|---|
| 197 | factor of the longest peerlist returned by the tracker, whichever is |
|---|
| 198 | smaller. Thus the tracker encrypts the <em>jth</em> byte of the <em>ith</em> |
|---|
| 199 | ip-port pair in an ipv4 tracker peer list by XORing with the byte |
|---|
| 200 | <em>(6i+j)</em> <cite>mod</cite> <em>n</em> bytes into the pseudorandom string.</p> |
|---|
| 201 | <p>Transmitting <em>i</em> and <em>n</em> as plaintext would significantly reduce the |
|---|
| 202 | cost for an attacker to recover the pseudorandom string. The tracker |
|---|
| 203 | MUST XOR the value of <em>i</em> with the first 32 bits of the pseudorandom |
|---|
| 204 | string. The tracker then XORs <em>n</em> with the next 32 bits from the |
|---|
| 205 | pseudorandom string (see Figure 1).</p> |
|---|
| 206 | <div class="figure"> |
|---|
| 207 | <img alt="bep_0008_pseudo.png" src="bep_0008_pseudo.png" /> |
|---|
| 208 | <p class="caption"><strong>Figure 1:</strong> The first 768 bytes of the RC4 pseudorandom |
|---|
| 209 | string are discarded. The parameter <em>i</em> in the tracker response has |
|---|
| 210 | value <tt class="docutils literal"><span class="pre">x</span> <span class="pre">xor</span> <span class="pre">i</span></tt>. The parameter <em>n</em> has value <tt class="docutils literal"><span class="pre">y</span> <span class="pre">xor</span> <span class="pre">n</span></tt>.</p> |
|---|
| 211 | </div> |
|---|
| 212 | <p>We describe encryption in the following example for an ipv4 tracker peer |
|---|
| 213 | list consisting of 3 ip-port pairs, and using an RC4 pseudorandom string |
|---|
| 214 | of length <em>n=2</em>. <em>n</em> is small for purposes of illustration. Also, for the |
|---|
| 215 | purpose of illustration, the tracker returns only 2 peers at a time.</p> |
|---|
| 216 | <pre class="literal-block"> |
|---|
| 217 | Given the following peer list |
|---|
| 218 | (208.72.193.86, 6881), (209.81.173.15,14321), (128.213.6.8, 6881) |
|---|
| 219 | |
|---|
| 220 | As a packed array represented in hex it becomes |
|---|
| 221 | |
|---|
| 222 | d048c1561ae1d151ad0f37f180d506081ae1 |
|---|
| 223 | |
|---|
| 224 | which we XOR with an RC4 pseudorandom string excluding discarded and |
|---|
| 225 | reserved bytes, e.g., |
|---|
| 226 | |
|---|
| 227 | a496e5f9b83e835013d42226 |
|---|
| 228 | |
|---|
| 229 | to generate |
|---|
| 230 | |
|---|
| 231 | 74de24afa2df5201bedb15d72443e3f1a2df |
|---|
| 232 | </pre> |
|---|
| 233 | <p>Because the RC4 pseudorandom string is shorter than the tracker |
|---|
| 234 | peer list, we wrap to the beginning of the pseudorandom string.</p> |
|---|
| 235 | <p>A tracker returning the first two peers would return the bencoded |
|---|
| 236 | equivalent of:</p> |
|---|
| 237 | <pre class="literal-block"> |
|---|
| 238 | peers=74de24afa2df5201bedb15d7, i=0, n=2 |
|---|
| 239 | </pre> |
|---|
| 240 | <p>A tracker returning the second and third peer would return the |
|---|
| 241 | bencoded equivalent of:</p> |
|---|
| 242 | <pre class="literal-block"> |
|---|
| 243 | peers=5201bedb15d72443e3f1a2df, i=1, n=2 |
|---|
| 244 | </pre> |
|---|
| 245 | <p>In each response the tracker includes additional parameters such as |
|---|
| 246 | the rerequest <tt class="docutils literal"><span class="pre">interval</span></tt> and the initialization vector <tt class="docutils literal"><span class="pre">iv</span></tt>.</p> |
|---|
| 247 | <p>The tracker response MUST remain a valid bencoded message.</p> |
|---|
| 248 | </div> |
|---|
| 249 | <div class="section" id="backwards-compatibility"> |
|---|
| 250 | <h1>Backwards Compatibility</h1> |
|---|
| 251 | <p>Trackers that support obfuscation are identified in the .torrent file |
|---|
| 252 | by the inclusion of an <tt class="docutils literal"><span class="pre">obfuscate-announce-list</span></tt> which otherwise has the |
|---|
| 253 | same semantics as the <tt class="docutils literal"><span class="pre">announce-list</span></tt> parameter. Peers that do not support |
|---|
| 254 | obfuscation simply ignore the <tt class="docutils literal"><span class="pre">obfuscate-announce-list</span></tt>.</p> |
|---|
| 255 | <p>A client that is configured to use this extension should always send |
|---|
| 256 | the <tt class="docutils literal"><span class="pre">sha_ih</span></tt> to any tracker supporting obfuscation. The client |
|---|
| 257 | SHOULD only contact trackers in the <tt class="docutils literal"><span class="pre">announce-list</span></tt> once the client |
|---|
| 258 | has attempted all trackers in the <tt class="docutils literal"><span class="pre">obfuscate-announce-list</span></tt> and all failed.</p> |
|---|
| 259 | <p>If a tracker that supports obfuscation wishes to allow legacy peers to |
|---|
| 260 | connect to the tracker then the announce URL should appear in both the |
|---|
| 261 | <tt class="docutils literal"><span class="pre">obfuscate-announce-list</span></tt> and the <tt class="docutils literal"><span class="pre">announce-list</span></tt>.</p> |
|---|
| 262 | <p>If a tracker URL appears in both lists running on the same port, and |
|---|
| 263 | the tracker failed to respond when selected from the |
|---|
| 264 | <tt class="docutils literal"><span class="pre">obfuscate-announce-list</span></tt> then the client MAY treat the tracker in |
|---|
| 265 | the <tt class="docutils literal"><span class="pre">announce-list</span></tt> as if it were temporarily unreachable and defer |
|---|
| 266 | trying it until it has tried other trackers in the <tt class="docutils literal"><span class="pre">announce-list</span></tt>.</p> |
|---|
| 267 | <p>Peers MUST never send both the <tt class="docutils literal"><span class="pre">info_hash</span></tt> and <tt class="docutils literal"><span class="pre">sha_ih</span></tt> parameters |
|---|
| 268 | in the same request, since that would defeat the purpose of the shared |
|---|
| 269 | secret.</p> |
|---|
| 270 | <p>Any peer that requests with a <tt class="docutils literal"><span class="pre">sha_ih</span></tt> SHOULD implement Message |
|---|
| 271 | Stream Encryption (MSE) <a class="footnote-reference" href="#mse" id="id1">[1]</a>. Any peer returned from the tracker |
|---|
| 272 | in response to a request with a <tt class="docutils literal"><span class="pre">sha_ih</span></tt> SHOULD be assumed to |
|---|
| 273 | support Message Stream Encryption. We include these provisions |
|---|
| 274 | because if a peer communicates with another peer without using MSE |
|---|
| 275 | then the BitTorrent protocol is trivially identified from the first |
|---|
| 276 | twenty bytes of the BitTorrent header and the <tt class="docutils literal"><span class="pre">info_hash</span></tt> appears in |
|---|
| 277 | plaintext as the next twenty bytes, hence also defeating the purpose |
|---|
| 278 | of the shared secret.</p> |
|---|
| 279 | <p>If the tracker does not know enough peers assumed to support MSE to |
|---|
| 280 | return the desired number of peers then it MAY include peers that are |
|---|
| 281 | not assumed to support MSE. If a peer closes a connection in response |
|---|
| 282 | to an encrypted header then the initiating peer SHOULD assume that the |
|---|
| 283 | peer does not support MSE. The initiating peer however SHOULD ONLY |
|---|
| 284 | initiate unencrypted connections when all peers have been tried and |
|---|
| 285 | those that support MSE fail to provide "adequate performance." We |
|---|
| 286 | intentionally omit any definition of "adequate performance."</p> |
|---|
| 287 | </div> |
|---|
| 288 | <div class="section" id="rationale"> |
|---|
| 289 | <h1>Rationale</h1> |
|---|
| 290 | <p>This extension directly addresses a known attack on the BitTorrent |
|---|
| 291 | protocol performed by some deployed network hardware. By obscuring |
|---|
| 292 | the ip-port pairs network hardware can no longer easily identify |
|---|
| 293 | ip-port pairs that are running BitTorrent by observing peer-to-tracker |
|---|
| 294 | communications. This deployed hardware under some conditions disrupts |
|---|
| 295 | BitTorrent connections by injecting forged TCP reset packets.</p> |
|---|
| 296 | <p>This hardware was presumably deployed to get around BitTorrent |
|---|
| 297 | Message Stream Encryption <a class="footnote-reference" href="#mse" id="id2">[1]</a>. Peers implementing BitTorrent Message Stream |
|---|
| 298 | Encryption obfuscate peer-to-peer connections by employing RC4 |
|---|
| 299 | encryption on every byte from the first byte transferred. BitTorrent |
|---|
| 300 | Message Stream Encryption thus increases the difficulty for a device |
|---|
| 301 | observing passing packets to identify BitTorrent peer-to-peer |
|---|
| 302 | connections.</p> |
|---|
| 303 | <p>By using the SHA-1 of the infohash, the tracker is able to identify |
|---|
| 304 | torrents without sending the plaintext infohash and without requiring |
|---|
| 305 | an additional prior exchange of a shared secret. Where trackers now |
|---|
| 306 | maintain mappings from infohash to the corresponding torrent's |
|---|
| 307 | peerlist and other torrent-specific state, obfuscated trackers would |
|---|
| 308 | need one additional mapping from <tt class="docutils literal"><span class="pre">sha_ih</span></tt> to the torrent's state. |
|---|
| 309 | Trackers may also cache the encrypted version of each torrent's |
|---|
| 310 | tracker peer list, to increase computational performance at the |
|---|
| 311 | expense of increasing memory footprint by a constant factor.</p> |
|---|
| 312 | <p>The obfuscation method meets the following criteria:</p> |
|---|
| 313 | <ul class="simple"> |
|---|
| 314 | <li>The entire plaintext of the peer list is not easily obtained even if |
|---|
| 315 | an eavesdropper identifies one or more subsequent connections as |
|---|
| 316 | using BitTorrent and the corresponding ip-port pairs appeared in the |
|---|
| 317 | ciphertext of the tracker response.</li> |
|---|
| 318 | <li>Even when a subsequent connection from a peer that has received a |
|---|
| 319 | tracker response is observed by an eavesdropper, it is difficult to |
|---|
| 320 | map the ip-port pair to specific ciphertext to verify that the |
|---|
| 321 | connection is using BitTorrent.</li> |
|---|
| 322 | </ul> |
|---|
| 323 | <p>When the <a class="reference internal" href="#optimizations">optimizations</a> are used,</p> |
|---|
| 324 | <ul class="simple"> |
|---|
| 325 | <li>Few computations are performed at request time.</li> |
|---|
| 326 | <li>Encryption may be performed at the time a peer is added. |
|---|
| 327 | The encrypted peer ip and port may be handed out hundreds of times.</li> |
|---|
| 328 | <li>Security is minimally impacted.</li> |
|---|
| 329 | </ul> |
|---|
| 330 | <p>The objective is NOT to create a cryptographically secure protocol |
|---|
| 331 | that can survive unlimited observation of passing packets and |
|---|
| 332 | substantial computational resources on network timescales. The objective |
|---|
| 333 | is to raise the bar sufficiently to deter attacks based on observing |
|---|
| 334 | ip-port numbers in peer-to-tracker communications.</p> |
|---|
| 335 | <p>If a tracker observes a large number of tracker requests and responses |
|---|
| 336 | and subsequent connections, it is possible to attack the encryption. |
|---|
| 337 | RC4 is known to have a number of weaknesses especially in the way it |
|---|
| 338 | is used with WEP <a class="footnote-reference" href="#borisov" id="id3">[2]</a> <a class="footnote-reference" href="#scott" id="id4">[3]</a> <a class="footnote-reference" href="#stubblefeld" id="id5">[4]</a>. However, with |
|---|
| 339 | tracker peer obfuscation, the number of bytes transferred between the |
|---|
| 340 | tracker and a client is likely significantly smaller than transferred |
|---|
| 341 | between a wireless computer and a basestation. An attacker faces a |
|---|
| 342 | much larger task in obtaining sufficient ciphertext to directly break |
|---|
| 343 | the encryption.</p> |
|---|
| 344 | <p>Hobbling the RC4 encryption by using a bounded-length RC4 pseudorandom |
|---|
| 345 | string for small swarms is likely to have negilgible impact on |
|---|
| 346 | security over any other encyption method since the pseudorandom string |
|---|
| 347 | is probably equal to or longer than the plaintext and thus no part of |
|---|
| 348 | it is repeated in the XOR except as peers arrive or leave the swarm. |
|---|
| 349 | Thus on the timescales of rerequest intervals, nearly the same |
|---|
| 350 | ciphertext is handed to every peer requesting the same infohash. |
|---|
| 351 | Intercepting the same ciphertext multiple times provides no additional |
|---|
| 352 | information to the attacker. The attacker could correlate ip-port |
|---|
| 353 | pairs in connections following tracker responses, but an attacker |
|---|
| 354 | could do this regardless of the encryption method employed. |
|---|
| 355 | Furthermore more direct methods of traffic analysis applied to |
|---|
| 356 | peer-to-peer communication is available to network operators.</p> |
|---|
| 357 | <p>For larger swarms, hobbling RC4 may simplify breaking the encryption |
|---|
| 358 | since the same pseudorandom string is used repeatedly across the peer |
|---|
| 359 | list. Some study is in order taking into account that the tracker can |
|---|
| 360 | periodically change intiailization vectors.</p> |
|---|
| 361 | <p>We know from experience that periodically reshuffling peer lists on |
|---|
| 362 | the order of the rerequest interval negligibly impacts tracker |
|---|
| 363 | performance even with swarms containing millions of peers. Generating |
|---|
| 364 | a new pseudorandom string using RC4 on this same time interval is |
|---|
| 365 | likely to incur negligible performance penalty because 1) RC4 is a |
|---|
| 366 | small constant factor more expensive than a shuffle on an input string |
|---|
| 367 | of equal length, 2) the generated pseudorandom string is only <em>n</em> |
|---|
| 368 | ip-port pairs long where recommended <em>n</em> is within a small constant |
|---|
| 369 | factor larger than the largest <em>returned peer list</em> and thus much |
|---|
| 370 | smaller than the <em>tracker peer list</em> for large swarms, and 3) the cost |
|---|
| 371 | of the XOR operation is lighter weight than performing a random |
|---|
| 372 | shuffle.</p> |
|---|
| 373 | </div> |
|---|
| 374 | <div class="section" id="references"> |
|---|
| 375 | <h1>References</h1> |
|---|
| 376 | <table class="docutils footnote" frame="void" id="mse" rules="none"> |
|---|
| 377 | <colgroup><col class="label" /><col /></colgroup> |
|---|
| 378 | <tbody valign="top"> |
|---|
| 379 | <tr><td class="label">[1]</td><td><em>(<a class="fn-backref" href="#id1">1</a>, <a class="fn-backref" href="#id2">2</a>)</em> BitTorrent Message Stream Encryption |
|---|
| 380 | (<a class="reference external" href="http://www.azureuswiki.com/index.php/Message_Stream_Encryption">http://www.azureuswiki.com/index.php/Message_Stream_Encryption</a>)</td></tr> |
|---|
| 381 | </tbody> |
|---|
| 382 | </table> |
|---|
| 383 | <table class="docutils footnote" frame="void" id="borisov" rules="none"> |
|---|
| 384 | <colgroup><col class="label" /><col /></colgroup> |
|---|
| 385 | <tbody valign="top"> |
|---|
| 386 | <tr><td class="label"><a class="fn-backref" href="#id3">[2]</a></td><td>Nikita Borisov, Ian Goldberg, and David Wagner. Intercepting |
|---|
| 387 | mobile communications: the insecurity of 802.11. In ACM MobiCom 2001, |
|---|
| 388 | pages 180-189. ACM Press, 2001.</td></tr> |
|---|
| 389 | </tbody> |
|---|
| 390 | </table> |
|---|
| 391 | <table class="docutils footnote" frame="void" id="scott" rules="none"> |
|---|
| 392 | <colgroup><col class="label" /><col /></colgroup> |
|---|
| 393 | <tbody valign="top"> |
|---|
| 394 | <tr><td class="label"><a class="fn-backref" href="#id4">[3]</a></td><td>Scott R. Fluhrer, Itsik Mantin, and Adi |
|---|
| 395 | Shamir. Weaknesses in the key scheduling algorithm of RC4. In Serge |
|---|
| 396 | Vaudenay and Amr M. Youssef, editors, Selected Areas in |
|---|
| 397 | Cryptography 2001, volume 2259 of Lecture Notes in Computer |
|---|
| 398 | Science, pages 1-24. Springer, 2001.</td></tr> |
|---|
| 399 | </tbody> |
|---|
| 400 | </table> |
|---|
| 401 | <table class="docutils footnote" frame="void" id="stubblefeld" rules="none"> |
|---|
| 402 | <colgroup><col class="label" /><col /></colgroup> |
|---|
| 403 | <tbody valign="top"> |
|---|
| 404 | <tr><td class="label"><a class="fn-backref" href="#id5">[4]</a></td><td>Adam Stubblefeld, John Ioannidis, and Aviel |
|---|
| 405 | D. Rubin. A key recovery attack on the 802.11b wired equivalent |
|---|
| 406 | privacy protocol (WEP). ACM Transactions on Information and System |
|---|
| 407 | Security, 7(2):319-332, May 2004.</td></tr> |
|---|
| 408 | </tbody> |
|---|
| 409 | </table> |
|---|
| 410 | <table class="docutils footnote" frame="void" id="id6" rules="none"> |
|---|
| 411 | <colgroup><col class="label" /><col /></colgroup> |
|---|
| 412 | <tbody valign="top"> |
|---|
| 413 | <tr><td class="label"><a class="fn-backref" href="#id7">[5]</a></td><td><a class="reference external" href="http://tools.ietf.org/html/rfc2119">http://tools.ietf.org/html/rfc2119</a></td></tr> |
|---|
| 414 | </tbody> |
|---|
| 415 | </table> |
|---|
| 416 | </div> |
|---|
| 417 | <div class="section" id="example-python-code"> |
|---|
| 418 | <h1>Example Python Code</h1> |
|---|
| 419 | <p>Request handling in a dummy tracker implementing tracker peer obfuscation:</p> |
|---|
| 420 | <pre class="literal-block"> |
|---|
| 421 | from sha import sha |
|---|
| 422 | from random import randint |
|---|
| 423 | from struct import unpack |
|---|
| 424 | from rc4 import rc4 # rc4(k) generates k RC4 pseudorandom bytes. |
|---|
| 425 | |
|---|
| 426 | rand = open("/dev/random","r").read |
|---|
| 427 | rc4 = rc4() |
|---|
| 428 | |
|---|
| 429 | # tracker configuration |
|---|
| 430 | MAX_PEERS = 100 |
|---|
| 431 | |
|---|
| 432 | # per torrent state. |
|---|
| 433 | infohash = sha("dummy_info").digest() |
|---|
| 434 | pseudo = '' # pseudorandom RC4 string. |
|---|
| 435 | num_peers = 1000 # current swarm size. |
|---|
| 436 | tracker_peer_list = rand(6) * num_peers |
|---|
| 437 | obfuscated_tracker_peer_list = '' |
|---|
| 438 | |
|---|
| 439 | def |
|---|