[or-cvs] r12599: more progress on the geoip proposal (tor/trunk/doc/spec/proposals)

[Robert Hogan]

On Friday 30 November 2007 08:13:18 you wrote:

>
> > 2. setconf  ExcludeCountryCodes
> > 3. setconf IncludeCountryCodes
>
> Hm. Most people I've talked to care about the position in the path too --
> they don't just want to skip a given country entirely, they want to only
> skip it at the beginning, or the end, or something like that.
>
> And what would IncludeCountryCodes do? Only use relays from those
> countries in all positions in the circuit?

Yes, a bit half-baked. Disengaging gently from auto-pilot:

ExcludeExitCountryCodes US,DE

StrictExitCountryCodes 1|0
ExitCountryCodes US,DE

EntryCountryCodes US,DE
StrictEntryCountryCodes 1|0

# For non-entry and non-exit servers
RelayCountryCodes US,DE
StrictRelayCountryCodes 1|0

So that the user can see what servers are being excluded by these choices:

getinfo servers/[countrycode] - giving network-statuses
getinfo names/countrycode - giving an fp list maybe.
um, that's it.

>
> >
> > @downloaded-at 2007-11-29 19:45:13
> > @source "86.59.21.38"
> > @geoip US Boston X-ordinate Y-ordinate
>
> The "router annotations" you describe here are added locally by the Tor
> that receives the router descriptor. They're not published in any signed
> way. If we were to add the countrycode into the server descriptor, then
> we would have to trust the server to write the correct countrycode into
> his signed descriptor, and if we decided he was lying our only recourse
> would be to not list that descriptor.
>
> If we want to provide the countrycode info for each router, signed by
> authorities, we could put it into that router's entry in the networkstatus
> consensus -- that's my "Option B" in Section 4.2.
>

Ah. Whoops.

> But I'm still not very happy about putting it in the networkstatus,
> since the IP to GeoIP mapping will be relatively static, so we'll be
> wasting a lot of bandwidth as caches mirror redundant information,
> and as clients fetch information they already know.
>
This is the definiitely the big downside with centralizing the geoip data to 
the authorities. 

That said, tt would be just an extra three bytes per status (including the 
space) if you were  to provide country code, roughly 4-5K at current volumes. 
If country code is enough for the near future then this might be the way to 
go. The x-y co-ordinates could then be an opt field in the network-status 
document, if a client needs them.

Again imvho the merits/demerits of centralizing come down to whether country 
code is enough in the immediate future for the feature's goal - if it is then 
the security advantages [reduced partitioning opportunities] of keeping it to 
the authorities may outweigh the small(?) bw penalty it incurs.

Given that bw is something to conserve, perhaps a few wasteful bytes from the 
network-status could be removed for 0.2, e.g.. the '-'  and ':' in the date 
and time stamps. Maybe the status flags could be abbreviated? These two alone 
would make enough room for country code and co-ordinates! ;-) I know what a 
hack that would be to code around, but...

 
> Since most of the answers won't change from hour to hour, the obvious
> solution is to only ask questions about the ones you don't already know
> the answer to -- which is exactly what Vidalia already does.
>
> But I haven't thought of a better way yet. Perhaps we'll have found one
> by the time we get around to switching from "Option A" to "Option B". :)
>
> Thanks,
> --Roger


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20071203/f34e6ea4/attachment.pgp>