Re: [tor-relays] About relay size

[teor]

> On 7 Oct 2017, at 23:04, grarpamp  wrote:
> 
>> On Wed, Oct 4, 2017 at 1:49 AM, teor  wrote:
>> And most clients just send a DNS name and a set of IP version flags.
>> 
>> For the rare cases where literal addresses are used, or there are
>> IPv6-only websites over DNS, tor could be smarter.
> 
> Not as rare as vanilla websurfing oriented people think.
> There are lots of tech implementors, pen test companies,
> diagnostics, p2p application developers, torrenters, etc... who
> use nothing but literal IPv4/6 numeric addresses over tor all day long.
> This is why it *sucks* that MAPADDRESS hasn't yet been
> enhanced to support even the simplest of /CIDR mapping semantics.
> *.fqdn DNS is hardly half the picture. See...
> https://trac.torproject.org/projects/tor/ticket/3982

You're right, we don't know the number of literal vs DNS connections.
I added it to the ticket:
https://trac.torproject.org/projects/tor/ticket/23761#comment:3

T___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[grarpamp]

On Wed, Oct 4, 2017 at 1:49 AM, teor  wrote:
> And most clients just send a DNS name and a set of IP version flags.
>
> For the rare cases where literal addresses are used, or there are
> IPv6-only websites over DNS, tor could be smarter.

Not as rare as vanilla websurfing oriented people think.
There are lots of tech implementors, pen test companies,
diagnostics, p2p application developers, torrenters, etc... who
use nothing but literal IPv4/6 numeric addresses over tor all day long.
This is why it *sucks* that MAPADDRESS hasn't yet been
enhanced to support even the simplest of /CIDR mapping semantics.
*.fqdn DNS is hardly half the picture. See...
https://trac.torproject.org/projects/tor/ticket/3982
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[teor]

> On 4 Oct 2017, at 01:38, grarpamp  wrote:
> 
> ... Exits would have
> to tag their support of "exit v4 and/or v6 to clearnet"
> in consensus so circuits get built to a place that
> can actually ship the client's cells out to clearnet.
> Relays WAN function already offer inbound connection
> capabilities by their listed OR IP format in consensus,
> but not yet any outbound IP version, which client must
> also know from consensus and compute to reach next input.

The ExitPolicy ad IPv6Exit options on Exits are put into the relay's
descriptor, which gets turned into the microdescriptor, which clients
use to select exits.

And most clients just send a DNS name and a set of IP version flags.

For the rare cases where literal addresses are used, or there are
IPv6-only websites over DNS, tor could be smarter.

We accept patches, but it's not a high priority, because it works for
almost all hostnames / addresses that clients actually use.

> Building WAN paths is different from what is carried within.
> So that, it seems possible, if in consensus, to make WAN path like...
> v6 cells ==> client v6 - v6 guard v6 - v6 mid v4 - v4 exit v6 ==> v6 clearnet
> v4 cells ==> client v6 - v6 guard v6 - v6 mid v4 - v4 exit v4 ==> v4 clearnet

This abstraction layer exists in tor and it works fine.

> On 4 Oct 2017, at 00:49, Scott Bennett  wrote:
> 
> teor  wrote:
> 
>> 
>>> On 3 Oct 2017, at 08:52, Scott Bennett  wrote:
>>> 
>>> teor  wrote:
>>> 
 
 On 3 Oct 2017, at 03:07, Scott Bennett  wrote:
 
>>> In the meantime, I think it would be great to have IPv6-only relays, to
>>> avoid this kind of NAT-related issues.
>> 
>> We'd love to make this happen, but the anonymity implications
>> of mixed IPv4-only and IPv6-only (non-clique) networks need
>> further research. Search the list archives for details.
>> 
>   Couldn't that be taken care of in the tor client code?  For example, a
> client, having chosen a path through which an IPv6-only relay, could 
> extend
> the path by one hop to tunnel through a node with both types of interface
> published?
 
 Yes, clients choose paths, and could choose them using these kinds of
 restrictions. But current tor relay versions won't extend to other relays
 over IPv6. Because we don't understand the anonymity implications of
 restricting the next relay in the path based on the previous relay. Which
 is why we need further research.
>>> 
>>>Here's a procedure:  if the next hop/destination does not use a protocol
>>> in common with the client/current hop, a dual-protocoled node must be
>>> interposed; else use the originally selected hop/destination directly.
>> 
>> But is this procedure safe?
> 
> Why might it not be safe?

Because it may make clients distinguishable from each other. Client
indistinguishability is a key part of tor's anonymity design. I encourage you to
read the original Tor paper.

>> And is it an efficient use of resources to add extra hops?
> 
> Well, the additional hops ought to increase the safety.  Wouldn't that
> have to be considered in an efficiency calculation?
> 
>> (That is, is there a more efficient 3-hop algorithm that's just as safe?)
>> We need research to answer these questions.
> 
> It seems to me that a) using a small number (i.e., 3) of hops reduces
> safety and b) a constant number of hops also reduces safety.  Added hops to
> make an unpredictable path length ought to counter the alleged safety issues
> in choosing hops from a smaller pool.

No, because added hops make clients distinguishable via latency, and as far as
we can tell, they don't increase safety. There's a paper on this, too.

> Also, unless the pool of dual-protocol
> hops is much smaller than the number of relays available, say, ten years ago,
> I don't see a reason to worry.  (We were thrilled to have 900 - 1300 up at
> any one time.)

Tor provides better anonymity guarantees than it used to ten years ago.
So it's today's anonymity we need to measure against, not 2007's.

>>> The client-to-first-hop situation is analogous to using a set of entry 
>>> guards
>>> today, so that much should be okay.  What do IPv6-only clients currently do?
>> 
>> Choose a relay with an IPv6 ORPort.
>> (Or configure a bridge with an IPv6 ORPort or pluggable transport.)
>> 
>> IPv6-only clients need to be manually configured using "ClientUseIPv4 0",
>> because this feature is still experimental. We think it will be safer when 
>> all
>> dual-stack clients use some IPv6 guards.
>> 
> Dual-protocol clients connecting to dual-protocol entry nodes ought to
> choose randomly which protocol to use.  Similarly, a dual-protocol relay
> extending to another dual-protocol relay ought to choose randomly which
> protocol to use for the connection.  Both clients and relays would have the
> option of retrying 

Re: [tor-relays] About relay size

[grarpamp]

Little thought yet but related, figured if client host is dual stack,
could separate "client over WAN via IPv to reach relay"
function from traffic routed into tor's cells for carriage to pop
out other side, like a VPN for IP versions. Exits would have
to tag their support of "exit v4 and/or v6 to clearnet"
in consensus so circuits get built to a place that
can actually ship the client's cells out to clearnet.
Relays WAN function already offer inbound connection
capabilities by their listed OR IP format in consensus,
but not yet any outbound IP version, which client must
also know from consensus and compute to reach next input.
Building WAN paths is different from what is carried within.
So that, it seems possible, if in consensus, to make WAN path like...
v6 cells ==> client v6 - v6 guard v6 - v6 mid v4 - v4 exit v6 ==> v6 clearnet
v4 cells ==> client v6 - v6 guard v6 - v6 mid v4 - v4 exit v4 ==> v4 clearnet
Not quite sure why yet, or if theory correct.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[Scott Bennett]

teor  wrote:

>
> > On 3 Oct 2017, at 08:52, Scott Bennett  wrote:
> > 
> > teor  wrote:
> > 
> >> 
> >> On 3 Oct 2017, at 03:07, Scott Bennett  wrote:
> >> 
> > In the meantime, I think it would be great to have IPv6-only relays, to
> > avoid this kind of NAT-related issues.
>  
>  We'd love to make this happen, but the anonymity implications
>  of mixed IPv4-only and IPv6-only (non-clique) networks need
>  further research. Search the list archives for details.
>  
> >>>Couldn't that be taken care of in the tor client code?  For example, a
> >>> client, having chosen a path through which an IPv6-only relay, could 
> >>> extend
> >>> the path by one hop to tunnel through a node with both types of interface
> >>> published?
> >> 
> >> Yes, clients choose paths, and could choose them using these kinds of
> >> restrictions. But current tor relay versions won't extend to other relays
> >> over IPv6. Because we don't understand the anonymity implications of
> >> restricting the next relay in the path based on the previous relay. Which
> >> is why we need further research.
> > 
> > Here's a procedure:  if the next hop/destination does not use a protocol
> > in common with the client/current hop, a dual-protocoled node must be
> > interposed; else use the originally selected hop/destination directly.
>
> But is this procedure safe?

 Why might it not be safe?

> And is it an efficient use of resources to add extra hops?

 Well, the additional hops ought to increase the safety.  Wouldn't that
have to be considered in an efficiency calculation?

> (That is, is there a more efficient 3-hop algorithm that's just as safe?)
> We need research to answer these questions.

 It seems to me that a) using a small number (i.e., 3) of hops reduces
safety and b) a constant number of hops also reduces safety.  Added hops to
make an unpredictable path length ought to counter the alleged safety issues
in choosing hops from a smaller pool.  Also, unless the pool of dual-protocol
hops is much smaller than the number of relays available, say, ten years ago,
I don't see a reason to worry.  (We were thrilled to have 900 - 1300 up at
any one time.)
>
> > The client-to-first-hop situation is analogous to using a set of entry 
> > guards
> > today, so that much should be okay.  What do IPv6-only clients currently do?
>
> Choose a relay with an IPv6 ORPort.
> (Or configure a bridge with an IPv6 ORPort or pluggable transport.)
>
> IPv6-only clients need to be manually configured using "ClientUseIPv4 0",
> because this feature is still experimental. We think it will be safer when all
> dual-stack clients use some IPv6 guards.
>
 Dual-protocol clients connecting to dual-protocol entry nodes ought to
choose randomly which protocol to use.  Similarly, a dual-protocol relay
extending to another dual-protocol relay ought to choose randomly which
protocol to use for the connection.  Both clients and relays would have the
option of retrying the attempt via the other protocol in the event a failed
attempt to connect.  This ought to have been implemented already, but can
still be done soon.

> > Allowing IPv6 destinations today limits exit-hop selections to dual-
> > protocol-capable exit nodes
>
> No, IPv4-only exits are still useful and used, because tor clients typically
> send DNS names to exits. IPv6 DNS records typically have IPv4 as well,
> so any exit will work. (There's a ticket for better handling of DNS that
> only resolves to IPv6.)
>
> And in the rare case of address literals, the client can choose a capable
> exit. (I think there's a ticket for this, too.)

 Okay, but those circuits are incidental to the circuit that a user wants,
which is limited to dual-protocol-capable nodes.
>
> > which is like using an "ExitNodesIPv6" (if there
> > were such a thing) line in torrc with a long and growing list of nodes.
>
> There are flags on SOCKSPort for IP versions, including PreferIPv6, which
> is the default.
>
> > How
> > long would that list have to be for the warning on the man page under the
> > ExitNodes statement definition to become unimportant?  How many were there
> > when IPv6 destinations were first allowed?
>
> The situation isn't analogous.
>
> For safety, IPv6 exit destinations were turned off by default until we had 
> enough
> IPv6 exits. Now they are on by default.

 I repeat:  how many were there when IPv6 destinations were first allowed?
How many when the default was changed?
>
> But we haven't done the same thing for relays, because we don't know how to
> design the feature so it's safe.

 As soon as there are as many IPv6-capable relays as there were IPv4
relays ten years ago, there will no longer be any reason not to enable their
use.  How close are we to reaching that number now?  Or have we already
passed it?
>
> > For interposing dual-protocoled nodes along the way, how many 

Re: [tor-relays] About relay size

[Scott Bennett]

Roman Mamedov  wrote:

> On Tue, 3 Oct 2017 09:53:46 -0400
> teor  wrote:
>
> > > For interposing dual-protocoled nodes along the way, how many do there
> > > have to be for it to become "not too limiting"?
> > 
> > This is one of the questions we need researchers to answer.
>
> I can't help but feel you are overcomplicating this.
>
> Clients create a circuit by randomly picking 3 nodes out of the all-nodes
> pile, right? If all 3 happen to be IPv6-capable, then the circuit can go over
> IPv6 and all is fine. If some of the 3 happen to be IPv6-only while others are
> IPv4-only, the whole selection can be thrown away and repeated.
>
> That way IPv6-only relays could get some usage on a totally random basis, with
> no compromises and no restraining "of the next hop based on the previous one",
> not hurting anonymity. Clients just need to know which nodes are IPv4-only,
> IPv6-only or dual-stack, to not attempt unworkable combinations, discarding
> them instead.

 Looks good to me, Roman.  I like it better than what I suggested, though
adding some variability to path length had some appeal, too.  Your way is
certainly simpler.
 If tor ever starts to support TCP over UDP and/or TCP over SCTP, that
will be a similar situation for a while, where some relays can do both and
others are limited to one protocol or the other.
>
> And as there are more and more dual-stack or IPv6-only relays, the "throw
> away" step will be needed less and less often.
>
 Yet the same process could be applied to the TCP-over-non-TCP situation
quite easily, too.  I think I like your way even better now.
 My memory is a bit hazy on this, but I seem to recall watching a video
file of Roger Dingledine giving a talk somewhere about tor long ago in which
he commented happily that the tor network had grown to where it usually had
at least 300 nodes up and running at all times of day.  If 300 were enough
for path selection before, aren't they still enough?  Aren't there at least
300 IPv6-only nodes and at least 300 dual-protocol nodes now?  And, of
course, there must have been a time when the network was smaller than 300...


  Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet:   bennett at sdf.org   *xor*   bennett at freeshell.org  *
**
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."   *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[teor]

> On 3 Oct 2017, at 10:57, Roman Mamedov  wrote:
> 
> On Tue, 3 Oct 2017 09:53:46 -0400
> teor  wrote:
> 
>>>For interposing dual-protocoled nodes along the way, how many do there
>>> have to be for it to become "not too limiting"?
>> 
>> This is one of the questions we need researchers to answer.
> 
> I can't help but feel you are overcomplicating this.
> 
> Clients create a circuit by randomly picking 3 nodes out of the all-nodes
> pile, right? If all 3 happen to be IPv6-capable, then the circuit can go over
> IPv6 and all is fine. If some of the 3 happen to be IPv6-only while others are
> IPv4-only, the whole selection can be thrown away and repeated.
> 
> That way IPv6-only relays could get some usage on a totally random basis, with
> no compromises and no restraining "of the next hop based on the previous one",
> not hurting anonymity. Clients just need to know which nodes are IPv4-only,
> IPv6-only or dual-stack, to not attempt unworkable combinations, discarding
> them instead.

Discarding unworkable combinations and restraining node choices seem
equivalent to me, although the relay weights may be different.

> And as there are more and more dual-stack or IPv6-only relays, the "throw
> away" step will be needed less and less often.

If you think this will work and is safe for client anonymity, then the next step
is to write a tor proposal. Having a concrete design could help with
analysing the anonymity implications as well.

I think IPv6-only relays are a lower priority than better IPv6 and dual-stack
client support, and IPv6-only bridge support  But we could do both in the
same release.

Tim
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[Roman Mamedov]

On Tue, 3 Oct 2017 09:53:46 -0400
teor  wrote:

> > For interposing dual-protocoled nodes along the way, how many do there
> > have to be for it to become "not too limiting"?
> 
> This is one of the questions we need researchers to answer.

I can't help but feel you are overcomplicating this.

Clients create a circuit by randomly picking 3 nodes out of the all-nodes
pile, right? If all 3 happen to be IPv6-capable, then the circuit can go over
IPv6 and all is fine. If some of the 3 happen to be IPv6-only while others are
IPv4-only, the whole selection can be thrown away and repeated.

That way IPv6-only relays could get some usage on a totally random basis, with
no compromises and no restraining "of the next hop based on the previous one",
not hurting anonymity. Clients just need to know which nodes are IPv4-only,
IPv6-only or dual-stack, to not attempt unworkable combinations, discarding
them instead.

And as there are more and more dual-stack or IPv6-only relays, the "throw
away" step will be needed less and less often.

-- 
With respect,
Roman
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[Scott Bennett]

teor  wrote:

>
>  A related question is can a relay with only an IPv4 address
>  published currently set an IPv6 OutboundBindAddress?
> >>> 
> >>> Yes. This is useful for IPv6 exits without a fixed IPv6 ORPort address.
> >>> 
> >> That's okay, but what if the node is an entry-and-middle node only?
> >> 
> > Hmm.  On second thought, it's *not* okay because it means that such a
> > node cannot be a middle node because it could only connect to the IPv6
> > universe.  Or the man page is wrong about OutboundBindAddress.  Or there
> > is something else amiss.
>
> "This option may be used twice, once with an IPv4 address and once with
> an IPv6 address"
>
 I see the problem.  I'm running 0.3.1.6-rc at present, 0.3.2.1-alpha
has been installed since I last started tor, and the timestamp on the man
page says "Oct 2 2012". :-(  Now I have to track down why the man page
updates have not been getting installed.  Sigh.  Sorry for that bit of noise.
 The other questions remain, however, including the one above.


  Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet:   bennett at sdf.org   *xor*   bennett at freeshell.org  *
**
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."   *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[teor]

> On 3 Oct 2017, at 08:52, Scott Bennett  wrote:
> 
> teor  wrote:
> 
>> 
>> On 3 Oct 2017, at 03:07, Scott Bennett  wrote:
>> 
> In the meantime, I think it would be great to have IPv6-only relays, to
> avoid this kind of NAT-related issues.
 
 We'd love to make this happen, but the anonymity implications
 of mixed IPv4-only and IPv6-only (non-clique) networks need
 further research. Search the list archives for details.
 
>>>Couldn't that be taken care of in the tor client code?  For example, a
>>> client, having chosen a path through which an IPv6-only relay, could extend
>>> the path by one hop to tunnel through a node with both types of interface
>>> published?
>> 
>> Yes, clients choose paths, and could choose them using these kinds of
>> restrictions. But current tor relay versions won't extend to other relays
>> over IPv6. Because we don't understand the anonymity implications of
>> restricting the next relay in the path based on the previous relay. Which
>> is why we need further research.
> 
> Here's a procedure:  if the next hop/destination does not use a protocol
> in common with the client/current hop, a dual-protocoled node must be
> interposed; else use the originally selected hop/destination directly.

But is this procedure safe?
And is it an efficient use of resources to add extra hops?
(That is, is there a more efficient 3-hop algorithm that's just as safe?)
We need research to answer these questions.

> The client-to-first-hop situation is analogous to using a set of entry guards
> today, so that much should be okay.  What do IPv6-only clients currently do?

Choose a relay with an IPv6 ORPort.
(Or configure a bridge with an IPv6 ORPort or pluggable transport.)

IPv6-only clients need to be manually configured using "ClientUseIPv4 0",
because this feature is still experimental. We think it will be safer when all
dual-stack clients use some IPv6 guards.

> Allowing IPv6 destinations today limits exit-hop selections to dual-
> protocol-capable exit nodes

No, IPv4-only exits are still useful and used, because tor clients typically
send DNS names to exits. IPv6 DNS records typically have IPv4 as well,
so any exit will work. (There's a ticket for better handling of DNS that
only resolves to IPv6.)

And in the rare case of address literals, the client can choose a capable
exit. (I think there's a ticket for this, too.)

> which is like using an "ExitNodesIPv6" (if there
> were such a thing) line in torrc with a long and growing list of nodes.

There are flags on SOCKSPort for IP versions, including PreferIPv6, which
is the default.

> How
> long would that list have to be for the warning on the man page under the
> ExitNodes statement definition to become unimportant?  How many were there
> when IPv6 destinations were first allowed?

The situation isn't analogous.

For safety, IPv6 exit destinations were turned off by default until we had 
enough
IPv6 exits. Now they are on by default.

But we haven't done the same thing for relays, because we don't know how to
design the feature so it's safe.

> For interposing dual-protocoled nodes along the way, how many do there
> have to be for it to become "not too limiting"?

This is one of the questions we need researchers to answer.

>>> A related question is can a relay with only an IPv4 address
>>> published currently set an IPv6 OutboundBindAddress?
>> 
>> Yes. This is useful for IPv6 exits without a fixed IPv6 ORPort address.
>> 
> That's okay, but what if the node is an entry-and-middle node only?

Relays don't extend to IPv6, so you can set the option, but it won't do
anything, because there are no outbound IPv6 connections.

Tim
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[teor]

 A related question is can a relay with only an IPv4 address
 published currently set an IPv6 OutboundBindAddress?
>>> 
>>> Yes. This is useful for IPv6 exits without a fixed IPv6 ORPort address.
>>> 
>> That's okay, but what if the node is an entry-and-middle node only?
>> 
> Hmm.  On second thought, it's *not* okay because it means that such a
> node cannot be a middle node because it could only connect to the IPv6
> universe.  Or the man page is wrong about OutboundBindAddress.  Or there
> is something else amiss.

"This option may be used twice, once with an IPv4 address and once with
an IPv6 address"

T
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[Scott Bennett]

Scott Bennett  wrote:

> teor  wrote:
>
> >
> > On 3 Oct 2017, at 03:07, Scott Bennett  wrote:
> >
> > >>> In the meantime, I think it would be great to have IPv6-only relays, to
> > >>> avoid this kind of NAT-related issues.
> > >> 
> > >> We'd love to make this happen, but the anonymity implications
> > >> of mixed IPv4-only and IPv6-only (non-clique) networks need
> > >> further research. Search the list archives for details.
> > >> 
> > > Couldn't that be taken care of in the tor client code?  For example, a
> > > client, having chosen a path through which an IPv6-only relay, could 
> > > extend
> > > the path by one hop to tunnel through a node with both types of interface
> > > published?
> >
> > Yes, clients choose paths, and could choose them using these kinds of
> > restrictions. But current tor relay versions won't extend to other relays
> > over IPv6. Because we don't understand the anonymity implications of
> > restricting the next relay in the path based on the previous relay. Which
> > is why we need further research.
>
>  Here's a procedure:  if the next hop/destination does not use a protocol
> in common with the client/current hop, a dual-protocoled node must be
> interposed; else use the originally selected hop/destination directly.  
> The client-to-first-hop situation is analogous to using a set of entry guards
> today, so that much should be okay.  What do IPv6-only clients currently do?
>  Allowing IPv6 destinations today limits exit-hop selections to dual-
> protocol-capable exit nodes, which is like using an "ExitNodesIPv6" (if there
> were such a thing) line in torrc with a long and growing list of nodes.  How
> long would that list have to be for the warning on the man page under the
> ExitNodes statement definition to become unimportant?  How many were there
> when IPv6 destinations were first allowed?
>  For interposing dual-protocoled nodes along the way, how many do there
> have to be for it to become "not too limiting"?
> >
> > > A related question is can a relay with only an IPv4 address
> > > published currently set an IPv6 OutboundBindAddress?
> >
> > Yes. This is useful for IPv6 exits without a fixed IPv6 ORPort address.
> >
>  That's okay, but what if the node is an entry-and-middle node only?
>
 Hmm.  On second thought, it's *not* okay because it means that such a
node cannot be a middle node because it could only connect to the IPv6
universe.  Or the man page is wrong about OutboundBindAddress.  Or there
is something else amiss.


  Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet:   bennett at sdf.org   *xor*   bennett at freeshell.org  *
**
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."   *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[Scott Bennett]

teor  wrote:

>
> On 3 Oct 2017, at 03:07, Scott Bennett  wrote:
>
> >>> In the meantime, I think it would be great to have IPv6-only relays, to
> >>> avoid this kind of NAT-related issues.
> >> 
> >> We'd love to make this happen, but the anonymity implications
> >> of mixed IPv4-only and IPv6-only (non-clique) networks need
> >> further research. Search the list archives for details.
> >> 
> > Couldn't that be taken care of in the tor client code?  For example, a
> > client, having chosen a path through which an IPv6-only relay, could extend
> > the path by one hop to tunnel through a node with both types of interface
> > published?
>
> Yes, clients choose paths, and could choose them using these kinds of
> restrictions. But current tor relay versions won't extend to other relays
> over IPv6. Because we don't understand the anonymity implications of
> restricting the next relay in the path based on the previous relay. Which
> is why we need further research.

 Here's a procedure:  if the next hop/destination does not use a protocol
in common with the client/current hop, a dual-protocoled node must be
interposed; else use the originally selected hop/destination directly.  
The client-to-first-hop situation is analogous to using a set of entry guards
today, so that much should be okay.  What do IPv6-only clients currently do?
 Allowing IPv6 destinations today limits exit-hop selections to dual-
protocol-capable exit nodes, which is like using an "ExitNodesIPv6" (if there
were such a thing) line in torrc with a long and growing list of nodes.  How
long would that list have to be for the warning on the man page under the
ExitNodes statement definition to become unimportant?  How many were there
when IPv6 destinations were first allowed?
 For interposing dual-protocoled nodes along the way, how many do there
have to be for it to become "not too limiting"?
>
> > A related question is can a relay with only an IPv4 address
> > published currently set an IPv6 OutboundBindAddress?
>
> Yes. This is useful for IPv6 exits without a fixed IPv6 ORPort address.
>
 That's okay, but what if the node is an entry-and-middle node only?


  Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet:   bennett at sdf.org   *xor*   bennett at freeshell.org  *
**
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."   *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[teor]

On 3 Oct 2017, at 03:07, Scott Bennett  wrote:

>>> In the meantime, I think it would be great to have IPv6-only relays, to
>>> avoid this kind of NAT-related issues.
>> 
>> We'd love to make this happen, but the anonymity implications
>> of mixed IPv4-only and IPv6-only (non-clique) networks need
>> further research. Search the list archives for details.
>> 
> Couldn't that be taken care of in the tor client code?  For example, a
> client, having chosen a path through which an IPv6-only relay, could extend
> the path by one hop to tunnel through a node with both types of interface
> published?

Yes, clients choose paths, and could choose them using these kinds of
restrictions. But current tor relay versions won't extend to other relays
over IPv6. Because we don't understand the anonymity implications of
restricting the next relay in the path based on the previous relay. Which
is why we need further research.

> A related question is can a relay with only an IPv4 address
> published currently set an IPv6 OutboundBindAddress?

Yes. This is useful for IPv6 exits without a fixed IPv6 ORPort address.

T
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[Scott Bennett]

grarpamp  wrote:

> >> Or instead of router mode, try bridge mode feeding into any old pc running
>
> Noting that even some crappy hardware will still fall over when put in its
> so called "bridge" mode, which should just be some packet buffering
> between the wires and their encodings, but it's obviously still looking
> at the traffic above layer2. So you may still need to swap out hardware.
>
 Absolutely.  Another reason to avoid electronics store routers for tor
(or many other things) is the information in recently exposed documents that
the CIA started invading those devices and, where possible, "upgrading" their
firmware as standard practice at least a decade ago.

> >  because there is secondary storage (HDD and/or SSD), paging
> > is available if the routing functions' memory needs grow larger than the
>
> Sure, but there's no free substitute for RAM, and you probably don't want
> packets burning a hole in your SSD. Add more RAM if not maxed out.

 My point was intended to be only that having a regular computer handle
the routing means it doesn't have to die if available RAM be exhausted, i.e.,
not an argument for speed, but rather for survival under unusual loads.
Now that I'm more awake than when I wrote that, though, I realize I don't
recall whether routing and NAT tables and mbufs are page-fixed or pageable
anyway. :-(  It's still better to have a router that you own and the CIA
[probably] doesn't.

> disable swap, boot USB, set read-only, use small ramdisks for write paths.
> If used RAM for a used PC isn't in budget or isn't enough, then maybe
> spindle, but it won't be as fast. And eventually CPU or interrupts or i/o
> get swamped. Then you put a newer PC that can hold proper amounts
> of RAM, CPU, etc.

 Very true.  The device need also not be dedicated to just those functions.
Many people would prefer to stick a heavily used relay on their border gateway
machine to keep its traffic load off their LANs anyway.
 Also, if FreeBSD is used, kernel memory for routing tables, NAT tables
if used, and mbufs should be allocated from 4 MB superpages, allowing the
routing to run very fast.  And with an electronics store router, you don't
have the kernel configuration information available to look at, whereas you
do have that and all the rest as well if you install the OS yourself.  Let's
also not omit the ability to apply security fixes as they become available,
where the store-bought boxes would be running obsolete and unsafe OS in their
firmware, probably by the time the store sold them.


  Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet:   bennett at sdf.org   *xor*   bennett at freeshell.org  *
**
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."   *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[teor]

> On 2 Oct 2017, at 16:54, Santiago  wrote:
> 
>> El 02/10/17 a las 13:19, Scott Bennett escribió:
>> grarpamp  wrote:
>> 
 On Mon, Oct 2, 2017 at 3:53 AM, Santiago  wrote:
>> …
>> 
>> Huh?  What kind of ISP NATs its customers' connections?  Your ISP
>> should be assigning your machine/router a legitimate, unique IPv4 address.
>> The assignment is often, even usually, a temporary assignment via DHCP,
>> but it should not be a private address.  If NAT is a factor, that should
>> happen at the boundary of your own private network, not at an ISP's facility.
> 
> It seems that a French ISP was also planning to share an IPv4 address
> per four costumers.
> 
> …
>> ...  One typical problem with running tor
>> on a NATed machine behind such a device is that the NAT table grows until all
>> of the real memory on the device has been consumed and there is no more room
>> for new NAT entries.
> 
> I am not currently able to replace the modem/router my ISP provides. But
> I'd plan to give it away in the future.
> 
> In the meantime, I think it would be great to have IPv6-only relays, to
> avoid this kind of NAT-related issues.

We'd love to make this happen, but the anonymity implications
of mixed IPv4-only and IPv6-only (non-clique) networks need
further research. Search the list archives for details.

T
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[Santiago]

El 02/10/17 a las 13:19, Scott Bennett escribió:
> grarpamp  wrote:
> 
> > On Mon, Oct 2, 2017 at 3:53 AM, Santiago  wrote:
…
> 
>  Huh?  What kind of ISP NATs its customers' connections?  Your ISP
> should be assigning your machine/router a legitimate, unique IPv4 address.
> The assignment is often, even usually, a temporary assignment via DHCP,
> but it should not be a private address.  If NAT is a factor, that should
> happen at the boundary of your own private network, not at an ISP's facility.

It seems that a French ISP was also planning to share an IPv4 address
per four costumers.

…
>  I'll second the above comments.  Most of those little router boxes are
> running some form of LINUX or FreeBSD as an embedded configuration, which
> includes swapping and paging being disabled due to the absence of secondary
> storage.  All of them have limited RAM.  One typical problem with running tor
> on a NATed machine behind such a device is that the NAT table grows until all
> of the real memory on the device has been consumed and there is no more room
> for new NAT entries.

I am not currently able to replace the modem/router my ISP provides. But
I'd plan to give it away in the future.

In the meantime, I think it would be great to have IPv6-only relays, to
avoid this kind of NAT-related issues.

Cheers,

 -- S
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[grarpamp]

>> Or instead of router mode, try bridge mode feeding into any old pc running

Noting that even some crappy hardware will still fall over when put in its
so called "bridge" mode, which should just be some packet buffering
between the wires and their encodings, but it's obviously still looking
at the traffic above layer2. So you may still need to swap out hardware.

>  because there is secondary storage (HDD and/or SSD), paging
> is available if the routing functions' memory needs grow larger than the

Sure, but there's no free substitute for RAM, and you probably don't want
packets burning a hole in your SSD. Add more RAM if not maxed out.
disable swap, boot USB, set read-only, use small ramdisks for write paths.
If used RAM for a used PC isn't in budget or isn't enough, then maybe
spindle, but it won't be as fast. And eventually CPU or interrupts or i/o
get swamped. Then you put a newer PC that can hold proper amounts
of RAM, CPU, etc.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[Andreas Krey]

On Mon, 02 Oct 2017 13:19:59 +, Scott Bennett wrote:
...
>  Huh?  What kind of ISP NATs its customers' connections?

All kinds of ISPs that were too late to grab enough IPv4 space
for their customer base. Here in germany these are mostly the
cable companies.

Also, generally mobile IP.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[Scott Bennett]

grarpamp  wrote:

> On Mon, Oct 2, 2017 at 3:53 AM, Santiago  wrote:
> >> And you can only have 2 tor instances per public IPv4 address.
> >
> > Why? Is there any place where I can find this kind of info?
>
> Read the archives of this list linked at the bottom of every message.
> As an operator you'll find lots more interesting subjects there too.
>
> > Maybe it's another issue, but I have recently tried to run a second
> > relay behind the same IPv4 address than my first relay, and the
> > connection quality strongly diminished. I suppose my ISP equipment was
> > not able to handle the two relays on NAT, but I would need to
> > investigate further.

 Huh?  What kind of ISP NATs its customers' connections?  Your ISP
should be assigning your machine/router a legitimate, unique IPv4 address.
The assignment is often, even usually, a temporary assignment via DHCP,
but it should not be a private address.  If NAT is a factor, that should
happen at the boundary of your own private network, not at an ISP's facility.
>
> Lots of hardware for use in the home, whether ISP provided or bought
> from wherever by the user, has been known to fall over under load,
> cable / dsl / fiber modems, whether in bridge or router modes, wifi, etc.
>
> For tor you need to test with tens to hundreds of TCP connections
> or more in parallel. The simple online "speedtests" don't do that.
> One way is to load up increasing numbers of opensource Unix iso's,
> conference videos, whatever... into whatever torrent client and watch
> the stats. If upon passing the expected / required number of connections,
> it starts falling significantly off the maximum recorded speed, never recovers
> when unloaded, locks up, reboots, melts / smokes / combusts, etc...
> then try another brand.

 I'll second the above comments.  Most of those little router boxes are
running some form of LINUX or FreeBSD as an embedded configuration, which
includes swapping and paging being disabled due to the absence of secondary
storage.  All of them have limited RAM.  One typical problem with running tor
on a NATed machine behind such a device is that the NAT table grows until all
of the real memory on the device has been consumed and there is no more room
for new NAT entries.
>
> Or instead of router mode, try bridge mode feeding into any old pc running
> [Free]BSD / Linux to do the functions of routing, wifi, firewall, nat,
> dhcp, dns,
> etc... this may often perform better and give more flexibility.

 Yes, and because there is secondary storage (HDD and/or SSD), paging
is available if the routing functions' memory needs grow larger than the
available real memory.  Home electronics store routers cannot hold a candle
to a full OS with a decent packet filter.


  Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet:   bennett at sdf.org   *xor*   bennett at freeshell.org  *
**
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."   *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[grarpamp]

On Mon, Oct 2, 2017 at 3:53 AM, Santiago  wrote:
>> And you can only have 2 tor instances per public IPv4 address.
>
> Why? Is there any place where I can find this kind of info?

Read the archives of this list linked at the bottom of every message.
As an operator you'll find lots more interesting subjects there too.

> Maybe it's another issue, but I have recently tried to run a second
> relay behind the same IPv4 address than my first relay, and the
> connection quality strongly diminished. I suppose my ISP equipment was
> not able to handle the two relays on NAT, but I would need to
> investigate further.

Lots of hardware for use in the home, whether ISP provided or bought
from wherever by the user, has been known to fall over under load,
cable / dsl / fiber modems, whether in bridge or router modes, wifi, etc.

For tor you need to test with tens to hundreds of TCP connections
or more in parallel. The simple online "speedtests" don't do that.
One way is to load up increasing numbers of opensource Unix iso's,
conference videos, whatever... into whatever torrent client and watch
the stats. If upon passing the expected / required number of connections,
it starts falling significantly off the maximum recorded speed, never recovers
when unloaded, locks up, reboots, melts / smokes / combusts, etc...
then try another brand.

Or instead of router mode, try bridge mode feeding into any old pc running
[Free]BSD / Linux to do the functions of routing, wifi, firewall, nat,
dhcp, dns,
etc... this may often perform better and give more flexibility.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[teor]

> On 2 Oct 2017, at 03:53, Santiago  wrote:
> 
> Hi tor-relay list,
> 
>> El 30/09/17 a las 14:02, teor escribió:
>>> On 30 Sep 2017, at 09:55, Andy Isaacson  wrote:
>> …
>> And you can only have 2 tor instances per public IPv4 address.
> 
> Why?

It makes it harder for people to start hundreds of relays.

> Is there any place where I can find this kind of info?

Yes, it's documented in the tor manual page.
And search the list archives for explanations.

> Maybe it's another issue, but I have recently tried to run a second
> relay behind the same IPv4 address than my first relay, and the
> connection quality strongly diminished. I suppose my ISP equipment was
> not able to handle the two relays on NAT, but I would need to
> investigate further.

This is typically many consumer NAT boxes.
Every active tor relay has ~6000 open connections to other relays.
Exits have even more.
Many systems just don't have this capacity.

T
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[Santiago]

Hi tor-relay list,

El 30/09/17 a las 14:02, teor escribió:
> On 30 Sep 2017, at 09:55, Andy Isaacson  wrote:
…
> And you can only have 2 tor instances per public IPv4 address.

Why? Is there any place where I can find this kind of info?

Maybe it's another issue, but I have recently tried to run a second
relay behind the same IPv4 address than my first relay, and the
connection quality strongly diminished. I suppose my ISP equipment was
not able to handle the two relays on NAT, but I would need to
investigate further.

Cheers,

-- S
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[Dhalgren Tor]

FWIW I run a 100TB (150mbps) exit and am convinced that this size
provides better quality exit connectivity than the highest ranked
monster bandwidth relays.  The biggest relays attract the greatest
blacklist treatment due to the volume of abuse emanating from them.

As a user of Tor I frequently observe connection attempts commencing
with a handful of top-rated relays, only to work down to a
mid-bandwidth relay such as mine before successfully completing.

For this reason I would like to see the exit selection algorithm bias
somewhat away from relays rated over 5.  Is annoying to wait 30
seconds for the discovery of a usable path.

Hard 100mbps connections will be easier to manage than the 100TB class
of service, as the latter is usually over a 1GB link with a FUP (fair
use policy) associated with it and extravagant surcharges for
exceeding the limit.


>Hi Tor list,
>
>I'm already running a small exit node (100Mbps bandwidth) and I'm ready
>to spend more money on it, so have a question for you guys :
>
>Is it better if I run other small ones (100Mbps too) or only 1 big exit
>relay (1 Gbps) ? What's best for the network stability/security ?
>
>Thanks a lot
>
>IPonU
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[grarpamp]

> Larger, faster relays help clients achieve low-latency, high bandwidth
> connections.

This may depend? Do we have a graph of actual headroom / saturation
in the network of boxes versus consensus weight versus max box speed?
Does weight back off below historically sensed saturation levels?
Because seems even the fastest box would become high latency low
bandwidth upon saturation, and a path through three 40Mbit boxes
that are all 25% loaded might provide better performance than through
a single saturated gig box anywhere in path.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[teor]

On 30 Sep 2017, at 09:55, Andy Isaacson  wrote:

>> Is it better if I run other small ones (100Mbps too) or only 1 big exit 
>> relay (1 Gbps) ? What's best for the network stability/security?
> 
> My overall analysis is that one 1Gbps relay is a better contribution to the 
> network than two 100 Mbps relays

I agree.
Larger, faster relays help clients achieve low-latency, high bandwidth
connections.

But depending on your processor speed, you might find that each tor
instance can only use about ~300Mbps before it maxes out the CPU.
(And it can take a few weeks for a new tor relay to get to the
maximum.)

So you may need 3-4 tor instances on your 1Gbps connection.
And you can only have 2 tor instances per public IPv4 address.

-- 
Tim / teor

PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[Christopher]

Hi IPonU, Thanks for running a relay.

As I understand it, running one larger relay may be better. Traffic
correlation attacks by a global persistent adversary might have a harder
time due to the fact that more circuits are using one IP, rather than less
circuits spread across multiple IPs. In no way is this a cure-all, but it
might help.

Cheers


On Fri, Sep 29, 2017 at 12:37 AM IPonU  wrote:

> Hi Tor list,
>
> I'm already running a small exit node (100Mbps bandwidth) and I'm ready
> to spend more money on it, so have a question for you guys :
>
> Is it better if I run other small ones (100Mbps too) or only 1 big exit
> relay (1 Gbps) ? What's best for the network stability/security ?
>
> Thanks a lot
>
> IPonU
>
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[Andy Isaacson]

On Fri, Sep 29, 2017 at 09:37:00AM +0200, IPonU wrote:
I'm already running a small exit node (100Mbps bandwidth) and I'm 
ready to spend more money on it, so have a question for you guys :


Thanks for running a relay!

Is it better if I run other small ones (100Mbps too) or only 1 big 
exit relay (1 Gbps) ? What's best for the network stability/security?


My overall analysis is that one 1Gbps relay is a better contribution to 
the network than two 100 Mbps relays, assuming other variables are held 
constant.  This choice by a single operator isn't a significant impact 
on security or stability, but in general we want


 - more operators
 - more AS diversity as share of exit bandwidth
 - more bandwidth
 - more nodes

in approximately that order of importance.  You're already nailing it on 
the first (thanks again!), I think you're not considering to add another 
AS (your new node would be on the same ISP), so it's mostly just a 
choice between 200 mbps and 1gbps, and a choice between one descriptor 
in the consensus or two descriptors.


Also, if we were very short of nodes, then adding more nodes would be a 
higher priority; but currently we seem to be more short of skilled and 
motivated operators, rather than node-limited.


-andy
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[IPonU]

I don't know if they accept foreign people to order (you could ask them 
by clicking on "Nous contacter ") 
The forum doesn't work in France either.


I already asked them about tor exits and they told me they were OK with 
it as long it's not spamming and it's not affecting (slowing) their network.


This ISP is already mentionned in the goodbadisp page and i'll update it 
if they shut down my relay.



Le 29/09/2017 à 13:31, Ralph Seichter a écrit :

On 29.09.2017 10:18, IPonU wrote:


http://www.digicube.fr/rapidserveurs

DigiCube notes "Offre uniquement valable pour la France métropolitaine".
Has anybody asked if non-French customers are also welcome? Have they
agreed to hosting Tor nodes, especially exits? My French is rusty, and I
could not find answers to these questions on their site, and I get only
timeouts when trying to connect to the DigiCube forum.

-Ralph

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[Ralph Seichter]

On 29.09.2017 10:18, IPonU wrote:

> http://www.digicube.fr/rapidserveurs

DigiCube notes "Offre uniquement valable pour la France métropolitaine".
Has anybody asked if non-French customers are also welcome? Have they
agreed to hosting Tor nodes, especially exits? My French is rusty, and I
could not find answers to these questions on their site, and I get only
timeouts when trying to connect to the DigiCube forum.

-Ralph

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[Tor Node Admin @ SechsNullDrei.org]

Hi there,

If your exit node has been online for more than two months with little hassle 
from the ISP, be sure to update the wiki at 
https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs with your exit 
node's ISP information.  And thank you for your contribution to the Tor network.

Thank you for your email,
Isaac, t...@sechsnulldrei.org

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
IPonU
Sent: Friday, September 29, 2017 2:37 AM
To: tor-relays
Subject: [tor-relays] About relay size

Hi Tor list,

I'm already running a small exit node (100Mbps bandwidth) and I'm ready to 
spend more money on it, so have a question for you guys :

Is it better if I run other small ones (100Mbps too) or only 1 big exit relay 
(1 Gbps) ? What's best for the network stability/security ?

Thanks a lot

IPonU


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[IPonU]

I'm not sure what you're asking so I'll show you the website : 
http://www.digicube.fr/rapidserveurs


ATM I have the cheapest (4€). So i'm not sure if I take others or if I 
take only one at the top with 1Gbps bandwidth.


I think it could be great to have multiple relays in case one is down 
but i'm not sure



Le 29/09/2017 à 09:54, John Ricketts a écrit :

Hi,

100Mbps is not a small node.  Thanks for running a relay!

When you say you’re going to spend more money on it...  do you mean 
hardware or bandwidth?


All of my relays are running as virtual machines on multiple computers 
to maximize the CPU and memory usage. If you didn’t want to virtualize 
your machines you could put two Tor nodes on the same physical box to 
maximize hardware usage.


If you’re comfortable telling us where you’re putting your money I 
suspect we can advise you better.


John
Quintex Alliance Consulting



On Sep 29, 2017, at 02:37, IPonU > wrote:



Hi Tor list,

I'm already running a small exit node (100Mbps bandwidth) and I'm 
ready to spend more money on it, so have a question for you guys :


Is it better if I run other small ones (100Mbps too) or only 1 big 
exit relay (1 Gbps) ? What's best for the network stability/security ?


Thanks a lot

IPonU


___
tor-relays mailing list
tor-relays@lists.torproject.org 
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays



___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[I]

Putting relays where there aren't many now would be good for diversity.



___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] About relay size

[John Ricketts]

Hi,

100Mbps is not a small node.  Thanks for running a relay!

When you say you're going to spend more money on it...  do you mean hardware or 
bandwidth?

All of my relays are running as virtual machines on multiple computers to 
maximize the CPU and memory usage. If you didn't want to virtualize your 
machines you could put two Tor nodes on the same physical box to maximize 
hardware usage.

If you're comfortable telling us where you're putting your money I suspect we 
can advise you better.

John
Quintex Alliance Consulting



On Sep 29, 2017, at 02:37, IPonU > 
wrote:

Hi Tor list,

I'm already running a small exit node (100Mbps bandwidth) and I'm ready to 
spend more money on it, so have a question for you guys :

Is it better if I run other small ones (100Mbps too) or only 1 big exit relay 
(1 Gbps) ? What's best for the network stability/security ?

Thanks a lot

IPonU


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays