Re: [tor-bugs] #11211 [Core Tor/Tor]: Multiple ServerTransportListenAddr entries should be allowed per transport.

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#11211: Multiple ServerTransportListenAddr entries should be allowed per transport.
-------------------------------------------------+-------------------------
 Reporter:  yawning                              |          Owner:  kaie
     Type:  enhancement                          |         Status:
                                                 |  needs_revision
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.3.0.x-final
Component:  Core Tor/Tor                         |        Version:  Tor:
                                                 |  unspecified
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-bridge, pt, needs-proposal,      |  Actual Points:
  tor-pt, bridgedb-parsers, 028-triage, ipv6,    |
  tor-03-unspecified-201612                      |
Parent ID:  #10629                               |         Points:
 Reviewer:                                       |        Sponsor:  T/U
-------------------------------------------------+-------------------------

Comment (by yawning):

 Replying to [comment:22 dcf]:
 > This is a good idea, but I think it's more complicated than just giving
 a list to ServerTransportListenAddr. You would need to also make
 ServerTransportOptions be similarly split, which would probably require
 new syntax in torrc. It would also require a change to pt-spec, because
 there would need to be a rule or something that states which options
 pertain to which listening address when there are multiple ones.

 obfs4proxy would require fairly substantial changes to handle this
 correctly, as would core tor and probably the bridge distribution stuff.
 So while it's a good idea, getting it to bind to addresses is just the
 start, and even that needs to be preceded by a spec change so that code
 that supports this use case will work, and that code that doesn't will
 error out per the existing spec.

 > I've been frustrated by this in the past, too. For example, in
 comment:10:ticket:20348, I wanted to run three obfs4 bridges with slightly
 different configuration on the same IP address, and there's just no way to
 do it other than to run three instances of tor. It was probably a mistake
 for torrc to use the transport name as a key that links
 ServerTransportListenAddr and ServerTransportOptions, because that makes a
 built-in assumption that there's only one thing identified by that
 transport.

 Lots of aspects of the design aren't great.

 > Incidentally, it might be the the case that using only the IPv6 syntax
 already does what you want. On some systems `[::]` will listen on both
 IPv6 and IPv4, so you don't need to separately list 0.0.0.0.

 That's a general Linux-ism.  Only one address will be distributed via
 BridgeDB though (fairly sure it's the IPv4 one).

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