[tor-dev] Testing Network Node Availability

[Xiaofan Li]

Sorry for the spam, but I have a critical typo on the previous message.
Instead of "with 11 nodes (2 relays) and 2 clients who have path
restriction." I meant 11 nodes (2 authorities) and 2 clients.

On Sun, May 8, 2016 at 1:52 AM, Xiaofan Li <xli2 at andrew.cmu.edu> wrote:

> Tim,
>
> I'm not sure if Tor is looking for alternative transport protocols like
>> QUIC.
>>
>
> What if it's a lot faster than TCP on Tor?
>
>
>> 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.
>>
>
> It does work like this. Our testing version has "parallel codepath" and
> supports both QUIC and TCP. And we devised our QUIC API to look almost
> exactly like the traditional UNIX socket API. So, code change is almost
> minimal.
>
>
>> Even if they did, I don't know if they solve any pressing issues for us.
>>
>
> What about the head-of-line blocking issue and the congestion control
> issue raised in 2009
> <https://svn.torproject.org/svn/projects/roadmaps/2009-03-11-performance.pdf>?
> From this paper <https://eprint.iacr.org/2015/235.pdf>, it seems they
> haven't been completely solved.
>
>
>> (And we'd need both a theoretical security analysis, and a code review.
>> And new features come with new risks and new bugs.)
>
>
> Of course! We don't expect Tor to suddenly start using QUIC because of a
> couple of emails. But I believe we do have something to argue for QUIC
> based on both theories and experimental results. We would probably make a
> formal, published argument soon.
>
> I've given you credit for reporting this issue, please feel free to
>> provide your preferred name (or decline) on the ticket.
>
> Thanks!
>
>
> About the issue, I've checkout the 0.2.8 commit and tested on that. The
> problem is still there so I looked deeper into it. I've run it many time
> and it seems like once I start restricting path, it becomes undeterministic
> whether the bootstrap will succeed. And I think it might have something to
> do with the cache-microdesc-consensus file fetched by that client. Just for
> recap, I'm running a network with 11 nodes (2 relays) and 2 clients who
> have path restriction. My observations are:
>
>    - Each client will have a cache-microdesc-consensus file with 4 relays
>    in it. relay 0, 1 and 2 will always be there and the last one changes each
>    time I start the network.
>    - When the all 3 nodes on the restricted path are on the cache-microdesc-consensus
>    file, the bootstrap will succeed quickly. For example, if my path is
>    restricted to R2->R3->R1, since 0, 1 and 2 are always present in the
>    consensus, whenever R3 is there, the bootstrap will work.
>    - When one of the node is not on the consensus, the bootstrap will be
>    stuck and never reach 100%. Depending on which node of the path is not
>    included in the consensus, the error message varies. In the above example,
>    if R3 is not in the consensus, we will fail to connect to hop 1 (assume
>    0-based logging).
>    - I waited for a long time (~30min) and nothing would improve:
>    consensus does not contain more nodes and bootstrap would still be stuck.
>
> I think the root of the problem might be the consensus having too few
> nodes.. Is it normal for a cache-microdesc-consensus file to only have 4
> nodes in a 11-node network? Should I look into how the code that generate
> the consensus?
>
>
> The routerlist_t I mentioned is in routerlist.c, line 124.
>
> 124 <http://192.168.1.14:8080/source/xref/tor/src/or/routerlist.c#124>/** Global list of all of the routers that we know about. */125 <http://192.168.1.14:8080/source/xref/tor/src/or/routerlist.c#125>*static* routerlist_t <http://192.168.1.14:8080/source/s?defs=routerlist_t&project=tor> *routerlist <http://192.168.1.14:8080/source/s?refs=routerlist&project=tor> = NULL <http://192.168.1.14:8080/source/s?defs=NULL&project=tor>;
>
>
> But now I think this probably just stores the same info as the cache-microdesc-consensus
> file, right?
>
> Hmm, then it's likely a configuration issue with your network.
>
>
> Shouldn't chutney also fail if it is a configuration issue? Or are you
> saying it's a configuration issue with my underlying network topology?
> The only thing different in the torrc files for the chutney run and the
> Emulab run is "Sandbox 1" and "RunAsDaemon 1" but I don't think they cause
> any issue?
>
> Thanks!
> Li.
>
>
> On Fri, May 6, 2016 at 6:18 PM, Tim Wilson-Brown - teor <
> teor2345 at gmail.com> wrote:
>
>>
>> > 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
>>
>>
>>
>>
>> _______________________________________________
>> tor-dev mailing list
>> tor-dev at lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160508/2cf9e7ef/attachment-0001.html>