It's the "fail closed" principle in action: if I don't understand it, it must be malicious, so the connection should be rejected as swiftly as possible.

Also seen in firewalls which drop all ICMP packets ("the only real-world use of ICMP is ping floods, right?"), breaking PMTUD.

But this isn't fail-closed. The specification allows for newer versions. The problem is, you are supposed to spit back the version you actually support instead of disconnecting. I don't understand how this can be interpreted as anything but non-compliance of the standard.

I would say that technically it's complaint because there's nothing saying a server can't tear down a connection whenever it wants.

Our InfoSec friends are rightfully suspicious of 'weird' looking packets and data from clients. It's one of the few ways to catch/stop zero day vulns. It does make things difficult when legitimate traffic is caught in the crossfire but such is the nature of most security practices.

Fun fact: Trying to apply that to IPv6 ends up without a working network connection.

Microsoft's Skype for business servers block(ed?) ICMPv6. That was a fun one to track down when there was an MTU issue on our network, especially when their diagnostic tool claimed there was a 403 error from the SIP endpoint!

Maybe whoever wrote that code was excellent on soft skills.

If the team had good soft skills, they might have felt comfortable to ask questions about edge cases. And they might have put the work in to make sure they understood the users' goals. Instead they probably just wrote code to pass some conformance test and patted themselves on the back for being very technically correct.

Reminds me of the OpenGL 2.0 version issue. So many games and programs just checked the minor version number, as OpenGL had been stuck in 1.x land for over a decade.

So when drivers suddenly started reporting 2.0 rather than 1.3 or 1.4 the flawed version check failed and reported you didn't have a modern enough OpenGL implementation.

As someone who has debugged many weird TLS problems, I'm not at all surprised. The protocol documentation is pretty hard to use, so I'm not surprised that server or proxy implementations would bail out on unexpected input, and that they would only use existing clients as their base of expected input.