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

Re: [tor-dev] [network-team] [doodle poll] Meeting to discuss guard proposal draft status

On Mon, Jul 11, 2016 at 12:41 PM, isis agora lovecruft
<isis@xxxxxxxxxxxxxx> wrote:
> Nick Mathewson transcribed 1.1K bytes:
>>
>
> Various questions and responses to the meeting logs [0]:
>
> 1. I'm not sure I understand the difference between USABLE_FILTERED_GUARD and
>    CONFIRMED_GUARDS.

USABLE_FILTERED_GUARDS is a subset of FILTERED_GUARDS where "is
running" is "yes" or "maybe".

> 2. It seems like USED_GUARDS and CONFIRMED_GUARDS are being used
>    interchangeably.  I realise that Nick at some point in IRC mentions the
>    former was renamed to the latter, but it isn't consistent and with so many
>    variables I'm finding myself a bit confused.

Right. CONFIRMED_GUARDS is the new name for USED_GUARDS.  I should
replace every instance of the old.

> 3. From:
>
>> 14:14:41 <nickm> (There is also a secret novelty in how it handles bridges
>>                  and entrynodes)
>
>   I don't actually see EntryNodes mentioned in the proposal?

Appendix A.2 ?

> 4. How were all the parameters in §A.1 [1] chosen?  Did we simulate the
>    algorithm yet and fuzz the parameters under different network conditions
>    like we did before?

All were totally pulled out of thin air, or out of the previous
iteration of the proposal.

> 5. For
>
>> 14:22:11 <nickm> #action try to think of ways that the "don't add to
>>                  USED_GUARDS till we use it" rule can be manipulated by an
>>                  attacker
>
>    I assume the function governing membership in the set of FILTERED_GUARDS
>    pushes old/stale/less-usable/less-good guards out of the set when new ones
>    are found?  That is, the size of FILTERED_GUARDS can't just grow
>    indefinitely, right?

FILTERED_GUARDS can only grow up to the size of SAMPLED_GUARDS; but
the size of SAMPLED_GUARDS is limited by MAX_SAMPLE_THRESHOLD.

> 6. For "treating primariness as a continuum", do you mean that we
>    should assign some float values to a bunch of guards we're trying
>    all in parallel, then pick the guard that succeeded that had the
>    highest value?  I worry a bit that this would complicate the code
>    and potentially result in many attempted connected to substantially
>    less-suitable nodes.

It would mean that instead of treating the first N_PRIMARY_GUARDS
members of CONFIRMED_GUARDS as 100% primary, and the remaining members
as 0% primary, we would somehow treat the i'th gmember of
CONFIRMED_GUARDS as f(i)% primary for some f.

Right now "primariness" is used for several things: we'd need to look
at which of these should look at a boolean, and which could instead
look at a continuous variable.  I do not yet know whether this is a
good idea.


> [0]: http://meetbot.debian.net/tor-dev/2016/tor-dev.2016-07-07-13.59.log.html
> [1]: https://trac.torproject.org/projects/tor/attachment/ticket/19468/prop259-redux-v3.txt#L414
>
> --
>  ♥Ⓐ isis agora lovecruft
> _________________________________________________________
> OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
> Current Keys: https://fyb.patternsinthevoid.net/isis.txt

cheers,
-- 
Nick
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev