tor-dev February 2012

tor-dev@lists.torproject.org

26 participants
24 discussions

Re: [tor-dev] Simulating a slow connection
by Rob Jansen 02 Feb '12

02 Feb '12

> Date: Thu, 26 Jan 2012 16:39:34 +0000 > From: Steven Murdoch <Steven.Murdoch(a)cl.cam.ac.uk> > To: tor-dev(a)lists.torproject.org > Subject: Re: [tor-dev] Simulating a slow connection > Message-ID: <CAE309A8-034E-4E6A-B05C-6B9B3EA1CDBE(a)cl.cam.ac.uk> > Content-Type: text/plain; charset=us-ascii > > Hi Adam, > > On 20 Jan 2012, at 10:55, Adam Katz wrote: > >> Well, I myself didn't have anything specific in mind but i have some >> experience with the linux tc utility as well as with generating >> realistic background traffic. I was wondering whether I could help on >> any of the existing projects or help establish a new one. > > I think Nick's comments summarized the current state of thinking. ExperimenTor and Shadow are the best Tor simulators to use for this project. The big missing pieces are: > - an automated framework for setting up experiments with slow Internet connections with ExperimenTor and Shadow, then collecting and summarizing results > - Tools for generating realistic link characteristics (delay and packet dropping), and for collecting data on the link properties found in particular locations > > Steven. > As Steven stated, this would be very easy to explore with Shadow. The network topology is passed in as an XML file: node properties include bandwidth up/down and link properties include latency, jitter, and packetloss. I already have some python scripts to generate topologies, and would be happy to share them once you have realistic measurements/values for the slow links you'd like to explore. I'd also be happy to explain more about how Shadow works or the structure of the XML file. Rob

1 0

Extending BridgeDB to reallocate bridges from a blocked country to others that do not block.
by Aaron 02 Feb '12

02 Feb '12

The following is a draft proposal of changes to BridgeDB to address the deliverable "Automated bridge allocation to reallocate bridges from a blocked country to others that do not block" (https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorE/PhaseTh…) This draft proposes two different approaches -- any feedback or questions are very welcome! --Aaron ==== Filename: xxx-bridgedb-reallocates-bridges.txt Title: BridgeDB Reallocates Bridges Author: Aaron Gibson Created: 15 Jan 2015 Status: Draft Introduction: This proposal outlines the required changes for BridgeDB to reallocate bridges from a blocked country to others that do not block. Current Status: Presently, BridgeDB does not allocate bridges to specific countries. The HTTPS distributor divides bridges into a cluster of rings. Requests for bridges are mapped to a single ring in the cluster using the class C network of the client, so that the IPv4 space is divided amongst the rings in the cluster (presently 4 rings). For an attacker to obtain the complete set of bridges she must control a number of IP addresses in diverse networks. The email based distributor uses a single ring, and bridge buckets are dumped from a single pool of unallocated bridges. Required modifications: 1. BridgeDB must be able to produce an unblocked set of bridges for a specific country, if these bridges are available. 2. If a bridge is blocked in a country, it must be available to users in other countries. BridgeDB could be modified to assign bridges to geographic regions. To do so, the cluster concept must be extended to support 'geographic clusters' of bridges that correspond to a set of country codes, so that requests will be directed to a corresponding cluster, by either automatic geoip detection or by client choice. Alternately, BridgeDB could be modified to guarantee that a client requesting unblocked bridges for a region would receive these bridges, if unblocked bridges exist. Presently, patches exist for BridgeDB that mark known blocked bridges as "Might be blocked", but makes no further effort to respond with unblocked bridges, even if those bridges exist. Proposed Solution 1 Modify BridgeDB to assign bridges to geographic regions. Regions are designated by a list of country codes. Regions should be balanced in size, or proportional to the number of bridge users. If a bridge is blocked in a region, the bridge should be reallocated to another region. Bridges for a region are stored in a cluster of rings. Pitfalls Bridges assigned to one geographic area are not available to clients requesting bridges from other regions. Possible Solution 2 Modify BridgeDB to dynamically produce rings of bridges 'Not blocked in' a specified country. Bridges are not mapped to a specific country or region, but BridgeDB's response would contain only unblocked bridges (if available). Pitfalls As bridges are not allocated to a specific region, bridges could not be reserved for distribution to specific regions. Common pitfalls As BridgeDB learns about blocked bridges that it may no longer provide, BridgeDB replaces blocked bridges with good bridges. An attacker with control over addresses from many class C networks could iteratively request and block bridges, until the entire set has been consumed. The rate of consumption could be limited by the rate that blocked bridges are updated, but clients would be more likely to receive a bridge that has been blocked.

2 2

DNS/DNSSEC resolving in Tor (PoC implementation)
by Ondrej Mikle 01 Feb '12

01 Feb '12

Hi, I decided to give it a shot in implementing full DNS/DNSSEC resolution support for Tor, here's the branch: https://github.com/hiviah/tor ATM the biggest limitation is that reply DNS packet must fit in a single cell (i.e. max size is RELAY_PAYLOAD_SIZE). How it's implemented: There's new command SOCKS_COMMAND_RESOLVE_FULL for SOCKS interface and new cells RELAY_COMMAND_RESOLVE(D)_FULL. The RESOLVE_FULL cell contains query string and RR-type, RESOLVED_FULL just the DNS packet in wire format. Resolving is implemented via libunbound on the relay's side, ldns parses packet on client's side. The tor-resolve now uses the new SOCKS command and accepts -t parameter with RR-type (numeric, default 1 - RR-type 'A'), e.g.: ./src/tools/tor-resolve -t 28 lupa.cz localhost:10050 Packet size: 319 Flags: qr: 1, aa: 0, tc: 0, rd: 1, cd: 0, ra: 1, ad: 1 -- Rcode: NOERROR -- Opcode: QUERY -- Question section lupa.cz. IN AAAA -- Answer section lupa.cz. 600 IN AAAA 2001:67c:68::7b lupa.cz. 600 IN RRSIG AAAA 5 2 600 20121022235305 20111023235305 8130 lupa.cz. wFdVqKCEh4Nmac3v5K9y6HT+aIBAtF4Q9QIqHjlAl/ljp4m5TKkgKCF083zFTMh0LqfwdODfQdSNTKAwO55hyw== -- Authority section lupa.cz. 600 IN NS ns.iinfo.cz. lupa.cz. 600 IN NS ns6.adminit.cz. lupa.cz. 600 IN RRSIG NS 5 2 600 20121022235305 20111023235305 8130 lupa.cz. SpqkpBlK1dzrfACHh3yfUp01Vr/w9qzVYQms4RDXNQZW1Hwr5WYMHIuGrFEgOOrjyg1vB01HENXJf4i2ISx51g== -- Additional section Other implementation notes: - some checks like whether private address is resolved are missing (also a whitelist of allowed RR-types might be implemented) - in the SOCKS5 request, RR-type is hacked onto port number - in SOCKS5 reply, high byte of length is hacked onto SOCKS5 reserved byte - libunbound supports async resolving, for now synchronous is used - there are more details, grep FIXDNS in code - Makefile.am's have -lldns and -lunbound hardwired - new code may not be pretty at some places (getting to know Tor code) Also, this seems to be a bug in relay.c:connection_edge_process_relay_cell_not_open(), the RELAY_COMMAND_RESOLVED case: answer_len = cell->payload[RELAY_HEADER_SIZE+1]; if (rh->length < 2 || answer_len+2>rh->length) {...} Payload is accessed before checking bounds. Ondrej

5 12

Improving the tests
by Esteban Manchado Velázquez 01 Feb '12

01 Feb '12

Hey guys, I wanted to try and help a bit, but I'm not exactly a C wizard or know much about networking code. However, I am an experienced developer, do understand C and have quite a bit of experience with automated testing. Luckily, according to https://www.torproject.org/getinvolved/volunteer.html.en#unitTesting, it seems you guys could use someone spending some time with the tests :-) I'm sure it's going to take me a while to get my head around the code and the tests, but I can give it a shot and see what happens. How do I get started? Any suggestions? -- Esteban

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev February 2012