P2P Hole punching in Home IoT - A best UX or build in security vulnerability?

There’s a punch, and then there’s P2P Hole punching…

It’s no news that many home IoT devices are constantly sending data to their corresponding mobile apps, especially when it comes to video and audio.

Consumers are therefore looking for devices that can properly deal with data, or in other words, smart devices that present good indications of performance and connectivity. But consumers will soon learn that they should consider additional parameters as well, as they realize that when they log into smart devices, they open a backdoor to their home WiFi.

The communication between smart devices and correspondent mobile apps are done either through a cloud server or by a peer-to-peer (AKA P2P) direct connection. Since overall performances are usually higher in quality when leaning on P2P, this protocol is preferred for video and audio smart devices.

But in order to create this direct connection, one has to overcome the home NAT. There are two common techniques to establish that: Port forwarding and Hole punching.

Even though port forwarding may be simpler to implement and does not require a third party mitigating server, most vendors avoid this method due to the obvious and well-known security risks it holds.

Is that the end of the story?

Well, before we rush to discuss leaving the hole punching technique to die at the expense of convenience and performance, let’s first take a closer look at how things work.

Let’s say I want to watch a live video stream derived from my home IP security camera to my smartphone (to a certain app).

Whether my phone is connected to cellular data or a WiFi network, the process requires my camera to maintain a live connection with a mitigating server. In order for that to happen, the camera constantly sends packets to the server, and the NAT remembers the IP/Port combination and recognizes a new incoming session with the other peer as a response to the device’s outbound session (sorry for speaking Chinese).  

This first step allows the server or mobile to reach the camera behind the NAT, and is therefore crucial for the UDP hole punching process.

But is it safe?

If you think about it a little, it basically means opening ports on the router, quite like the famous port forwarding method. If worse comes to worst, all it takes is to catch one of the packets that the device sends to the mitigating server, and an attacker can – theoretically – easily reach the device behind the NAT. As easy as it may sound.

This apprehension raises serious security concerns, but somehow, and I don’t fully understand why these concerns aren’t getting enough attention these days.

True, for an attack to actually occur, a hacker will need to ‘enjoy’ initial vulnerability (to actually exploit the device behind the NAT). Still, the hole punching technique can be basically treated as a technique that has a sub-effect of creating an attack platform through many simple devices.

Identifying a known vulnerability or cracking default passwords in these devices isn’t usually too hard. Hole punching is somewhat exposing smart devices to the internet, turning them into easy prey.

Conclusion

As we can not change all IoT devices to communicate through the cloud, and we don’t really want to compromise on performance anyway, any optimal security solution should pull through the hole punching technique, not try to change it.

That’s why IoT companies must use a real-time, ever-learning and proactive security solution that could provide a fix to this flaw (or any other threat that may arise).

There is a consistent conflict between security and user experience, IoT companies can now use a security solution that protects their device without compromising on infrastructure and features. This type of cybersecurity solution, that is implemented in the device core, can prevent, detect and respond to cyber threats, even ones that lie behind legitimate techniques.