Moritz wrote:
Maybe this is better taken to tor-relays.
Ok.
url to the tor-dev thread: https://lists.torproject.org/pipermail/tor-dev/2016-March/010473.html
Brian didn't say anything about planed deployment locations, but if _all_ relays are within a single /16 network you might skip MyFamily altogether, but I assume they are not.
In my case machines have a lifecycle. They come and they go
out of curiosity: What percentage of them do you expect to be online concurrently? (starting when) Are planing to rekey when "coming back" or resume with the former?
On 03/05/2016 10:31 PM, Brian "redbeard" Harrington wrote:
"Lets say you are about to deploy 100 relays within the next week." - Take this an order of magnitude greater and we're on the right track with the correct scale. It is a regular occurrence for our users to deploy 500 to 5000 nodes at a time.
This is why I said "and maybe set yourself an upper boundary as to how big you want to grow"
A single entity deploying 5000 relays isn't very sane at the current network size I guess, but instead of speaking of relay counts using CW fraction/exit/guard probability as upper boundaries makes more sense. <10% might be a worthy upper boundary for exit/guard probability.
The biggest (known) exit operator is currently at 7-8% exit probability.
teor wrote:
And there's likely some limit on MyFamily or on descriptor size that would stop you listing 1000 fingerprints.
That is actually another good use-case for replacing the current MyFamily design with something that scales better with family size like Mike's proposed design (#5565), but we did not see declared families that big so far. It was no problem in practice.
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n364
Server descriptors may not exceed 20,000 bytes in length; [...] If they do, the authorities SHOULD reject them.
So the max family size would be something around 400 relays?
(20000 - 1250) / 42 = 446
(1250 bytes was the size of a non-exit sample descriptor without family)
generating 1000 relay keys and coordinating that key distribution dance across the same number of nodes (more than likely in highly distributed environments) seems to bring more questions than it answers (securing the keys for those nodes, securely distributing them, etc)
What problems do you expect when generating and transferring 1000 relay keys? (besides the descriptor limit) ... but before trying to solve any problems it is probably best to answer the question whether a single entities should run >5% CW fraction at all.
There are about 7000 relays in total, with over 1000 of them (almost 40% of the capacity) at only three ASes.
Top 3 ASes currently account for 32% cw fraction. https://compass.torproject.org/#?exit_filter=all_relays&links&sort=c...
but the top 1000 relays account for >72% cw fraction
https://compass.torproject.org/#?exit_filter=all_relays&links&sort=c...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 03/06/2016 05:21 AM, nusenu wrote:
Moritz wrote:
Maybe this is better taken to tor-relays.
Ok.
url to the tor-dev thread: https://lists.torproject.org/pipermail/tor-dev/2016-March/010473.html
Brian didn't say anything about planed deployment locations, but if _all_ relays are within a single /16 network you might skip MyFamily altogether, but I assume they are not.
To help better explain this to folks on this mailing list, this started as a discussion of how to play nicely with the network. To be a bit less coy, I work for a Linux vendor (CoreOS). Some of our users run small groups of servers (1-10) many also run clusters of 1000 machines or more. When folks deploy machines, the goal is to keep the configurations as minimal & static as possible so as to avoid treating each config as a unicorn. When I deploy a cluster of machines for a workload they're generally split between Google Compute Engine, Amazon Web Services, and physical machines split across a number of different datacenters.
I was originally inquiring as to how to best inform the network that these machines are all related so as to be able to
1) expand the network with a number of hosts 2) Avoid the appearance of a sybil attack 3) Simplify the configuration so that /more/ operators could duplicate the work
This originally focused around the use of the Families. At the same time, I'm coming to the community to give both an anecdote of how we (and our users) deploy software as well as make sure we're providing the maximum benefit for the network.
In my case machines have a lifecycle. They come and they go
out of curiosity: What percentage of them do you expect to be online concurrently? (starting when) Are planing to rekey when "coming back" or resume with the former?
This is generally up to operators. In my case, machines generally *never* "come back." This is to say that I treat all machines as untrusted (the caveat to this is below) and I treat the provisioning process as vital to ensuring a minimally tampered state.
On 03/05/2016 10:31 PM, Brian "redbeard" Harrington wrote:
"Lets say you are about to deploy 100 relays within the next week." - Take this an order of magnitude greater and we're on the right track with the correct scale. It is a regular occurrence for our users to deploy 500 to 5000 nodes at a time.
This is why I said "and maybe set yourself an upper boundary as to how big you want to grow"
A single entity deploying 5000 relays isn't very sane at the current network size I guess, but instead of speaking of relay counts using CW fraction/exit/guard probability as upper boundaries makes more sense. <10% might be a worthy upper boundary for exit/guard probability.
The biggest (known) exit operator is currently at 7-8% exit probability.
teor wrote:
And there's likely some limit on MyFamily or on descriptor size that would stop you listing 1000 fingerprints.
That is actually another good use-case for replacing the current MyFamily design with something that scales better with family size like Mike's proposed design (#5565), but we did not see declared families that big so far. It was no problem in practice.
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n364
Server descriptors may not exceed 20,000 bytes in length; [...] If they do, the authorities SHOULD reject them.
So the max family size would be something around 400 relays?
(20000 - 1250) / 42 = 446
(1250 bytes was the size of a non-exit sample descriptor without family)
generating 1000 relay keys and coordinating that key distribution dance across the same number of nodes (more than likely in highly distributed environments) seems to bring more questions than it answers (securing the keys for those nodes, securely distributing them, etc)
What problems do you expect when generating and transferring 1000 relay keys? (besides the descriptor limit) ... but before trying to solve any problems it is probably best to answer the question whether a single entities should run >5% CW fraction at all.
In my normal use case (e.g. non Tor processes) secret keys are never transferred to a host. This means that (in the case of PKCS#7 & PKCS#11) key distribution is handled more via CSR rather than traditional "distribution" (copying of files). In fact, members of our team are in the process of attempting to ratify this for some large scale distributed computing projects (https://github.com/kubernetes/kubernetes/pull/20439).
This doesn't answer the question of "it is probably best to answer the question whether a single entities should run >5% CW fraction at all." I humbly agree that a single entity should probably *not* operate that much of the network but the reality of the situation is that when operators have the *abilit**y* to run that much of the network, they may. The easiest way to challenge this is to expand the size of the network making it harder to reach that 5% mark. As an operating system vendor minimizing the deployment process of this, it could make this easier.
There are about 7000 relays in total, with over 1000 of them (almost 40% of the capacity) at only three ASes.
Top 3 ASes currently account for 32% cw fraction. https://compass.torproject.org/#?exit_filter=all_relays&links&sort=c...
but the top 1000 relays account for >72% cw fraction
https://compass.torproject.org/#?exit_filter=all_relays&links&sort=c...
The final piece of this is that we are currently building attestation of running Linux containers using the TPM. While these are being attested by individual signers today, obviously the long term goal would be to help the current signers of the Tor binaries use this process in addition to signed tarballs which would then give a mechanism for full cross distro runtime attestation in a reproducible way. Walk before running though. Let's make sure this can nicely play with the network.
- --redbeard
A few more thoughts
- consider asking dir auths at what cw fraction they are going to start de-listing relays - to avoid wasting efforts (if you are lucky and get an answer from most of them share them with us :)
- maybe run without DirPort so you do not become HSDir for to many HSes
- your relays might significantly increase the overall churn rate, which means that some tor users have to change guard relays more often than currently (if your relays are around long enough to become guards) -> consider "recycling" your keys as long as they stay in the same AS to a certain extend (even if instances are "never coming back")
- maybe proactively announce it here before adding >50 relays/day
Looking forward to the first of your relays. (also because it will practically answers interesting questions like how big is to big according to dir auth ops)
Perfect. I'll poke at this a bit more and then notify folks on tor-relays and release the hounds. Since there isn't really a "good" way to do the families I'll settle for consistent ContactInfo. Likely I'll have some of the configuration done so that users may set an environment variable to enable DirPort while leaving it disabled by default.
--rb
On 03/08/2016 02:29 PM, nusenu wrote:
A few more thoughts
- consider asking dir auths at what cw fraction they are going to start
de-listing relays - to avoid wasting efforts (if you are lucky and get an answer from most of them share them with us :)
maybe run without DirPort so you do not become HSDir for to many HSes
your relays might significantly increase the overall churn rate, which
means that some tor users have to change guard relays more often than currently (if your relays are around long enough to become guards) -> consider "recycling" your keys as long as they stay in the same AS to a certain extend (even if instances are "never coming back")
- maybe proactively announce it here before adding >50 relays/day
Looking forward to the first of your relays. (also because it will practically answers interesting questions like how big is to big according to dir auth ops)
Brian, This sounds like a great effort. I wanted to point out 2 things: 1) I think that GCE IP addresses are blacklisted (due to an earlier sybil attack, https://lists.torproject.org/pipermail/tor-relays/2015-August/007656.html). 2) How do you see your work relating to and differing from the discontinued Tor Cloud (https://cloud.torproject.org/) project? I don't mean to discourage you, but I'm curious what the differences are.
Thank you.
On Wed, Mar 9, 2016 at 8:26 AM, nusenu nusenu@openmailbox.org wrote:
Since there isn't really a "good" way to do the families I'll settle for
consistent ContactInfo.
Worst-case outcome for a "how do I do MyFamily properly" discussion ;)
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
This sounds like a great effort. I wanted to point out 2 things:
- I think that GCE IP addresses are blacklisted (due to an earlier sybil
attack, https://lists.torproject.org/pipermail/tor-relays/2015-August/007656.html).
I don't think it is blacklisted currently (but maybe someone at the dir auth level can confirm that), see also this tor-dev thread:
https://lists.torproject.org/pipermail/tor-dev/2015-August/009389.html
- How do you see your work relating to and differing from the discontinued
Tor Cloud (https://cloud.torproject.org/) project? I don't mean to discourage you, but I'm curious what the differences are.
cloud.torproject.org is dead.
On Mar 11, 2016 3:51 AM, "nusenu" nusenu@openmailbox.org wrote:
This sounds like a great effort. I wanted to point out 2 things:
- I think that GCE IP addresses are blacklisted (due to an earlier
sybil
attack,
https://lists.torproject.org/pipermail/tor-relays/2015-August/007656.html).
I don't think it is blacklisted currently (but maybe someone at the dir auth level can confirm that), see also this tor-dev thread:
https://lists.torproject.org/pipermail/tor-dev/2015-August/009389.html
I just read that thread. Thanks for referencing my issue back then! Greg
- How do you see your work relating to and differing from the
discontinued
Tor Cloud (https://cloud.torproject.org/) project? I don't mean to discourage you, but I'm curious what the differences are.
cloud.torproject.org is dead.
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Greg,
Thank *you* for the reminder!
So as far as the GCE note, that's good to know. I'll put a note in some of the documentation about this.
In terms of it's relation to cloud.torproject.org... In a way this pre-dates that, in a way it's new artwork.
Many moons ago (~circa 2007) I was discussing this idea with Roger and Jake at the Non-profit Development Summit in Oakland. Due to a number of factors (impostor syndrome, security concerns, etc) I abandoned the project convinced that someone else would do it.
Moving on a number of years I never abandoned the idea. In fact, in my mind it became a fantastic place to showcase some more recent work I've been involved with.
Over the past two years I have been working with folks on a self-updating Linux distribution called CoreOS. The important parts are that it's been massively stripped down (removing the attack surface), similar to old school Bell UNIX machines the /usr partition operates read only (think of the days of NFS mounted /usr), and the updates are atomically signed images including the kernel, systemd, sshd, glibc, and a very small number of other utilities. All of these updates are pushed out using a mechanism called "Omaha protocol" (https://coreos.com/docs/coreupdate/custom-apps/coreupdate-protocol/) and images are pulled down, undergo GPG validation (and a few other checks) with an embedded key,and are processed. All applications are run inside of Linux containers (systemd-nspawn, rkt, docker, doesn't really matter) to provide both a portable environment and process, mount, and network isolation (to the degree that the administrator chooses).
With some of the more recent work, we've added GPG validation and TPM attestation of the container image as well. This leads to a state where the user can guarantee that the applications executing on a host are attested by a known, trusted entity.m In the short term we (CoreOS) must continue to demonstrate the utility of this. One easy option is of course to provide usable applications atop the platform with a *need* to utilize these features. In the long run it would be ideal if the "Tor developers" (in reality, the Tor release managers) could generate this container GPG signed giving users the ability to attest that the binaries have come "directly from the source". This would then allow a user to download updates to the application and trust that the application came from an attested source.
Back to how this works in practice, when a CoreOS update is processed it will reboot to pivot into the new user-land on disk. This means that the application will temporarily go down, but state can maintained on disk. When the host gets back to a state with working networking it can look for an update to the application and pull it down (re-attesting it's source) and resume the running state of the application.
I'm happy to go into more detail, but I'm afraid it would bore the majority of people on the mailing list.
--Brian 'redbeard' Harrington
On 03/13/2016 10:13 PM, Greg wrote:
On Mar 11, 2016 3:51 AM, "nusenu" <nusenu@openmailbox.org mailto:nusenu@openmailbox.org> wrote:
This sounds like a great effort. I wanted to point out 2 things:
- I think that GCE IP addresses are blacklisted (due to an earlier sybil
attack, https://lists.torproject.org/pipermail/tor-relays/2015-August/007656.html).
I don't think it is blacklisted currently (but maybe someone at the dir auth level can confirm that), see also this tor-dev thread:
https://lists.torproject.org/pipermail/tor-dev/2015-August/009389.html
I just read that thread. Thanks for referencing my issue back then! Greg
- How do you see your work relating to and differing from the discontinued
Tor Cloud (https://cloud.torproject.org/) project? I don't mean to discourage you, but I'm curious what the differences are.
cloud.torproject.org http://cloud.torproject.org is dead.
tor-relays mailing list tor-relays@lists.torproject.org mailto: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
Brian, That's all quite interesting. Thanks for sharing. I hope this work goes well. It would help move Tor forward toward the cloud-based software model that's becoming more and more popular. Greg
On Mon, Mar 14, 2016 at 12:29 PM, Brian 'redbeard' Harrington redbeard@coreos.com wrote:
Greg,
Thank *you* for the reminder!
So as far as the GCE note, that's good to know. I'll put a note in some of the documentation about this.
In terms of it's relation to cloud.torproject.org... In a way this pre-dates that, in a way it's new artwork.
Many moons ago (~circa 2007) I was discussing this idea with Roger and Jake at the Non-profit Development Summit in Oakland. Due to a number of factors (impostor syndrome, security concerns, etc) I abandoned the project convinced that someone else would do it.
Moving on a number of years I never abandoned the idea. In fact, in my mind it became a fantastic place to showcase some more recent work I've been involved with.
Over the past two years I have been working with folks on a self-updating Linux distribution called CoreOS. The important parts are that it's been massively stripped down (removing the attack surface), similar to old school Bell UNIX machines the /usr partition operates read only (think of the days of NFS mounted /usr), and the updates are atomically signed images including the kernel, systemd, sshd, glibc, and a very small number of other utilities. All of these updates are pushed out using a mechanism called "Omaha protocol" (https://coreos.com/docs/coreupdate/custom-apps/coreupdate-protocol/) and images are pulled down, undergo GPG validation (and a few other checks) with an embedded key,and are processed. All applications are run inside of Linux containers (systemd-nspawn, rkt, docker, doesn't really matter) to provide both a portable environment and process, mount, and network isolation (to the degree that the administrator chooses).
With some of the more recent work, we've added GPG validation and TPM attestation of the container image as well. This leads to a state where the user can guarantee that the applications executing on a host are attested by a known, trusted entity.m In the short term we (CoreOS) must continue to demonstrate the utility of this. One easy option is of course to provide usable applications atop the platform with a *need* to utilize these features. In the long run it would be ideal if the "Tor developers" (in reality, the Tor release managers) could generate this container GPG signed giving users the ability to attest that the binaries have come "directly from the source". This would then allow a user to download updates to the application and trust that the application came from an attested source.
Back to how this works in practice, when a CoreOS update is processed it will reboot to pivot into the new user-land on disk. This means that the application will temporarily go down, but state can maintained on disk. When the host gets back to a state with working networking it can look for an update to the application and pull it down (re-attesting it's source) and resume the running state of the application.
I'm happy to go into more detail, but I'm afraid it would bore the majority of people on the mailing list.
--Brian 'redbeard' Harrington
On 03/13/2016 10:13 PM, Greg wrote:
On Mar 11, 2016 3:51 AM, "nusenu" nusenu@openmailbox.org wrote:
This sounds like a great effort. I wanted to point out 2 things:
- I think that GCE IP addresses are blacklisted (due to an earlier
sybil attack,
https://lists.torproject.org/pipermail/tor-relays/2015-August/007656.html).
I don't think it is blacklisted currently (but maybe someone at the dir auth level can confirm that), see also this tor-dev thread:
https://lists.torproject.org/pipermail/tor-dev/2015-August/009389.html
I just read that thread. Thanks for referencing my issue back then! Greg
- How do you see your work relating to and differing from the
discontinued Tor Cloud (https://cloud.torproject.org/) project? I don't mean to discourage you, but I'm curious what the differences are.
cloud.torproject.org is dead.
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
On Fri, Mar 11, 2016 at 11:51:23AM +0000, nusenu wrote:
This sounds like a great effort. I wanted to point out 2 things:
- I think that GCE IP addresses are blacklisted (due to an earlier sybil
attack, https://lists.torproject.org/pipermail/tor-relays/2015-August/007656.html).
I don't think it is blacklisted currently (but maybe someone at the dir auth level can confirm that), see also this tor-dev thread:
https://lists.torproject.org/pipermail/tor-dev/2015-August/009389.html
Right, since March 9 we are no longer rejecting relays in the Google cloud.
Cheers, Philipp
On 9 Mar 2016, at 09:29, nusenu nusenu@openmailbox.org wrote:
- maybe run without DirPort so you do not become HSDir for to many HSes
Hmm, I don't think that this will work as you expect. As of 0.2.7, every relay advertises that it will be a hidden service directory (regardless of whether it has a DirPort or not). This used be controlled by the HidServDirV2 option, but that's now obsolete.
See ticket 16543 and commit 2f8cf524b.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
By setting "DirPort: 0" the relays wont get flaged as Dir. So: Should be set to 0 in this case, no?
Am Sonntag, 20. März 2016 02:54 schrieb Tim Wilson-Brown - teor teor2345@gmail.com:
On 9 Mar 2016, at 09:29, nusenu nusenu@openmailbox.org wrote:
- maybe run without DirPort so you do not become HSDir for to many
HSes
Hmm, I don't think that this will work as you expect. As of 0.2.7, every relay advertises that it will be a hidden service directory (regardless of whether it has a DirPort or not). This used be controlled by the HidServDirV2 option, but that's now obsolete. See ticket 16543 and commit 2f8cf524b. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
On 21 Mar 2016, at 21:32, tor-server-creator@use.startmail.com wrote:
By setting "DirPort: 0" the relays wont get flaged as Dir. So: Should be set to 0 in this case, no?
In 0.2.8, every relay is potentially a hidden service directory and a directory mirror. Clients tunnel directory connections through the ORPort. So the only thing that changes when you set the DirPort to 0 is that the port isn't opened.
The details are:
Hidden Service Directories (HSDir) and Directory Mirrors (V2Dir) are independent functions, with different consensus flags.
HSDir:
Since 0.2.7, all relays, (even if the have no DirPort) advertise in their descriptor that they are willing to be a hidden service directory. Then the authorities impose minimum uptime and bandwidth requirements for the HSDir flag. Then clients use this flag to decide whether to ask for hidden service descriptors from the relay.
Directory Mirrors:
In 0.2.8, almost all relays, (even if the have no DirPort) advertise in their descriptor that they are willing to accept directory connections tunnelled over their ORPort. Then 0.2.8 clients use this part of the descriptor to decide whether to make tunnelled directory connections to relays, even if they don't have the V2Dir flag.
In all current releases, relays with a DirPort advertise they support the version 2 directory protocol, and then the authorities impose requirements and assign the V2Dir flag. Then clients use this flag to decide whether to make tunnelled directory connections to relays.
Direct DirPort Use:
Some obscure client configurations and firewalled clients may use the DirPort directly. We're looking to fix that so all client connections (and bridge connections, for consistency) are tunnelled.
Relays use the DirPort directly, but they typically use the authorities for directory documents. (Some obscure relay configurations will use the fallback directory mirrors.)
Tim
Am Sonntag, 20. März 2016 02:54 schrieb Tim Wilson-Brown - teor teor2345@gmail.com:
On 9 Mar 2016, at 09:29, nusenu <nusenu@openmailbox.org mailto:nusenu@openmailbox.org> wrote:
- maybe run without DirPort so you do not become HSDir for to many HSes
Hmm, I don't think that this will work as you expect. As of 0.2.7, every relay advertises that it will be a hidden service directory (regardless of whether it has a DirPort or not). This used be controlled by the HidServDirV2 option, but that's now obsolete.
See ticket 16543 and commit 2f8cf524b.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Tim Wilson-Brown - teor:
In 0.2.8, every relay is potentially a hidden service directory and a directory mirror.
But with this configuration :
# 20 TB/month: echo "20 * 1024^4 / 31 / 24 / 60 / 60 / 1024^2" | bc # == 8017 # #BandwidthRate 8 MB AccountingMax 20 TB
no directories are served, or ?
- -- Toralf PGP: C4EACDDE 0076E94E, OTR: 420E74C8 30246EE7
On 22 Mar 2016, at 04:22, Toralf Förster toralf.foerster@gmx.de wrote:
Signed PGP part Tim Wilson-Brown - teor:
In 0.2.8, every relay is potentially a hidden service directory and a directory mirror.
But with this configuration :
# 20 TB/month: echo "20 * 1024^4 / 31 / 24 / 60 / 60 / 1024^2" | bc # == 8017 # #BandwidthRate 8 MB AccountingMax 20 TB
no directories are served, or ?
I did say "almost all relays" later in my email, but I didn't explain the details - sorry!
AccountingMax disables directory mirroring: * if the relay thinks it's likely to be exceeded, or doesn't know (the first period); and * if the AccountingRule is not "in".
Relays with very low bandwidth also disable directory mirroring.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Tim Wilson-Brown - teor:
- if the AccountingRule is not "in".
Thx for the explanation - the above I do not understood - may I ask what "in" means in detail ?
- -- Toralf PGP: C4EACDDE 0076E94E, OTR: 420E74C8 30246EE7
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Tim Wilson-Brown - teor:
- if the AccountingRule is not "in".
Ah, AccountingRule in was meant. I did not set that config option in the past due to the impact of network-in-attacks as is seen in [1].
Because I do have to pay just for outgoing connections I was already looking for AccountingRule out in the past - is the config option implemented in 0.2.8.1-alpha ?
[1] https://www.zwiebeltoralf.de/torserver/ddos_sysstat_example.txt
- -- Toralf PGP: C4EACDDE 0076E94E, OTR: 420E74C8 30246EE7
On 22 Mar 2016, at 08:14, Toralf Förster toralf.foerster@gmx.de wrote:
Signed PGP part Tim Wilson-Brown - teor:
- if the AccountingRule is not "in".
Ah, AccountingRule in was meant. I did not set that config option in the past due to the impact of network-in-attacks as is seen in [1].
Because I do have to pay just for outgoing connections I was already looking for AccountingRule out in the past - is the config option implemented in 0.2.8.1-alpha ?
Yes, t's in 0.2.8.1-alpha, but 0.2.8.1-alpha is unstable for relays. Please wait for 0.2.8.2.
[[AccountingRule]] **AccountingRule** **sum**|**max**|**in**|**out**:: How we determine when our AccountingMax has been reached (when we should hibernate) during a time interval. Set to "max" to calculate using the higher of either the sent or received bytes (this is the default functionality). Set to "sum" to calculate using the sent plus received bytes. Set to "in" to calculate using only the received bytes. Set to "out" to calculate using only the sent bytes. (Default: max)
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
tor-relays@lists.torproject.org
-
Brian 'redbeard' Harrington -
Greg -
nusenu -
Philipp Winter -
Tim Wilson-Brown - teor -
tor-server-creator＠use.startmail.com -
Toralf Förster