Re: classifying P2P traffic - what about legit uses?

[Joel Rosenblatt <joel () COLUMBIA EDU>]

Sorry .. this is only for Columbia DMCA .. we can't do this for affiliates.

Joel

--On Tuesday, January 29, 2008 9:38 PM -0500 Barbara Torney <bt42 () columbia edu> wrote:

> Joel, will this replace the emails we get now about abuse complaints? When will it go into production?  Can we get more 
> info?  Thanks, bat
>
> On Tue, 29 Jan 2008, Joel Rosenblatt wrote:
>
> > We have automated our DMCA takedown process. This fully automated version
> > will go live next month.
> >
> > Complaints come into our copyright abuse ID and are parsed for IP and
> > timestamp
> >
> > Complaint is verified from Flows (fuzzy logic is used :-)
> >
> > Mac address is gotten from DHCP and ARP logs
> >
> > Remedy ticket is built
> >
> > Mac address is captured
> >
> > User sees notice by bringing up web browser - this includes notice,
> > information on copyright, test about information on copyright
> >
> > If user passes test, they can uncapture with or without protest - information
> > is logged into ticket
> >
> > with protest tickets are verified by human
> >
> > Letter is sent to proper Dean's office, and depending on number of
> > violations, appropriate action is taken by Dean.
> >
> > We (IT Security) are not in the punishment business, we find them, check them
> > and turn them over.
> >
> > This is obviously a trimmed down, simplified version of what we are doing -
> > but you can get the idea.
> >
> > We started building this process when processing complaints started taking up
> > 1 FTE
> >
> > Your mileage may vary.
> >
> > Joel Rosenblatt
> >
> > Joel Rosenblatt, Manager Network & Computer Security
> > Columbia Information Security Office (CISO)
> > Columbia University, 612 W 115th Street, NY, NY 10025 / 212 854 3033
> > http://www.columbia.edu/~joel
> >
> >
> > --On Tuesday, January 29, 2008 4:56 PM -0600 Curt Wilson <curtw () SIU EDU>
> > wrote:
> >
> > > I concur with most of Randy's points, however our attempts at blocking
> > > potentially copyrighted contents and letting "safe" contents pass through
> > > was met with
> > > failure and many takedown notices. We could potentially try again, but many
> > > other priorities exist.
> > >
> > > Our campus was experiencing bandwidth issues, and a deluge of RIAA/MPAA
> > > takedown notices (especially wrt areswarez) and have a small staff handling
> > > many
> > > other issues. Technical solutions to block P2P were instituted with
> > > significant success. We've had to utilize several techniques to provide for
> > > decent
> > > coverage, and it's still not completely foolproof. The opportunity for
> > > exceptions is less than ideal, however that option does exist. In every
> > > case so far
> > > the user has been able to obtain the contents through other means (such as
> > > http). Bandwidth is a lot cleaner, and we are less clogged up with notices
> > > and
> > > takedown bureaucracy.
> > >
> > > How do other .edus handle their takedown processes? I believe that the IT
> > > Security role in such a process should be minimal - collect the relevant
> > > logs for
> > > another campus area and let them handle the bureaucracy components of the
> > > situation. But that's not how things are currently executed here.
> > >
> > >
> > > Randy Marchany wrote:
> > > > Having lurked on this and other related threads over the past couple of
> > > > months, I'd like to ask a few questions and make a few observations about
> > > > how
> > > > EDUs appear to be dealing with P2P.
> > > >
> > > > 1. With all of the "monitoring" and "rate limiting" strategies, how does
> > > > your
> > > > institution deal with legit uses of P2P? We're a land grant and our
> > > > extension
> > > > division may use P2P to distribute videos/sound recordings of their
> > > > products
> > > > to extension agents around the state.  Obviously, blocking all P2P would
> > > > prevent them from doing their business. Music students working on projects
> > > > and
> > > > putting their "product" on the net for download (legit because permission
> > > > was
> > > > given to distribute) is another example.
> > > >
> > > > 2. How many BitTorrent servers or other P2P servers are on your campus
> > > > nets?
> > > > What type of scanning or metrics do you collect about p2p traffic? The
> > > > usual
> > > > suspects like excessive traffic to/from IP address is nice but what do you
> > > > do
> > > > to keep tabs on "normal" P2P traffic?
> > > >
> > > > 3. An observation: I'm a security type and a musician. I've always thought
> > > > that banning P2P traffic because of the potential "copyright" problems was
> > > > like banning the US Postal Service (Fedex, UPS) because someone xeroxed a
> > > > book
> > > > and use them to mail the book. I don't buy the volume issue (it's much
> > > > faster
> > > > using P2P than USPS....duh!) because that's a smoke screen. The real issue
> > > > is
> > > > making sure users understand copyright issues and know what the potential
> > > > penalties are.  There are legit uses of P2P in our world and I don't see
> > > > forcing users to jump through hoops to do real work as being an effective
> > > > practice. If it's too cumbersome, they'll circumvent it. Having IPS
> > > > rulesets
> > > > blocks the casual user but not the determined user. I can remember not
> > > > being
> > > > able to download tunes from our band www site because of an arbitrary
> > > > block
> > > > while visiting an EDU. Never mind that it was legal (we, the copyright
> > > > owners,
> > > > give permission to distribute freely). The block prevented a legit use of
> > > > P2P.
> > > >
> > > > 4. Another observation: are we taking the easy way by arbitrarily blocking
> > > > P2P
> > > > because a) we're short staffed b) we're lazy c) we don't have resources
> > > > for
> > > > user education d) we don't have upper mgt support d) we're afraid of the
> > > > RIAA/MPAA e) all of the above? Shouldn't we be investing more in the short
> > > > term (policy enforcement, user education, categorizing P2P traffic to id
> > > > the
> > > > illegal stuff)? This short term effort would eliminate a good chunk of the
> > > > longer term problem.
> > > >
> > > > Just my .01 worth.
> > > >
> > > >         -Randy Marchany
> > > >         VA Tech IT Security Office
> >
> >
> >
> > Joel Rosenblatt, Manager Network & Computer Security
> > Columbia Information Security Office (CISO)
> > Columbia University, 612 W 115th Street, NY, NY 10025 / 212 854 3033
> > http://www.columbia.edu/~joel
>
>   -------------------------------------------------------------------------
>   Barbara Torney                                        phone: 212-678-3487
>   Director, Administrative Information Services fax:   212-678-3243
>   Teachers College, Columbia University                212-678-4048
>   525 West 120 Street, Box 43                   email: bt42 () columbia edu
>   New York, NY 10027                            room:  241 Horace Mann



Joel Rosenblatt, Manager Network & Computer Security
Columbia Information Security Office (CISO)
Columbia University, 612 W 115th Street, NY, NY 10025 / 212 854 3033
http://www.columbia.edu/~joel