There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB getting
back to the TCP servers. There are also IDIOTS that deploy load balancers that
DO NOT LOOK INSIDE ICMP messages for redirecting ICMP messages to the correct
back end. There are also IDOITS that rate limit PTB generation to ridiculously
low rates. One should be able to generate PTB at line rate.
Everyone that has configured mss-fix-up has contributed to misunderstanding that
you can block ICMP. It is time we had a flag day to REMOVE mss-fix-up from all
the boxes you control. We need to get PTB working and unfortunately that means
that we need to stop pandering to admins who don’t know how IP is supposed to
work. ICMP is NOT optional.
It would seem IETF's intention is to actually move away from
ICMPv6-based PMTUD, to the extent that is possible. (RFC4821).
Which is not a reason to not fix broken equipment and misconfigured firewalls.
The workarounds are basically there because people deploy broken equipment.
Agreed. That said, it wasn't solved in 30+ years of IPv4. Do you have
hopes it will be different with IPv6?
Make a big enough stink and it will get fixed. People just don’t make enough of
a stink. Use social media. None of the companies with broken firewalls really
want their idiotic practices pointed out in public. Start doing so every time
you see it #STUPIDFIREWALL.
At times, it's fw defaults. Other times, it is admin policies.
RFC4821 seems to signal that the IETF has given up in making ICMP-based
PMTUD work, and aims at a (mostly) ICMP-free PMTUD.
Essentially, when brokenness is widespread, you have to come-up with
workarounds. And when workarounds are sufficiently widespread, there's
less of an incentive to fix the original issue.
Other times, there's a disconnect between with protocol standards,
products, and operational requirements. That's the case of IPv6 EHs.
This is their usability on the public Internet: RFC 7872. And these are
some of the reasons why you get the numbers in RFC 7872:
https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops
Cheers,
I think the (Inter)network is growing a lot faster than we can shame
folk into fixing things.
Mark.
As much as I hate to admit it, I think this is a more realistic approach.
Mark.
My point is, let it break. Don't pre-emptively drop things that you
don't know to be harmful, but where dropping definitely is harmful.
After risk has realised you have more data about the risk. If it has
never realised you have no idea. If we extrapolate this culture of
fear, we will only have HTTPS open, nothing else, and we have to build
then next-gen stuff as an overlay using HTTPS transport.
Hey Saku,
From: Saku Ytti <saku@ytti.fi>
Sent: Thursday, March 7, 2019 3:29 PM
> From past experience my assumptions would be more along the lines of if
it's not mainstream there's a higher likelihood that it might trigger exceptions
in code.
My point is, let it break. Don't pre-emptively drop things that you don't know
to be harmful, but where dropping definitely is harmful.
After risk has realised you have more data about the risk. If it has never
realised you have no idea. If we extrapolate this culture of fear, we will only
have HTTPS open, nothing else, and we have to build then next-gen stuff as
an overlay using HTTPS transport.
Sure I get it it's a very valid and a noble point,
But what you're asking is let it break (yes potentially -it's just probability until it happens) for 1000s of subs just so that one kiddo has a working niche feature, I can already see what board has to say about that -screw that kid we have money to make there's our brand at stake (yes again just potentially -it's just probability until it actually happens) -but you'll already know what they're gonna say.
So yes on a technical level I agree with you, but on a commercial level it's a tough case to make.
And the same logic applies to the other thread around BGP communities filtering...
adam
So why not disable ICMP Echo and UDP traceroute, those kids using
network diagnostics don't need them.
For clue constrained audience fear will always be the most compelling argument.
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.