Delivery-Date: Mon, 14 Dec 2015 22:31:53 -0500
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	T_RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id 324FC1E12C7;
	Mon, 14 Dec 2015 22:31:51 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 4320A37005;
	Tue, 15 Dec 2015 03:31:44 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 3D24B36C29
 for <tor-talk@lists.torproject.org>; Tue, 15 Dec 2015 03:31:41 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id nuktEBlIPpkj for <tor-talk@lists.torproject.org>;
 Tue, 15 Dec 2015 03:31:41 +0000 (UTC)
Received: from mx.binnacle.cx (mx.binnacle.cx [IPv6:2001:470:885c:87::18])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "mx.binnacle.cx", Issuer "RapidSSL SHA256 CA - G3" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 1AC1F3680D
 for <tor-talk@lists.torproject.org>; Tue, 15 Dec 2015 03:31:40 +0000 (UTC)
Received: from CIANNAIT.binnacle.cx (ciannait [172.29.87.10])
 by mx.binnacle.cx (envelope-from <starlight@binnacle.cx>)
 (8.15.2/8.15.2) with ESMTP id tBF3VbWM014484
 for <tor-talk@lists.torproject.org>; Mon, 14 Dec 2015 22:31:37 -0500
Message-Id: <6.2.5.6.2.20151214221300.04776090@binnacle.cx>
Date: Mon, 14 Dec 2015 22:28:53 -0500
To: tor-talk@lists.torproject.org
From: starlight@binnacle.cx
In-Reply-To: <29839476.480507.1450145690954.JavaMail.ngmail@webma
 il11.arcor-online.net>
References: <29839476.480507.1450145690954.JavaMail.ngmail@webmail11.arcor-online.net>
Mime-Version: 1.0
X-Scanned-By: MIMEDefang 2.75 on 172.29.87.18
Received-SPF: pass (mx.binnacle.cx: 172.29.87.10 is whitelisted by SPF-milter
 whitelist entry)
Subject: Re: [tor-talk] Why is 'Wgm' (middle-relay-for-guard weight) not
 zero?
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

Just scanned through all the material and did find anything that directly discusses the question:

_specifically_ why is the weight of middle relays for USE AS A GUARD not zero?  The 'Wgm' parameter is described as 

   Wgm - Weight for non-flagged nodes in the guard Position

The fix for bug #17772 causes the guard selection logic to skip over non-guard relays in the set of candidates.  I have not reviewed the code in detail, but presumably that set of guard candidates is assembled using the weights published under 'bandwidth-weights' in the hourly consensus document applied to the consensus weights of available relays.  Thus the set of guard candidates would consist of about 50% guard-flagged relays and 50% unflagged relays.

One possibility that comes to mind is that the client logic may drop pre-existing guards that have a zero guard probability.  It's apparent from various discussions that the preference is for clients to retain as guards, relays that have lost the guard flag so long as they remain useable.

If the client code behaves as such it means that, due to Wgd=0, clients will immediately drop any guard that transitions to operation as an exit.




At 03:14 12/15/2015 +0100, you wrote:
>hi starlight
>
>to your text
>> it seems that middle relays have a weight equal to guard 
>relays when guard selection occurs [...]
>> ... understand the purpose
>
>there are several possible answers for such a purpose
>
>https://blog.torproject.org/blog/improving-tors-anonymity-changi
>ng-guard-parameters
>Improving Tor's anonymity by changing guard parameters
>
>https://mice.cs.columbia.edu/getTechreport.php?techreportID=1545
>On the Effectiveness of Traffic Analysis Against Anonymity 
>Networks Using Flow Records
>
>to your subject 
>https://gitweb.torproject.org/torspec.git/plain/path-spec.txt
>"   For all circuits, we weight node selection according to 
>router bandwidth."
>
>if a node's weight is zero there might be not enough router 
>bandwidth for (another) Tor user
>
>you don't want to be the only Tor user who isn't squeezed out of 
>this circuit and have to remain for a deanonymization attack

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

