4 Home Automation Network Protocols
This chapter provides more detail on some of the key home access network (HAN) communication protocol procedures, especially as they relate to configuration settings on the network router, which are essential to get right. While this discussion might be demanding for the reader, who has not yet dealt with communication protocols yet, it’s understanding is of utmost importance and the prerequisite for the ability to plan, design and install a safe and performant smarthome network. Trying to set up or change the configuration parameters of routers, smart hubs and smarthome devices without exactly knowing what you are doing is like playing the lottery: chances to get it right are very small. So unless you know what NAT, UPnP, IGD, or HTTP-REST is and how they function, do not skip this chapter.
4.1 Network Address Translation (NAT)
The way a DSL router connects the devices in a private local area network (e.g. a HAN) to the public Internet is through the process of Network Address Translation (NAT). For all communication with the public Internet the DSL router is being assigned an external IP address, which has to be unique in the entire Internet. (This address by the way is rotated and changed by the Internet service provider every 24 hours or when the router restarts, unless you have a more expensive permanent IP address.) Towards the private local area network the IP addresses do not need to be unique, but can randomly be selected from the below ranges:
10.0.0.0 – 10.255.255.255
172.16.0.0 – 172.31.255.255
192.168.0.0 – 192.168.255.255
The IP addresses of all network packets from local devices, which need to be sent to the public Internet, are replaced by the NAT instance of the router with it’s external IP address, before they are being sent on to the public Internet. In addition to the source IP address, the router also stores data such as destination address and port number of every packet, so it can easily route reply packets from the public Internet to their correct destination in the local network.
4.2 Open Ports and Port Forwarding (Port Sharing)
Port numbers are 16 bit long identifiers for networked applications, which are managed by the Internet Assigned Numbers Authority (IANA). Common port numbers are:
- HTTP: 80
- File Transfer Protocol: 20/21
- Secure Shell (SSH): 22
- Telnet: 23
- Simple Mail Transfer Protocol (SMTP): 25
Every packet in the network must contain a destination port number, based on which the network stack of a networked device decides to which application to send the packet to, and based on which routers decide, whether or not to process this packet . An “Open Port” is a router configuration setting for a specific port number, which tells the router to process packets, which carry this port as destination port. As an example, if you are running a web sever and a FTP server, you will need ports 80 for web, and 20 / 21 for FTP to be open. A “Closed Port” is a router configuration setting, which tells the router to actively refuse or completely ignore packets, which carry this port as destination port. To summarize, the term “Open Port” (also “Port Forwarding” or “Port Sharing”) describes a router setting, where all packets, which are arriving from the public Internet, and which carry a particular port as destination port, are forwarded to a particular IP address in the private network. Popular applications for configuring port forwarding are
- Operating a public HTTP server within a private LAN
- Allowing Secure Shell (SSH) access to a host on the private LAN from the Internet
- Allowing FTP access to a host on a private LAN from the Internet
- Running a publicly available game server within a private LAN
- Accessing home automation devices (surveillance cameras, thermostats) from the Internet
The problem with open ports is, that malicious code can be hidden inside packets sent to any open port, which is why accepting packets on open ports can cause your system to be hacked and infected. Applications which are associated with a port such as a FTP server, a HTTP server or a surveillance camera might get attacked. Smart devices within a HAN, which are reachable via an open port (see next section on UPnP), are of particular concern, since their software is by far less advanced and protected than the one of a FTP or HTTP server. They often respond to arbitrary requests and are an easy target for an attack. Since you normally will not run an HTTP or FTP server from your HAN, on your HAN-DLS router you should not have an open port at all.
The UPnP protocol (Universal Plug and Play) together with the Internet Gateway Device Protocol (IGD) provides the functionality to automatically configure port forwarding on DSL routers. A typical use case in HANs are remote controllable webcams, refrigerators, baby phones, wall plugs or light switches, which use UPnP to connect to an external cloud service. Many routers have UPnP enabled per default, so that a user with a UPnP capable smart device can setup such devices without any changes to the router. UPnP capable smart devices such as products from the Belkin WeMo series then automatically connect to an external cloud service, which is used for software updates or for remote control through a smartphone app. Once this connection is established, the cloud service then can in turn connect to the device inside the HAN. As an example, port numbers Belkin’s WeMo devices use are 49153 and 49154. The fact that smart devices using UPnP can open arbitrary ports on DSL routers without administrative rights is a major security risk. In 2013 the US Computer Emergency Readiness Team (CERT) issued a vulnerability note on UPnP (http://www.kb.cert.org/vuls/id/922681), in 2016 the German BSI issued a similar warning (https://www.bsi-fuer-buerger.de/BSIFB/DE/Service/Aktuell/Informationen/Artikel/Botnetz_iot_24102016.html) following the massive DDNS attack against the Internet service provider Dyn. I strongly recommend to disable UPnP on your router and not to use any UPnP based products.
4.4 Dynamic DNS
Dynamic DNS resolves the problem, that the IP address of residential Internet/DSL routers is dynamically re-assigned by the Internet service providers (ISP), which causes it to change every 24 hours or every time the router reboots. This is why the router and with it any device inside the private network can only be reached from the outside, if it’s current public IP address is known. Here the dynamic DNS services come into play. They work as follows: Routers, which need to be accessible from the Internet, periodically send their current IP address to a dynamic DNS server, where it is associated with a dedicated domain name. When this domain name is called, the dynamic DNS server responds with the current IP address of the router. Dynamic DNS services are used to connect from the public Internet or from any other network outside of the private network (e.g. from the office) to home computers, home security systems, webcams or a privately hosted websites located inside the HAN. Dynamic DNS is also (mis)used in combination with remote control software such as SSH, RDP or VNC, since it is much easier than setting up a VPN connection. The most common way to use dynamic DNS in smart home environments is to combine dynamic DNS with port forwarding to access IP surveillance cameras, network digital video recorders, thermostats, refrigerators or wall switches. Unfortunately all of the above applications pose a significant security risk. The reason is, that dynamic DNS service provider domains offer an easy way to identify hosts, which run insecure IoT devices. many IoT devices have vulnerabilities and their software is commonly not updated in order to fix them. While the usage of dynamic DNS in itself is not inherently harmful, it does add risks to your HAN. In the past several malware campaigns have utilized dynamic DNS services as part of their payload distribution. Using dynamic DNS services is an invitation for potential intruders. They can easily take control of your network if you use dynamic DNS in combination with open ports, as explained in the next chapter.
4.5 HTTP REST
REpresentational State Transfer (REST) is a technology developed based on the Internet standards HTTP and URI, allowing the secure and stateless communication between networked devices. Stateless means, that no client information needs to be stored on the server between two requests, which is why this technology is ideally suited for IoT and smart home applications. Each request from any client contains all the information necessary to service that request. Most RESTful web services are implemented using the OAuth2.0 security standard, which uses session based authentication, either by establishing a session token via a POST command, or by using an API key contained in the POST command. Usernames, passwords, session tokens, and API keys do not appear in the transmitted URLs, as otherwise they could be captured in web server logs. Many REST based IoT devices and cloud services such as Google NEST or Samsung SmartThings use a REST/OAuth 2.0 based architecture. While it does require intervention by the user before a REST connection between two devices or a device and a service is activated, it is significantly more secure than using open ports or UPnP. Before a device (e.g. a smart thermostat) or an application (e.g. the home controller software) can connect to another application or device using REST/OAuth 2.0, it must obtain an access token, that grants access to the RESTful API. In case of an application, this is done the first time the application is started, in case of a device, during device set up. Once the user (e.g. the owner of a cloud service account) grants the permission to connect, an access token is being sent. This access token then is either manually entered in the device (e.g. NEST thermostat) or, in case of an application, it is stored as a secret key on the host computer of the application. To further increase security, these tokens have limited lifetimes. Once their end of life is reached, new access tokens are sent in response to special refresh tokens.
4.6 HTTP Server Push
HTTP Server push allows to initiate communication from the public Internet (e.g. a cloud service) to a device inside a private network (e.g. HAN) without configuring open ports. This is done by the server (e.g. the cloud service) not terminating a connection after response data has been sent to a client. The server basically leaves the connection open. Now a cloud based rule, which needs to execute a service, or a remote control request from a smart phone (via the cloud service) can be sent immediately. HTTP Server Push was introduced as part of the HTTP 2 standard (RFC 7540) in 2015.
Given the significant risk UPnP, dynamic DNS and open router ports pose, the much safer approach of HTTP REST and HTTP Server Push have gained wide acceptance in the industry. Today the combined use of REST, OAuth 2.0 and HTTP-2 Server Push provides a secure framework for communicating from private networks to the public Internet and vice versa.
Carnegie Mellon University, Software Engineering Institute (2011): Vulnerability Note VU#357851 – UPnP requests accepted over router WAN interfaces. http://www.kb.cert.org/vuls/id/357851
Postscapes (2017): IoT Standards and Protocols. https://www.postscapes.com/internet-of-things-protocols/
Dominique Guinard, Iulia Ion, and Simon Mayer (2011): In Search of an Internet of Things Service Architecture: REST or WS-*? http://www.vs.inf.ethz.ch/publ/papers/dguinard-rest-vs-ws.pdf