On Thu, Mar 7, 2019 at 8:33 PM Stephen Satchell <list@satchell.net> wrote:
OK, OK, so I will continue to rate-limit both, to reasonably high limits on the order of 250/second. Absent a DoS, it allows network operators to use these tools as they should.
My logs show no harm except to attack traffic.
Everything in moderation.
Yes this is fair, all untrusted traffic to control-plane should be limited. But the question was, what about ICMP types you don't know about, like timestamps, is it fair to drop those just because we didn't know about them? What are the risks? Essentially timestamp it's just echo which happens to have timestamp from each side, hard to imagine a threat if ICMP echo is not also considered a threat. And massive benefit in diagnostics if you are able tell that issue is unidirectional and which direction is the culprit. Similarly, what about the ICMP type which doesn't exist yet? Should that be victim of our protection mechanism? This is essentially the reason why we can't introduce new L4 protocols, because Internet is full of networks on autopilot with legacy policies where we drop things we don't know about, without having any specific realised threat or way to test if that threat is still valid. And even if there are threats, remember ICMP echo f00fc7c8, +++ or plethora of crash bugs? We still run ICMP echo, because the diagnostic value exceeds the cost of the risk. What tools and protocols are we missing, because we never specify them as we know they would never work in practice? We have beautiful, expressive, extendible protocols and then operational policies which nullify that. We recently had crash bug in pseudowire LSP ping, but it gives us operational benefits so we'll just address the bug and we will continue using the tool. Threat was realised, but it was lower cost than the cost of losing the tool. -- ++ytti