WIndows Updates Fail Via IPv6 - Update!

Saku Ytti saku at ytti.fi
Thu Mar 7 18:52:35 UTC 2019


On Thu, Mar 7, 2019 at 8:33 PM Stephen Satchell <list at 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



More information about the NANOG mailing list