On 09/10/13 18:05, Matthew Finkel wrote: >>>> These two changes combined should help with the two goals. Reliability >>>> is improved by having multiple OP's providing the service, and having >>>> all of these accessible from the introduction points. Scalability is >>>> also improved, as you are not limited to one OP (as described above, >>>> currently you can also have +1 but only one will receive most of the >>>> traffic, and fail over is slow). >>> >>> Do you see any disadvantages to this design? >> >> So, care needs to be taken around the interaction between the hidden >> service instances, and the introduction points. If each instance just >> makes one circuit, then this reveals the number of instances. > > Does it? Given the above, that is, each instance of the hidden serivce connects once to each introduction point. Then the number of instances of a hidden service, is equal to the number of connections with that each introduction point sees with that key. >> There is also uncertainty around the replacement of failing introduction >> points. New ones have to be chosen, but as the service instances do not >> directly communicate, there could be some interesting behaviour unless >> this is done carefully. > > Is there a reason they shouldn't communicate with each other? I have avoided it so far, as it increases the complexity both the implementation and setup. However, this is probably a minor issue, as the major issue is how service providers would want to use this? Complex hidden services (compared to hidden services with static content) will probably require either communication between instances, or communication from all instances to another server (set of servers)? >>>> I am aware that there are several undefined parts of the above >>>> description, e.g. how does a introduction point choose what circuit to >>>> use? but at the moment I am more interested in the wider picture. It >>>> would be good to get some feedback on this. >>>> >>>> 1: https://blog.torproject.org/blog/hidden-services-need-some-love >>>> 2: >>>> http://tor.stackexchange.com/questions/13/can-a-hidden-service-be-hosted-by-multiple-instances-of-tor/24#24 >>> >>> This is a good start! Some important criteria you might also think >>> about include how much you trust each component/node and which nodes do >>> you want to be responsible for deciding where connections are routed. >>> Also seriously think about how something like a botnet that uses hidden >>> services might impact the reliability of your design (crazy idea, I >>> know). >> >> I assume the characteristics of this are: 1 or more hidden service >> instances, connected to by very large numbers of clients, sending and >> reviving small amounts of information? > > Perhaps, but just think about the load an intro point can handle and > sustain. If Introduction Points are where load balacing takes place, > then does this affect the difficulty of attacking a hidden service? (for > some undefined definition of 'attack'.) At the moment, I am really considering the redundancy and scalibility of the serivce. Both of these could be helped by allowing for multi-instance hidden serivces (in a planned and thought through manor). Hopefully allowing for this will increase the difficulty to attack hidden serivce, not directly, but by allowing the operators to use this functionality.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev