request to enable ICMP echo-reply on rpki.ripe.net?
Hi RIPE NCC, hi all, In today's troubleshooting adventure, an operator experienced difficulty pinpointing where exactly a connectivity issue between them and rpki.ripe.net (193.0.6.138 + 2001:67c:2e8:22::c100:68a) resided. It would be helpful if RIPE NCC reverted disabling responding to ICMP echo requests originating from the Internet. Would it be possible to adjust the firewall settings to accomodate troubleshooting and monitoring? Right now connectivity testing has to be performed directly against the rsync daemon's internet-exposed TCP port (873) - but it would be much cheaper and faster for both the tester and the service hoster if instead ICMP echo requests could be used as an early warning system (rather than the rsync service itself). $ ping -c 6 rpki.ripe.net PING rpki.ripe.net (193.0.6.138): 56 data bytes --- rpki.ripe.net ping statistics --- 6 packets transmitted, 0 packets received, 100.0% packet loss The above test result differs compared to sending echo requests to molamola.ripe.net or manus.authdns.ripe.net. Kind regards, Job
Hello Job, I understand your point. But there is really no big effort to check if Port 873 is working: <host>nc -zvw100 rpki.ripe.net 873 Connection to rpki.ripe.net 873 port [tcp/rsync] succeeded! Let's make a security comparison, if this is really a necessary feature? regards, Kurt Am 05.05.21 um 12:23 schrieb Job Snijders via routing-wg:
Hi RIPE NCC, hi all,
In today's troubleshooting adventure, an operator experienced difficulty pinpointing where exactly a connectivity issue between them and rpki.ripe.net (193.0.6.138 + 2001:67c:2e8:22::c100:68a) resided.
It would be helpful if RIPE NCC reverted disabling responding to ICMP echo requests originating from the Internet. Would it be possible to adjust the firewall settings to accomodate troubleshooting and monitoring?
Right now connectivity testing has to be performed directly against the rsync daemon's internet-exposed TCP port (873) - but it would be much cheaper and faster for both the tester and the service hoster if instead ICMP echo requests could be used as an early warning system (rather than the rsync service itself).
$ ping -c 6 rpki.ripe.net PING rpki.ripe.net (193.0.6.138): 56 data bytes
--- rpki.ripe.net ping statistics --- 6 packets transmitted, 0 packets received, 100.0% packet loss
The above test result differs compared to sending echo requests to molamola.ripe.net or manus.authdns.ripe.net.
Kind regards,
Job
Hi, On Wed, May 05, 2021 at 12:30:01PM +0200, Kurt Kayser wrote:
I understand your point. But there is really no big effort to check if Port 873 is working:
<host>nc -zvw100 rpki.ripe.net 873 Connection to rpki.ripe.net 873 port [tcp/rsync] succeeded!
Let's make a security comparison, if this is really a necessary feature?
So where exactly is the *security* drawback of permitting ICMP echo? But yes, of course, we can all do tcpping instead - which is much more likely to have an adverse effect on the actual service... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
And doesn't as easily let you fuzz things like the MTU for issues. Sent from my TI-99/4a
On May 5, 2021, at 6:33 AM, Gert Doering <gert@space.net> wrote:
But yes, of course, we can all do tcpping instead - which is much more likely to have an adverse effect on the actual service...
Gert, you surely know that every enabled protocol/port is a potential threat. .kurt Am 05.05.21 um 12:32 schrieb Gert Doering:
Hi,
On Wed, May 05, 2021 at 12:30:01PM +0200, Kurt Kayser wrote:
I understand your point. But there is really no big effort to check if Port 873 is working:
<host>nc -zvw100 rpki.ripe.net 873 Connection to rpki.ripe.net 873 port [tcp/rsync] succeeded!
Let's make a security comparison, if this is really a necessary feature? So where exactly is the *security* drawback of permitting ICMP echo?
But yes, of course, we can all do tcpping instead - which is much more likely to have an adverse effect on the actual service...
Gert Doering -- NetMaster
On Wed, May 05, 2021 at 12:52:51PM +0200, Kurt Kayser wrote:
you surely know that every enabled protocol/port is a potential threat.
Sometimes disabling a protocol or port is a potential threat (because hindering troubleshooting efforts harms network stability). RIPE NCC is the only RIR that does not respond to ICMP Echo Requests on their main RPKI service. Kind regards, Job $ ping -c 1 rpki.afrinic.net PING rpki.afrinic.net (196.216.2.26): 56 data bytes 64 bytes from 196.216.2.26: icmp_seq=0 ttl=48 time=183.631 ms --- rpki.afrinic.net ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 183.631/183.631/183.631/0.000 ms $ ping -c 1 rpki.apnic.net PING rpki.apnic.net (203.119.101.18): 56 data bytes 64 bytes from 203.119.101.18: icmp_seq=0 ttl=240 time=315.433 ms --- rpki.apnic.net ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 315.433/315.433/315.433/0.000 ms $ ping -c 1 rpki.lacnic.net PING rpki.lacnic.net (200.3.14.185): 56 data bytes 64 bytes from 200.3.14.185: icmp_seq=0 ttl=49 time=204.922 ms --- rpki.lacnic.net ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 204.922/204.922/204.922/0.000 ms $ ping -c 1 rpki.arin.net ping: Warning: rpki.arin.net has multiple addresses; using 199.71.0.150 PING rpki.arin.net (199.71.0.150): 56 data bytes 64 bytes from 199.71.0.150: icmp_seq=0 ttl=51 time=152.630 ms --- rpki.arin.net ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 152.630/152.630/152.630/0.000 ms
Kurt Kayser <kurt_kayser@gmx.de> writes: Kurt,
you surely know that every enabled protocol/port is a potential threat.
<rant> Yes. Many years ago we had a ping of death implemented in Windows 98(?). And then in some other IP implementations as well. So ping is evil!!1!!! Somebody could easily and with little overhead diagnose problems or just do simple monitoring. The additional overhead of using TCP is absolutely no problem for a modern system! Even if more then half of the users setup a check in their monitoring every minute or so. Please disable ICMP(v6) everywhere! Nobody needs PMTUD, ping and diagnostic messages! And disabling ICMPv6 makes IPv6 networks so much more secure. And we shouldn't stop there. Everybody who wants to access a service should have a written contract to do so. Every connection should be allowed with a packet filter *and* a router ACLs. Also there should be no direct connection to the service itself. Everything has to go through a proxy! Because proxies no any protocol better than the service itself. </rant> Jens -- ---------------------------------------------------------------------------- | Delbrueckstr. 41 | 12051 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@quux.de | --------------- | ----------------------------------------------------------------------------
Security through obscurity isn't security. Even this approach is popular on some places. I don't thing there isn't valid *security* reason to fully block ICMP echo requests on NCC firewalls. This just makes diagnostics of network/connectivity incidents harder (and more unfriendly). In the fact, requests are processed and ICMP responses are sent by firewalls anyway (admin prohibited / packet filtered). - Daniel On 5/5/21 12:52 PM, Kurt Kayser wrote:
Gert,
you surely know that every enabled protocol/port is a potential threat.
.kurt
Am 05.05.21 um 12:32 schrieb Gert Doering:
Hi,
On Wed, May 05, 2021 at 12:30:01PM +0200, Kurt Kayser wrote:
I understand your point. But there is really no big effort to check if Port 873 is working:
<host>nc -zvw100 rpki.ripe.net 873 Connection to rpki.ripe.net 873 port [tcp/rsync] succeeded!
Let's make a security comparison, if this is really a necessary feature? So where exactly is the *security* drawback of permitting ICMP echo?
But yes, of course, we can all do tcpping instead - which is much more likely to have an adverse effect on the actual service...
Gert Doering -- NetMaster
you surely know that every enabled protocol/port is a potential threat.
i don't. yes, some ports might have vulnerable listen()ers. but i am not aware that echo request is one of them. can we not become security hysterical? randy
Sure the most secure system doesn't allow any remote access and is likely turned off. For a networked system having some limited exposure for diagnostics is helpful when you may have hashing or MTU issues to diagnose. One of my carriers had issues yesterday with 1500 frames to specific destinations. Do we want to be able to debug the routing system? Sent from my TI-99/4a
On May 5, 2021, at 6:30 AM, Kurt Kayser <kurt_kayser@gmx.de> wrote:
Hello Job,
I understand your point. But there is really no big effort to check if Port 873 is working:
<host>nc -zvw100 rpki.ripe.net 873 Connection to rpki.ripe.net 873 port [tcp/rsync] succeeded!
Let's make a security comparison, if this is really a necessary feature?
regards,
Kurt
Am 05.05.21 um 12:23 schrieb Job Snijders via routing-wg: Hi RIPE NCC, hi all,
In today's troubleshooting adventure, an operator experienced difficulty pinpointing where exactly a connectivity issue between them and rpki.ripe.net (193.0.6.138 + 2001:67c:2e8:22::c100:68a) resided.
It would be helpful if RIPE NCC reverted disabling responding to ICMP echo requests originating from the Internet. Would it be possible to adjust the firewall settings to accomodate troubleshooting and monitoring?
Right now connectivity testing has to be performed directly against the rsync daemon's internet-exposed TCP port (873) - but it would be much cheaper and faster for both the tester and the service hoster if instead ICMP echo requests could be used as an early warning system (rather than the rsync service itself).
$ ping -c 6 rpki.ripe.net PING rpki.ripe.net (193.0.6.138): 56 data bytes
--- rpki.ripe.net ping statistics --- 6 packets transmitted, 0 packets received, 100.0% packet loss
The above test result differs compared to sending echo requests to molamola.ripe.net or manus.authdns.ripe.net.
Kind regards,
Job
Hi, On Wed, May 05, 2021 at 12:23:15PM +0200, Job Snijders via routing-wg wrote:
In today's troubleshooting adventure, an operator experienced difficulty pinpointing where exactly a connectivity issue between them and rpki.ripe.net (193.0.6.138 + 2001:67c:2e8:22::c100:68a) resided.
It would be helpful if RIPE NCC reverted disabling responding to ICMP echo requests originating from the Internet. Would it be possible to adjust the firewall settings to accomodate troubleshooting and monitoring?
Yes, please. Breaking ICMP(v6) troubleshooting is generally not a nice approach for network-relevant services... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi Job, Our ops team just enabled ICMP echo-reply on rpki.ripe.net <http://rpki.ripe.net/>. Kind regards, Nathalie Trenaman RIPE NCC
Op 5 mei 2021, om 12:23 heeft Job Snijders via routing-wg <routing-wg@ripe.net> het volgende geschreven:
Hi RIPE NCC, hi all,
In today's troubleshooting adventure, an operator experienced difficulty pinpointing where exactly a connectivity issue between them and rpki.ripe.net (193.0.6.138 + 2001:67c:2e8:22::c100:68a) resided.
It would be helpful if RIPE NCC reverted disabling responding to ICMP echo requests originating from the Internet. Would it be possible to adjust the firewall settings to accomodate troubleshooting and monitoring?
Right now connectivity testing has to be performed directly against the rsync daemon's internet-exposed TCP port (873) - but it would be much cheaper and faster for both the tester and the service hoster if instead ICMP echo requests could be used as an early warning system (rather than the rsync service itself).
$ ping -c 6 rpki.ripe.net PING rpki.ripe.net (193.0.6.138): 56 data bytes
--- rpki.ripe.net ping statistics --- 6 packets transmitted, 0 packets received, 100.0% packet loss
The above test result differs compared to sending echo requests to molamola.ripe.net or manus.authdns.ripe.net.
Kind regards,
Job
On Fri, May 07, 2021 at 03:29:44PM +0200, Nathalie Trenaman wrote:
Our ops team just enabled ICMP echo-reply on rpki.ripe.net.
Thank you. Have a good weekend! Kind regards, Job
participants (8)
-
Daniel Suchy -
Gert Doering -
Jared Mauch -
Jens Link -
Job Snijders -
Kurt Kayser -
Nathalie Trenaman -
Randy Bush