public inbox for linux-newbie@vger.kernel.org
 help / color / mirror / Atom feed
From: joy merwin monteiro <joy.merwin@gmail.com>
To: Ray Olszewski <ray@comarre.com>
Cc: "John T. Williams" <jtwilliams@vt.edu>, linux-newbie@vger.kernel.org
Subject: Re: filtering .mp3 packets
Date: Fri, 29 Apr 2005 08:35:36 +0530	[thread overview]
Message-ID: <4b0d6e0d050428200525186e50@mail.gmail.com> (raw)
In-Reply-To: <427030A8.8020604@comarre.com>

Hi,

Since this thread dealt mainly with blocking p2p downloading of 
mp3s since they consume large b/w, and has come to a discussion of
https and scp,
I wanted to know wether any p2p protocol uses the above......
or even wehter they use compression.......

if neither is the case, what John said seems to be reasonable,, since
MP3 _has_ to have a header......

blocking all outgoing http requests for or blocking all incoming MP3's
will prevent genuine users who need it. alternatively, there should be
a limit of connections that a user can open at a single time to get
MP3s... since most p2p protocol that i've encountered always try to process
the waiting list as fast as possible by downloading multiple files all
at once....

Comments. anyone?

regards,
Joy

> Second, making the "signature" obscure is fairly trivial. Any encrypted
> transfer (e.g., scp, https) makes it impossible for intermediate points
> to analyze packet contents (since any method of doing so would
> constitute a successful man-in-the-middle attack on the encryption,
> hence be a security hole requiring repair. Even doing ZIP of tgz
> compression of the file would make life hard for the router.
> 
> Beyond that, the original poster mentioned MP3 as an example of the kind
> of file he wanted to detect and block. If there are several formats he
> wants to block (e.g., OGG, WMA as well as MP3), he'd have to do this on
> a type-by-type basis.
> 
> A better strategy might be to monitor the content of the outgoing
> packets to look for (say) http requests that ask for files with .mp3
> extensions to be downloaded. Then pseudo-404 the responses to them. This
> still has its problems, like the encryption problem I mention above, but
> it might be of some help and easier than dissecting the incoming binaries.
> 
> BTW, I did look around a bit for solutions, and all I came up with were
> ones that were variants on blacklisting the IP addresses of known
> sources of music files or were straightforward uses of proxy servers. If
> anyone has more general a content-level solution, it would seem to be
> proprietary, not Open Source.
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.linux-learn.org/faqs
> 


-- 
<ed__> riel: if it were a vax, gcc would probably be an opcode

	- excerpt from #kernelnewbies
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

  reply	other threads:[~2005-04-29  3:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-25 11:27 filtering .mp3 packets William Stanard
2005-04-25 16:56 ` Ray Olszewski
2005-04-26 11:36 ` John T. Williams
2005-04-27 14:15   ` J.
2005-04-27 15:22     ` simon
2005-04-27 19:51       ` J.
2005-04-27 22:57         ` John T. Williams
2005-04-28  0:39           ` Ray Olszewski
2005-04-29  3:05             ` joy merwin monteiro [this message]
2005-04-29 11:43               ` Stephen Ray
2005-04-29 15:24                 ` joy merwin monteiro
2005-04-29 15:51                   ` Ray Olszewski
2005-04-29 23:39                     ` joy merwin monteiro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4b0d6e0d050428200525186e50@mail.gmail.com \
    --to=joy.merwin@gmail.com \
    --cc=joy_mm@ieee.org \
    --cc=jtwilliams@vt.edu \
    --cc=linux-newbie@vger.kernel.org \
    --cc=ray@comarre.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox