# A Secure Internet of Things Smart Home Network: Design and Configuration
## 3 Network Design and Configuration  
According to our investigation, unlike the traditional request/response model of HTTP, which tends to impose unnecessary control data even in the many cases of unchanging data, the publish/subscribe model of MQTT can use the available bandwidth more effectively. The compactness and efficiency of MQTT makes it possible to collect, transmit, control, monitor, and analyze significantly larger amounts of data for multimedia applications. However, we need to mention that not all IoT devices are resource constrained, which makes HTTP remain worthy in some IoT networks with its popularity and extendibility. In contrast, if the low battery and bandwidth usage are first priority due to resource constraints of the environment, MQTT is more suitable. Since application developers need to choose between the two protocols depending on the requirements of the target applications, in this paper, we do not discuss the effectiveness comparison of the protocols in IoT network for multimedia applications. Instead, our aim is designing and configuring an accessible secure home network framework that can be applied in legacy, newly developed, or in-development IoT solutions that prioritize enhanced security and improved performance for multimedia applications. We design the home network to operate IoT devices and their IoT server as shown in Figure 1.  
The IoT server can be either a HTTP server or a MQTT broker. We consider the most general case of a home network, where the hosts are interconnected through a routing device such as a home gateway. A typical home gateway has one public IP address (20.20.20.1/24) assigned by its Internet Service Provider (ISP) and comes with a built-in Dynamic Host Configuration Protocol (DHCP) server module, which distributes private IP addresses to its local hosts within the range of its IP address pool (192.168.0.0/16). In our design, we divide the home network into two subnets--the inside-subnet and the IoT-subnet. We locate the IoT devices in the inside-subnet and the IoT server in IoT-subnet. This structural design separates the IoT server from other parts of home network, which in turn allows the IoT server to operate as an independent host providing IoT services to the external network. Since there are two subnets, the home gateway performs a subnet masking with a given 192.168.0.0/16 address pool, 192.168.0.0/24 for the inside-subnet, and 192.168.1.0/24 for the IoT-subnet. Therefore, the home gateway is configured with three IP addresses with three interfaces. As shown in Figure 2, the home gateway has 192.168.0.1 to connect the inside-subnet, 192.168.1.1 to connect IoT-subnet, and 20.20.20.1 to connect to the external network. The Network Address Translation (NAT) and access-group configuration will be discussed later in this paper. Figure 1: Design of the home network for IoT service. Figure 2: IP address allocation for the three interfaces. In the inside-subnet, the Domain Name System (DNS) server has a static IP address 192.168.0.53 and dynamic IP addresses are assigned by the home gateway. In the IoT-subnet, we set a static IP address 192.168.1.2 for the IoT server. If we add additional hosts to the IoT-subnet, their dynamic IP addresses will be assigned by the home gateway. To implement these IP address configurations for the home network, we define the DHCP pool named inside and IoT, respectively and give associated commands on the home gateway. Finally, a routing protocol is applied to the home gateway to connect the external network. Even though a proper selection of routing protocol is beyond the range of this paper, among the five available routing protocols in packet tracer emulator including static routing, Boarder Gateway Protocol (BGP), Routing Information Protocol (RIP), Enhanced Interior Gateway Routing Protocol (EIGRP), and Open Shortest Path First (OSPF), we adopt the OSPF protocol for the purpose of possible extension to a large-scale network.