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

Re: [tor-bugs] #34129 [Circumvention/Snowflake]: Use STUN to determine NAT behaviour of peers



#34129: Use STUN to determine NAT behaviour of peers
-------------------------------------+---------------------------
 Reporter:  cohosh                   |          Owner:  cohosh
     Type:  enhancement              |         Status:  assigned
 Priority:  Medium                   |      Milestone:
Component:  Circumvention/Snowflake  |        Version:
 Severity:  Normal                   |     Resolution:
 Keywords:                           |  Actual Points:
Parent ID:                           |         Points:
 Reviewer:                           |        Sponsor:  Sponsor28
-------------------------------------+---------------------------

Comment (by cohosh):

 I submitted a PR to upstream the changes to pion/stun:
 https://github.com/pion/stun/pull/33

 There are a couple ways to move forward with this. I'm suggesting the
 following steps:
 - Do NAT discovery at the proxy and use that to decide how often they poll

  This is actually more useful for webextension users to do than standalone
 go proxies since we have way more of them. There's no functionality for
 this in the webrtc library we're using, but the
 [https://www.npmjs.com/package/stun stun] package claims to have partial
 support for RFC 5780, and lists the attributes we need.

  This basically replaces our datachannel failure heuristic with a NAT type
 heuristic. We can do both but should make sure they interact correctly.

 - Do NAT discovery at the proxy and client and send that information to
 the broker to match them up in a smarter way.

  I'd like some feedback on this before moving forward since it will take
 some effort and be a substantial change to the way the broker works. I'm
 also hesitant to make decisions that prioritize some proxies over others
 that rely on proxy honestly since it increases the ability of a malicious
 party to DoS Snowflake with bad proxies. If they can falsely report a
 value to get their bad proxies prioritized over others, we'll be in a
 worse situation w.r.t. DoS than we are now.

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