nanog mailing list archives
Re: WIndows Updates Fail Via IPv6 - Update!
From: Saku Ytti <saku () ytti fi>
Date: Thu, 7 Mar 2019 20:52:35 +0200
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
Current thread:
- Re: WIndows Updates Fail Via IPv6 - Update!, (continued)
- Re: WIndows Updates Fail Via IPv6 - Update! Saku Ytti (Mar 04)
- Re: WIndows Updates Fail Via IPv6 - Update! Rich Kulawiec (Mar 05)
- Re: WIndows Updates Fail Via IPv6 - Update! Saku Ytti (Mar 05)
- RE: WIndows Updates Fail Via IPv6 - Update! adamv0025 (Mar 05)
- Re: WIndows Updates Fail Via IPv6 - Update! Saku Ytti (Mar 05)
- RE: WIndows Updates Fail Via IPv6 - Update! adamv0025 (Mar 07)
- Re: WIndows Updates Fail Via IPv6 - Update! Saku Ytti (Mar 07)
- RE: WIndows Updates Fail Via IPv6 - Update! adamv0025 (Mar 07)
- Re: WIndows Updates Fail Via IPv6 - Update! Saku Ytti (Mar 07)
- Re: WIndows Updates Fail Via IPv6 - Update! Stephen Satchell (Mar 07)
- Re: WIndows Updates Fail Via IPv6 - Update! Saku Ytti (Mar 07)
- Re: WIndows Updates Fail Via IPv6 - Update! Martin Hannigan (Mar 05)
- Re: WIndows Updates Fail Via IPv6 - Update! Fernando Gont (Mar 05)
- Re: WIndows Updates Fail Via IPv6 - Update! Mark Andrews (Mar 05)
- Re: WIndows Updates Fail Via IPv6 - Update! Fernando Gont (Mar 05)
- Re: WIndows Updates Fail Via IPv6 - Update! Mark Andrews (Mar 05)
- Re: WIndows Updates Fail Via IPv6 - Update! Fernando Gont (Mar 05)
- Re: WIndows Updates Fail Via IPv6 - Update! Mark Tinka (Mar 06)
- Re: WIndows Updates Fail Via IPv6 - Update! Mark Tinka (Mar 06)
- Re: WIndows Updates Fail Via IPv6 - Update! Jeroen Massar (Mar 04)
- Re: WIndows Updates Fail Via IPv6 - Update! Mark Tinka (Mar 03)