RE: QUIC / TailScale…
Could you hack-up the Chromium (not Chrome, but Chromium) code to make this happen? It supports WebRTC which means it implements ICE and will return everything you need to then establish a QUIC transport between Client / Server including opening WebTransport via the Chromium code to facilitate API calls / streaming. You can also combine this with RTCDataChannels for peer-to-peer stuff. I assume this is what TailScale is doing based on initial read of their overview architecture. There is even some work to make the RTCDataChannnel do it’s peer-to-peer set-up but then use quik as transport. (RTCQuicTransport Coming to an Origin Trial Near You (Chrome 73) | Blog | Chrome for Developers)
You’d need infrastructure to tell both client and server to go initiate a connection towards each other but you already have that. Won’t be 100% without TURN but it will may very will be closer than port forwarding.
RE: UPnP
Appreciate your feedback on this topic and I agree with you about 99%. The only bit that isn’t addressed in your response is the acknowledgement that UPnP changes the attack surface and it does this without any validation. If the router / firewall supports UPnP then the attack surface is able to change without the user knowing. This automagical reconfiguration of networks may expose additional / unintended attack vectors and that’s the real security concern. But, you’re right, using or expecting UPnP to be available as part an attack is lame and there are far more reliable ways to gain access into a network. But this automagical adjustment of attack surface is why I keep it off and statically configure. It’s also why Enterprises will never turn it on.
It depends on if you consider a DoS a security issue. It would not take much to overwhelm my Roon Core with attack traffic even if that attack traffic wasn’t modifying or compromising my data. Some goof on the 'net who decides they don’t want my Roon to function isn’t too far away from succeeding once they identify my IP:Port for ARC. It takes CPU cycles to throw things away. This is why I plan on using ARC behind a firewall once launched. My VPN concentrator does a better job of throwing away rouge attack traffic than a web service. Then I just have to worry about some goof eating up all my bandwidth. It’s never foolproof but this “always on” does allow for a fairly targeted attack against a single service and that can fall down pretty quickly.
Doesn’t sound like you think it’s quite around the corner.
But once it’s readily available, does it mean that RAAT can also be drastically simplified? I mean, if the transport layer already combines TCP-style redundancy with UDP or better speed, fast initiation, secure connection, multiple streams …
Seems it ticks a lot of Roon boxes straightaway.
(And will everybody else be able to do something akin to RAAT, on the cheap )
People talk about ports like they’re traffic trap doors… they‘re not, it’s just a number in the tcp/ip header. “Opening a port” doesn’t suddenly expose your network, it was exposed the moment you plugged it into the internet. So forget port paranoia, use strong passwords, and trusted software.
Agreed. Also always disable default/built-in admin and guest accounts, and create new ones that are unique to your device/service… and as you say, use a strong, unique password for each.
Don’t think RAAT is complicated at all - it’s invisible to me as a user, so great! I was thinking about what you would have needed to code so it works on top of TCP, and imagined it would be a smaller / easier task with QUIC. Starting to suspect from your response that my thinking is flawed …
For example: the Federal Office for Information Security in Germany provides some certification scheme for secure consumer grade internet devices; for broadband routers, to comply a device shall not offer automatic port forwarding. Looks like not that many manufacturers actually claim conformance, but for instance AVM seems to deliver their Fritz!Boxes with upnp auto port forwarding off by default anyway.
That’s why I’d rather turn to CISA or the German BSI (from the above example) for IT security related recommendations.
4.3 Firewall
The end-user MUST be able to configure the set of rules being used to adjust it to the specific (security) needs of the respective network. The firewall MUST NOT contain any port forwarding rules configured initially.
(…)
After initialization the firewall SHOULD allow all outgoing communication from the private network and deny all not requested incoming communication from the public network.
Note their emphasis on initially. And my search of the document did not find any mention of UPnP or not allowing it.
Regarding Fritzboxes, UPnP off by default seems reasonable if one doesn’t need it (the principle of least privilege also makes sense for services that you don’t consider a risk) but in the case of Fritzbox it would not make any sense to enable it by default, because UPnP rights can/must be assigned in the admin interface to specific devices on the network.
You’re right. Only after getting ready to operate, they want the router to not have any port forwarding configured. That’s what I meant with automatic.
“The firewall MUST NOT contain any port forwarding rules configured initially.” clearly means that they don’t want routers to come with preconfigured port forwarding rules.
Since both factoryandinitialized settings are to be tested, I would think that’s what they consider to be essential for safe out-of-the-box operation.
I stand corrected re: “automatic port forwarding”. What I tried to get at is exactly that: for safe operation after being intialized (not: factory or customized), they seem to want no port forwarding active. And that’s why I mentioned it. Just so it could get considered when recommendations changing the (security) settings of a home network get prepared. This very topic shows that it can raise concerns – reasonably or not. So if there’s a nice FAQ on launch which addresses the security aspects and maybe explains, why it’s safe to enable port forwarding for devices or how to do it in safe way, that would be good.
Jesus. Obviously they don’t want router vendors to preconfigure port forwarding rules, this would be stupid and dangerous for obvious reasons (what if the machine that finds itself at the end of the preconfigured forwarding rule actually answers the requests without being properly configured to deal with such unexpected external traffic). This has nothing whatsoever to do with the user or UPnP creating a rule that the user desires.
If there’s no port forwarding, nothing works. Nada, nix. To enable port forwarding “in a safe way”, you open only the ports you actually need. Common services like DNS and web-surfing do this automatically, but less common services (eg Roon ARC) will need a rule manually set. This is not like leaving your front door wide open, it’s like providing a letter box if you want to receive letters. You might still get junk mail in that letter box, but the “trusted application” (using the letter box) will ignore them.
)
.
, so the QUIC observations from Danny seemed relevant to me. I may completely misunderstand.