[tor-dev] Testing Network Node Availability

[Tim Wilson-Brown - teor]

> On 7 May 2016, at 05:10, Xiaofan Li <xli2 at andrew.cmu.edu> wrote:
> 
> Thanks for the replies!
> 
> 1. About the name:
> Thanks for the headsup! We'll definitely pay attention to the trademark rules when we publish our results. We are not planning to roll out our own version of Tor. I think our most important goal is probably: demonstrate a possibility of UDP-based protocol to solve some of TOR's hard performance problems. And hope that you guys would consider using it in future versions.
> This leads me to a question about licensing: I believe TOR and QUIC have different (conflicting) licenses. Would it even be a possibility that QUIC ever makes it into TOR?

I am not a lawyer or a software architect for Tor, so these are simply my opinions:

Here is the tor license:
https://gitweb.torproject.org/tor.git/tree/LICENSE

Is QUIC under the Chromium license? I couldn't find a QUIC-specific one.
https://chromium.googlesource.com/chromium/src/+/master/LICENSE

If so, the licenses look compatible to me, they're both BSD-style, and are almost identical.

What restrictions concern you?

On the architecture side:

I'm not sure if Tor is looking for alternative transport protocols like QUIC.
One of the issues is that any modified client is easy to fingerprint.
So, as with IPv6, we'd need relays to run QUIC and TCP in parallel for some time, then clients could optionally use QUIC when there were enough relays supporting it. Perhaps relays could open a QUIC UDP port on the same port as their TCP ORPort, and then advertise support in their descriptors. But TCP would remain the default for the foreseeable future.

For example, our IPv6 adoption is still at the stage where clients need to be explicitly configured to use it.
(And parts of it are only coming out in 0.2.8.)

If your modifications don't work like this, then it would be very hard for us to adopt them.
Even if they did, I don't know if they solve any pressing issues for us.
(And we'd need both a theoretical security analysis, and a code review. And new features come with new risks and new bugs.)

> ...
> I also wonder why you need to use path restrictions at all.
> 3. For path restriction, we have our own implementation. We parse the config file and use the nickname in choose_good_*() functions to return the corresponding nodes. We have to use this because restricting the middle node is very important to us for testing HOL blocking problem. (We have to manually create 1-hop overlapping path for two clients and test the interference.)
> 
> 4. Regarding the issue, it's probably not entry guard problem, because: 1) Shouldn't that give "failed to select hop 0" instead of hop 1?

Yes, you're right, in that message, hop counts are 0-based.

But the code is inconsistent in onion_extend_cpath:

  if (!info) {
    log_warn(LD_CIRC,"Failed to find node for hop %d of our path. Discarding "
             "this circuit.", cur_len);
    return -1;
  }

  log_debug(LD_CIRC,"Chose router %s for hop %d (exit is %s)",
            extend_info_describe(info),
            cur_len+1, build_state_get_exit_nickname(state));

The control spec says hops are 1-based, so we should fix the logging.

See:
https://trac.torproject.org/projects/tor/ticket/18982

I've given you credit for reporting this issue, please feel free to provide your preferred name (or decline) on the ticket.

> 2) I can see in our debugging log that we failed on the extending info with the second node. The node returned by choose_good_middle_server is not NULL but the routerinfo_t pointer is NULL. Any idea why?

Perhaps you looked it up the wrong way, or it's not in the consensus.
What code are you using to look up the node?

Are you using extend_info_from_node()?
If not, please note that different fields are present depending on whether you use descriptors (ri) or microdescriptors (md).

> My guess is that consensus is a little short for some reasons, how do I validate this guess?

Read the plain-text cached-{microdesc-}consensus file in the tor client's data directory and check if the middle node is in it.
Read the plain-text cached-{descriptors,microdescs} file in the tor client's data directory and check if the middle node is in it.

> Does the global router list contain everything on the consensus?

I'm not sure exactly what you're referring to here, please provide a function or global variable name for this list.

> 5. More observation on this issue:
> For both tor and our tor, when I decrease the size of the network (i.e. number of relays in the network), the hanging issue resolves itself..

Hmm, then it's likely a configuration issue with your network.

> I'll try rebase back to an official release today.

That might help, we are still fixing bugs in 0.2.8.

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B
ricochet:ekmygaiu4rzgsk6n



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160507/d39868d1/attachment.sig>