Subject: Re: [p2pi] FYI - "Inside the Attack that Crippled Revision3"

From: Laird Popkin <[email-masked]>
Date: Mon, 2 Jun 2008 12:40:58 -0400 (EDT)

Comments below. 

- Laird Popkin, CTO, Pando Networks 
mobile: 646/465-0570 

----- Original Message ----- 
From: "Robb Topolski" <[email-masked]> 
To: [email-masked] 
Sent: Monday, June 2, 2008 11:45:50 AM (GMT-0500) America/New_York 
Subject: Re: [p2pi] FYI - "Inside the Attack that Crippled Revision3" 

On Mon, Jun 2, 2008 at 7:59 AM, Laird Popkin < [email-masked] > wrote: 

1) Did Revision3 really see a SYN flood attack, or were they just getting so many TCP connection attempts (from broken retry logic) that they couldn't handle it? 

I don't believe the attack was anything but a side-effect of broken retry logic. I don't see anything in the history of MediaDefender that suggests a denial-of-service attack is in their M.O.. 

2) Was MediaDefender using Revision3's open tracker to host their own torrents (which is what Revision3 claimed) 

Laird, since this is you asking, I'm confused as to what exactly you're asking (because you definitely know that trackers don't 'host' torrents, they simply store IP:port combinations attached to infohashes). The torrent file has to be obtained elsewhere (sometimes on an affiliated website). Perhaps you're asking if MediaDefender uploaded the *.torrent files to Revision3's website? (And I don't know the answer to that. I never heard of them before now.) 

Sorry my question was ambiguous. So let me try rephrasing: 

The question was whether they were: 

1) Detecting that Revision3's tracker was providing Tracking for pirate torrents and joining those torrents as a peer in order to do whatever MD does to BitTorrent torrents (scraping, serving, etc.). This seems like a reasonable way for them to know what's going on in the swarm, etc. 
2) Publishing new torrents, and running them on Revision3's open tracker. This seems questionable, because if they want to use a Tracker they should run one. 

I think I can explain why MediaDefender would use their tracker, though. MediaDefender owns several of their own trackers that they use for data collection. They release their own *.torrent files, masquerading as some popular album or movie the rights of which are owned by their customer. Encoded into the *.torrent files is a list of trackers. To hide their "fake" trackers, MediaDefender embed their "fake" trackers URLs in a long list of open trackers that prominently include popular systems. Perhaps including the revision3 tracker was chaff to hide the fakes. 

Here is an interesting link: http://www.btmon.com/tracker/http_tracker.revision3.com_20000_announce/ 

As I look at some of the items on that link, I see one that has 63 different tracker URLs listed. This is one hint of a fake torrent, but it's not definitive. 

Very interesting stuff. Nice ads on the page, too. :-) 

This would generate tons of client connections to Revision3's Trackers, though, which MediaDefender can't control. According to Revision3, once they contacted MediaDefender, MD stopped the DOS attack quite quickly, which tells me that it was coming from MD's servers, not clients. 

On Mon, Jun 2, 2008 at 7:59 AM, Laird Popkin < [email-masked] > wrote: 

According to Media Defender, they were monitoring 260K torrents in Revision3's open Tracker, which Revision3 has said could well be true. Revision3's claim is that their Tracker was open from when they launched until a year ago, then was closed, then when it started crashing they opened it again (5 weeks ago), and was closed last weekend. Revision3's theory is that torrents are packaged with a long list of trackers, including theirs (because it was open a year ago), so when it was reopened the torrents all announced to them, instantly making them a very popular pirate Tracker. I don't see a lot of multi-tracker torrents, much less torrents with trackers that have been down for a year, but it's possible... 

The alternative is that in five weeks 260K new torrents were packaged with their newly open Tracker, which would be stunning. 

In either case, tracking 260K pirate torrents would have generated tons of traffic that Revision3 should have noticed, since it would dwarf whatever level of traffic they saw on their (hundreds?) videos that they were delivering using BitTorrent. 

Two things that's not clear to me from the coverage - perhaps someone else here knows more: 

1) Did Revision3 really see a SYN flood attack, or were they just getting so many TCP connection attempts (from broken retry logic) that they couldn't handle it? 
2) Was MediaDefender using Revision3's open tracker to host their own torrents (which is what Revision3 claimed) or were they running BitTorrent clients that joined pirate torrents running on Revision3's open tracker? 

- Laird Popkin, CTO, Pando Networks 
mobile: 646/465-0570 

----- Original Message ----- 
From: "Robb Topolski" < [email-masked] > 
To: "Nicholas Weaver" < [email-masked] > 
Cc: [email-masked] 
Sent: Sunday, June 1, 2008 11:51:05 AM (GMT-0500) America/New_York 
Subject: Re: [p2pi] FYI - "Inside the Attack that Crippled Revision3" 

I think you're right -- MD was tracking those who were exploiting Revision3's open tracker -- and/or they were putting their own fake torrents there. 

However, the behavior of several torrent clients I've used do not respond the way that MD did when the tracker throws an error (e.g. "Not Registered"). They will either to stop the task and wait for the user to start it again, or, wait for a minimal interval (which doubles on each attempt) and then ask the tracker again. This is not by specification, but by common programming practices with networking applications experiencing an error. 

With the above in mind, if they were tracking a number of different hashes, most clients I've used would attempt at least once per hash. The error response thrown for a single infohash query attempt would not apply to different infohash queries using the same tracker. Individual clients don't do enough simultaneous tasks to matter. But if MD tracks thousands upon thousands of hashids on a single tracker, they would be well advised to add some anti-hammer code to prevent hammering even though the infohashes differ. 

Robb Topolski 

On Fri, May 30, 2008 at 3:17 PM, Nicholas Weaver < [email-masked] > wrote: 

Actually, it sounds like MD was tracking those who were exploiting Revision3's open tracker. 

They were set up to agressively monitor, and when they found a hash in the open tracker that was being used to host questinable material, they kept on it. And when all those hashes all got removed at the same time, their monitor went bonkers as it tried to reconnect to every single hash all at once. 

At least, thats what I'd be doing. 

-- 
Robb Topolski ( [email-masked] ) 
Hillsboro, Oregon USA 
http://www.funchords.com/ 
_______________________________________________ p2pi mailing list [email-masked] https://www.ietf.org/mailman/listinfo/p2pi 

-- 
Robb Topolski ( [email-masked] ) 
Hillsboro, Oregon USA 
http://www.funchords.com/ 
_______________________________________________ p2pi mailing list [email-masked] https://www.ietf.org/mailman/listinfo/p2pi 

_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: "Robb Topolski" <[email-masked]>
Date: Mon, 2 Jun 2008 11:51:29 -0700

> Very interesting stuff. Nice ads on the page, too. :-)
My apologies to all -- I run an ad-blocker and didn't see anything.  I
apologize if that was not work-safe.

-- 
Robb Topolski ([email-masked])
Hillsboro, Oregon USA
http://www.funchords.com/
_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi