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

Re: [tor-bugs] #2668 [Tor Relay]: Rate limit RELAY_EARLY and TLS by IP

#2668: Rate limit RELAY_EARLY and TLS by IP
-----------------------+----------------------------------------------------
 Reporter:  mikeperry  |          Owner:       
     Type:  defect     |         Status:  new  
 Priority:  normal     |      Milestone:       
Component:  Tor Relay  |        Version:       
 Keywords:             |         Parent:  #2664
   Points:             |   Actualpoints:       
-----------------------+----------------------------------------------------

Comment(by nickm):

 Rate-limiting TLS by IP is, I think, a good idea.  One way to limit the
 attack multiplier here is to impose a slight delay between successful TLS
 connections from a single IP, and a larger delay between failed TLS
 connections.  (It's relatively cheap to force the server to do a TLS
 handshake resulting in a failure, and relatively less cheap to force the
 server to do a TLS handshake resulting in a success.)

 Rate-limiting CREATE cells is harder.  If we get a bunch of  circuits from
 some host x, it's not easy to tell if x is responsible, or if somebody is
 just using x as an intermediary.  The same problem could apply to
 RELAY_EARLY cells: if x is sending a bunch of them, is x a client trying
 to use lots of CPU, or is x relaying them for someone else?

 Another idea is that instead of rate-limiting early RELAY_EARLY cells and
 TLS handshakes  we could prioritize in the way similar to what we do for
 circuit ewma: we could prioritize EARLY cells and TLS handshakes from
 addresses that haven't sent any in a while.

 In addition to rate-limiting, we could/should also add proof-of-work
 features to future protocol versions.   We'd want a consensus parameter to
 limit the maximum work factor, and we'd need a way to tell clients what
 kind of proof-of-work is needed.  Of course, this won't help existing
 servers that need to support existing clients, since existing clients
 don't send proof-of-work.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2668#comment:2>
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