Re: Bittorrent

[Scott Bennett <bennett@xxxxxxxxxx>]

     On Thu, 19 Feb 2009 02:41:10 +0100 slush <slush@xxxxxxxx> wrote:
>> >Disagree. I wrote _port_ oriented QoS, not _content_.  There can be config
>>
>>  is encrypted between the client and the exit
>
>
>But not between exit and target (well, we are not speaking about tunelling
>any kind of SSL connection).
>
>
>> >option to prioritize some port (port range) above other. Just because
>> >somebody want to support HTTP transfer than other, but he dont want to
>> fully
>> >stop other services (torrents).
>>
>>      It appears that you do understand neither how tor works nor why it
>> must
>> work that way to protect anonymity.  Please familiarize yourself with the
>> documentation available at the tor web site at http://www.torproject.org.
>
>
>Thank you, I read it carefully. Lets summarize it:
>
>* Traffic on exit node is decrypted (there is no encryption added by Tor
>itself, just encryption on level of application protocol in some cases)
>* Exit node knows target IP and port
>
>Where is problem with anonymity? Why it is not possible to prioritize
>traffic on exits? Please be specific and dont send me link to torproject. Of
>course, you are welcome in specific comments.
>
>It is not about critism to missing implementation in Tor. Im just wondering,
>why it is bad design idea.
>
>
>
>>     Every tor relay operator uses an exit policy, whether they use the
>> ExitPolicy statement(s) in torrc or not.  I don't happen to see that it is
>> my
>> business, in general, what exit policies are used by other tor operators.
>
>
>So, and ... ? I spoke anything about that?
>
     Yes, you did, although you have omitted it here.  You wrote:

++>Did you ask others, why are they using ExitPolicies? I dont think so.

That is what I responded to above when I wrote that it wasn't my business
what exit policies other tor operators use.
>
>    As noted above and in the tor documentation, all information regarding
>> the user's proxied TCP connections through tor's SOCKS port is encrypted
>> from that point onward until it reaches an exit relay.  To determine the
>> destination port number of a proxied connection within the tor network
>> would
>> require providing a way to decrypt information passing through the circuit.
>> Such decryption destroys both security and anonymity.
>>
>
>No. Not on exit. Again, Im not speaking about any kind of prioritization on
>middle nodes.
>
     Okay, Marek, I apologize.  I did not understand from your earlier
postings that you were referring only to tor *exit* traffic, rather than tor
traffic at all stages of transit.  I don't see any showstoppers offhand for
plans to use, say, packet filter-based QoS support for exiting traffic.  It
is unclear to me whether attempting to use QoS support for external traffic
entering the exit for transmission back to the tor client would have the
desired effect if the filter-based QoS support is running on the same system
as the tor relay.  If the prioritizations are instead implemented on a
separate router through which the tor process's traffic passes, then they
ought to work as well as the output prioritizations.


                                  Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet:       bennett at cs.niu.edu                              *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
**********************************************************************