The brief survey I put out a couple weeks ago has gotten 34 responses. The response rate seems to be tailing off, so I've closed the survey. Here's a summary of results. First, the simple things: -- All but one respondent is an Atlas probe host. -- Respondents preferred source to binary release 26:4 (4 abstentions) The responses as to reasons for wanting the Atlas platform opened up are a little more challenging to read. There were four options that respondents, from which respondents could choose as many as they wanted. 0 - I'm not interested in RIPE NCC releasing the Atlas firmware 1 - So that parties other than RIPE to build probes that can feed into the Atlas system 2 - So that I can easily build Atlas-like probes for my own, independent measurement network 3 - So that I can re-use some Atlas features for a non-measurement-related purpose The response patterns, ordered by frequency Pattern Frequency 1 8 2+3 6 0 5 1+2 3 1+2+3 3 2 3 3 1 (who noted: "I don't care too much") Respondents could also fill in an "other" response for their reason. There were two major themes to these responses: -- Security, in the sense both of making the device more secure, and of assuring probe hosts of what the device is doing -- Contributions, i.e., that the community could contribute to probe development One respondent also noted in an "other" response that responses 1 and 2 are not necessarily mutually exclusive; a modified probe could feed both the RIPE system and a private system. Analyze as you will :) --Richard
"Richard L. Barnes" <rbarnes@bbn.com> writes:
Analyze as you will :)
One thing that strikes me from the discussion has been an absence of answers to this question: What would reasons be to _not_ release the source code? I believe that unless there is a strong reason not to release the source, it should be done because there is interest in it and there is potential to get improvements out of it. One reason could be that the current security architecture is based on obscurity, but that discussion wasn't conclusive if I remember correctly. In that case, releasing things gradually might be a good compromise, so that people can contribute a better security architecture. /Simon
On 1/4/12 16:11 , Simon Josefsson wrote:
"Richard L. Barnes"<rbarnes@bbn.com> writes:
Analyze as you will :) One thing that strikes me from the discussion has been an absence of answers to this question: What would reasons be to _not_ release the source code?
I believe that unless there is a strong reason not to release the source, it should be done because there is interest in it and there is potential to get improvements out of it.
There are some non-technical arguments that I won't list here. One argument for not releasing is security by obscurity. It is easier to find security holes if you can just download the source. Instead of trying to obtain a probe, getting the firmware out of it and decompiling the binaries. In short, within RIPE NCC the question needs to be answered whether the source can released as is, or whether a security audit is required. Needless to say, a security audit is likely to cost money. Dumping the source just as a tar file on a web site is easy. But that will be one way communication. And most likely fork the project. Not good. If you want to turn it into an open source project, then a lot of stuff has to happen. In particular, the project has to be mature enough that it can actually be installed without too much pain. Of course, this costs time and money.
As the survey shows, and as Simon just stated, I do not think that security through obscurity is the way to go, provided the nature of this volunteering measurement platform. However, it is not all that simple, IMHO. I particularly support the idea of releasing the source code gradually, even under temporary NDAs if necessary, in order to improve the security of probe or controllers by getting the code audited by more people. Enhancing the system by introducing more features (different traceroute algorithms and options) or polishing the existing ones (IPv6 support, which is currently limited by the busybox version probes are running atm, IIRC) is something possible and desirable, if we dont forget that its Atlas itself what has to improve. I personally do not endorse the creation of further parallel, *public* measurement platforms. This is a hairy topic that guarantees a nice discussion on its own thread or meeting, but if I had to say something, I would say Atlas is doing pretty well and that a hybrid model allowing independent probes to join in a controlled fashion (as it has already been suggested) making Atlas grow... that'd be the way to go. There are way too many factors to consider here (tampering, tweaking, faking, validating the measurement results; reasearch interest in the measurements performed and archived data, how to deal with that possible variety of measurement types...) and so a single post is clearly not enough to elaborate, so... please take it with a grain of salt. Philip has been able to articulate my ideas much better than myself, so I will simply +1 his educated points: On Wed, Jan 4, 2012 at 4:45 PM, Philip Homburg <philip.homburg@ripe.net> wrote:
On 1/4/12 16:11 , Simon Josefsson wrote:
"Richard L. Barnes"<rbarnes@bbn.com> writes:
Analyze as you will :)
One thing that strikes me from the discussion has been an absence of answers to this question: What would reasons be to _not_ release the source code?
I believe that unless there is a strong reason not to release the source, it should be done because there is interest in it and there is potential to get improvements out of it.
There are some non-technical arguments that I won't list here.
One argument for not releasing is security by obscurity. It is easier to find security holes if you can just download the source. Instead of trying to obtain a probe, getting the firmware out of it and decompiling the binaries. In short, within RIPE NCC the question needs to be answered whether the source can released as is, or whether a security audit is required. Needless to say, a security audit is likely to cost money.
Dumping the source just as a tar file on a web site is easy. But that will be one way communication. And most likely fork the project. Not good.
+1 I couldnt be more openly against unnecessary forks.
If you want to turn it into an open source project, then a lot of stuff has to happen. In particular, the project has to be mature enough that it can actually be installed without too much pain. Of course, this costs time and money.
+1 Its always good to deal with any subject around Atlas, but perhaps it is not the _optimal_ moment to release the source, to say the least.
On 1/4/12 17:07 , Iñigo Ortiz de Urbina wrote:
As the survey shows, and as Simon just stated, I do not think that security through obscurity is the way to go, provided the nature of this volunteering measurement platform. However, it is not all that simple, IMHO. I particularly support the idea of releasing the source code gradually, even under temporary NDAs if necessary, in order to improve the security of probe or controllers by getting the code audited by more people.
Doing stuff under NDA is of course something completely different.
Enhancing the system by introducing more features (different traceroute algorithms and options) or polishing the existing ones (IPv6 support, which is currently limited by the busybox version probes are running atm, IIRC) is something possible and desirable, if we dont forget that its Atlas itself what has to improve.
We are not limited by any code we already have. In particular, we are not saying: we cannot do this or that because it is not in busybox. The probes are out there and we want to make the most of them. So if you have any ideas on what kind of measurements are worth doing that we currently cannot do, please let us know, in particular, make sure that Vesna or Ann keep track of what you want. :-)
Hi, On 05.01.2012 00:23, Philip Homburg wrote:
So if you have any ideas on what kind of measurements are worth doing that we currently cannot do, please let us know, in particular, make sure that Vesna or Ann keep track of what you want. :-)
Test the respond-time of services like DNS and http. Maybe even checking the reply. ICMP-Echo is blocking by our central firewall :( -- Jens Weibler IT-Services Hochschule Darmstadt www.h-da.de University of Applied Sciences Fachbereich Informatik www.fbi.h-da.de Schöfferstr. 8b D-64295 Darmstadt Tel +49 6151 16-8425 Fax +49 6151 16-8935 jens.weibler@h-da.de
Test the respond-time of services like DNS and http. Maybe even checking the reply.
ICMP-Echo is blocking by our central firewall :(
And some top-level dns servers block icmp echo too so stats by icmp echo are not right thing to do. dns response time would be better way to measure root dns servers. -- Tuomo Soini <tis@foobar.fi> Foobar Linux services +358 40 5240030 Foobar Oy <http://foobar.fi/>
On 1/5/12 0:51 , Jens Weibler wrote:
Hi,
On 05.01.2012 00:23, Philip Homburg wrote:
So if you have any ideas on what kind of measurements are worth doing that we currently cannot do, please let us know, in particular, make sure that Vesna or Ann keep track of what you want. :-)
Test the respond-time of services like DNS and http. Maybe even checking the reply.
The probe firmware can do that already :-) The problem with DNS is that switching would break the historical continuity (for the measurements of the DNS root servers). For UDM, it depends on when there is time to add more features. Enabling http in UDM has a security risk, so that will take even more time.
Morning everyone On Thu, Jan 5, 2012 at 12:23 AM, Philip Homburg <philip.homburg@ripe.net> wrote:
On 1/4/12 17:07 , Iñigo Ortiz de Urbina wrote:
As the survey shows, and as Simon just stated, I do not think that security through obscurity is the way to go, provided the nature of this volunteering measurement platform. However, it is not all that simple, IMHO. I particularly support the idea of releasing the source code gradually, even under temporary NDAs if necessary, in order to improve the security of probe or controllers by getting the code audited by more people.
Doing stuff under NDA is of course something completely different.
Enhancing the system by introducing more features (different traceroute algorithms and options) or polishing the existing ones (IPv6 support, which is currently limited by the busybox version probes are running atm, IIRC) is something possible and desirable, if we dont forget that its Atlas itself what has to improve.
We are not limited by any code we already have. In particular, we are not saying: we cannot do this or that because it is not in busybox. The probes are out there and we want to make the most of them.
This is good to hear. I was meaning that according to the FAQ, there seems to be something around IPv6 (not affecting ping6 or traceroute6). See: " Q: I have an IPv6-only network. Will the probe work on it? A: Although the probe itself is IPv6-ready in general, some of the off-the-shelf software components on it are not (yet). We hope that this will be resolved soon, but until then the probe needs IPv4 to communicate with our infrastructure. The measurements themselves can run on IPv6. "
So if you have any ideas on what kind of measurements are worth doing that we currently cannot do, please let us know, in particular, make sure that Vesna or Ann keep track of what you want. :-)
Sure, so far they both have been very kind and responsive to user feedback :-) But, as Jens already jumped in, I want to support his comments on adding DNS or HTTP checks. Sometimes ICMP cant be unfiltered, or the user experience is degraded due to HTTP, DNS response times themselves, and not the latency.
On 1/5/12 9:26 , Iñigo Ortiz de Urbina wrote:
This is good to hear. I was meaning that according to the FAQ, there seems to be something around IPv6 (not affecting ping6 or traceroute6). See: " Q: I have an IPv6-only network. Will the probe work on it? A: Although the probe itself is IPv6-ready in general, some of the off-the-shelf software components on it are not (yet). We hope that this will be resolved soon, but until then the probe needs IPv4 to communicate with our infrastructure. The measurements themselves can run on IPv6. " The main limiting factor is DNS. For static configurations it should work.
For normal (dynamic) configuration, the problem is that we have no support for either DHCPv6 or the DNS resolver option in RA. So without IPv4, the probe will not have a DNS resolver. But I guess the FAQ needs to be updated to say that it can be made to work with static configuration.
But, as Jens already jumped in, I want to support his comments on adding DNS or HTTP checks. Sometimes ICMP cant be unfiltered, or the user experience is degraded due to HTTP, DNS response times themselves, and not the latency. For DNS it is just a matter of adding it to the user interface. Http requires a policy decision on how to avoid getting probe hosts in trouble.
On Thu, Jan 5, 2012 at 1:11 PM, Philip Homburg <philip.homburg@ripe.net> wrote:
On 1/5/12 9:26 , Iñigo Ortiz de Urbina wrote:
This is good to hear. I was meaning that according to the FAQ, there seems to be something around IPv6 (not affecting ping6 or traceroute6). See: " Q: I have an IPv6-only network. Will the probe work on it? A: Although the probe itself is IPv6-ready in general, some of the off-the-shelf software components on it are not (yet). We hope that this will be resolved soon, but until then the probe needs IPv4 to communicate with our infrastructure. The measurements themselves can run on IPv6. "
The main limiting factor is DNS. For static configurations it should work.
For normal (dynamic) configuration, the problem is that we have no support for either DHCPv6 or the DNS resolver option in RA. So without IPv4, the probe will not have a DNS resolver.
But I guess the FAQ needs to be updated to say that it can be made to work with static configuration.
Thank you so much for making these points clear. I'd like to suggest this addition to the FAQ, it can be used as a draft to start from: " Although the probe itself is IPv6-ready in general, some of the off-the-shelf software components on it are not (yet). More particularly, current firmware does not support DHCPv6 (RFC3345) or DNS resolver option in RA (RFC6106) and thus no way of dynamically acquiring DNS information to function properly. We hope that this will be resolved soon, but until then the probe needs IPv4 to communicate with our infrastructure, unless full IPv6 configuration is performed manually. The measurements themselves can run on IPv6. "
But, as Jens already jumped in, I want to support his comments on adding DNS or HTTP checks. Sometimes ICMP cant be unfiltered, or the user experience is degraded due to HTTP, DNS response times themselves, and not the latency.
For DNS it is just a matter of adding it to the user interface. Http requires a policy decision on how to avoid getting probe hosts in trouble.
My particular use case would require HTTP probing first, rather than DNS probing. Both of them are interesting for many scenarios, though. Have a nice day,
Hi, On 05.01.2012 13:11, Philip Homburg wrote:
On 1/5/12 9:26 , Iñigo Ortiz de Urbina wrote:
This is good to hear. I was meaning that according to the FAQ, there seems to be something around IPv6 (not affecting ping6 or traceroute6). See: " Q: I have an IPv6-only network. Will the probe work on it? A: Although the probe itself is IPv6-ready in general, some of the off-the-shelf software components on it are not (yet). We hope that this will be resolved soon, but until then the probe needs IPv4 to communicate with our infrastructure. The measurements themselves can run on IPv6. " The main limiting factor is DNS. For static configurations it should work.
For normal (dynamic) configuration, the problem is that we have no support for either DHCPv6 or the DNS resolver option in RA. So without IPv4, the probe will not have a DNS resolver.
maybe while waiting for an implementation of dhcpv6 or dns option in RA for the nodes you could simple use |fec0:0:0:ffff::1 as fallback. Well, it's deprecated but used in a well known OS.. Just an idea, no need for me - I've got ipv4+ipv6 for my node ;) |// -- Jens Weibler IT-Services Hochschule Darmstadt www.h-da.de University of Applied Sciences Fachbereich Informatik www.fbi.h-da.de Schöfferstr. 8b D-64295 Darmstadt Tel +49 6151 16-8425 Fax +49 6151 16-8935 jens.weibler@h-da.de
On Wed, Jan 04, 2012 at 05:07:10PM +0100, Iñigo Ortiz de Urbina <inigo@infornografia.net> wrote a message of 81 lines which said:
I personally do not endorse the creation of further parallel, *public* measurement platforms.
They already exist (SamKnows, Grenouille, Bismark) so what's the point? Whether you endorse it or not, it happens. I am involved in a national measurement project in France <http://www.arcep.fr/index.php?id=8571&tx_gsactualite_pi1[uid]=1469&tx_gsactualite_pi1[backID]=1&cHash=a1c027a224> and Atlas is considered for the implementation but, of course, not being able to modify Atlas is a no-no.
On 05.01.2012, at 15:49, Stephane Bortzmeyer wrote:
On Wed, Jan 04, 2012 at 05:07:10PM +0100, Iñigo Ortiz de Urbina <inigo@infornografia.net> wrote a message of 81 lines which said:
I personally do not endorse the creation of further parallel, *public* measurement platforms.
They already exist (SamKnows, Grenouille, Bismark) so what's the point? Whether you endorse it or not, it happens. I am involved in a national measurement project in France <http://www.arcep.fr/index.php?id=8571&tx_gsactualite_pi1[uid]=1469&tx_gsactualite_pi1[backID]=1&cHash=a1c027a224> and Atlas is considered for the implementation but, of course, not being able to modify Atlas is a no-no.
Stephane, while we are not ready to open-source RIPE Atlas we are very interested to cooperate with initiatives like this provided that the data gathered is shared for the benefit of the RIPE community. Of course such cooperation can very well include transfer or exchange of technology. But we have to be sure that the RIPE community benefits from the cooperation. Maybe we should discuss this further privately? Cordialment Daniel NB: I believe in open software and I have been contributing before the term even existed. But that does not mean that it useful in all cases at all times.
On Wed, Jan 04, 2012 at 04:45:03PM +0100, Philip Homburg <philip.homburg@ripe.net> wrote a message of 33 lines which said:
Dumping the source just as a tar file on a web site is easy. But that will be one way communication. And most likely fork the project. Not good.
That's a very strange argument. Nobody asked the RIPE-NCC to spend money and time on doing a perfect tarball, complete with correct README, INSTALL and Makefile (or configure.ac). Yes, just dump the source, it will be a good step in the right direction and it will help in at least one use case (learn how the box works). One of the alternatives, Grenouille <http://git.grenouille.com/>, is currently at this step (code, zero doc). The argument about the fork is also very 20th century. The entire point of free software is the ability to use it... freely and of course this freedom implies the right to fork (whether it is a good idea or not is a separate topic).
If you want to turn it into an open source project, then a lot of stuff has to happen.
No.
In particular, the project has to be mature enough that it can actually be installed without too much pain.
No. Nobody requested a perfect system.
participants (8)
-
Daniel Karrenberg -
Iñigo Ortiz de Urbina -
Jens Weibler -
Philip Homburg -
Richard L. Barnes -
Simon Josefsson -
Stephane Bortzmeyer -
Tuomo Soini