Subject: [p2pi] Slide decks from today's meetings?

From: "John Bartlett" <[email-masked]>
Date: Wed, 28 May 2008 22:09:03 -0400

Are the slide decks from today's (MIT) presentations available?  Thanks.

JB
John Bartlett      NetForecast, Inc.
call  +1-508-969-4456    skype amlafrance19 

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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 29 May 2008 06:26:51 -0400

I haven't seen anyone else answer this yet ... you can find the slides at <http://www.funchords.com/p2pi/slides/>http://www.funchords.com/p2pi/slides/  .

Cheers,
Andy

---

From: Dan York <[email-masked]>
Date: Thu, 29 May 2008 17:04:58 -0400

Being in the midst of a physical house move, I was unable to attend  
the session this week (but have been working through the slides and  
papers), but this post up today, "Inside the Attack that Crippled  
Revision3", by the CEO of Revision3 certainly speaks to some of the  
interesting dynamics going on outside the purely technical realm of P2P:

   http://revision3.com/?p=153

(As well as the need to ensure the security of your P2P software!)

Dan

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 30 May 2008 10:07:49 -0700

One thing that seems strange is that it doesn't sound like a huge  
volume to me:

8000 SYN/second, with ethernet MTU overhead is ~80 bytes/packet or 5  
Mbps.  Even being generous and say 10 Mbps.  (The .02 second posted  
TCPdump shows only SYNs, not SYN/ACKs from their server)

I could easily see such a load taking down their tracking server  
through state-handling issues, but as a TRAFFIC DOS which took down  
their other services it appears downright mild (as they claim outage  
on both web and mail due to traffic DOS).

Thus I could believe the scum at Media Defender's excuse of "We Just  
F#@)(*ed up" as being the proper one.  The following is to NOT defend  
Media Defender, thats lowlife behavior and they deserve a visit from  
the Federales, but...

I think this is a classic example of why ISPs have to look at the cost  
shifting issues on bulk-data P2P, and it worries them:

This is a company serving LARGE, multimedia files.  Its their ENTIRE  
business model.  And they obviously have at least some customers.

Yet their central service can't take a 10 Mbps traffic DOS but they  
want to distribute video which, being generous, is at least 100 kbps/ 
customer?

So this is a company who's BUSINESS is providing LARGE files (HD  
video), and ideally to a lot of people, and can't (or won't) spring  
for even remotely decent bandwidth for their critical infrastructure  
for their tracker, mail, and web server?  (Which traceroute to their  
mail server suggests is in a UnitedLayer colo facility)

Let alone serving the actual contents?

Why should an ISP want to facilitate such business models?

(For reference, if instead they hosted their tracker server at EC2,  
the entire incremental bandwidth cost for a 10 Mbps attack at $.10/GB  
over 3 days would be $33.  Parking at SFO for three days costs twice  
as much!

Even at a much more expensive per bit colo/managed hosting facility ($. 
85/GB), it would still be just a $250 attack, or less than my total  
reimbursement request!  How cheap are they in buying bandwidth?!?)

---

From: "Robb Topolski" <[email-masked]>
Date: Fri, 30 May 2008 15:16:32 -0500

LOL @ "parking at SFO"

A tracker does not normally need a lot of CPU, so they probably didn't have
a big machine there.  8000 packets per second is huge volume to a machine
capable to run a tracker, and SYN packets being the state-changing things
that they are, the load isn't just in moving bits from one process to
another. There's probably a lot of allocation going on there.

I haven't figured out whether to care about this too much.  It sounds like
MD was exploiting Revision3's open tracker and when Revision3 closed them
late on a Friday before a long holiday, their scripts ran away on some code
not adequately tested.  Certainly MD didn't commit an intentional DOS
attack.  While MD looks responsible, it sounds like Amateur Hour on both
sides of the wire.

"Nick: I think this is a classic example of why ISPs have to look at the
cost shifting issues on bulk-data P2P, and it worries them."    They can
look but it's really bandwidth made available for their consumers to use or
not use.  It's legal, disclosed, and it's not harmful.   (Now if the
consumers are conned into giving up bandwidth by a P2P app that doesn't
advertise itself as such, I agree that's a different story.)

It was nice matching a face to a name this week.  You don't look anything
like I had imagined.  Despite areas were we might disagree, you had some
good ideas.  

--Robb

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Nicholas Weaver
Sent: Friday, May 30, 2008 12:08 PM
To: Dan York; [email-masked]
Cc: Nicholas Weaver
Subject: Re: [p2pi] FYI - "Inside the Attack that Crippled Revision3"

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 30 May 2008 15:17:10 -0700

> another. There's probably a lot of allocation going on there.

It isn't just the tracker.  It took down (alegedly) their mail server  
and web server as well.  So <10 Mbps was enough to DoS not jsut the  
tracker but their entire IT infrastructure! which is located in a colo  
facility (so bandwidth is cheap).

> attack.  While MD looks responsible, it sounds like Amateur Hour on  

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.

---

From: Ted Hardie <[email-masked]>
Date: Fri, 30 May 2008 15:35:30 -0700

>facility (so bandwidth is cheap).

As you noted before, tracker servers are typically low usage systems. 
My guess (with no evidence at all, mind you) is that they put the
tracker server on something else that already needed to be in their
DMZ, like the DNS server, NAT, or Firewall.  That level of SYN flood
would chew through the system resources for networking on pretty
much any single box, so any other services on that box would die as
a result.

In other words, it likely wasn't bandwidth, but fate-sharing that got them.

			regards,
				Ted