[tor-dev] Tor and BGP integration

Jacob Appelbaum jacob at appelbaum.net
Thu Jun 9 22:35:14 UTC 2011

On Thu, Jun 9, 2011 at 10:23 PM, Robert Ransom <rransom.8774 at gmail.com>wrote:

> On Thu, 9 Jun 2011 21:34:17 +0000
> Jacob Appelbaum <jacob at appelbaum.net> wrote:
> > On Thu, Jun 9, 2011 at 8:40 PM, grarpamp <grarpamp at gmail.com> wrote:
> >
> > > Some thoughts from a quasi network operator...
> > >
> > > Perhaps a tracking reason not to do this...
> > >
> > > Normally exit traffic is free to travel the globe across jurisdictions
> > > on its way to its final destination (ie: webserver). Doing this
> > > forces that traffic to sink at the exit jurisdiction... removing
> > > that part of its independence.
> > >
> > >
> > No, it does not change anything except adding more exiting bandwidth to
> the
> > network. People who otherwise would run a middle node are willing to
> endure
> > Tor connections *to their own netblocks* from their own Tor nodes. That
> will
> > only improve things and it does not aide in tracking and Tor will still
> use
> > three hop circuits...
> No.
> Three hops are enough for normal Tor circuits because in a three-hop
> circuit, although the second hop knows some information about the
> client (one of its guard nodes) and the third hop knows the
> destination, no single hop has useful information about both.  When a
> client's choice of exit node leaks useful information about its
> intended destination, as it does when using an ‘exit enclave’ and would
> when using an exit node that exits to a small number of destinations.
Sure but this in no way changes the picture. It's not like exit enclaving at
all, except that it encourages nodes that would otherwise reject *:* to
accept some exiting traffic. There would be no change to the way that the
Tor client builds the circuit; this is just a way to encourage network
operators (who want to play nice) to run more than a middle node without a
lot of overhead. Or do I misunderstand?

All the best,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20110609/f804c290/attachment.htm>

More information about the tor-dev mailing list