[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Interoperating with p2p traffic
>Marc Abel writes:
>> a) Would it help to have a per-connection throttling
>> 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
>> 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
> to use high-priority ports if b) was used. tunneling
> seems to be particularly easy to hack to me.
> - i think a) also is more fair between non-filesharing users
> differ in bandwidth hunger.
>what about sybil attacks, though, ie. attacks that open many
>in parallel, impersonating a large number of anonymous users?
>in general, i would love to see the 'we don't like this or
>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
>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.