Protocol/Technology testing?
Hello, Are there any plans to extend the Atlas probe's functionality from simple Pings to more sophisticated testing? For example: Can actual payloads be transferred (http, ftp, SMTP, NNTP etc.) and with which parameters? Is encryption available (https, ssh, starttls, etc.)? Some countries and/or ISPs restrict what users can do. Currently, Iran is inhibiting all encrypted international connection. For the users on the ground this is horrible - no gmail, no yahoo, no online banking, no Tor network - no proivacy! Yet on the Atlas network everything seems to be fine, as pings still work. (However, only one of the six probes is online, the rest has been offline for weeks. And the one that is online was offline for weeks until a few days ago. I'm not sure what the issue is there.) It would be good to know if some protocols are not available in a certain jurisdiction. Of course, such tests could be done at a much lower rate than Pings - some maybe every hour, others every couple of hours. Then again, the probes might not be mighty enough? BR Daniel AJ -- Follow me on twitter @newstik http://twitter.com/newstik
Question for you: RFC 4884 says that ICMP/ICMPv6 define an Echo Request/Reply message, but as I read it doesn't permit the use of that structure with the Echo Request or Reply. It seems like RFC 4884 would help in this context. For example, if Atlas Probes and their servers use NTP to synchronize time, an Echo Request could contain the time the message was sent, and the service could deduce one-way delay. The response could similarly include a timestamp, the probe could calculate one-way delay, and report the time and delta-time of that response in its next request. Additionally, the service could command a probe to additionally traceroute to another probe, and the probe could later report its experience. What would it take to facilitate the use of RFC 4884 extensions with ICMP/ICMPv6? On Feb 12, 2012, at 1:00 AM, Daniel AJ Sokolov wrote:
Hello,
Are there any plans to extend the Atlas probe's functionality from simple Pings to more sophisticated testing?
For example: Can actual payloads be transferred (http, ftp, SMTP, NNTP etc.) and with which parameters? Is encryption available (https, ssh, starttls, etc.)?
Some countries and/or ISPs restrict what users can do.
Currently, Iran is inhibiting all encrypted international connection. For the users on the ground this is horrible - no gmail, no yahoo, no online banking, no Tor network - no proivacy!
Yet on the Atlas network everything seems to be fine, as pings still work. (However, only one of the six probes is online, the rest has been offline for weeks. And the one that is online was offline for weeks until a few days ago. I'm not sure what the issue is there.)
It would be good to know if some protocols are not available in a certain jurisdiction. Of course, such tests could be done at a much lower rate than Pings - some maybe every hour, others every couple of hours.
Then again, the probes might not be mighty enough?
BR Daniel AJ
-- Follow me on twitter @newstik http://twitter.com/newstik
On 2/13/12 4:22 , Fred Baker wrote:
Question for you:
RFC 4884 says that ICMP/ICMPv6 define an Echo Request/Reply message, but as I read it doesn't permit the use of that structure with the Echo Request or Reply. It seems like RFC 4884 would help in this context.
For example, if Atlas Probes and their servers use NTP to synchronize time, an Echo Request could contain the time the message was sent, and the service could deduce one-way delay. The response could similarly include a timestamp, the probe could calculate one-way delay, and report the time and delta-time of that response in its next request. Additionally, the service could command a probe to additionally traceroute to another probe, and the probe could later report its experience.
What would it take to facilitate the use of RFC 4884 extensions with ICMP/ICMPv6?
At the moment, the Atlas system does not include targets with special software. We rely only on well defined protocols that are up and running on the Internet. Note that for time measurements, we could just use the ntp packet format. At the moment, the probes also do not run ntpd. The current time synchronization is in the order of seconds. So for one-way delay measurements, the first step would be to enable ntp on the probes and see if on the whole the synchronization distance is low enough that these kinds of measurements would make sense.
On 02/12/2012 10:22 PM, Fred Baker wrote:
Question for you:
RFC 4884 says that ICMP/ICMPv6 define an Echo Request/Reply message, but as I read it doesn't permit the use of that structure with the Echo Request or Reply. It seems like RFC 4884 would help in this context.
For example, if Atlas Probes and their servers use NTP to synchronize time, an Echo Request could contain the time the message was sent, and the service could deduce one-way delay. The response could similarly include a timestamp, the probe could calculate one-way delay, and report the time and delta-time of that response in its next request. Additionally, the service could command a probe to additionally traceroute to another probe, and the probe could later report its experience.
What would it take to facilitate the use of RFC 4884 extensions with ICMP/ICMPv6?
It's been 5 years since I thought about any of this but I think the way to parse the text in section 4 is that the ECHO Request and Reply messages fall into the category of:
Many ICMP messages are extensible as currently defined. Protocol designers can extend ICMP messages by simply appending fields or data structures to them.
I _think_ the idea was that the existing <Data> field in the ECHO messages could be replaced with an extension structure, which would be validated using the checksum. I don't know why this wasn't spelled out more explicitly, since technically responding to or updating the extension would be in violation of the text :
The data received in the echo message must be returned in the echo reply message.
in 792 or
Data The data from the invoking Echo Request message. in 4443
Maybe because changing that behavior would be beyond the scope of 4884.
On Feb 12, 2012, at 1:00 AM, Daniel AJ Sokolov wrote:
Hello,
Are there any plans to extend the Atlas probe's functionality from simple Pings to more sophisticated testing?
For example: Can actual payloads be transferred (http, ftp, SMTP, NNTP etc.) and with which parameters? Is encryption available (https, ssh, starttls, etc.)?
Some countries and/or ISPs restrict what users can do.
Currently, Iran is inhibiting all encrypted international connection. For the users on the ground this is horrible - no gmail, no yahoo, no online banking, no Tor network - no proivacy!
Yet on the Atlas network everything seems to be fine, as pings still work. (However, only one of the six probes is online, the rest has been offline for weeks. And the one that is online was offline for weeks until a few days ago. I'm not sure what the issue is there.)
It would be good to know if some protocols are not available in a certain jurisdiction. Of course, such tests could be done at a much lower rate than Pings - some maybe every hour, others every couple of hours.
Then again, the probes might not be mighty enough?
BR Daniel AJ
-- Follow me on twitter @newstik http://twitter.com/newstik
Hi Dan, On 2/13/2012 8:15 AM, Dan Tappan wrote:
On 02/12/2012 10:22 PM, Fred Baker wrote:
Question for you:
RFC 4884 says that ICMP/ICMPv6 define an Echo Request/Reply message, but as I read it doesn't permit the use of that structure with the Echo Request or Reply. It seems like RFC 4884 would help in this context.
For example, if Atlas Probes and their servers use NTP to synchronize time, an Echo Request could contain the time the message was sent, and the service could deduce one-way delay. The response could similarly include a timestamp, the probe could calculate one-way delay, and report the time and delta-time of that response in its next request. Additionally, the service could command a probe to additionally traceroute to another probe, and the probe could later report its experience.
What would it take to facilitate the use of RFC 4884 extensions with ICMP/ICMPv6?
It's been 5 years since I thought about any of this but I think the way to parse the text in section 4 is that the ECHO Request and Reply messages fall into the category of:
Many ICMP messages are extensible as currently defined. Protocol designers can extend ICMP messages by simply appending fields or data structures to them.
I _think_ the idea was that the existing <Data> field in the ECHO messages could be replaced with an extension structure, which would be validated using the checksum. I don't know why this wasn't spelled out more explicitly, since technically responding to or updating the extension would be in violation of the text :
The data received in the echo message must be returned in the echo reply message.
in 792 or
Data The data from the invoking Echo Request message. in 4443
Maybe because changing that behavior would be beyond the scope of 4884.
If I remember correctly, additionally, RFC 4884 encountered pushback when we were trying to define an object extension at a fixed location, and therefore we ended up needing to add a "Length" field in the ICMP header. And since Echo / Echo Reply did not have room for a field in the ICMP header, it was out of scope for RFC 4884. Because also RFC 4884 extended error messages that were including part of the original datagram. Thanks, -- Carlos.
On Feb 12, 2012, at 1:00 AM, Daniel AJ Sokolov wrote:
Hello,
Are there any plans to extend the Atlas probe's functionality from simple Pings to more sophisticated testing?
For example: Can actual payloads be transferred (http, ftp, SMTP, NNTP etc.) and with which parameters? Is encryption available (https, ssh, starttls, etc.)?
Some countries and/or ISPs restrict what users can do.
Currently, Iran is inhibiting all encrypted international connection. For the users on the ground this is horrible - no gmail, no yahoo, no online banking, no Tor network - no proivacy!
Yet on the Atlas network everything seems to be fine, as pings still work. (However, only one of the six probes is online, the rest has been offline for weeks. And the one that is online was offline for weeks until a few days ago. I'm not sure what the issue is there.)
It would be good to know if some protocols are not available in a certain jurisdiction. Of course, such tests could be done at a much lower rate than Pings - some maybe every hour, others every couple of hours.
Then again, the probes might not be mighty enough?
BR Daniel AJ
-- Follow me on twitter @newstik http://twitter.com/newstik
Fred, That is correct, RFC 4884 does not allow the use of the extensions in Echo / Echo Reply ICMP messages. Moreover, RFC 4884 only defines the "return path" extensions. However, draft-shen-traceroute-ping-ext was attempting to do just that (among other thing or two) -- to allow extensions on a probe and ability to use them with ICMP. Thanks, -- Carlos. On 2/12/2012 10:22 PM, Fred Baker wrote:
Question for you:
RFC 4884 says that ICMP/ICMPv6 define an Echo Request/Reply message, but as I read it doesn't permit the use of that structure with the Echo Request or Reply. It seems like RFC 4884 would help in this context.
For example, if Atlas Probes and their servers use NTP to synchronize time, an Echo Request could contain the time the message was sent, and the service could deduce one-way delay. The response could similarly include a timestamp, the probe could calculate one-way delay, and report the time and delta-time of that response in its next request. Additionally, the service could command a probe to additionally traceroute to another probe, and the probe could later report its experience.
What would it take to facilitate the use of RFC 4884 extensions with ICMP/ICMPv6?
On Feb 12, 2012, at 1:00 AM, Daniel AJ Sokolov wrote:
Hello,
Are there any plans to extend the Atlas probe's functionality from simple Pings to more sophisticated testing?
For example: Can actual payloads be transferred (http, ftp, SMTP, NNTP etc.) and with which parameters? Is encryption available (https, ssh, starttls, etc.)?
Some countries and/or ISPs restrict what users can do.
Currently, Iran is inhibiting all encrypted international connection. For the users on the ground this is horrible - no gmail, no yahoo, no online banking, no Tor network - no proivacy!
Yet on the Atlas network everything seems to be fine, as pings still work. (However, only one of the six probes is online, the rest has been offline for weeks. And the one that is online was offline for weeks until a few days ago. I'm not sure what the issue is there.)
It would be good to know if some protocols are not available in a certain jurisdiction. Of course, such tests could be done at a much lower rate than Pings - some maybe every hour, others every couple of hours.
Then again, the probes might not be mighty enough?
BR Daniel AJ
-- Follow me on twitter @newstik http://twitter.com/newstik
thanks Carlos. attached the newer version of the draft (hasn't been posted), which is under discussion in the int-area list. Regards, - Naiming On Feb 13, 2012, at 6:27 AM, Carlos Pignataro wrote:
Fred,
That is correct, RFC 4884 does not allow the use of the extensions in Echo / Echo Reply ICMP messages. Moreover, RFC 4884 only defines the "return path" extensions.
However, draft-shen-traceroute-ping-ext was attempting to do just that (among other thing or two) -- to allow extensions on a probe and ability to use them with ICMP.
Thanks,
-- Carlos.
On 2/12/2012 10:22 PM, Fred Baker wrote:
Question for you:
RFC 4884 says that ICMP/ICMPv6 define an Echo Request/Reply message, but as I read it doesn't permit the use of that structure with the Echo Request or Reply. It seems like RFC 4884 would help in this context.
For example, if Atlas Probes and their servers use NTP to synchronize time, an Echo Request could contain the time the message was sent, and the service could deduce one-way delay. The response could similarly include a timestamp, the probe could calculate one-way delay, and report the time and delta-time of that response in its next request. Additionally, the service could command a probe to additionally traceroute to another probe, and the probe could later report its experience.
What would it take to facilitate the use of RFC 4884 extensions with ICMP/ICMPv6?
On Feb 12, 2012, at 1:00 AM, Daniel AJ Sokolov wrote:
Hello,
Are there any plans to extend the Atlas probe's functionality from simple Pings to more sophisticated testing?
For example: Can actual payloads be transferred (http, ftp, SMTP, NNTP etc.) and with which parameters? Is encryption available (https, ssh, starttls, etc.)?
Some countries and/or ISPs restrict what users can do.
Currently, Iran is inhibiting all encrypted international connection. For the users on the ground this is horrible - no gmail, no yahoo, no online banking, no Tor network - no proivacy!
Yet on the Atlas network everything seems to be fine, as pings still work. (However, only one of the six probes is online, the rest has been offline for weeks. And the one that is online was offline for weeks until a few days ago. I'm not sure what the issue is there.)
It would be good to know if some protocols are not available in a certain jurisdiction. Of course, such tests could be done at a much lower rate than Pings - some maybe every hour, others every couple of hours.
Then again, the probes might not be mighty enough?
BR Daniel AJ
-- Follow me on twitter @newstik http://twitter.com/newstik
Folks, Considering Daniel's initial question, I don't think that an extension to ICMP will help. Most probably, the solution is for ATLAS nodes to send a more diverse mix of traffic (ICMP, HTTP, HTTPS IPSEC) and report results. While discussion of RFC 4884 and draft-shen was interesting, it doesn't solve Daniel's problem. Ron
-----Original Message----- From: Fred Baker [mailto:fred@cisco.com] Sent: Sunday, February 12, 2012 10:22 PM To: Carlos Pignataro; Dan.Tappan@gmail.com; derhwagan@yahoo.com; Ronald Bonica Cc: ripe-atlas@ripe.net; Daniel AJ Sokolov Subject: Re: [atlas] Protocol/Technology testing?
Question for you:
RFC 4884 says that ICMP/ICMPv6 define an Echo Request/Reply message, but as I read it doesn't permit the use of that structure with the Echo Request or Reply. It seems like RFC 4884 would help in this context.
For example, if Atlas Probes and their servers use NTP to synchronize time, an Echo Request could contain the time the message was sent, and the service could deduce one-way delay. The response could similarly include a timestamp, the probe could calculate one-way delay, and report the time and delta-time of that response in its next request. Additionally, the service could command a probe to additionally traceroute to another probe, and the probe could later report its experience.
What would it take to facilitate the use of RFC 4884 extensions with ICMP/ICMPv6?
On Feb 12, 2012, at 1:00 AM, Daniel AJ Sokolov wrote:
Hello,
Are there any plans to extend the Atlas probe's functionality from simple Pings to more sophisticated testing?
For example: Can actual payloads be transferred (http, ftp, SMTP, NNTP etc.) and with which parameters? Is encryption available (https, ssh, starttls, etc.)?
Some countries and/or ISPs restrict what users can do.
Currently, Iran is inhibiting all encrypted international connection. For the users on the ground this is horrible - no gmail, no yahoo, no online banking, no Tor network - no proivacy!
Yet on the Atlas network everything seems to be fine, as pings still work. (However, only one of the six probes is online, the rest has been offline for weeks. And the one that is online was offline for weeks until a few days ago. I'm not sure what the issue is there.)
It would be good to know if some protocols are not available in a certain jurisdiction. Of course, such tests could be done at a much lower rate than Pings - some maybe every hour, others every couple of hours.
Then again, the probes might not be mighty enough?
BR Daniel AJ
-- Follow me on twitter @newstik http://twitter.com/newstik
On 2012-02-13 19:36 wrote Ronald Bonica:
Considering Daniel's initial question, I don't think that an extension to ICMP will help. Most probably, the solution is for ATLAS nodes to send a more diverse mix of traffic (ICMP, HTTP, HTTPS IPSEC) and report results.
While discussion of RFC 4884 and draft-shen was interesting, it doesn't solve Daniel's problem.
Yes, thank you for pointing that out! BR Daniel AJ -- Follow me on twitter @newstik http://twitter.com/newstik
On 2012-02-13 19:36 wrote Ronald Bonica:
Folks,
Considering Daniel's initial question, I don't think that an extension to ICMP will help. Most probably, the solution is for ATLAS nodes to send a more diverse mix of traffic (ICMP, HTTP, HTTPS IPSEC) and report results.
While discussion of RFC 4884 and draft-shen was interesting, it doesn't solve Daniel's problem.
BTW, my article on the Iran situation has been translated into English: http://www.h-online.com/security/news/item/Reports-Iran-disrupts-secure-inte... FYI Daniel AJ
On 2/12/12 7:00 , Daniel AJ Sokolov wrote:
Are there any plans to extend the Atlas probe's functionality from simple Pings to more sophisticated testing?
At the moment, probes do pings, traceroutes and DNS queries.
For example: Can actual payloads be transferred (http, ftp, SMTP, NNTP etc.) and with which parameters? There is support in the probe firmware for doing more, but it is not enabled in User Defined Measurements. For http it is an open issue whether that is safe. We haven't really thought about ftp, smtp, nttp. Is encryption available (https, ssh, starttls, etc.)?
Probes use ssh to connect to the Atlas infrastructure, but there are no measurements that try to set up an encrypted channel.
Some countries and/or ISPs restrict what users can do.
Currently, Iran is inhibiting all encrypted international connection. For the users on the ground this is horrible - no gmail, no yahoo, no online banking, no Tor network - no proivacy!
Yet on the Atlas network everything seems to be fine, as pings still work. (However, only one of the six probes is online, the rest has been offline for weeks. And the one that is online was offline for weeks until a few days ago. I'm not sure what the issue is there.)
Atlas is not fine. Last time I looked (early this year), all probes in Iran were unable to connect to the infrastructure. They can do measurements, but they cannot report their results over ssh. I'm amazed that one is now connected again.
It would be good to know if some protocols are not available in a certain jurisdiction. Of course, such tests could be done at a much lower rate than Pings - some maybe every hour, others every couple of hours.
Are there more countries than Iran that have this issue? (We implicitly measure ssh, and that doesn't seem to an issue except in Iran)
Yes, there certainly are countries that block certain protocols! See here https://blog.torproject.org/blog/ - there's even a recent post on Iran. However, Iran is far from the only offender. -----Original Message----- From: ripe-atlas-bounces@ripe.net [mailto:ripe-atlas-bounces@ripe.net] On Behalf Of Philip Homburg Sent: Monday, 13 February 2012 21:07 To: ripe-atlas@ripe.net Subject: Re: [atlas] Protocol/Technology testing? On 2/12/12 7:00 , Daniel AJ Sokolov wrote:
Are there any plans to extend the Atlas probe's functionality from simple Pings to more sophisticated testing?
At the moment, probes do pings, traceroutes and DNS queries.
For example: Can actual payloads be transferred (http, ftp, SMTP, NNTP etc.) and with which parameters? There is support in the probe firmware for doing more, but it is not enabled in User Defined Measurements. For http it is an open issue whether that is safe. We haven't really thought about ftp, smtp, nttp. Is encryption available (https, ssh, starttls, etc.)?
Probes use ssh to connect to the Atlas infrastructure, but there are no measurements that try to set up an encrypted channel.
Some countries and/or ISPs restrict what users can do.
Currently, Iran is inhibiting all encrypted international connection. For the users on the ground this is horrible - no gmail, no yahoo, no online banking, no Tor network - no proivacy!
Yet on the Atlas network everything seems to be fine, as pings still work. (However, only one of the six probes is online, the rest has been offline for weeks. And the one that is online was offline for weeks until a few days ago. I'm not sure what the issue is there.)
Atlas is not fine. Last time I looked (early this year), all probes in Iran were unable to connect to the infrastructure. They can do measurements, but they cannot report their results over ssh. I'm amazed that one is now connected again.
It would be good to know if some protocols are not available in a certain jurisdiction. Of course, such tests could be done at a much lower rate than Pings - some maybe every hour, others every couple of hours.
Are there more countries than Iran that have this issue? (We implicitly measure ssh, and that doesn't seem to an issue except in Iran)
participants (8)
-
Carlos Pignataro -
Dan Tappan -
Daniel AJ Sokolov -
Fred Baker -
Naiming Shen -
Philip Homburg -
Robert -
Ronald Bonica