Security with Roon ARC / Roon 2.0

Danny it was not a criticism of Roon’s implementation at all. I think that it’s great to try and make it easier for less technical users. It’s the only way something like this is likely to work across the expanded user base.

I also think that this early beta will be good to help debug the issues before a wider roll out and that is likely to be an important step to a smooth rollout.

I don’t think anyone is really saying this.

In pretty much all scenarios the malicious software is already in the local network (most likely due to a user error). Then the damage is done already.

By disabling uPnP you just give the malicious software fewer escape routes and make the attack service a bit smaller.

Note that most professional network manufacturers do in fact recommend disabling uPnP, in part for the reason mentioned above. Pretty sure they are familiar with how malicious software behaves in networks :wink:


If the biggest risk is Valence thinking I like Barry Manilow due to some rogue plays, well that’s a risk I’m willing to take.




Gentleman, most of this thread’s technical details are bit hard to effectively utilize for this not-technically-inclined-Roon ARC-end user.

I’d never even considered any home network security risks after setting up my network to accommodate Roon ARC (glad I’m not using UPnP - if I’m following this).

Would it be prudent for Roon Labs to create a home-networking security configuration Pro/Con document summarizing main security items to consider, prior to opening ports, for laypeople-end users like myself? @connor @mike @jamie

1 Like

I think it a good idea to read up on securing a home network with or without roon.
Home Network Security | CISA
this is just a starting page. They have plenty of advice and you can even sign up to get 0-day exploit notifications via email when found. Super handy when you have thousands of instances needing updating.


Can’t disagree Paul, @MamaTried. Sheesh, another technical, information subset to learn…

On the other side of this discussion; I’m the type of end-user that simply wants a TIDAL et al.- like mobile experience. Which, may or may not be, a Roon Labs’ ICP, as regards the platform’s growth :rofl:.

For Roon :heart:, I’ll work-learn/up my technical KB.

At least YouTube has become a great, centralized source for learning consumer-level-tech usability… related subjects.

1 Like

That would be very bad. I think something like this happened with Celine Dion several years ago. Took weeks to flush the taste out of Valence.

This is exactly what I’m refuting. It is my opinion that disabling UPnP does not actually prevent any “escape” routes. It’s purely theatre and actually impacts no nefarious software in any meaningful manner.

You mean the same providers that introduced the buggy/exploitable code in the first place, or are there others with reasonable implementations that also recommend this? And if so, who and what is their reason for such a recommendation?

While I’m a fan for knowing more about how things work, it is completely unnecessary in this situation to achieve safe success. You’d have to work hard to create a security issue here. It’s not going to happen by accident. If someone believes otherwise, I’d like to hear in explicit exploitable detail how that might occur. I’m genuinely curious so we can update the docs and help-guides to help future users avoid such actions.

I agree with almost everything at a high level (I disagree about antivirus) in this guide. It’s a realistic guide to what you can do to reduce threats.


Summarised as: always use unique strong passwords, keep all soft/firmware up to date, delete any apps you’re not actually using.


From that CISA guide:

  • Disable Universal Plug and Play (UPnP) when not needed. UPnP is a handy feature that allows networked devices to seamlessly discover and establish communication with each other on the network. However, though the UPnP feature eases initial network configuration, it is also a security risk. Recent large-scale network attacks prove that malware within your network can use UPnP to bypass your router’s firewall, allow attackers to take control of your devices remotely, and spread malware to other devices. You should therefore disable UPnP unless you have a specific need for it.

What I understood – and I’m no IT security expert – about disabling UPnP: it should be done because especially with IoT stuff there’s always a good chance implementations may contain known as well as unknown security related deficiencies and / or backdoors; the latter may be there by design or by accident. Getting support and security updates for IoT devices isn’t a given either.

Recommending to enable UPnP without knowing what else is operated in a particular home network seems like a risk I would not take. Especially when experts seem to believe disabling it is the SOTA approach.


Roon security bounty, Roon Red Team.


It seems pretty simple to me. When enabled, the malware can configure port forwarding, so that someone from outside can enter the network via that port. When disabled, they can’t use upnp to configure port forwarding. Are there other ways? Sure, but it’s one less.

I would say literally all the big corporate network vendors. I’m sure you know them. They have reasonable implementations as far as I can tell, and I’ve stated the reaason just above. Maybe we just have to agree to disagree, but aluding on their buggy / exploitable code, seems a bit lame. I would never have brought it up, but since you opened that gate, I dare say Roon is not without bugs either.


They suggest this because they don’t want a corporate employee to open ports into the corporate network. Not because of malicious software. Malicious software that relies on port forwarding wouldn’t be very effective. Many of these vendors don’t even support automatic port forwarding configuration. Example in the SOHO space: UniFi EdgeRouters need extra addon software to do it.

Again, because of the exploitable nature of poor implementations, not because they will open random ports inbound.

I think the critical piece people seem to be missing is that it is not hard for a malicious piece of software to tunnel in traffic without port forwarding at all. This was demonstrated at scale with Back Orifice back in the late 1990s, and the ease of implementation as well as proliferation of this type of code has made it quite widespread.

Great example of why one shouldn’t talk about security without expertise. Most IoT devices have mechanisms for tunnelling in traffic without port forwarding, but no one talks about them (outside security circles) until they go awry. There was quite a fiasco with the first generation Wyze cameras just recently.

Turning off a mechanism to make port forwarding easier will only make it more difficult for legit software. It won’t do anything to the malicious software. At best it’ll give you a sense of false security.

If Roon had access to a good cross-platform QUIC implementation, we’d skip the port forwarding completely. It’ll happen someday, and when that happens, we’ll be able to get through routers without any configuration, UPnP/NATPMP/PCP, or manual port forwarding. One less thing to configure or worry about, and an overall better experience.

The malicious software out there doesn’t have requirements like we do, and is not hindered by you turning off support for UPnP/NATPMP/PCP.

An example of legit software that uses the above QUIC technique is TailScale. They have zero issues getting through your router. they can afford to do this because it’s a core part of their value proposition. If we went down this road, we’d be releasing ARC a year later than we plan to.

Because we prefer users to have a good experience out of the box, we will move towards mechanisms that avoid all this mess. I predict in a few years, there will be very little software being built on TCP, which should also eliminate this entire class of configuration. The mass adoption of HTTP/3 will be the final nail in the coffin of TCP.

Our advice is to turn on UPnP for a good experience or set up manual port forwarding if you can’t/wont, and none of this will matter later on.


@danny random thoughts / questions

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) - Chrome 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.

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 :thinking:)

I don’t think any of this has anything to do with RAAT just the ARC connectivity.

Nothing to do with ARC testing for sure, so maybe I should not have asked/posted - can hardly do this in the main forum though :slight_smile:.

Most LANs use TCP/IP :wink:, so the QUIC observations from Danny seemed relevant to me. I may completely misunderstand.

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.

1 Like

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.

I’m not sure I understand. In what ways do you find RAAT to be complicated?