Re: Interoperating with p2p traffic

[<dick@xxxxxxxxxxxx>]

>Marc Abel writes:
>> a)  Would it help to have a per-connection throttling
mechanism?  Not
>> using hard limits, but a policy which responds to requests from
>> low-traffic connections ahead of higher-traffic connections?
>> 
>> b)  Alternatively, would it help if torrc prioritizes port
numbers?  Tor
>> might put ssh first, then http(s), then ..., then bittorrent.
>
>two advantages of a) over b):
>
> - it wouldn't be difficult for people to adapt the torrent
protocol
>  to use high-priority ports if b) was used.  tunneling
through ssh
>  seems to be particularly easy to hack to me.
>
> - i think a) also is more fair between non-filesharing users
that
>  differ in bandwidth hunger.
>
>what about sybil attacks, though, ie. attacks that open many
channels
>in parallel, impersonating a large number of anonymous users?
>
>in general, i would love to see the 'we don't like this or
that kind
>of application' policy go away.  currently i'm all for it, but it
>would be better if the network could survive all users at the
same
>time.  (hum, i've been stating the obvious again, sorry...)

does anyone have an estimate of the percentage of tor traffic
which is from p2p? what is the overall outproxy bandwidth of
the tor network?

i think that throttling based on bandwidth usage would be a
good idea. it makes sense that the less you use the network,
the more priority you should have in doing so. i also think
that content filtering is bogus, but people using tor just to
download the latest crappy warez/music isn't any less so.

i heard that the newer versions of snort are able to filter
p2p traffic pretty effectively by working in conjunction with
the IDS "plugins" (e.g. snort2pf). maybe exit node operators
could setup a configuration like this to prevent p2p traffic
from coming out of their node? if i have time to set this up
i'll post back about it.

cheers,
jake