Re: [tor-bugs] #9729 [Tor]: Make bridges publish additional ORPort addresses in their descriptor

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

#9729: Make bridges publish additional ORPort addresses in their descriptor
----------------------------+----------------------------------------------
     Reporter:  sqrt2       |      Owner:
         Type:              |     Status:  needs_information
  enhancement               |  Milestone:
     Priority:  normal      |    Version:  Tor: 0.2.5.1-alpha
    Component:  Tor         |   Keywords:  ORPort bridge multiple addresses
   Resolution:              |  Parent ID:
Actual Points:              |
       Points:              |
----------------------------+----------------------------------------------
Changes (by isis):

 * status:  new => needs_information
 * cc: isis@â (added)
 * version:  Tor: 0.2.4.17-rc => Tor: 0.2.5.1-alpha


Comment:

 From L1448-1552 in torspec.git/dir-spec.txt:

 {{{
      "a" SP address ":" port NL

         [Any number]

         The "or-address" element as specified in 2.1.
 }}}

 would seem to imply that we can have as many as we want (at least it won't
 affect descriptor parsing), and that they can be IPv4 or IPv6 addresses.

 though in `tor.git/src/or/router.c` in `router_rebuild_descriptor()`, the
 `routerinfo_t *ri` only has one extra orport, which is always used for
 IPv6:
 {{{
   /* For now, at most one IPv6 or-address is being advertised. */
   {
     const port_cfg_t *ipv6_orport = NULL;
     SMARTLIST_FOREACH_BEGIN(get_configured_ports(), const port_cfg_t *, p)
 {
       if (p->type == CONN_TYPE_OR_LISTENER &&
           ! p->no_advertise &&
           ! p->bind_ipv4_only &&
           tor_addr_family(&p->addr) == AF_INET6) {
         if (! tor_addr_is_internal(&p->addr, 0)) {
           ipv6_orport = p;
           break;
 [...]
     if (ipv6_orport) {
       tor_addr_copy(&ri->ipv6_addr, &ipv6_orport->addr);
       ri->ipv6_orport = ipv6_orport->port;
     }
 }}}

 So this behaviour is not a bug, though for bridges it is certainly
 desirable to have more than one address per bridge.

 If you make bridges send multiple descriptors to the BridgeAuthority,
 there could be some problems:
   1. The same bridge (in this case, by "bridge" I mean "box") would have
 multiple entries in BridgeDB's hash rings, meaning an increased likelihood
 of being handed out. Similarly, in the "social bridge disributor" design
 for BridgeDB, because this one box has more descriptors in the database,
 it's likelihood of being handed out is correspondingly higher.
 This is probably fine as long as each of these descriptors is a different
 IP address, and there is not an easy way, given one of these
 IPs/descriptors, to discover the other ones (i.e. via a reverse DNS query
 and then a regular DNS query to get the other addresses for that host).

   2. You might have to do a bit of juggling to keep track of which
 descriptor was updated and resent to the BridgeAuthority when, though my
 guess is that in practice routers with multiple IP routes configured are
 not going to be shifting IP addresses too much.

   3. You probably should '''not''' allow multiple descriptors to contain
 the same address. I.e. something like:
      {{{
      Bridge
        |- desc1
        |    |- ORPort 1.1.1.1:443
        |    |- ORPort 12.12.12.12:4443
        |    |_ ServerTransportListenAddr obfs3 1.1.1.1:3333
        |
        |_ desc2
             |- ORPort 2.2.2.2:2222
             |_ ORPort 12.12.12.12:6666
       }}}
 would be bad for the following reasons:
    1. Double the chance of handing out `12.12.12.12`, so double the chance
 it gets blocked.
    2. Since these separate descriptors would essentially be separate
 bridges, for the social bridge distribution scheme (the last of the
 redesign is being hammered out now), if `desc1` got blocked (i.e. the
 `1.1.1.1` IP address was blackholed), then `desc2` would also be blocked
 via the `12.12.12.12` address. In this case, the clients of `2.2.2.2`
 would stop earning coins for the `desc2` bridge, since it's been blocked.
 It might be possible to further revise the scheme to deal with cases like
 this, but you can see how it would start to get hairy.

 My preference would be to have one descriptor per IP address (that way PTs
 can run on that same address under alternate ports). Perhaps nickm and
 others have different concerns, however.

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