Notices for planetlab: message number 00050
[Date Prev][Date Next][Date Index]

FYI: Further information regarding DMCA take-down notice]

-------- Original Message --------
Subject: [PlanetLab-PIs] Fwd: [PL #45353] Further information regarding DMCA take-down notice
Date: Mon, 31 Aug 2009 16:51:03 -0400
From: Larry Peterson <llp@cs.princeton.edu>

I'm forwarding a detailed description of what happened
from Mike Freedman.

We've seen quite a few take-down notices today. As a PI,
please communicate with your University's DMCA  agent
and security officials about the situation, and try to help
them appreciate why taking your PlanetLab nodes offline
is not warranted.


---------- Forwarded message ----------
From: Michael J Freedman via RT <support@planet-lab.org>
Date: Mon, Aug 31, 2009 at 3:58 PM
Subject: [PL #45353] Further information regarding DMCA take-down notice

Email Recipients (see http://www.planet-lab.org/Support )
     Requestor: mfreed@CS.Princeton.EDU


Mon Aug 31 15:58:20 2009: Request 45353 was acted upon.
Transaction: Ticket created by mfreed@CS.Princeton.EDU

Subject: Further information regarding DMCA take-down notice

New possible information which might shed more light on these DMCA
complaints from the VPA.  The high-level point is that this remains a
false positive, and CoralCDN never transmitted, sent, stored, proxied,
etc. actual BitTorrent traffic, and it was indeed just involved with
proxying requests to the BitTorrent tracker at denis.stalker.h3q.com.

The BitTorrent tracker protocol does not include both POSTs (for
announcing one's address) and GETs (for retrieving meta-data about
others), as one should conceptually build RESTful protocols that do
state modifications.  (Sidenote: As CoralCDN blocks all POST requests,
this would have prevented the problem.)

Instead, a BitTorrent tracker's API is basically a single GET request
"announce", which has a request string that includes:

 info_hash:  which file/swarm is the client interested in
 peer_id: identity of the client
 ip: OPTIONAL address of the client
 port: port client is listening on



The problem is that the spec lists IP address as an optional value, even
though it does further say:

#  ip: Optional. The true IP address of the client machine, in dotted
quad format or rfc3513 defined hexed IPv6 address. Notes: In general
this parameter is not necessary as the address of the client can be
determined from the IP address from which the HTTP request came. The
parameter is only needed in the case where the IP address that the
request came in on is not the IP address of the client. This happens if
the client is communicating to the tracker through a proxy (or a
transparent web proxy/cache.) ...

Of course, that's precisely what is going on here:  The BitTorrent
client is connecting to the BitTorrent tracker via a HTTP proxy (namely,
CoralCDN).  Unfortunately, my spot-check of a few requests to the
tracker showed that they LACKED this IP field, i.e., the client software
did not include this optional parameter:




Thus, the tracker presumably used CoralCDN's IP address in place of an
explicit one specified by the client, and recorded "peer_id"'s network
address as being the <coralcdn_IP>:<client_port> pair, where
<coralcdn_ip> is a PlanetLab IP address.  This tuple is useless, of
course, as it's the combination of the proxy's IP and the client port.
(And the proxy isn't running BitTorrent, of course.)

I should note that CoralCDN does not try to hide the fact that it is an
HTTP proxy -- namely, in includes both X-Forwarded-For and Via headers
in the HTTP request it sends on to the server (which is a BitTorrent
tracker, in this case) -- but I somewhat doubt that the BitTorrent
tracker is smart enough to consider these "de facto standard" headers.

(On further consideration, this actually appears to be a bug in the
BitTorrent specification.  Without an explicitly-supplied IP address,
there's no way this will work if the client is connecting to the tracker
over an HTTP proxy, even if the client itself has a publicly-routable IP

So, this complaint might actually be the same false positive as we saw
before: namely, a PlanetLab IP address was incorrectly included in the
tracker's set of peers.  Although it also remains the possibility that
this complaint could have originated due to the announced domain of the
tracker, as we thought before  Under both scenarios, of course, no
content was stored, cached, sent, proxied, etc.  And really, all this
did was make the BitTorrent swarm behave worse, as any request to this
<coralcdn_ip>:<client_port> would just fail.

Mike Freedman