Re: How to fight with encrypted p2p

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I believe "fighting" is the wrong approach.  Badly shaping the wrong
traffic is just as bad, if not worse IMO.  An ISP in my neck of the
woods plays havoc with encrypted mail (SMTP + TLS as well as IMAPS) as a
result of their P2P fight.  Needless to say we no longer use them, and
we encourage clients, friends, and colleagues not to as well.  I don't
use P2P but I do use ssh, imaps, sftp, and https daily.  Screwing with
these services is not useful.

Using the rules in the example previously given specifically steers well clear
of these services.

Limiting your rules to specific ports is
pretty useless.  This has been done before, and it failed miserably.

Agreed.

For me, if P2P does not belong at all, for instance on a corporate
network, then a default deny on the outbound works much better.  We then
only allow specific connections on a case by case basis.

I have seen this work very well on corporate networks, and would recommend this
approach where possible. Unfortunately though, on a normal home user network,
there are so many different possibilities that this isn't very practical.

For instances
where I am not able to block p2p, I define specific rules for high and
low priority, and leave everything else in the default.  If the end user
wants to use the bulk of his or her bandwidth for P2P, so be it.  Of
course in this case bandwidth accounting is far more useful.

Again, this depends on the circumstances. If you only have 2Mbit/s to share
between 100 users then each user cannot have their own 'share' of the
connection. Equally, people downloading in a responsible way are lumped into the
same category as p2p users, which is not fair. Bandwidth accounting is a
possibility, and something I haven't investigated.

For those who want to fairly share bandwidth beween users, I would recommend the
ESFQ patches. These allow bandwidth sharing to be done on an IP address basis,
rather than per connection. This prevents the hundreds of p2p connections from
drowning out single downloads.

I would also encourage your users to use software that is or can be well
behaved.  Software that allows you set a proper TOS for instance.  If
possible work with the end users.
I have personally found that the best solutions are not tech solutions.
Having a well defined Acceptable Use Policy, plus a constructive
dialogue with my users has been far more effective than any shaping
routine I/we could come up with.

Agreed. However, in a situation where you have a lot of users coming and going,
it is not easy to educate the many hundreds of users.

I guess it all boils down to your own situation. Traffic shaping on a corporate network or on a network where your users are static can be done using the above
techniques. However, sharing a small connection between hundreds of regularly
changing users is difficult, and I have found the 'blunt' rules previously
described to work very well with no complaints.

Regards,

Andy Beverley


_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux