Those of a non technical persuasion, look away now. :)The...

Those of a non technical persuasion, look away now.

The "invisibility" of the VIN comes from the idea that the internet locations (IP addresses) of two endpoints which need to talk to each other are known to a central register machine and no one else. The register puts the endpoints in touch with each other. Because the endpoints talk directly to each other instead of sending their data to be relayed via a server, if a hacker wanted to intercept the channel he would need to find the endpoints first. That would be very difficult. Technically the "invisibility" argument holds water, but in practise it just means an attacker has to attack the register rather than the endpoints. The register can not be invisible because the endpoints need to be able to register with it. If the endpoints know where it is, an attacker can see it too.

SSH does not use any of that registration stuff. An administrator wanting to connect two SSH endpoints, like those in a water sanitation facility for example, would know the IP addresses of those endpoints. Traditional VPN does not use registration either. In that model, one endpoint is fixed (the "office" end) and the other end always knows where to find it (at a domain like vpn.myoffice.com, for example). Those connection models have served well for decades. The "invisibility" model offers little of practical advantage, which is why no one has ever asked for it.

Regarding the use of UDP by Google for their HTTP/3 proposal, yes, that makes sense. There is nothing inherently wrong with UDP, and we use it for things like remote desktops all the time. But the VIN does not replace TCP with UDP, as Google are proposing. The VIN wraps TCP in a sequence of UDP datagrams, which actually gives you the worst of both worlds. You end up with the problems of TCP, as described in the article you link to, plus the unreliable nature of UDP on top. We have known since the 1970s that that is never going to work.