[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #19625 [Core Tor/Tor]: Allow relays to set peering policy



#19625: Allow relays to set peering policy
----------------------------+-----------------------------------
 Reporter:  twim            |          Owner:
     Type:  project         |         Status:  needs_information
 Priority:  Medium          |      Milestone:
Component:  Core Tor/Tor    |        Version:
 Severity:  Normal          |     Resolution:
 Keywords:  needs-proposal  |  Actual Points:
Parent ID:                  |         Points:
 Reviewer:                  |        Sponsor:
----------------------------+-----------------------------------
Changes (by yawning):

 * keywords:   => needs-proposal
 * status:  new => needs_information


Comment:

 This needs a full design proposal (and also appears to be directly counter
 to how path selection is intended to function, eg: #19068).

 There's at least two open major design questions:

  * Clients need to know this information when doing path selection, thus
 this information needs to be part of the descriptor/microdescriptor.  Most
 clients only fetch the latter, and those don't even have the full exit
 policy.  How will this impact bootstrapping overhead, particularly when
 relays start to do things like "block all the relays in the US because the
 NSA is spying on them from their orbital satellite platforms" leading to
 gigantic descriptors.

  * How would one guard against malicious relays using this mechanism to
 mount a partitioning attack.  More generically, currently clients are
 responsible for 100% of the path selection.  What is the
 security/anonymity impact of allowing potentially malicious relays to
 influence this.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/19625#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs