Machine Communication at Resato

University of Groningen

Integration Project

Machine communication at Resato

Supervisors: Author: 1st supervisor: Dr. ir. A.A. Geertsema Sanne van Kasteel 2nd supervisor: Dr. A.J. Bosch Company supervisor: R.J. Boer

Bachelor Thesis Industrial Engineering & Management

July 2, 2018

UNIVERSITY OF GRONINGEN Abstract

Faculty of Science and Engineering Industrial Engineering & Management

Machine communication at Resato by Sanne van Kasteel

With the modern technology, many companies use data to predict and anticipate on events. This data has to be transported from one point to another in order to use it. Everything can be connected through the Internet of Things, but the connection is not always easily made due to security in companies, such as a ﬁrewall. In order to let the connection run smoothly, methods are developed to bypass the ﬁrewall constructions and securely transport the data from one company to another.

Resato International BV is a company that develops high pressure and waterjet technology. Resato has machines at customers all over the world but has problems with connecting to those machines. Methods for bypassing the ﬁrewall are necessary to allow for an easier connection to these machines. In this research, several methods are evaluated and ranked according to the requirements of Resato. One of the methods is tested to gain insight into the method and provide an example of implementation. This method, STUN, provides the client with an open port and its IP address. From the tests, STUN is capable of communication in most situations. For the cases that STUN is inadequate, the advice for combining methods is given.

iii

Contents

Abstract iii

Terminology vi

1 Introduction 3 1.1 Resato...... 3 1.2 Innovation Cluster Drachten...... 3 1.3 Project Motivation...... 4 1.4 Trade-oﬀs...... 5 1.4.1 Ethical limit...... 5 1.4.2 Technical limit...... 5 1.5 Digitalisation at Resato...... 6 1.5.1 The OSI model...... 6 1.5.2 The TCP/IP model...... 7 1.5.3 TCP and UDP...... 9 1.5.4 NATs...... 9 1.6 Use of TCP or UDP...... 11 1.7 PTC ThingWorx...... 12 1.8 Problem holder and stakeholders...... 12 1.8.1 Problem holder analysis...... 13 1.8.2 Stakeholder analysis...... 13 1.9 System description...... 14 1.10 Risk analysis...... 14 1.11 Planning...... 15

2 Research Design 17 2.1 Research Topic...... 17 2.2 Design goal and scope...... 17 2.2.1 The design goal...... 17 2.2.2 Scope...... 18 2.3 Research problem...... 18 2.4 Design steps...... 18 2.5 Needed Resources...... 21 2.5.1 Literature resources...... 21 2.5.2 Test design...... 22

3 Requirements 23

4 Methods 25 4.1 Introduction...... 25 4.2 STUN...... 26 4.3 TURN...... 27

v 4.4 ICE...... 28 4.5 PS-STUN...... 31 4.6 3G/4G/LTE...... 31 4.7 SWEET...... 32 4.8 WANTS...... 33 4.9 CAN...... 34 4.10 CODO...... 34 4.11 NSLP...... 35 4.12 Tunnelling...... 36 4.13 UPnP...... 38 4.14 Hole Punching...... 39 4.14.1 UDP hole punching...... 39 4.14.2 TCP hole punching...... 40 4.14.3 Well behaved NAT...... 40 4.15 ALG...... 41 4.16 Comparison Traversal Methods...... 42

5 Test Design of Traversal Method 45 5.1 Setup...... 45 5.1.1 First setup...... 45 5.1.2 Second setup...... 46 5.2 Test Program...... 46 5.3 Results Tests...... 49 5.3.1 Test 1...... 49 5.3.2 Test 2...... 49 5.3.3 Test 3...... 49 5.3.4 Validation...... 49

6 Discussion 51 6.1 Results...... 51 6.2 Discussion...... 51

7 Conclusion and recommendations 53 7.1 Conclusion...... 53 7.2 Recommendations...... 53

A Program Code 55

B Wireshark Screenshots 65

Bibliography 69

vi Terminology

Auto IP is a method that automatically distributes IP addresses to devices without a router or server. In a Client-server network devices send information to one another through a centralised server. DCR is a direct connection rate. DHCP (Dynamic Host Configuration Protocol) is a protocol that can automatically assign IP addresses to devices in a network. DNS (Domain Name System) is a decentralised naming system for devices that are connected to a private network or the internet. It is used to translate names of devices to IP addresses and vice versa. Expedited data is urgent data. HIP (Host Identity Protocol) is a protocol that allows for forming and maintaining IP addresses as both “locators” and “identifiers”. [1] HTTP (Hypertext Transfer Protocol) is a protocol in place for communication between a client and server. ICE (Interactive Connectivity Establishment) is a method for direct communication between devices. IGD (Internet Gateway Device) is a protocol for port control in NATs. IoT (Internet of Things) is a system that allows devices with different IP addresses to connect. IP (Internet Protocol) is the main protocol for communication in the internet protocol suite. IP address is the numerical code given to a device in a network that uses the IP for communication. IPsec (Internet Protocol security) is a network protocol suite that encrypts and authenticates packets. Kernel is the core of an operating system. A log file is a record of every data activity that takes place in a system. Middlebox is a device that can manipulate data before traversing. Multihoming is a mechanism that allows to connect to more than one network or IP address. NAT (Network Address Translation) is a method where IP addresses are appointed and trans- lated. A Node is a device, structure or peer. NTT stands for NAT Traversal Technologies. Octet equals 8 bytes. Overhead is the network overload. Payload is the actual message sent in a network, the information without the data to make the transportation possible. In a Peer to Peer network devices (peers) send information directly to each other. Polling is a regular check for incoming data or changes. Protocol suite is a collection of communication protocols. Relaying is passing on data. SIP (Session Initiation Protocol) is a protocol for communication of multimedia. SOAP (Simple Object Access Protocol) is a messaging protocol that uses a XML format. SSH (Secure Shell) is the protocol that allows for a secure channel over an unsecured network. SSPR (Self-Service Password Reset) is the technology that one uses when, for example, one has to reset their password because of forgetting it.

1 2

STUN (Session Traversal Utilities for NAT) is a collection of methods for transport across NATs. Throughput is the absolute performance of a process. Tunnel is a manner to transport data while encapsulated. TURN (Traversal Using Relays around NAT) is a protocol for relaying packages of data from one IP address to another. VoIP (Voice over IP) is a method where the internet protocol is used to make telephone calls. XML (Extensible Markup Language) is a simple text format that uses code and is readable to both humans and machines. Chapter 1

Introduction

Modern systems communicate in different networks and there are different techniques to do so. Re- sato and more organisations encounter problems with this communication, while at other organisations such as WhatsApp, it does work. The problems arise from the security surrounding the machines because the machines are located at Resato’s customers. These customers use firewalls to protect their network and prevent unwanted communication. Different techniques for communication need to be found and evaluated. In this chapter, the problem context is discussed, such that one can understand the background of Resato and its problem.

Resato is part of a subsidised project where they are to provide knowledge on the subject of transportation and storage. Resato works together with a group of companies from Innovation Cluster Drachten. These companies all have the problem mentioned above.

1.1 Resato

Resato is a relatively small company that develops high pressure and waterjet technology. Even though Resato has less than 100 employees, they have their own distribution oﬃces throughout the world, besides the headquarters in Assen, the Netherlands. Resato makes machines for customers all over the world. They carry two brands related to the technologies they produce. In 1991 Resato started with high-pressure technology. From this technology, the waterjet technology was realised. [2] In Groningen, several busses from Qbuzz1 run on hydrogen. Resato is the company that makes the compressor needed to fuel these busses. Resato’s mission is ‘To improve our customer’s business by providing them with High-Pressure technology, products and systems that meet or exceed their expectations.’ [3]

1.2 Innovation Cluster Drachten

Resato is part of Innovation Cluster Drachten, which consists of 18 collaborating companies in the manufacturing industry. Their goal is to make use of their shared knowledge to be able to make high quality, high-tech products. [4]

They work on ﬁve future challenges [5]:

• 3D metal printing: a unique combination of 3D printing, fundamental metals science, and post- processing technologies like ECM;

• Remote sensoring and big data: establishing remote connections between appliances, instruments and machines, and collecting, transferring, storing, analysing and using data;

1https://www.qbuzz.nl/

3 4 Chapter 1. Introduction

• Robotics: nearly or completely unmanned operation of high-tech systems at customers and in factories;

• Visual intelligence: a unique combination of camera technologies, big data and neural networks;

• All-electric propulsion: 100% emission-free drive systems through electric drive trains, including high-performance photovoltaic technology (100% renewable energy). The research that will be discussed in this paper is related to the subsidised project of Innovation Cluster Drachten. They have a certain amount of knowledge they need to gather on these challenges. This research is on the subject of smart machines. In case the results of this research are useful, they will be presented to Innovation Cluster Drachten. The subject of smart machines is divided into diﬀerent work packages, this research is part of work package 2. The province of Friesland is the one providing subsidy for the project of Innovation Cluster Drachten. This is done on the condition that the ﬁve challenges mentioned above are worked on in R&D projects. It is important, according to the province, that innovation cluster Drachten collaborates with educational institutions, such as the University of Groningen. [6]

1.3 Project Motivation

The communication between Resato and its machines is needed because the material of Resato’s products can wear quickly. A batch of material might be of the wrong quality. Therefore, Resato would like to be able to communicate with their machines, such that preventive maintenance can be done. It is difficult to predict behaviour because their machines have strictly nonlinear behaviour. Resato is working on the usage of artificial intelligence, but this is only on one machine and still work in progress. This artificial intelligence is used for the prediction of behaviour in the future. The test machine has sensors everywhere, which are used to read data for analysis of the machine. There are 70 sensors on the machine. These measure everything, such as temperature, pressure, current, leakages and strokes. Since the strictly nonlinear behaviour of the machine makes analysing difficult, only a 60% prediction rate can be met at this moment. Naturally, this is not enough to be useful. Therefore, it is still being tested on only one machine. In the future, all machines should be able to communicate, but Resato rather wants to be able to predict their behaviour than to monitor the machines. Resato offers service to their customers, but there is much effort and money involved in randomly sending a mechanic to the customer. With the use of communication, a mechanic can be sent only when necessary. Besides the fact that this is better for Resato itself, this is also an improvement for the customer. Since the customer cannot use its machine when it breaks before a check-up, it is costly for the customer to have to wait for repair. The artificial intelligence used at Resato is “PTC ThingWorx” from PTC, a software company that helps companies use IoT to connect the physical and digital world. IoT (Internet of Things) is a system that connects many devices with different IP addresses. The software ensures that manufacturers can use digital information in order to innovate. [7] ThingWorx is an IoT platform that can also analyse processes and provide predictions, just as it is able to make a connection between devices. [8] However, Resato has trouble with establishing a connection. PTC ThingWorx is further explained in section 1.7.

Sometimes Resato has to wait for half a year before being able to communicate with their machine. Customers do not generally want to provide Resato with access or have Resato in their network all the time. This is for their own security, thus it takes several months before such access is authorised. Resato would do the same, nobody can get access to their network. At this moment it will take a day to actually construct a communication line, which can be done faster and more automatic. Chapter 1. Introduction 5

The companies from Innovation Cluster Drachten encounter the same difficulties. The companies do have methods in place to communicate at this moment. However, when internationally active, more problems are encountered. For example, Germany is very strict with the traversal of data. An essential aspect of being able to bypass the firewalls automatically is that the customer does not have to do anything. As Resato has their machines all over the world, every customer has a different background and network environment.

1.4 Trade-oﬀs

1.4.1 Ethical limit One of the trade-offs to consider is ethical responsibility. The meaning of trade-offs in this context relates to the method of bypassing the firewall. There are many methods, of which some can be ethically challenging. The problem is that Resato wants to find a way to bypass the firewall that is ethically responsible. Some methods, however, seem to approach hacking. Naturally, Resato would not like to use a method that is of questionable origin.

Actions that seem harmless can have undesirable consequences that one cannot anticipate. The problem lies in the different perspectives of countries on data transfer. One country can think it is reasonable the provider of a company’s machines reads out data, while in another country the government can think of it as espionage. The governments have different viewpoints, but all the companies do as well. Especially large companies that are more vulnerable to being the victim of a digital attack have trouble with allowing data transfer outside their network. If a port is opened for data transfer through their firewall, then the company is exposed to the possibility of attacks. Therefore, barely any company would allow for data transfer outside their network. Besides the concern of hacking, the companies also have legal issues. Many companies have customers of their own, in the case of a hospital, patients for example. These customers have the right to their privacy. Therefore, no company would like, or is allowed, to share data that might have customer information in them. When the company gives access to the data, customer information can be gathered as well. Even if one promises not to gather any sensitive information and only log files, the company might still be hesitant because of customer confidentiality. As tunnelling is an option for transporting data in an unobservable manner, these methods should be taken into account in this research. How- ever, it is important to take into account this ethical limit when doing so, since it could be termed as hacking. In the requirements (3) for evaluating the methods, the ethical side is represented by customer approval.

1.4.2 Technical limit The technical limit lies mostly with the customers, because every customer has different IT knowledge. This implies the technique should be made such that the customer is not involved in any of the steps. All firewalls are based on the same techniques, they merely differ in strictness. Thus, if it is possible to cross one, it is possible to cross practically all of them and one does not have to take into account any possible differences in designing a method to pass through the firewall. It is also important to the customer that their environment, either physical or digital, does not change excessively. For example, if Resato needs the customer to add a certain application to their machine so that it would take up more space. A digital example is that the customer needs to make a portal for Resato in order to access their machine, which happens at this moment but does take up effort from the customer, thus Resato has to wait until they have access. Important to note, is that Resato offers service to the customers, which means they send a mechanic or part when necessary. Naturally, this 6 Chapter 1. Introduction should be Resato’s responsibility, and the customer should not have to put in much effort to enable this. Equipment can also play a role once implementing a method. However, this is not relevant for this research as the test design will be on a small scale with little data. Resato already has the availability to store data, hence in case of realising a method, not much extra equipment would be immediately necessary.

1.5 Digitalisation at Resato

Resato would like to be able to communicate with their machines without waiting for the customer to act. To deﬁne the problem, an example can be given; at a certain company that has a machine of Resato, it took half a year before the company actually made an access point for Resato through their ﬁrewall.

This problem revolves around the digitalisation of practices, which is very useful for data gathering and prediction models, but can result in difficulties since it is a different level of expertise that a manufacturing company such as Resato might not have at its disposal. This problem is based on IoT, which is a system that connects many devices with an IP address. These devices can consist of many different technologies and applications, such as mechanical machines. Without demanding any human interaction, it can exchange data within a network.

1.5.1 The OSI model The OSI model is a well-known term in IT; it is an abbreviation of Open Systems Interconnection model. The model was composed such that the diﬀerent communication systems at the time could become more compatible. The OSI model has seven layers, [9] of which the 4th layer is important to this research. The layers are depicted in Figure 1.1 below.

Figure 1.1: Communication involving relay open systems [9] Chapter 1. Introduction 7

The transport layer provides a connection establishment, connection release, data transfer, expedited data transfer and suspend facility. [9] TCP and UDP are the most well-known protocols in the transport layer.

1.5.2 The TCP/IP model To be able to understand the process of sending and receiving data, the TCP/IP model is explained in this section. TCP/IP is a network protocol, similar to IPX/SPX and NFS. As a network protocol, the TCP/IP model can be related to the OSI model, where layer 4 is transport. Compared to the OSI model, TCP/IP has the application layer, which is similar to the application, presentation and session layers of the OSI model. Comparable, the network access layer in the TCP/IP model is related to the data link and physical layer of the OSI model. The other two layers are the same. In the TCP/IP model the transport layer, the protocol suite consists of transport layer services TCP and UDP. TCP has a diﬀerent data structure than UDP, namely segments compared to packets [10]. TCP and UDP are explained in more detail in section 1.5.3.

Figure 1.2: The TCP/IP layers with some protocols

The TCP/IP model can be seen in Figure 1.2, which shows the four layers of the model. It starts at the application layer, which is the interface. In this layer, one can request a website for example. The request is sent to the transport layer through a port. This can be any port, but with a website most likely the HTTP protocol and thus port 80 will be used. The transport layer divides the data into packets with headers such that they can be put back together the same way they were taken apart. These 8 Chapter 1. Introduction packets go to the internet layer where more information is added to the packet to ensure it reaches its destination and it can be returned. After the internet layer, the network access layer is reached. This is the actual physical layer, where the packet goes to the right device and can even send the right elec- tronic pulses. In the case of the website one is looking for, it is where the request is put on the network.

The layers are passed multiple times, as the request is sent and answered as well. At each cross- point in the route that data passes, a little extra information is added, such that the data can find its way back. An example of this is similar to the header before. A NAT can give different information such as a (public) IP address to the data. A NAT (network address translator) is a technique in a router, designed to assign IP addresses. Once the answer to the request returns, the NAT sees it is addressed to its own IP address and strips away this piece of information, after which the next (local) IP address can be found. This way the NAT knows which device in its network to send the data to. As can be seen in the Figure 1.2 each layer has its own protocols that can be used. The protocols shown in the figure are a few examples, as there are many possible protocols. Another important aspect of the model is the whole process of requesting a website, the route of this request toward the server and the server answering with access. In this process, some steps can be done partly simultaneously. For example, some parts of addressing, such as routing information or destination address, are done at the same time.

Figure 1.3 shows the TCP/IP process with the analogy of writing and sending a letter. In the application layer, one writes the letter, after which the letter can be put in an envelope and addressed in the transportation layer. The letter is then sent, which includes transportation to a distribution centre, sorting the letter and transporting the letter to the recipient. These steps all transpire in the internet layer. The letter is then received by the recipient, which is in the network layer. Here the recipient can read the letter. Using this analogy the difference between TCP and UDP can also become clear. If one writes a letter and addresses it to the wrong address, the letter will simply be lost or returned. If UDP is used, the letter gets lost and one cannot know if it was received or not. In the case of TCP, the letter is returned and an error will occur, as the sender is waiting for a confirmation of the recipient. Without a confirmation, the sender knows that something is wrong with the process of sending the letter. Data is sent in different packets, which could be seen as chapters of a long letter. It is possible that for example one of the five letters sent goes missing. Because the letters are numbered, the recipient knows that for example chapter two is missing. The recipient can return a message to the sender that one chapter is missing, after which the sender can send chapter two again. This is why TCP is a more reliable method than UDP, where the chapter is simply lost.

This research relates to the transportation part of the TCP/IP model. The methods that will be discussed are methods for traversing from the application layer to the internet layer.

Figure 1.3: Schematic of the TCP/IP analogy Chapter 1. Introduction 9

1.5.3 TCP and UDP From section 1.5.2 one knows there are diﬀerent methods for transport, namely TCP and UDP. These methods are protocols for a connection with data transfer within a network. The protocol used for the communication at this moment at Resato is TCP. TCP is a longer, more elaborate protocol and stands for Transmission Control Protocol. Before two devices can communicate, a three-way handshake should take place. This is the case if one wants a two-way connection, thus two TCP connections: One from device X to device Y, and one from Y to X. The process is shown in Figure 1.4. To begin with, device X sends a request for making a connection (SYN). Then device Y should reply to this with an acknowledgement (ACK) of the request and its own request for a connection, after which device X replies with an acknowledgement again. Once this is done, the devices can exchange data. With this data exchange, the receiver of data should acknowledge that the package of data has been received every time. Once the data transfer is ﬁnished, there will be a four-way handshake. This means device X sends a termination request, which device Y will acknowledge. Then device X will terminate the connection. Since there are two separate connections, device Y should also send a termination request which device X should acknowledge. An example to make TCP more tangible is the protocol POP3, which is used for emails. [11]

Figure 1.4: TCP three-way handshake between two devices

UDP stands for User Datagram Protocol, which is a connectionless protocol, which means there are no UDP sessions set up and acknowledgement or retransmission does not take place. The data is sent in a package, after which the data is extracted from that package by a UDP module at the receiver. [11] This protocol takes less time and, thus, is more eﬃcient. However, there is no need for acknowledgements of data. This results in a less reliable method of data exchange.

1.5.4 NATs As mentioned in section 1.5.2, a NAT is a network address translator. It is designed for assigning IP addresses in a network, such that external networks can connect. The technique is generally built into routers. It is important to note that a NAT is not a firewall. A NAT can be seen as a sorter, while it does not provide actual security. However, address and port translation in a NAT allow for strictness in a network. There are several basic types of NATs, a full cone NAT, restricted cone NAT, port 10 Chapter 1. Introduction restricted cone NAT and symmetric NAT. The Figure 1.5 shows a decision tree for finding some types of NAT with UDP. The tests are sending a STUN binding request to a server. The first test sends this request without asking for the change-request attribute, it does, however, in the other two tests. The change-request attribute contains a change IP and port flag, which is used for discovering the type of NAT the client is behind. In the first test, there is no response-address either, which means the binding response is sent to the source IP and port of the request. In the second test, the binding request contains both change IP and port flags. During the third test, the request contains only a change port flag.[12]

Figure 1.5: Schematic ﬁnding what NAT one uses (based on [12]) Chapter 1. Introduction 11

The full cone NAT allows for any inbound connections that are included in a formerly established rule. These rules are previously conﬁgured or can be created by a network administrator. The Figure 1.6a shows the full cone NAT. A restricted cone NAT, or address restricted cone NAT is similar to

(a) Full cone NAT (b) Restricted cone NAT

Figure 1.6: Schematic of different type of NATs explained [13] a full cone NAT. The difference with a restricted cone NAT is that an external host can only send a message when the internal host has already sent one before and thus the IP address is recognised. It is not, however, required to be in the same session, as a rule is made and kept at the first outbound connection. Figure 1.6b shows the restricted cone NAT. With a port restricted cone NAT not only the IP address, but also the port from an inbound connection has to be recognised. Further, this NAT is similar to the restricted cone NAT, as a rule is created with the respective IP address and port. This NAT is illustrated in Figure 1.6c. The symmetric NAT is similar to the port restricted cone NAT, but for each connection a new random port is assigned. This means only the external host that received a packet can connect and send a packet back to the internal host. The symmetric NAT is shown in Figure 1.6d.

1.6 Use of TCP or UDP

TCP and UDP are the best-known transport protocols. However, there are also other, newer protocols such as SCTP, DCCP and MPTCP. [14] Stream Control Transport Protocol (SCTP) is another protocol that can be used, instead of TCP or UDP. The protocol has the ﬂexibility of UDP, but the reliability of TCP. In the research of Henrik Ostendahl¨ (2005), TCP and SCTP are compared according to performance over HTTP. [15] This research concludes that SCTP is slower than TCP, which could be because supporting software has to be developed to compete. In this research, they only made a comparison for web browsing, which means it is not clear if the protocol would hold up for transporting loads of data. However, the research in Jinyang Shi et al. (2004) shows that SCTP is a proper solution for multi-access, which is a technique where multiple users can connect and transmit over one medium. [16] The research in Ra- jesh Rajamani, Sumit Kumar, and Nikhil Gupta (2002) also supports SCTP usage and demonstrates 12 Chapter 1. Introduction that SCTP can improve throughput and reduce latency in web traﬃc. [17] Firewalls tend to discard SCTP packets, [18] thus they are not the best option for this problem. In the study of Shahrudin Awang Nor, Raaid Alubady, and Wisam Abduladeem Kamil (2017), the researchers compared TCP, UDP, SCTP and DCCP, and concluded that TCP is the protocol with the least package loss and highest delivery rate. [19] However, DCCP, Datagram Congestion Control Protocol, turned out to perform the best on throughput, jitter and delay. The research was on video streaming over LTE but proves that data transfer over TCP or DCCP are the least wasteful methods. DCCP has also been proven to function implemented in practical big data management. [20] Nonetheless, if no packet loss is important DCCP is not the best method. [21] MPTCP is the abbreviation for MultiPath TCP and is an extension for TCP, [22] it supports two endpoints that use multiple paths between them simultaneously. [23] With MPTCP multihoming is more accessible, which is especially useful in data centres because it allows for improved performance and higher availability. [18] In fact, MPTCP is already universally implemented in, for example, Ap- ple iOS [23]. There are many other protocols that people made themselves to replace or complement TCP. An example is MPLOT [24], but for the purpose of this research these other protocols will not be considered.

In the Netherlands, generally, the connections are good enough, so that even over UDP packets are unlike to get lost. However, this is not the case in every country over the world. Therefore, it is important that in those countries a TCP connection is used. As Resato desires a single method that they can implement everywhere, it is most likely the best option not to use UDP. There is, however, the possibility of TCP over UDP, which makes for more reliable packets. When TCP packets are sent over UDP, TCP is more likely blocked by ﬁrewalls than UDP, which would mean the chances of bypassing the ﬁrewall are larger when using UDP.

1.7 PTC ThingWorx

PTC ThingWorx uses ports 80, 8080, 8443 and 443, which are HTTP and HTTPS ports for regular requests. Besides these standard ports, ThingWorx also uses port 8000, 25, and 587, which are SDK and SMTP ports. ThingWorx also uses ports from the external database connection, extensions and the local system. [25] As one can see ThingWorx uses many different technologies and thus ports, which is a method where they combine those different ports. This is a slow method, it is better to use one port, which they will probably do in the future. However, this is not the most important aspect of transferring data; one still needs to be able to bypass a firewall. For ThingWorx to be able to pass through a firewall, one has to allow access to specific IP addresses. Naturally, this means that the customer would have to accept these IP addresses, which means the customer has to do something. Therefore, PTC ThingWorx does not suffice in bypassing the firewalls. However, it is possible to build one’s own tunnel through the firewall and use ThingWorx for the collection, analysis and the further retrieval of data.

1.8 Problem holder and stakeholders

In this section, the problem holder analysis and stakeholder analysis are shown. These analyses are done to have a clear overview of who to keep in mind while doing the research, as each stakeholder has a diﬀerent perspective of, and ideas about the problem. This can be useful in reﬂecting on the problem-solving method. Chapter 1. Introduction 13

1.8.1 Problem holder analysis Anybody that uses machines and wants to make a connection with these machines can have this problem, preferably without modifying the environment. This is the case for manufacturers, but also for people with a smart home. To be speciﬁc, the main problem holder is Roelof Jan Boer, since he is the person leading this project. Resato is the main contractor for the project. They want to ﬁnd a possible method to conduct their communication with their machines. Therefore, R.J. Boer is the main problem holder.

1.8.2 Stakeholder analysis In Table 1.1 below, one can see the different stakeholders with their goals and requirements towards this research. None of these stakes are conflicting. R.J. Boer is the person who actually experiences the problem as he is responsible for the work package. He is also the person who is responsible for the IT department of Resato. The final requirements of Resato besides the list of methods are the trade-offs they are based on. These trade-offs can be divided into multiple requirements, such as that the method should be standardised and thus take little time and effort. The method should work in almost every country, because Resato has machines all over the world, which is also why the method should be ethically responsible. Every country has different ethical and technical limits, which should be taken into account not to agitate any company or government. The little time to implement is indicated in the requirements in chapter3 as availability. The fact that it has to work in almost every country is similar to being able to use it at different companies, thus reusability. As mentioned before, the ethical responsibility is represented by customer approval. The costs are relative but can be assumed as high when over e20 000 per year.

Stakeholder Goals Requirements Resato: Roelof Jan Boer Solve the communication Have a selection of methods problem between Resato and on communication between their placed machines. Gain machines. Have a knowledge to use for the representation of one or more subsidised project. methods. - Take little time to implement - Works in almost every country (80%) - Be ethically responsible - Doesn’t cost much money - Customer doesn’t have to do anything Innovation cluster Drachten: Solve the same communication Receive information about a IT departments problem Resato has. possible solution. Province of Friesland Have research done on the Receive any information about subject. a possible solution.

Table 1.1: Stakeholder analysis 14 Chapter 1. Introduction

1.9 System description

The system is described in Figure 1.7, which shows the actual system of machine communication. The system shows the communication between Resato and the machine, where the data travels through the customers’ and Resato’s network, such that information can be exchanged. Resato asks for information, whereas the machine has to send it. This data should go through the firewall of the customer. A firewall is either hardware or software that protects a network by scanning any data asking for access. It does so to keep any dangerous data out of the network. The goal for Resato is to use the data to conduct preventative maintenance. This project is situated around the ’pass firewall’ action, from the moment data is sent until the data is received. As Resato would also like to send data to the machine, it should bypass the firewall again. There is artificial intelligence used for the prediction of behaviour. At this moment Resato uses such an artificial intelligence on one machine, with the software of PTC ThingWorx. The goal is to be able to predict behaviour on all machines that are situated at customers.

Figure 1.7: System of machine communication

1.10 Risk analysis

The research consists mostly of a literature study. There is no apparent risk in doing literature research. The only diﬃculty that might be encountered is when one focuses too much in a particular direction. Knowing this, this problem can be avoided. This is the same case with the problem that has been given. It is important to make sure this is the actual problem and if the solution might lie somewhere else.

With the test design, no problems should occur. If the test is done in a closed environment, there should be no danger to any part of the company. The programming is done by a junior programmer; thus the progress is dependent on the programmer. There is the risk of the test design not working properly. Nevertheless, a test design is made to be tested and to ﬁnd any possible diﬃculties. Thus, the test design not working properly would only be part of the research and can be used to improve the design.

There is the risk that the research will not provide any useful outcome for Resato.

Another risk is that it will not be possible to continue the research due to, for example, illness, or not ﬁnding a solution. Chapter 1. Introduction 15

1.11 Planning

In the second block, the research will start full-time. This will be done at Resato, such that anything can be discussed or evaluated immediately. In Figure 1.8 one can see the Gantt chart that goes with the planning in Table 1.2.

Process step Start date End date Start IP / workshops 21-feb 12-mar RDP 12-mar 15-apr Literature study 16-apr 13-may Start test design 14-may 20-may Evaluate test design 21-may 27-may Conduct further research 21-may 3-jun Finish preliminary report 5-jun 5-jun Try new test design (if needed) 4-jun 6-jun Make poster 7-jun 13-jun Finish research and evaluate 7-jun 17-jun Write report 12-mar 17-jun Finish ﬁnal report 18-jun 18-jun Presentations 18-jun 25-jun Symposium 26-jun 26-jun

Table 1.2: Planning for block 2

Figure 1.8: Gannt chart planning block 2

Chapter 2

Research Design

In this chapter, the research topic, design goal and scope, research problem, design steps and needed resources are discussed. In the sections, the problem statement, design goal and research questions are given. These are used throughout the research to ﬁnd a solution.

2.1 Research Topic

As mentioned before, this problem is situated around the topic of IoT, which can be shared under an IT department. With the context of the previous chapter, a problem statement can be made.

Problem statement ‘It is complex and time-consuming for Resato to be able to communicate with their machines while considering their customer’s environment’

In chapter1, the meaning of trade-offs and the customer’s environment can be found, just as the reasons behind the fact that Resato would like to communicate in the first place. To summarise, the trade-offs need to be found to ensure the method is ethically responsible for using. The customer’s environment should have as little change as possible. Resato would like to communicate with its machines in order to improve their service and develop a prediction model.

2.2 Design goal and scope

In this section, the design goal and scope of the research are mentioned and explained.

2.2.1 The design goal The design goal is: ‘To develop a test design of a method for machines to connect, with limited change in the customer’s environment.’

The main goal of the test design that will be made is to ﬁnd a prototype, which will help steer in the right direction. Resato wants to have an idea of which methods ﬁts the company. The test design can easily be made with the help of the programmer. It will be constructed with the use of computers. One can use two setups with each their own network to represent Resato and the customer.

As mentioned in the trade-oﬀs, it is important to limit the change in the customer’s environment. The main goal is to have access to the machine without needing the customer to do anything. This

17 18 Chapter 2. Research Design way Resato keeps control over the access to information, without having to rely on the customer. For the customer, it is also better if nothing has to be adjusted, as they purchase a product with service.

2.2.2 Scope The scope of this project is limited to finding methods to communicate with the machines. According to Resato, the problem lies within bypassing the firewall. However, it is important to additionally consider other options, such as not using their network at all. For example, if one is able to construct their own VPN, bypassing the firewall is not necessary. Thus, methods of communication should be found and evaluated, but also other possibilities should be taken into account.

2.3 Research problem

The research is built up from one research question, with some sub-questions to help along with answering that one research question. In this section, those questions are mentioned.

Research question ‘What is the best method to communicate with the machines, with limited environment change?’

The communication Resato wants with their machines is to be able to do preventive maintenance. This best method is dependent on the requirements of Resato. Therefore, this is included in the following sub-questions. As mentioned above, these sub-questions are necessary to answer the main question. Some questions have their own sub-questions, in order to be able to answer them.

Sub-questions • What are methods for communication well known and used?

Does PTC ThingWorx not suffice? Would TCP or rather UDP fit the situation? What are other possibilities than bypassing the firewall? • How do the methods score on their requirements?

• How can a traversal method be tested?

What are important factors to include in the test design?

2.4 Design steps

In this section, the design steps are discussed. Many methods can be used for a design. In this research those of M.C. Jackson will be used. Besides showing the general steps, these are modiﬁed to a proper design plan for this research.

Using the system approaches from System of Systems Methodologies (SOSM), see Figure 2.1, the following can be found.[26] The problem does not have many subsystems and the existing subsystems only have a few highly structured interactions. These will not experience much change over time. Chapter 2. Research Design 19

Besides that, they are not much aﬀected by the actions of their parts, nor by any environmental inﬂuence as long as the network is adequately protected. This means the system of communication between Resato and its machines is simple if the right method is found. The participants are the ones involved with the system. Those relations should be taken a look at, which results in a unitary relation, since the participants have a common purpose and similar objectives and interests. This is the case as both Resato as the customer want the communication to work. As it is a technical problem focused on optimising the system towards one goal, it is simple and unitary, which means Hard Systems Thinking can be applied.

Figure 2.1: Systems approaches related to problem context in the SOSM [26]

The Hard Systems Thinking approach consists of several steps, shown in Figure 2.2. These steps can be formulated for this research as follows:

1. Understand the context and the problem;

2. Understand the ethical and technical boundaries;

3. Identify and select the (alternative) methods;

4. Select a proper method and build a test design;

5. Evaluate the test design;

6. Use the analysis of the test design for deﬁning more selective requirements;

7. Identify improvement for the test design;

8. Evaluate the test design;

9. Identify further research requirements.

Steps 6 to 8 are left out of the scope of this research, due to the length of the project. It is important that, while doing the research, the context is continued to be considered, since the context might change due to a diﬀerent perspective on the problem or a diﬀerent kind of method to bypass the 20 Chapter 2. Research Design problem.

Figure 2.2: Systems analysis methodology [26] Chapter 2. Research Design 21

2.5 Needed Resources

Multiple resources are needed to do proper research. In this section, the main resources are explained. These include literature and a test design.

2.5.1 Literature resources The most important part of this research is to find methods to bypass firewalls. Literature on communication methods is also useful. According to Resato, the central aspect of this research is a literature study since they do not have the available resources to do this themselves. Therefore, during this research, the literature study is extended. This extended literature study is on the methods and can thus be found in chapter4. Useful databases to find proper literature are SmartCat and Google Scholar.

The research started with search terms such as: • IoT

• Manufacturing

• Machines

• Communication

• Firewall Further in the research more terms were added, such as: • NAT

• Traversal

• Network

• Tunnelling From the literature in the beginning, some information could already be found, as this is a subject that many companies deal with. However, there is a difficulty often encountered in literature study. A great amount of literature gives methods that are meant for one’s own plant, which results in many methods within one’s own network and not specifically outside. It is notable that this literature men- tions the use of a firewall to protect one’s network, which is exactly the problem that Resato would like to bypass. In, for example, banking services, communication is made between the customer and service provider, which is Resato in this case. In this example, a reservation system is often used, but that does not have real-time interaction. What can be useful for this research is looking into rational incentive mechanisms. However, these methods still require the customers’ participation.[27] An incentive mechanism is based on game theoretical analysis and is designed to promote the desired behaviour of rational players, such as a computer. [28]

From the research in S. Kubler, K. Främlingand A. Buda (2015) it can be found that the QLM, Quantum Lifecycle Management, standard was developed to have the main requirements of IoT ful- filled; to have peer-to-peer communication, also in a secure environment, such as a customers’ at Resato. [29] QLM makes use of a TCP connection. The researchers promote a piggybacking based model that allows for two-way communication through a firewall. This method does require acknowledgement from the customers’ network to be able to enter it. 22 Chapter 2. Research Design

Some known communication technologies, such as RFID (radiofrequency identiﬁcation) or WiFi, can communicate only on a relatively short distance. In the case of WiFi, a range of 100 meters. [30] This information can be used as a start in this research. As can be concluded from these papers, there are many methods available. Nevertheless, many of those methods are not useful to Resato. This shows that this research is supposed to help Resato make a selection of methods that would be proper for the company.

2.5.2 Test design After the literature research, together with the knowledge of a junior programmer, a test design can be made. This test design will be tested and evaluated at Resato, which is the ﬁnal step of this research. As mentioned before, this test design can be made with two computers. Chapter 3

Requirements

Requirements are necessary for categorising the methods in this research. With the use of requirements the methods can be ranked, which will result in a clear overview of the methods. In this chapter, the requirements are evaluated and rated on importance.

The requirements in this research are based on software quality assurance, where stakeholder requirements are the basis for deciding which method would fit the problem. Software quality assurance (SQA) is ‘a set of activities that define and assess the adequacy of software processes to provide evi- dence that establishes confidence that the software processes are appropriate for and produce software products of suitable quality for their intended purposes.’ [31] There are multiple aspects to software quality assurance, such as planning, technical and development reviews, software testing and demon- stration. [32]

In A. Mili and F. Tchier (2015) the attributes for testing software are divided into several categories. Namely, functional, operational, usability, business and structural attributes,[33] where the functional attributes define the input/output behaviour of software products. The operational attributes define the functions and condition of the services that are delivered to its users. There are five attributes that are operational. These are latency, throughput, efficiency, capacity and scalability. Usability attributes are a measure of the services provided to the user, the extent to which the product is easy to use. Business attributes are more in consideration of the software manager in the development of the product, such as costs, maintainability and reusability. The structural attributes are also more in consideration of the developers, but rather the technical aspects of development.

From the attributes mentioned above the following are deemed important in combination with the stakeholder analysis:

• Throughput

• Latency

• Packet loss

• Overhead

• Availability

• Reusability

• Costs

• Customer involvement

• Customer approval

23 24 Chapter 3. Requirements

Throughput is the absolute performance of the system, which is the volume of processing that can be delivered. The throughput in this research is in transactions per ms. A value for throughput that an average router can handle ranges from 1 kb/s to 2 GB/s. Latency is the perceived response time between the input and output of a system. The time it takes for the request to actually reach the server is called delay. The value for latency in typical internet connections is below 100 ms, but is around 25 to 40 ms average. [34, 35] Packet loss is another important aspect to take into account. When packets tend to get lost, not all the data will be received. This results in incomplete data, which is not useful for processing. The maximum amount of packet loss allowed is 2%, but below 1% is the advised amount. [34, 36] Overhead is the network overload, which is the extra delay, bandwidth, memory etc. necessary for the transaction. The average overhead in a local network range from 4% for a simple task to around 20%, but overhead can easily reach above the 50%. [37, 38] Availability is the ease of receiving the software or hardware necessary for implementing the method. Reusability is relative to the amount of effort that has to be put in once the method is implemented at another customer. This means the method is highly reusable if no adaptations need to be made. The reusability also relates to the ability to use the method in most countries, as Resato would like to be able to use the method in almost every country they have machines. The costs are for the implementation and upkeep of the method, which can consist of a monthly payment for the use of a server. These costs are high when they are over e20 000, which should not be the case for keeping a server. Another important requirement is customer involvement, which should be slim to none because Resato does not want to have to rely on any action by the customer. The last requirement is customer approval, which is important for keeping the customer satisfied and allow for data extraction from the machine. This also relates to the different countries that would allow for the method to be used. To ease the outcome, the methods are ranked on each attribute as good, deficient or acceptable, a 10, 1 or 6 respectively.

In order to rank the attributes to their importance and thus ﬁnd the most important method, a scorecard is used. Each attribute is listed with its ranking, across from the methods. The score of each method is taken relative to the ranking of the attribute, which results in an overall score for each method. Each attribute has a score of 1 because they are of similar importance. However, customer involvement has a score of 2, because a method cannot be used by Resato if customer involvement is necessary. The scorecard is shown in section 4.16 Figure 4.10. Chapter 4

Methods

In this chapter, the different methods found for bypassing a firewall and communicate are shown. At first, an example of the use of these methods is given, namely, Skype. This will give an insight in how methods can work and complement each other. After this example, methods are explained and evaluated, next a table is given with the general advantages and disadvantages of each method.

4.1 Introduction

Skype An example that one can use for this research is the peer-to-peer application called Skype, which allows for one to make phone calls from one device to another. As Skype is a program used all over the world, where it works practically everywhere, it is used as an example of what the methods can be used for. This section explains the known techniques that Skype uses to let peers connect through ﬁrewalls in any country.

Skype is an example of a Voice over IP programme, which allows for phone calls to be made over the internet instead of cable. It is not possible to find the exact method that Skype uses, as it makes use of secret, proprietary protocols that cannot be studied. [39] However, it is clear that Skype makes use of something called ‘supernodes’, this are nodes that support firewall traversal. It is probable that they use some sort of STUN server, such that the existence of a firewall can be determined by other nodes. Nevertheless, there is no information on these ‘supernodes’, thus it is not possible to describe their process. [39]

In Ying-Dar Lin et al. (2010) the researchers attempted to find the influence of NAT device to a VoIP connection. [40] One element they found is that Skype has its own technology for port prediction. The table in Figure 4.1 below shows different NAT traversal technologies (NTT) for several VoIP applications. [40] From their research, it can be concluded that in VoIP applications, the NTTs path check, port prediction and relay first are not commonly used. The research also points out that in case both peers are behind a multilevel NAT, a direct connection cannot be established. From the research in S.A. Baste and H.G. Schulzrinne (2006) the process of making a connection through Skype can roughly be deducted.[41] At first, the Skype client opens a random TCP and UDP listening port, besides opening a HTTP (80) and HTTPS (443) port. It then uses a combination of STUN and TURN protocols to define the type of firewall it is behind. At first, a UDP package is sent to the entry, if after about five seconds there was no reply it would try to create a TCP connection. In case this was still unsuccessful it would try to establish a connection with the HTTP port and after failure, the HTTPS port. When all these actions fail, it would wait for around 6 seconds and repeat the process four times before reporting an error. There are a couple of Skype nodes that are used by the Skype client to connect to and it randomly picks one of these. The research concluded that the Skype client was able to determine the type of firewall it was behind

25 26 Chapter 4. Methods

Figure 4.1: NAT traversal technologies for some VoIP applications [40] in two possible ways. One exists of exchanging messages with the Skype node by using some sort of STUN protocol. The second option is that during login, the Skype client exchanges data from a few nodes after making a TCP connection with the Skype node. After this step, the Skype node would still have to use a sort of STUN protocol to deﬁne the type of ﬁrewall. From the experiments, it also became clear that this information is stored in the Windows registry, and refreshed periodically. However, the researchers are unable to say how often it is refreshed, as the messages from Skype are encrypted. An important aspect of the Skype sessions is that data packets are still transferred, even if there are no noises. These ‘silent packets’ are useful to avoid connectivity problems due to a sudden drop in data exchange. [41] It is possible that the customer uses white listing, which is restricting access to all internet sites except the ones approved. White listing costs much maintenance, but it can prevent any communication other than the approved. [42] It has also been shown that a system comparable to Skype can still be observed because a reproduction is complicated and unattainable in most cases. [43]

In conclusion, Skype is a program that uses diﬀerent approaches together. This way it is most likely that a connection can be established one way or the other. This is likely to be the best approach, as every company has a slight diﬀerence in the restriction of their NAT.

4.2 STUN

Session Traversal Utilities for NAT (STUN) is a protocol that provides a device with its location behind a NAT and the kind of NAT it is behind. STUN works as follows: The client sends a message to the STUN server containing its IP address and port in the payload. The server can then examine this message and reply with the IP address and port after the client receives this message, it can compare the information and thus see if there is a NAT in-between. If the information is different, it will send new messages to the STUN server to find the NAT behaviour and type. [44] For STUN messages TCP and UDP both support transport. [45] There are multiple STUN servers that exist and one can make use of, for example, Google has multiple servers one can use. Therefore, besides the development costs of a program to use STUN, no further costs are required. As STUN only provides the device with information, it does not affect the general throughput, latency, packet loss or overhead. With the use of STUN, no customer involvement is necessary and the sending of information will go through a regular, relatively safe route. Figure 4.2 shows the use of STUN and TURN, the last of which is explained in the next section.

STUN is only useful when the NAT device has an independent filtering rule, which means any device Chapter 4. Methods 27 can send a packet. However, when the NAT has an address and port dependent filtering rule (symmetric NAT), which means a packet can only be sent to a device if there was previously communication, STUN does not suffice. [40] When this is the case, the TURN or PS-STUN protocol can be used. The table in Figure 4.4 summarises the STUN, TURN and ICE protocol. ICE is explained in section 4.4.

Method Advantages Disadvantages STUN - Throughput: protocol dependent: 10 - Reusability: does not work with all - Latency: protocol dependent: 10 NATs: 6 - Packet loss: protocol dependent: 10 - Overhead: protocol dependent: 10 - Availability: STUN servers available: 10 - Costs: already exists: 10 - Customer involvement: none: 10 - Customer approval: acceptable: 6

Table 4.1: STUN evaluation

Figure 4.2: Schematic of the use of STUN and TURN

4.3 TURN

TURN (Traversal Using Relays around NAT) is a protocol that allows for a device to connect to another device with the use of relay. This way the devices can establish a connection, even if a NAT would not allow for a Peer-to-Peer connection. TURN can have a delay, because the packets go through the server twice as it has to relay. [40, 42] This can result in more overhead, because of more nodes on the route of the data packets. One can create their own TURN server or make use of a company to host one. Since TURN can use a TCP connection, it also tends to have the reliability of a TCP connection. This would mean the packet loss is low. Because a TURN server has to be provided with a high-bandwidth connection to the internet, it can be costly. [46] A TURN server including 28 Chapter 4. Methods other services can be rented for $500 per month, which equals $6000 per year. [47] Therefore, the TURN server should only be used when a peer-to-peer connection is not possible. If a high-bandwidth connection is necessary, this means the throughput is likely high. Initially, TURN was created to support multimedia sessions signalled using SIP, and as part in the ICE method as an extension to STUN. [46] Which also means no customer involvement is necessary and the connection is relatively safe. Figure 4.2 shows a schematic of the use of STUN and TURN in a system.

Method Advantages Disadvantages TURN - Throughput: acceptable: 6 - Latency: delay: 6 - Packet loss: low: 10 - Costs: relatively high, but below max: 6 - Availability: acceptable: 6 - Overhead: chance of higher overhead: 6 - Reusability: works for every NAT: 10 - Customer approval: TCP reliability: 6 - Customer involvement: none: 10

Table 4.2: TURN evaluation

4.4 ICE

Interactive Connectivity Establishment (ICE) is a method that combines the use of a STUN and TURN server. It then uses a communication protocol to establish a connection between two devices. ICE uses hole punching techniques [46] to find if, before relaying a connection, it can make one directly between devices, if not it will proceed using a relay server. [40] The method is described in J. Rosenberg (2010) and starts with finding a transport address candidate.[48] This is for a specific transport protocol and consists of the combination of an IP address and a port. The local interface is called the host candidate and allows to allocate ports, after which further candidates can be located. These can be either on the TURN server or in the public network, which is used when only STUN is utilised. If it is the last case, the STUN server informs the client of the candidate through copying the transport address. The TURN server assigns a port from its IP address to generate a response when the request arrives.

Figure 4.3: Deployment solution ICE [49] Chapter 4. Methods 29

Then it advises the server of the relayed candidate, after which it will act as a relay and forward traﬃc between the two nodes. Connectivity checks will be executed, when the candidates are sorted according to the priority of the pair. These checks issue a four-way handshake, where both clients execute a check, after which this pair is nominated for use and they can start exchanging messages. Besides the full implementation of ICE, there is also a lite version, [50] which can be used when full implementation is not yet possible. In the research of Yang and Lei (2016) ICE is combined with the SIP protocol, such that the candidate addresses found by ICE are added to the SIP protocol as supplementary features, after which the addresses can be exchanged through SIP. [49] The Figure 4.3 shows the structure of this method and Figure 4.5 the belonging procedure. From the research, it can be concluded that the combination of these methods works for traversal of all NAT types. As ICE can be conﬁgured in the way that has the least delay, overhead, packet loss etc. as the TCP connection allows for, these factors are dependent on that connection.

Method Advantages Disadvantages ICE - Reusability: works for all NAT types: - Costs: of TURN server: 6 10 - Availability: is available in code: 6 - Customer involvement: none: 10 - Latency: chooses fastest connection: 10 - Throughput: network dependent: 10 - Packet loss: network dependent: 10 - Overhead: network dependent: 10 - Customer approval: acceptable: 6

Table 4.3: ICE evaluation

The table in Figure 4.4 shows a comparison of the STUN, TURN and ICE methods mentioned before. One can see that STUN is not possible for certain types of NATs, except in combination with other methods.

Figure 4.4: Comparison on STUN, TURN and ICE [40] 30 Chapter 4. Methods

Figure 4.5: Procedure NAT traversal [49] Chapter 4. Methods 31

4.5 PS-STUN

In Wang, Lu and Gu (2006) research is done on a protocol to use if STUN does not suﬃce because of a symmetric NAT. [51] The algorithm was designed such that a middle server is not needed, which should ensure less delay. Yet, not every type of NAT can be traversed with PS-STUN. The table in Figure 4.6 shows the combinations of NATs divided into classes where STUN does not suﬃce. How- ever, PS-STUN is only adequate for classes A, B and C. In this table P and R type are progressive symmetric and random symmetric NATs respectively. The PS-STUN method is based on UDP packets and provides the ability to make a direct connection between clients. The goal is to increase NAT traversal capability and system performance. With the use of PS-STUN, there is a chance of packet loss due to a high sending speed. [51] The method is not well known and no further research was done into it, which results in no clear image of the throughput, latency, overhead and the program itself.

Figure 4.6: Situations where NATs can’t be traversed by STUN [51]

Method Advantages Disadvantages

PS- - Customer involvement: no NAT - Costs: development costs: 6 STUN adjustments: 10 - Reusability: does not work for all NAT combinations: 6 - Latency: less delay: 10 - Availability: STUN servers available, - Customer approval: acceptable: 6 extension not: 1 - Overhead: UDP based: 6 - Packet loss: can occur due to UDP: 1 - Throughput: UDP based: 6

Table 4.4: PS-STUN evaluation

4.6 3G/4G/LTE

The use of 4G/LTE is a relatively easy method, as it goes around the network of the company. Besides this, 4G/LTE has the same frequency almost all over the world, which means it is a viable option to use. Some institutions use it in for example anchored measurement equipment throughout the Netherlands. From the research in Kamil, Nor and Alubady (2015) it can be concluded that for a connection over LTE with the least package loss, the use of TCP is possible. [21] The average latency for a 3G network is 80 ms and that of a 4G network 45 ms, [52] whereas the new cat 9 and 5G networks 32 Chapter 4. Methods have an average latency of 24 and 8 ms respectively. [53] The research in Nor, Alubady and Kamil (2017) also made a comparison on jitter, which is directly proportional to delay. [19] The overhead in a LTE network generally ranges between 15 and 25 percent. [54, 55] The study in Lao and Teng (2011) shows the possibility of using a 3G network to make a connection to a machine, [56] resulting in the use of VPN technology to control a private IP together with the protocol L2TP and IPSec. L2TP is the abbreviation of layer two tunnelling protocol and allows for tunnelling in a network. [57] However, the use of a method such as LTE, can result in many costs, especially with the number of machines Resato has. The costs for using LTE will deﬁnitely exceed the e20 000 per year. At this moment Resato has around 200 machines, in a quickly expanding market. In case a 4G connection costs e10 per month, this would be e120 per year per machine, thus at least e24 000 per year. Some companies also pointed out that the customers will not be happy knowing that there is a separate connection placed within their network, which could serve as a weak spot to their security. Some buildings scramble wireless connections due to their construction. For example, buildings with much metal will not allow for a good connection through 3G, 4G or LTE.

Method Advantages Disadvantages 3G/4G/LTE - Reusability: applicable almost - Customer approval: dislike everywhere: 10 customers: 1 - Latency: acceptable: 6 - Costs: high: 1 - Customer involvement: none: 10 - Overhead: some: 6 - Throughput: acceptable: 6 - Availability: good: 10 - Packet loss: none: 10

Table 4.5: 3G/4G/LTE evaluation

4.7 SWEET

SWEET is a system developed by Houmansadr et al. (2017) for unobservable communication over the internet. [43] The traffic patterns of an imitated method such as Skype make the system more noticeable than a non-imitated system, therefore, SWEET is developed. [58] SWEET uses a public mail provider such as Gmail to exchange encapsulating emails, which allows for the emails to go through the standard email filtering mechanisms. The emails are sent to a general email address or SWEET server, the IP address and recipient’s email address are not observable, which all results in the emails going through filtering mechanisms and remain unidentifiable. [43] The Figure 4.7 shows the main architecture of the SWEET server. The email agent in the figure consists of a SMTP and IMAP server and receives traffic and registration emails. The converter then extracts and decrypts the tunnelled information, after which it sends it to the proxy agent, which sends it to the requested destination. [43] This process works similarly the other way around, towards the client. Chapter 4. Methods 33

Figure 4.7: Process of SWEET [43]

Besides the protocol-based design where the email agent is connected with a SMTP or IMAP/POP3 server, SWEET can be webmail-based. The email agent is then connected through HTTP/HTTPS to the client. [43] The email agent was implemented using Fetchmail, which is a mail retrieval daemon that downloads messages and passes them on. [59] The research on the usage of SWEET concluded that one is able to perform 35-70 web downloads a day while remaining unobservable, [43] such that the email usage does not appear abnormal. The research did ﬁnd that there is some latency and overhead, but SWEET still works acceptably. The bandwidth and thus throughput is kept low in order to remain unobservable, which is not necessary when there is little chance of problems from the government. The programs used can be found in the research together with the steps, which make it easier to use. [43] No customer involvement is required, but it does not appear as the most secure method, which might result in objection from the customers. The method does, however, make use of client registration in order to protect from DoS attacks.

Method Advantages Disadvantages SWEET - Reusability: almost always works: 10 - Costs: implementation costs: 6 - Latency: acceptable: 6 - Throughput: low bandwidth: 1 - Customer involvement: none: 10 - Packet loss: little: 10 - Availability: only implement for machine: 6 - Customer approval: acceptable: 6 - Overhead: acceptable: 6

Table 4.6: SWEET evaluation

4.8 WANTS

WANTS (WiFi Assisted NAT Traversal Scheme) is a method designed by Tseng et al. (2013). [60] The researchers were looking for a method diﬀerent from STUN and TURN, thus they developed WANTS for a SIP-enabled surveillance patrol robot. The principle of the WANTS method is to discard of any protocol messages that are not necessary to shorten any delay in the establishment of a session. [60] In the problem of this research both devices are behind a NAT, which the research provides a solution 34 Chapter 4. Methods for. However, there is not enough information about this method to be able to investigate it further, besides this, WANTS is quite speciﬁc [61] for the use with a mobile device and SSPR. Therefore, it is not further discussed in this research.

4.9 CAN

The Context Aware NAT (CAN) traversal scheme introduced by Tseng et al. (2013) operates with a SIP based proxy and STUN servers.[62] Similar to the WANTS method, CAN decreases the number of connectivity checks, such that it is faster than ICE. The steps of CAN start with gathering information about the context of the network, after which the information is exchanged with a signalling protocol. Once the information about the NAT is gathered, a connectivity check is run, this results in the path used for the session, which can then start. [62] CAN should perform better than ICE [62], but the fact that the context information has to be collected and stored is a disadvantage. [61] There is not enough research done to be able to use CAN and compare it to the other methods.

4.10 CODO

Cooperative On-Demand Opening (CODO) is a middleware system for NAT traversal. [44] It config- ures open holes in a firewall when needed and supports both inbound as outbound connections. [63] The Figure 4.8 shows a CODO structure, where CL means client library, which is linked with the firewall agent (FA) and applications. To use CODO it is, however, required to update the NAT. [44] Besides this, CODO is not backwards compatible, but it does provide proper security.

Figure 4.8: CODO topology [63]

The overhead is high when setting up a connection, but not during the data communication. [63] Because the method can use TCP, no packet loss has to occur. The method is not well known and no open source code can be found, which means it has to be developed. The use of a server app also Chapter 4. Methods 35 adds to costs, to keep it running. In the research, only messages of 1 kilobyte were sent, which results in little knowledge on latency and throughput.

Method Advantages Disadvantages CODO - Customer approval: Proper security: 10 - Customer involvement: requires NAT - Packet loss: none: 10 updates: 1 - Overhead: low during communication: 6 - Reusability: NAT dependent: 1 - Overhead: high during connection: 6 - Availability: no available code: 1 - Throughput: no information: 6 - Latency: no information: 6 - Costs: development and server app costs: 6

Table 4.7: CODO evaluation

4.11 NSLP

NAT/Firewall NSIS Signalling Layer Protocol (NSLP) is located in the NSIS framework and is a path-coupled signalling protocol for NAT and firewall configuration. [44] It allows for hosts behind a firewall to obtain a public reachable address and receive data traffic. [64] Before understanding NSPL, NSIS should be explained. NSIS is the abbreviation of Next Steps in Signalling, the protocol suite supports signalling applications that manipulate and/or install state in the network. [65] NSIS entities are network elements, such as a router, that can understand NSIS signals. [44] Yet, not every node on the path has to be a NSIS entity. NSIS has two layers, a ‘signalling transport’ layer and a ‘signalling application’ layer, where NSLP is located in the application layer. [65] From the research in Steinleitner, Peters and Fu (2006), NSLP can be implemented and is applicable to most networks. [66] It also shows that when the system tries to open a hole, the processing time is very slow, while at other times the processing time is constant and between 40-50 ms. This is most likely the case because the researchers used Netfilter1, they expect another method could be faster. Netfilter also stalls the packet processing during chain updates, but there are alternative options to implement. Netfilter facilitates NAT, packet filtering and mangling. The session setup time remained under 150 ms in the research, which is acceptable as it also comprises the more time-consuming path discovery and setup. There is no high overhead and the memory utilisation slowly increases linearly with each session. The NAT devices’ owner can authenticate and decide which NSLP nodes are allowed to punch holes into the private realm of the NAT. [67] Which means NSLP does require changes in the client’s firewall, which is not what the client would like to do. Because there is not much information about the method yet and the code cannot easily be found, one would have to develop the program from scratch. In the study of Klaver (2007), the throughput and packet loss is tested using disruptive packets. [68] The test shows that packet loss only occurs with the disruptive packets and not the rest of the data stream. The test also shows that the maximum throughput is dependent on the hosts.

1https://netﬁlter.org/ 36 Chapter 4. Methods

Method Advantages Disadvantages NSLP - Reusability: applicable to most - Customer involvement: requires NAT networks: 10 updates: 1 - Latency: acceptable session setup time: - Customer approval: average: 6 6 - Overhead: high during connection: 6 - Overhead: acceptable overhead: 6 - Availability: method has to be - Packet loss: generally none: 10 developed: 1 - Throughput: acceptable throughput: 6 - Costs: development costs: 6

Table 4.8: NSLP evaluation

4.12 Tunnelling

Tunnelling exists of transferring data from one communication endpoint to another over diﬀerent networks. This tunnelling exists of encapsulating, transmitting and decapsulating the data. [69] Some tunnelling protocols are IPSec tunnel mode, L2TP and PPTP.

Domain Name System (DNS) is an important factor in the internet, as it allows one to connect without the necessity of remembering an IP address. [70] DNS tunnelling is a method to bypass a ﬁrewall by sending data packets as DNS traﬃc. The DNS covert channels can be split into two classes: one where IP packets are transported through the tunnel, IP over DNS. Second communication channels that allow a TCP connection, TCP over DNS. [71] There are several types of DNS tunnelling such as FTP, POP3, HTTP and HTTPS-tunnelling. [70] The following tunnelling tools are divided over the two classes mentioned before.

IP over DNS [72]:

• NSTX: A rogue server is necessary to run the NSTX tool, just as a certain kernel conﬁguration at the client and server.

• DNSCat has replies that are encapsulated in the CNAME record, which allows for referencing to an actual domain. This tool does not demand for kernel conﬁguration, hence, it is more ﬂexible than the NSTX tool.

• Iodine sends replies with NULL records, which is another format that allows for anything in the ﬁeld, on the condition that it is less than 65535 octets (8 bytes). [73] The packets are sent in several parts, thus need to be reassembled at the endpoint, similar to NSTX.

• TUNS works on UNIX-like systems, which is a type of operating system. It does not split packets. This method has been shown to work on many networks.

TCP over DNS [72]:

• Dns2TCP has a server side, which has resources searching for a TCP connection. The client side of Dns2TCP listens on a designated port to relay incoming connections to the ﬁnal service by means of DNS. Compared to IP over DNS, this method does not regularly poll activity from the client side.

• OzyManDNS is made from 4 scripts that allow for downloads or uploads, or, serve as client or server. The server searches on port 53, which is the DNS port, for DNS requests. The server Chapter 4. Methods 37

imitates a DNS server. The client sends converted input to a given domain. The ports can manually be mapped with the tunnel created from a secure shell and the scripts. In the study of Aiello, Merlo and Papaleo (2013) the methods mentioned above were tested on throughput, perceived response time (RTT) and overhead. [71] These tests resulted in the following analysis: NSTX has a low RTT and throughput, where the throughput cannot be increased because the method is not configurable. DNSCat has a high overhead and tolerable RTT and throughput. As DNSCat is straightforward to configure, the overhead can be decreased. Iodine is exceptionally configurable, it can work for most networks, which means it is a perfect tool for regular objectives. However, Iodine has low results in throughput, overhead and RTT. It is also the single tool that shows linear behaviour in configurations and metrics. TUNS has a low throughput and high RTT, but the overhead has a good value. The method is reliable in choke networks but has the lowest performance in most configurations, because it is difficult to build usable channels for real applications. Dns2TCP has a higher throughput than the previously mentioned tools. It has a tolerable RTT, but the overhead is substantially high such that the tunnel can be detected. OzyManDNS was not reliable enough at the time of the research to even be used, as it crashed every time they tried to use it. In the end, it was concluded that Iodine is a possibility in which more research has to be invested. Dns2Tcp remained the tool with the best performances. In the test at Edgecombe (2011) Iodine was used to bypass a firewall, where it works even though it is slow and not capable of working in conjunction with a real DNS server. [74] The research from Noujua, David and Hämäläinen(2017) concludes that certain malware attack detection mechanisms are able to recognise both Iodine and Dns2TCP, which means that a large commercial company most likely has this type of protection and these tools will fail. [75] However, there are also many companies that will not have these tools implemented yet.

There are more tools than just the ones mentioned above, such as Heyoka, PSUDP, squeeza, DNScat and DNScapy. [76] Because from the TCP over DNS tunnelling tools, Dns2TCP is the most researched and reliable method, only this one is used for method comparison. In the IP over DNS tunnelling tools, NSTX, DNSCat and TUNS are not taken into account due to low performance on some requirements. This results in only Iodine used for further method comparison.

Method Advantages Disadvantages

Iodine (IP - Availability: easy to implement: 10 - Customer approval: low, not secure: over DNS) - Reusability: works with midrange 1 companies, good conﬁgurability: 6 - Throughput: low throughput: 1 - Costs: low: 10 - Packet loss: no information: 6 - Customer involvement: none: 10 - Reusability: not in conjunction with - Latency: low RTT: 10 real DNS: 6 - Overhead: low: 10 Dns2TCP (TCP over - Throughput: high throughput: 10 - Packet loss: no information: 6 DNS) - Latency: acceptable RTT: 6 - Customer approval: low, not secure: - Availability: readily available code: 1 10 - Overhead: high, chance of detection - Reusability: acceptable: 6 due to much traﬃc on network: 1 - Costs: low: 10 - Customer involvement: none: 10

Table 4.9: NSLP evaluation 38 Chapter 4. Methods

4.13 UPnP

Universal Plug and Play (UPnP) is a protocol that allows for interaction with the NAT itself. The purpose of UPnP is to be able to let new devices communicate in a network with the least configuration possible. With the use of UPnP, one can open a port in the NAT of one’s choosing. UPnP is part of the Open Connectivity Foundation. [77] There are multiple control points in a network that use UPnP. Control points are devices on the network that control and discover the other devices. [78] The standards UPnP is based on are TCP, UDP, HTTP, XML and SOAP. Another standardised device protocol (DCP) is IGD, which is the identification of many firewalls. This means that NAT traversal can be done using the service of IGD DCP. [79] IGD is the Internet Gateway Device Protocol and is the NAT traversal in UPnP. [13]

UPnP consists of six steps [78]:

1. Addressing

2. Discovery

3. Description

4. Control

5. Eventing

6. Presentation

Where in the first step the device obtains an IP address either through Auto IP or a DHCP server. This address is then tested and other devices sought out on recognition points other than their IP address, which can be done with the use of a DNS server. In the second step, the UPnP network sends a message to the control points with a link to an encoded UPnP description of the device. The contents of this description consist of model and serial numbers, manufacturer, vender-specific URLs, embedded devices, services, etc. The fourth step is where the UPnP description that presents the services, is received by a control point. After this, a control message for a certain service can be sent, which is done using SOAP (Simple Object Access Protocol). The fifth step consist of messages sent by services if there is a change in their state. The first “event” message that a device receives includes the initial state variables, such that a model for that state can be built by the device. The final step enables the status information to be seen or the device to be controlled by the control point. This is only possible if the device has a certain presentation service. [78]

The steps for NAT traversal with UPnP are as follows [79]:

• The client binds to the local address and port;

• The client has the option to learn the IGD’s external address;

• The client asks for port mapping for the address and port it is bound to. It can demand that the external side is mapped on the same port number, which is called Port preservation. In the case that the external IP address is known by the client, it can also be determined;

• The client receives the resulting code from the IGD, after the port mapping is performed. In case of success, the response is “200 OK”. In the case that an external facing port was already mapped, an error will be returned or the current mapping will be overwritten by UPnP. [78] Chapter 4. Methods 39

The research in Widmer (2015) shows that UPnP has a lower response time for port mapping than a public STUN server, even though STUN used UDP and UPnP used TCP. [78] The median response time for UPnP was 57 ms and 68 ms including peer ping, which is a ping to the host. UPnP is only able to work when all devices in the network support it, otherwise making a connection is not possible. [13] The overhead is dependent of the level of security. [80] Generally some packet loss will occur using UPnP. The throughput is dependent of the bandwidth of the network. [81] UPnP can be a proper solution for a home network, but larger companies will most likely turn oﬀ the support for UPnP.

Method Advantages Disadvantages UPnP - Latency: low response time: 10 - Reusability: needs to be supported: 1 - Costs: low because it exists: 10 - Overhead: depends on security level: 6 - Throughput: network dependent: 10 - Packet loss: some: 6 - Availability: already exists: 10 - Customer involvement: has to be supported: 6 - Customer approval: will not support because of security: 1

Table 4.10: UPnP evaluation

4.14 Hole Punching

Hole punching is a method where two devices behind diﬀerent NATs attempt to communicate with each other through a peer-to-peer connection. Because a NAT often only allows for a connection to be made if it has already been attempted before, the two peers try to make a connection simultaneously such that the NAT recognises the connection. There are two types of hole punching, UDP and TCP, both are explained in this section. The behaviour of a NAT relative to hole punching is also described.

4.14.1 UDP hole punching From the research in Ford, Srisuresh and Kegel (2005) information could be found on the topic of UDP hole punching. [82] UDP hole punching allows for two peers to set up a peer-to-peer connection with UDP. This is done using a rendezvous server assuming there already is an active UDP session between the peer and the server. Two endpoints of the peer are recorded, the IP address and UDP port that the peer uses within its private network and the one that the NAT provides, thus public endpoint. In the case of this research, both peers are behind a different NAT. The hole punching process starts with client A asking the server to aid in connecting to client B. The server will then reply with client B’s endpoints while sending client B a connection request with the endpoints of client A. Now both clients know each other’s endpoints and client A starts sending UDP packets to client B’s endpoints. Depending on through which endpoint client B replies, that is the one that will be used for the session. Client B will do the same with the endpoints of client A. The first message client A will send to client B traces back of its own endpoint and that of NAT B. In case NAT A is well behaved (explained in section 4.14.3), the NAT will recognise the endpoint of client A, which is already in a session with the server. Therefore the NAT should let the message through. This is the ‘hole punching’ practice Once the message from client A reaches the NAT of client B, this message can be dropped because the endpoint of A is unknown. However, once client B also punches a hole in its NAT, the message from client A will be able to go through. From this moment, normal UDP communication between client A and B is possible. Figure 4.9 shows the process of UDP hole punching. The research in Ford, Srisuresh and Kegel (2005) shows that UDP hole punching is possible to set up 40 Chapter 4. Methods a connection between peers behind a firewall 64% of the time. [82] The research in Roverso, El-Ansary and Haridi (2009) concludes that hole punching has one of the highest success rates compared to their other traversal strategies. [83] The researchers also show that simple hole punching does take some time to complete the traversal process, but not much more than other strategies, around 700 ms.

Figure 4.9: UDP hole punching, peers behind diﬀerent NATs [82]

4.14.2 TCP hole punching From the research in Ford, Srisuresh and Kegel (2005) it can be concluded that the method for establishing a TCP connection through hole punching is more complex, yet similar to UDP hole punching. [82] Mainly the difficulty lies with the application programming interface, because the standard application programming interface was designed to either listen or connect instead of both, which is necessary for TCP hole punching to work. Thus, the difference between a TCP and UDP connection is that for TCP multiple sockets are necessary. However, most operating systems support a particular socket option for TCP that allows for multiple sockets to bind to one endpoint. The process of establishing a peer2peer connection with TCP starts similar to that of UDP. Assuming client A and B already have an established TCP connection with the server, client A asks the server for connecting to client B. After which the server sends the endpoints of client B to A and the other way around. From the local TCP ports that are known to the server, client A and B try to establish a connection in turns, while listening for incoming connections at the same time. In case establishing a connection fails due to an error, the client will try to make that connection again after a short delay. Once a connection is established, the hosts authenticate one another to verify they are the correct host. In the case of failure to authenticate, the connection is closed and the client waits for a new one. The first correct link is used as the TCP connection. Similar to UDP hole punching, the clients will authenticate if the host is the correct one. Because of multiple attempts to make a connection, the NATs will open new ‘holes’ that allow for a direct TCP connection between the two clients. If the NATs are well behaved, the first attempt on a connection from client A will be dropped because it is unknown. The connections should succeed because the addresses are already known.

4.14.3 Well behaved NAT The hole punching techniques are only able to work with certain types of NAT. For example, similar to STUN, hole punching does not work with a symmetric NAT. [82] It is, however, sometimes possible to Chapter 4. Methods 41 predict the behaviour of a symmetric NAT, but these methods are not ﬂawless and many mistakes can be made during the process. In case the NAT does not silently drop a SYN packet, but rather sends back a TCP reset packet or error report, it can also interfere with the hole punching process. [82] Another type of NAT behaviour that interferes with the hole punching is when the NAT translates IP addresses from the packet header. In this case the IP address changes, such that the packet is useless for the hole punching process. However, this can be evaded by obscuring the IP addresses. [82] Both TCP and UDP can make a connection with the use of hole punching. However, from the test results of Ford, Srisuresh and Kegel (2005) it is clear that UDP has a higher success rate concerning the NAT support of hole punching. [82] The research in Srirama and Liyanage (2014) shows that the use of TCP hole punching is also possible on mobile devices through a 4G network. [84]

Method Advantages Disadvantages

Hole - Throughput: TCP or UDP - Reusability: does not work for all punching connection: 10 NATs: 6 - Overhead: TCP or UDP dependent: - Latency: some latency: 6 10 - Packet loss: occurs: 1 - Customer involvement: none: 10 - Customer approval: not secure: 1 - Costs: acceptable: 6 - Availability: available techniques: 10

Table 4.11: Hole punching evaluation

4.15 ALG

Application Layer Gateways (ALGs) are designed to provide a NAT with additional capabilities such that it can translate information in the application layer. ALG is capable of transparently modifying payload, because it is located in a NAT. These modifications are done because some packets have the wrong information in the payload, a host IP address rather than host DNS name for example. [85] ALGs can have problems with scalability, reliability and speed of deployment, while it also relies on upgrades when the protocol is altered. [44] As ALG usually demands modifications to the NAT or firewall implementation of the method is restricted. [85] The throughput is depend on the network, thus ALG does not affect this, similar to the overhead. 42 Chapter 4. Methods

Method Advantages Disadvantages ALG - Throughput: network dependent: 10 - Packet loss: not reliable: 1 - Overhead: network dependent: 10 - Latency: high latency: 1 - Customer involvement: requires adaptations in NAT: 1 - Availability: not readily available: 6 - Reusability: requires NAT updates: 1 - Costs: for development or implementation: 6 - Customer approval: tempering to NAT: 1

Table 4.12: ALG evaluation

4.16 Comparison Traversal Methods

The methods described in this chapter have diﬀerent results on their performance. Each method is evaluated on the requirements in this research. The tables with requirement results are brought together in this section.

Figure 4.10 shows the results of the methods together in a scorecard for easy comparison. The scorecard uses the grades 1, 6 and 10, where a 1 is the value for insufficient, 6 is average and a 10 is good. The methods where values are dependent of the network they are located in, a 10 is given because the value has no influence from the method. Because customer involvement is the most important requirement to Resato, this value counts double. The other requirements are of similar importance and thus count once. The final values of the methods have a colour, which indicates its rank due to the requirements. A bright green value illustrates a good performance, whereas bright red indicates an inadequate method.

From the scorecard, one can see the STUN or ICE method are the best options. Because these methods are already known and used, these are the easier and most safe methods to use. Therefore, STUN is chosen for the test design. Chapter 4. Methods 43

Figure 4.10: Scorecard methods, ﬁnal rank from red to green (continues on page 44) 44 Chapter 4. Methods

Figure 4.10: Scorecard methods, ﬁnal rank from red to green Chapter 5

Test Design of Traversal Method

In order to show a piece of the research, a test design is made. This test design allows for insight in a method for further understanding and as an example for implementation. In this chapter, the test design is shown and explained.

The tested method is that of STUN, which is a method where a device can ask the STUN server for information on its location. The server is able to provide the device with both its public and private IP address and port, such that the device can use this information for establishing a connection to a peer on the other side of the NAT. However, STUN does not suffice for every type of NAT a device can be located behind. STUN can, therefore, be supplemented with TURN, which is a relay server. STUN is also part of the ICE method, which combines STUN and TURN while rather trying to establish a peer-to-peer connection. As STUN works for most types of firewalls, this is the first method tested.

5.1 Setup

5.1.1 First setup The setup of the test design is quite simple, two computers and a local network are used. The local network is that of Resato. This setup is shown in the Figure 5.1 below. One computer serves as the client, which is the machine in the real-life situation, while the other represents the server (Resato). In order to add a ﬁrewall, a software version is used on each computer. The test program is then started.

Figure 5.1: Setup ﬁrst test design

45 46 Chapter 5. Test Design of Traversal Method

5.1.2 Second setup As explained before, the test is done using two computers with a ﬁrewall and a router in-between. However, a second test was done without the private network. In the Figure 5.2 the process of the second setup is shown. The S is the server and M the machine. Each step has a colour, thus the test starts with STUN action, which has connections in orange. Then a TCP connection is established, which is represented in yellow. Finally, a UDP connection takes place, which is in green.

Figure 5.2: Setup second test design (by Chiel Reijnen)

In this setup, a computer in the Resato network is used as server. Because upon implementation an entrance is established for incoming data, the Resato firewall does not impose a hurdle for the data traffic. Therefore during the test, the computer was set up to use a certain port that was only opened for that computer. This way the network of Resato would not impose a threat to the communication traffic. The router could be replaced by, or seen as, the public internet in this case.

5.2 Test Program

The client asks the STUN server for its location, to which the STUN server replies with the requested information. The location of the server is known and is pre-programmed, as it will be the data storage at Resato. With its location, the client knows which port to use to pass through the ﬁrewall. This results in the client sending a TCP data packet to the server and the server establishing a UDP connection with the client. One can see the starting screen in Figure 5.3a, where the green section shows the activity that the program will use at that moment. It can be on ‘ontvangen’ which is to receive data packets, thus the server. To change the program type, one has to press 3, which results in the red and green switching, such that ‘versturen’ is in use. This means one will send the data packets and thus, acts as the client. Chapter 5. Test Design of Traversal Method 47

(a) Startscreen

(b) Settings

Figure 5.3: General screens of program using STUN

Each time the program is started, the settings will be set to default, which are a local IP address and port used at Resato. The settings can be changed by pressing 1, similar to the STUN settings that can be adjusted by pressing 2. In Figure 5.3b the screen is shown after pressing 1 and then pressing 3, such that the local IP address and port can be changed. One is now able to enter a diﬀerent header to use for passing the ﬁrewall. Once all the settings are correct, the listening or receiving can be started by pressing 4. In case a mistake is made during the process, an error message is displayed in the program. 48 Chapter 5. Test Design of Traversal Method

The test is done with the use of both UDP and TCP. In Figure 5.4a one can see the screen after receiving the IP address and port through STUN and establishing a TCP connection with the server. After establishing the TCP connection, the machine starts to listen for UDP packets. The Figure in 5.4b shows the messages of sending UDP packets as the server. The messages that are displayed in the program is for one’s convenience, to be able to quickly see if the packets are sent and received. The printed text is not the actual data the server receives, as for example the zeros are deleted. As can be seen from the Figure 5.4b the messages contain a mere ascending number, which is useful for testing to show if all the packets are sent and/or received.

(a) Established TCP connection, listening for UDP packets

(b) Sending UDP packets

Figure 5.4: General screens while using STUN program Chapter 5. Test Design of Traversal Method 49

5.3 Results Tests

In this section, the results of the test design are explained and evaluated. The tests are compared and the STUN method is evaluated with the use of resulting test values.

5.3.1 Test 1 The ﬁrst setup was tested and appeared to work correctly. The messages were all sent and received very quickly, which is because the setup puts the two devices in the same network. However, the test should be done in diﬀerent networks, which is also the case in real life. This is done in the second setup.

5.3.2 Test 2 This test was done using the second setup with both peers in a different network. A typical home router/firewall was used in this test, instead of a corporate hardware firewall, where the firewall is separated from the router. This test was also successful and points out that STUN works on regular NATs. The client’s NATs used in this setup is a port restricted cone NAT.

5.3.3 Test 3 In the third test, the devices are put in a different network, which is the same setup as test 2. However, now the computer at Resato serves as machine. This test was unsuccessful because the firewall at Resato is too strict. The machine was able to send a message, but a UDP connection could not be established. This should be the case, as Resato has a very strict and new firewall.

5.3.4 Validation In order to validate the use of the STUN method, the program Wireshark1 is used. This program allows for monitoring incoming and outgoing traffic over a network. As mentioned before, some of the tests were successful while the last test was not. The first two tests were done with the use of a local network and a home router as firewall respectively. The last test was done trying to make a connection into the Resato network, which did not succeed. This can be seen from both the program, which does not show messages being received, and Wireshark. Some screenshots of Wireshark were made during the tests and can be found in Appendix B. Figure B.2 shows the incoming and outgoing data during the establishment of a TCP connection. The Figure B.1 shows the data during the established UDP connection. In the figures, one can see which protocol is used, the source, destination and time.

As shown in the Figure 5.2 in section 5.1.2, the program first lets the machine make a connection to a STUN server and request its location. In Figure B.3, the activities taking part in the process can be seen. The client sends multiple requests to the server until the server replies with the location of the client. The location can be seen in the figure, both an IP address and port are given. All together this process takes less than 10 seconds, which is acceptable because this also includes the STUN server to find the right location. In the Figure B.2 one can see the different steps in making a TCP connection. In section 1.5.3 the three-way handshake is explained, which can be seen in the figure. The connection starts with an

1https://www.wireshark.org/ 50 Chapter 5. Test Design of Traversal Method incoming request (SYN), which is acknowledged. This can be seen from the changing destination and source address. The time at which the data is sent or received can be seen from the time stamps. For example, it only takes 2/1000th of a second to send an acknowledgement of the connection request. All together it takes less than a tenth of a second to establish a TCP connection, send the required data and respond that it has arrived. At the bottom of the ﬁgure, more information is given on the selected activity. For example, one can see the used protocol, the source and destination addresses and ports.

Figure B.1 shows the outgoing UDP packets sent to the ’machine’. The program automatically sends a packet every second. From the ﬁgure, one can see this is the case, with a deviation ranging from 20 μs to 0.1 ms. Besides this deviation in time, from the data it could be concluded that each packet was sent and received. Each packet contains an ascending number as message, which provides an easy check in case a packet is lost. In Figure B.1 the number in the selected packet can be seen in the bottom right. The text contains the number 122, which means it is the 122nd packet sent.

Altogether the program works without a high latency or packet loss. As with STUN, the throughput is dependent on the network. This value was not measured. The overhead could not be measured, because the messages only contained ascending numbers. This is not representative of the size of messages that a machine would be sending or receiving. In conclusion, the test proves STUN is a useful and reliable method for most NATs. Chapter 6

Discussion

In this chapter, the results of the methods and test design are brieﬂy mentioned, after which they are included in the discussion.

6.1 Results

In section 4.16 the results of the methods are discussed with the use of the scorecard in Figure 4.10. This results in the STUN and ICE method being the most appropriate methods to use for implementation.

The test design in chapter5 is based on the STUN method. The test concludes the STUN method to work on several occasions, however, not when Resato serves as the client. This means that if the customer of Resato has a professional ﬁrewall which is similar to Resato’s, one is not able to make a connection using STUN.

6.2 Discussion

The research question at the beginning of this research was as follows: ‘What is the best method to communicate with the machines, with limited environment change?’

In this research, multiple methods have been evaluated. From the results, it is clear that many differences exist between the methods. Each method acts in another way on particular aspects. The best method would be a combination of methods. Therefore, ICE would be a good method, as it combines STUN, TURN, peer search etc. This is especially the case for a long-term solution. In case the firewalls evolve to block one of the methods used, the others are able to intercept the limitations that occur without that method. None of the methods involved in ICE need any modifications to the customer’s environment, which makes the method appropriate for Resato to use. As mentioned, the methods have ranging results on the requirements. It is notable that none of the values are a ten. This indicates none of the methods are perfect, which can be expected from real life solutions with many attributes. Most methods score around average, which indicates most methods do perform well on some aspect. In the beginning of the research, it was expected to come across methods, other than simply bypassing the firewall. The method of using a 3G/4G/LTE connection is such a method. However, it is costly at this point, because of the many machines Resato has. Connectivity issues might also occur. Nonethe- less, if the expenses would not be this high, it can be a proper solution. These expenses might decrease in the future, or if a deal can be made with another company. Especially if multiple companies would like to use such connections, more offers for usage might be set up.

51 52 Chapter 6. Discussion

The results from the test design conclude for STUN to work for most NATs, but not the one of Resato itself. According to the STUN server used in the test design, Resato has a port restricted cone NAT. This type of NAT is supposed to be bypassed by a STUN server, which is not the case with Resato. However, the other router used in the test design, a home router, also had a port restricted NAT and did allow for STUN to work. The most likely explanation for the diﬀerence between the NAT of Resato and a home router is the strictness of the NAT that can be added. Every NAT can add strictness due to extra options. Another explanation is that the STUN server used in the test is wrong. STUN is not supposed to work with a symmetric NAT and the behaviour of the NAT at Resato is similar to that of a symmetric NAT. Therefore, Resato either has a stricter version of a port restricted cone NAT, or a symmetric NAT, which implies the STUN server might be wrong. The STUN server used, belongs to Google and works as intended but to exclude the possibility multiple servers should be tested. Nevertheless, many customers of Resato are small to mid-level companies, which tend to have a more regular ﬁrewall similar to that one has at home. Thus, STUN is likely to work at most customers, but for implementation one can better use a combination of methods.

In the tests, some deviation in time is found. Deviation in time can be a problem if the deviation is substantially large, such that it results in high overhead, which makes the traﬃc more visible in the network. The deviation can come from multiple sources. The ﬁrst possibility is that there is some delay using the STUN method. However, the process using STUN already happens before establishing a TCP connection, thus should not be the reason for delay with UDP packets. Another possibility is the accuracy of the program, Wireshark or Go. Because Go is the used programming language, the program is dependent on its accuracy. For example, it could be the case that Go does not send the packets exactly every second, which would explain the deviation. The program itself or Wireshark could also be the inaccuracy that results in a deviation. With Wireshark it is also possible to see the time takes less than a second, this is the case because there can be a delay in displaying the activity. The last possible explanation for the deviation is the internet speed. If at the same time a lot of data is coming in on either of the devices, it can slow down the speed. This can result in a delay, which explains the deviation. It can be concluded that the program works according to a proper time and thus latency is good. Because all the messages are sent and received, it is also known that no packet loss occurs.

There are several limitations to this research. The ﬁrst limitation is that the methods are evaluated based on research, while it would give a more accurate overview to test every method in the same environment, with the same network. Another limitation is with the test design. Only one method is tested, which does not provide an equal overview of the methods. In case one wants to compare multiple methods, the advise is to test it in one’s own environment, to ensure possible network limitations, such as throughput, are restricted. A third limitation is that only one test design was made. In this test design, the STUN method worked, except on a symmetric NAT. However, the design could have been made to use the method wrong. Therefore, it is advisable to test a method in diﬀerent programs, such that in case of trouble, it is not because of the program. This was, however, not possible due to the time limit of this research. The fourth limitation relates to the same problem. Because of the time limitation, it was not possible to do another test design. However, it would be better for comparison to make at least two test designs. The last limitation is rather an encountered problem. At the beginning of the research, it was expected that the test design would not take more than two days to set up. However, in practice, it took more time than these expected two days, which resulted in a delay in reviewing the test design. Chapter 7

Conclusion and recommendations

7.1 Conclusion

In this research, many methods for bypassing a ﬁrewall to communicate with a machine were ex- plored. These methods have been ranked according to requirements. The most important requirement throughout the research is to have no customer involvement. This requirement immediately termi- nated several methods. The methods that stand out as the best according to all the requirements are STUN and ICE. Therefore STUN was used in a test design for communication between a server at Resato and a machine at a customer of Resato. The test concluded STUN to work well with most NATs, similar to the literature. Besides this, the test validated the STUN method with the conclusion that it has no packet loss and little latency. The stakeholder requirements were also implemented in the requirements throughout the research. STUN meets these requirements; It does not take much time to implement, it works anywhere, thus in every country, STUN is ethically responsible as the data can be protected, STUN is not expensive and the customer is not involved. As the STUN method does not work for every NAT, it is recommended to implement STUN together with other methods to create one that always works, such as ICE.

7.2 Recommendations

With the outcome of this research, some recommendations for future research can be given. As ICE is the most promising method, a future project can be to conduct more research on the method. The method should be made and tested in a real-life environment such as Resato. The expectation is for this method to provide the solution to the problem Resato and other companies encounter. However, besides this method, it is advised to test some other methods as well, to provide a proper comparison.

Another recommendation is to try diﬀerent manners of implementing the method. In this research, only one test design was made to use STUN. However, STUN can most likely be used in many diﬀer- ent ways. Therefore, it is essential to consider other ways of implementing a method. Mainly when a method does not work, the problem can lie with the program used rather than the method itself.

A further recommendation concerning the test design made in this research is to test with multiple STUN servers. In this research, only one STUN server is used. However, Google already has multiple servers that one can use. There exist many freely available servers, besides that, one can make their own STUN server. Therefore, it is advised to try multiple servers when testing. This is the same case for ICE. One can make their own TURN server, or use one from another company. One should ﬁnd the best option for their method.

53 54 Chapter 7. Conclusion and recommendations

Another recommendation is to use some other requirements besides the one used in this research. From the process during the research, it became clear that some other requirements can be critical. These were as follows: Limitations to usage, backwards compatibility, memory utilisation and support of diﬀerent message formats.

The last recommendation is to test in multiple environments. In this research, the Resato network is always used on either side of the test. However, diﬀerent peers were used on the other side. It is recommended to change peers for optimal results because those results can change in diﬀerent environments. Appendix A

Program Code

1 /∗ 2 ∗ Stun en turn demo 3 ∗/ 4 package main 5 6 import ( 7 ” os ” 8 ” b u f i o ” 9 ” os / exec ” 10 ”github.com/fatih/color” 11 ”fmt” 12 ” net ” 13 ” time ” 14 ” l o g ” 15 ”github .com/ccding/go−stun / stun ” 16 ” strconv ” 17 ” s t r i n g s ” 18 ” bytes ” 19 ) 20 21 var ( 22 programType = ”server” 23 programConnected = false 24 programPacketType = ”udp” 25 programAddressInput = ”:10011” 26 programLocalAddressInput = ”:10004” 27 programUseStun = true 28 programActive = false 29 inputIsVar = false 30 inputIsMenu = true 31 inputIsVarValue string 32 menuLocation = ”0” 33 subMenuLocation = ”0” 34 35 scanner = bufio.NewScanner(os.Stdin) 36 ) 37 38 39 /∗ 40 ∗ Alle functies die met het menu te maken hebben. 41 Deze functies hebben niks met de packets te maken 42 Alleen de user interface 43 ∗/ 44 45 func clear() { 46 c := exec.Command(”clear”) 47 c.Stdout = os.Stdout

55 56 Appendix A. Program Code

48 c . Run ( ) 49 } 50 func g e t s t u n s e t t i n g m e n u ( ) { 51 color.Set(color.BgBlue, color.FgWhite) 52 fmt.Println(” ”) 53 fmt.Println(” STUN − TURN ”) 54 fmt.Println(” ”) 55 color .Unset() 56 color .Unset() 57 color .Set(color .BgRed, color .FgWhite) 58 fmt.Println(” STUNInstellingen ”) 59 fmt.Println() 60 color .Unset() 61 fmt.Println(” 1. Terug naar hoofdmenu”) 62 fmt.Println() 63 fmt.Println(” 2. Wijzig stun gebruik”) 64 fmt.Println(” 3. Reset instellingen”) 65 fmt.Println() 66 color.Set(color.BgBlue, color.FgWhite) 67 fmt.Println(” ”) 68 fmt.Println(” ”) 69 color .Unset() 70 fmt.Println() 71 fmt.Print(”:”) 72 73 } 74 func g e t s e t t i n g m e n u ( ) { 75 color.Set(color.BgBlue, color.FgWhite) 76 fmt.Println(” ”) 77 fmt.Println(” STUN − TURN ”) 78 fmt.Println(” ”) 79 color .Unset() 80 color .Set(color .BgRed, color .FgWhite) 81 fmt.Println(” Instellingen ”) 82 fmt.Println() 83 color .Unset() 84 fmt.Println(” 1. Terug naar hoofdmenu”) 85 fmt.Println() 86 fmt.Println(” 2. IP en PORT wijzigen”) 87 fmt.Println(” 3. Local IP en PORT wijzigen”) 88 fmt.Println(” 4. Packet type wijzigen”) 89 fmt.Println(” 5. Reset instellingen”) 90 fmt.Println() 91 color.Set(color.BgBlue, color.FgWhite) 92 fmt.Println(” ”) 93 fmt.Println(” ”) 94 color .Unset() 95 fmt.Println() 96 fmt.Print(”:”) 97 } 98 func get head menu ( ) { 99 color.Set(color.BgBlue, color.FgWhite) 100 fmt.Println(” ”) 101 fmt.Println(” STUN − TURN ”) 102 fmt.Println(” ”) 103 color .Unset() 104 fmt.Println() 105 fmt.Println(” 1. Instellingen”) 106 fmt.Println(” 2. Stun instellingen”) 107 fmt.Println(” 3. Wijzig programma type (server/client)”) Appendix A. Program Code 57

108 fmt.Println() 109 fmt.Println(” 4. Start”, programType) 110 fmt.Println() 111 color .Unset() 112 color.Set(color.BgBlue, color.FgWhite) 113 fmt.Println(” ”) 114 fmt.Println(” ”) 115 color .Unset() 116 fmt.Println() 117 fmt.Print(” ”) 118 if programType == ”server”{ 119 color .Set(color .BgGreen, color .FgWhite) 120 } e l s e { 121 color .Set(color .BgRed, color .FgWhite) 122 } 123 fmt . Print (” ONTVANGEN ”) 124 fmt.Println() 125 color .Unset() 126 fmt.Println(” IP Address:”, programAddressInput) 127 fmt.Println(” Packet type:”, programPacketType) 128 fmt.Println() 129 130 fmt.Print(” ”) 131 if programType == ”client”{ 132 color .Set(color .BgGreen, color .FgWhite) 133 } e l s e { 134 color .Set(color .BgRed, color .FgWhite) 135 } 136 fmt . Print (” VERSTUREN ”) 137 fmt.Println() 138 color .Unset() 139 fmt.Println(” IP Address:”, programAddressInput) 140 if programUseStun{ 141 fmt.Println(” LOCAL IP Address: STUN”) 142 } e l s e { 143 fmt.Println(” LOCAL IP Address:”, programLocalAddressInput) 144 } 145 fmt.Println(” Packet type:”, programPacketType) 146 fmt.Println() 147 color.Set(color.BgBlue, color.FgWhite) 148 fmt.Println(” ”) 149 fmt.Println(” ”) 150 color .Unset() 151 fmt.Println() 152 fmt.Println() 153 fmt.Print(”:”) 154 } 155 func get input menu(value string) { 156 color.Set(color.BgBlue, color.FgWhite) 157 fmt.Println(” ”) 158 fmt . P r i n t l n (” WAARDE TOEVOEGEN/VERANDEREN ”) 159 fmt.Println(” ”) 160 color .Unset() 161 fmt.Print(value + ”: ”) 162 } 163 func startServer s c r e e n ( ) { 164 color.Set(color.BgMagenta, color.FgBlack, color.Bold) 165 fmt.Println(” ”) 166 fmt . P r i n t l n (” PACKET LISTENER ( s e r v e r ) ”) 167 fmt.Println(” ”) 58 Appendix A. Program Code

168 color .Unset() 169 color .Set(color .BgGreen, color .FgWhite) 170 fmt. Println(” PACKET TYPE: (” + programPacketType + ”) ”) 171 color .Unset() 172 color.Set(color.BgHiGreen, color.FgBlack) 173 fmt.Println(” LISTENING ON: (” + programAddressInput + ”)”) 174 color .Unset() 175 } 176 func startClient s c r e e n ( ) { 177 color.Set(color.BgWhite, color.FgBlack, color.Bold) 178 fmt.Println(” ”) 179 fmt.Println(” PACKETSENDER(client) ”) 180 fmt.Println(” ”) 181 color .Unset() 182 color.Set(color.BgHiBlue, color.FgWhite) 183 fmt. Println(” PACKET TYPE: (” + programPacketType + ”) ”) 184 color .Unset() 185 color.Set(color.BgWhite, color.FgBlack) 186 fmt.Println(” SENDING TO: (” + programAddressInput + ”)”) 187 color .Unset() 188 } 189 190 191 func sendStunIP(host string) { 192 buf := []byte(host) 193 conn, err := net.Dial(”tcp”, programLocalAddressInput) 194 conn.Write(buf) 195 fmt.Println(”Sended:”, host , ”to:”, programLocalAddressInput) 196 checkError(err) 197 } 198 func listenStunIP() { 199 fmt. Println(”Yes”) 200 // listen on all interfaces 201 ln , := net.Listen(”tcp”, programLocalAddressInput) 202 // accept connection on port 203 204 205 f o r { 206 conn , := ln.Accept() 207 buf := make([]byte, 1024) 208 // Read the incoming connection into the buffer. 209 , err := conn.Read(buf) 210 i f e r r != n i l { 211 fmt.Println(”Error reading:”, err.Error()) 212 } 213 // Send a response back to person contacting us. 214 215 buf = bytes.Trim(buf, ”\ x00 ”) 216 217 msg := string(buf[:]) 218 fmt. Println(msg) 219 // 220 //address := strings.Split(msg, ”:”) 221 // , port := address[0], address[1] 222 programConnected = true 223 programAddressInput = msg 224 225 conn.Close() Appendix A. Program Code 59

226 } 227 228 229 } 230 231 232 /∗ 233 Behandel de gegeven waarde bij een variable change 234 ∗/ 235 func s e t i n p u t variable(input string) (status string , err error) { 236 switch inputIsVarValue { 237 case ”1 ip ” : 238 programAddressInput = input 239 status = input 240 241 break 242 case ”1lip”: 243 programLocalAddressInput = input 244 status = input 245 246 break 247 case ”1packet”: 248 if input == ”tcp” | | input == ”udp”{ 249 programPacketType = input 250 status = input 251 252 } e l s e { 253 254 status = ”wrong” 255 } 256 break 257 case ”2stun”: 258 if input == ”y” | | input == ”n”{ 259 if input == ”y”{ 260 programUseStun = true 261 } e l s e { 262 programUseStun = false 263 } 264 status = input 265 } e l s e { 266 status = ”wrong” 267 } 268 break 269 } 270 271 return status, err 272 } 273 274 /∗ 275 Behandel errors 276 ∗/ 277 func checkError(error error) { 278 if(error != nil) { 279 log.Fatal(error) 280 } 281 } 282 283 /∗ 284 Start de server 285 Server betekent dat de server de packets ”ontvangt” 60 Appendix A. Program Code

286 ∗/ 287 func startServer() { 288 c l e a r ( ) 289 if programUseStun { 290 fmt.Println(”Resolving ip...”) 291 nat, host, err := stun.NewClient().Discover() 292 i f e r r == n i l { 293 Shost := host.String() 294 go sendStunIP(Shost) 295 296 address := strings.Split(Shost, ”:”) 297 , port := address[0], address[1] 298 299 programAddressInput = ”:” + port 300 fmt.Println(”Listen to:”, port) 301 } 302 fmt.Println(host ,nat) 303 } 304 startServer s c r e e n ( ) 305 if programPacketType == ”udp”{ 306 // luister naar inkomende packets 307 ser ver , := net .ResolveUDPAddr(”udp4”, programAddressInput) 308 serverConn , err := net.ListenUDP(”udp4”, server) 309 checkError(err) 310 fmt. Println(programAddressInput) 311 // Lees de packets 312 buf := make([]byte, 1024) 313 f o r { 314 // Wacht op binnenkomende packets 315 n,addr , err := serverConn.ReadFromUDP(buf) 316 msg := string(buf[0:n]) 317 318 // Show de packet in een fancy stijl 319 320 color .Set(color .FgGreen) 321 fmt.Println(”[UDP] Received message”) 322 color .Unset() 323 color .Set(color .BgCyan) 324 fmt.Println(”Message:”, msg, ”from:”,addr) 325 color .Unset() 326 fmt.Println() 327 328 // Show errors 329 checkError(err) 330 } 331 } 332 } 333 334 /∗ 335 Start de client 336 client betekent dat de server de packets ”verstuurd” 337 ∗/ 338 func startClient() { 339 c l e a r ( ) 340 341 // Als alles is geupdate word de client uitgevoerd 342 startClient s c r e e n ( ) 343 go listenStunIP() 344 f o r { 345 if programConnected { Appendix A. Program Code 61

346 347 server , err := net.ResolveUDPAddr(”udp4”, programAddressInput) 348 checkError(err) 349 lServer , err := net.ResolveUDPAddr(”udp4”, programLocalAddressInput) 350 checkError(err) 351 352 //Maak verbinding 353 conn, err := net.DialUDP(”udp4”, lServer , server) 354 checkError(err) 355 356 i := 0 357 f o r { 358 msg := strconv.Itoa(i) 359 i++ 360 buf := []byte(msg) 361 , err := conn.Write(buf) 362 i f e r r != n i l { 363 fmt.Println(msg, err) 364 } 365 fmt.Println(”sended:”, i , ”to:”, programAddressInput) 366 time.Sleep(time.Second ∗ 1) 367 } 368 } 369 370 371 } 372 373 } 374 375 376 377 /∗ 378 ∗ Behandel de gegeven waarde in het console. 379 ∗/ 380 func handle input(input string) { 381 382 if programActive == false { 383 c l e a r ( ) 384 if inputIsMenu { 385 menuLocation = input 386 switch menuLocation { 387 case ”0”: 388 get head menu ( ) 389 inputIsMenu = true 390 break 391 case ”1”: 392 g e t s e t t i n g m e n u ( ) 393 inputIsMenu = false 394 break 395 case ”2”: 396 g e t s t u n s e t t i n g m e n u ( ) 397 inputIsMenu = false 398 break 399 400 case ”3”: 401 402 if programType == ”server” { 403 programType = ”client” 404 } e l s e { 405 programType = ”server” 62 Appendix A. Program Code

406 } 407 get head menu ( ) 408 409 break 410 case ”4”: 411 programActive = true 412 if programType == ”server” { 413 startServer() 414 415 } e l s e { 416 startClient() 417 } 418 break 419 420 } 421 } e l s e { 422 subMenuLocation = input 423 switch menuLocation { 424 case ”1”: 425 switch subMenuLocation { 426 case ”1”: 427 get head menu ( ) 428 inputIsMenu = true 429 break 430 case ”2”: 431 inputIsVarValue = ”1ip” 432 inputIsVar = true 433 434 get input menu(”IP Address”) 435 break 436 case ”3”: 437 inputIsVarValue = ”1lip” 438 inputIsVar = true 439 440 get input menu(”Local IP Address”) 441 break 442 case ”4”: 443 inputIsVarValue = ”1packet” 444 inputIsVar = true 445 446 get input menu(”Packet type (udp/tcp)”) 447 break 448 case ”5”: 449 get head menu ( ) 450 menuLocation = ”0” 451 inputIsMenu = true 452 453 programType = ”server” 454 programPacketType = ”udp” 455 programAddressInput = ”:10011” 456 programLocalAddressInput = ”:10004” 457 458 break 459 } 460 case ”2”: 461 switch subMenuLocation { 462 case ”1”: 463 get head menu ( ) 464 inputIsMenu = true 465 break Appendix A. Program Code 63

466 case ”2”: 467 inputIsVarValue = ”2stun” 468 inputIsVar = true 469 470 get input menu(”Use stun (y/n)”) 471 break 472 } 473 break 474 case ”3”: 475 476 break 477 } 478 } 479 } 480 } 481 482 483 /∗ 484 Begin met het aflezen van inputs in het console 485 ∗/ 486 func main ( ) { 487 handle input (”0”) 488 for scanner.Scan() { 489 input := scanner.Text() 490 if inputIsVar { 491 status, err := set i n p u t variable(input) 492 if(err != nil) { 493 color .Set(color .FgRed) 494 fmt.Println(”Het veranderen van de geselecteerde variable is fout gegaan”) 495 fmt.Println() 496 fmt.Println(” − Variable roep nummer:”, inputIsVarValue) 497 fmt.Println(” − Variable text:”, input) 498 fmt.Println(” − Fout:”, err) 499 color .Unset() 500 } 501 if status == ”wrong”{ 502 fmt.Println(”Geef een correcte waarde op!”) 503 fmt.Print(”:”) 504 505 } e l s e { 506 color .Set(color .FgGreen) 507 fmt.Println(”Waarde is veranderd naar:”, status) 508 time.Sleep(time.Second ∗ 1) 509 c l e a r ( ) 510 color .Unset() 511 inputIsVar = false 512 inputIsMenu = true 513 inputIsVarValue = ”” 514 get head menu ( ) 515 menuLocation = ”0” 516 subMenuLocation = ”0” 517 } 518 } e l s e { 519 520 if input == ”1” | | input == ”2” | | input == ”3” | | input == ”4” { 521 handle input(input) 522 } e l s e { 523 fmt.Print(”:”) 524 } 525 64 Appendix A. Program Code

526 } 527 } 528 } Appendix B

Wireshark Screenshots

Figure B.1: Activity during UDP connection

65 66 Appendix B. Wireshark Screenshots

Figure B.2: Activity during TCP connection Appendix B. Wireshark Screenshots 67

Figure B.3: Activity STUN request

Bibliography

[1] R. Moskowitz et al. In: Host Identity Protocol Version 2 (HIPv2) (2015). [2] Our brands. url: https://www.resato.com/en/about-us/our-brands (visited on 04/01/2018). [3] Our mission. url: https : / / www . resato . com / en / about - us / our - mission (visited on 04/01/2018). [4] Innovation cluster Drachten. url: https://en.icdrachten.nl/ (visited on 04/01/2018). [5] Our cluster. url: https://en.icdrachten.nl/our-cluster (visited on 04/01/2018). [6] Kennisgevingen Europa. url: https://www.fryslan.frl/document.php?m=7&fileid=19240& f=57b0c1538bd6e6d3ca6c6a1509e56793&attachment=0&c=6754 (visited on 04/01/2018). [7] About PTC. url: https://www.ptc.com/en/about (visited on 04/01/2018). [8] Thingworx platform. url: https://www.ptc.com/en/products/iot/thingworx-platform (visited on 04/01/2018). [9] ITU-T Recommendation X.200 (07/94). [10] Craig Hunt. TCP/IP network administration. Vol. 2. ” O’Reilly Media, Inc.”, 2002. [11] Huawei Technologies Co. Hcna Networking Study Guide 2017. Springer, Singapor, 2016. [12] Jonathan Rosenberg et al. “STUN-simple traversal of UDP through network address translators”. In: (2003). [13] Yuan Wei et al. “A new method for symmetric NAT traversal in UDP and TCP”. In: Network 4 (2008), p. 8. [14] Ernesto Exposito. Advanced Transport Protocols: Designing the Next Generation. John Wiley Sons, 2013. [15] Henrik Osterdahl.¨ “A comparison of TCP and SCTP performance using the HTTP protocol”. In: (2005). [16] Jinyang Shi et al. “Performance evaluation of SCTP as a transport layer solution for wireless multi-access networks”. In: Wireless Communications and Networking Conference, 2004. WCNC. 2004 IEEE. Vol. 1. IEEE, 2004, pp. 453–458. [17] Rajesh Rajamani, Sumit Kumar, and Nikhil Gupta. “SCTP versus TCP: Comparing the performance of transport protocols for web traﬃc”. In: University of Wisconsin-Madison (2002). [18] Christoph Paasch and Olivier Bonaventure. “Multipath TCP”. In: Queue 12.2 (2014), pp. 40–51. [19] Shahrudin Awang Nor, Raaid Alubady, and Wisam Abduladeem Kamil. “Simulated performance of TCP, SCTP, DCCP and UDP protocols over 4G network”. In: Procedia Computer Science 111.5 (2017), pp. 2–7. [20] Tao Wang et al. “DCCP: an eﬀective data placement strategy for data-intensive computations in distributed cloud computing systems”. In: The Journal of Supercomputing 72.7 (2016), pp. 2537– 2564.

69 70 BIBLIOGRAPHY

[21] Wisam Abduladheem Kamil, Shahrudin Awang Nor, and Raaid Alubady. “Performance Eval- uation of TCP, UDP and DCCP Traffic Over 4G Network”. In: Research Journal of Applied Sciences, Engineering and Technology 11.10 (2015), pp. 1048–1057. [22] RémiChauvenne and Thibault Libioulle. “MultiPath TCP connections : analysis and models”. PhD thesis. 2017. [23] Ali Munir et al. “Multipath TCP traffic diversion attacks and countermeasures”. In: Network Protocols (ICNP), 2017 IEEE 25th International Conference on. IEEE, 2017, pp. 1–10. [24] Vicky Sharma et al. “A transport protocol to exploit multipath diversity in wireless networks”. In: IEEE/ACM Transactions on Networking 20.4 (2012), pp. 1024–1039. [25] PTC support. url: https://www.ptc.com/en/support/article?n=CS249602 (visited on 04/26/2018). [26] Michael C. Jackson. Systems thinking: Creative holism for managers. Citeseer, 2003. [27] Zhaogang Shu et al. “Cloud-integrated cyber-physical systems for complex industrial applications”. In: Mobile Networks and Applications 21.5 (2016), pp. 865–878. [28] Yuan Liu et al. “A practical robustness measure of incentive mechanisms”. In: Proceedings of the 2014 international conference on Autonomous agents and multi-agent systems. International Foundation for Autonomous Agents and Multiagent Systems, 2014, pp. 1379–1380. [29] Sylvain Kubler, Kary Främling,and Andrea Buda. “A standardized approach to deal with firewall and mobility policies in the IoT”. In: Pervasive and Mobile Computing 20 (2015), pp. 100– 114. [30] Ala Al-Fuqaha et al. “Internet of things: A survey on enabling technologies, protocols, and applications”. In: IEEE Communications Surveys Tutorials 17.4 (2015), pp. 2347–2376. [31] IEEE Computer Society. IEEE standard for software quality assurance processes. New York: Institute of Electrical and Electronics Engineers, 2014. [32] Claude Y. Laporte and Alain April. Software quality assurance. English. Hoboken, NJ : IEEE Press, 2018. [33] Ali Mili and Fairouz Tchier. Software testing: Concepts and operations. John Wiley Sons, 2015. [34] What’s ”normal” for latency and packet loss? 2014. url: https://www.pingman.com/kb/42 (visited on 06/05/2018). [35] Bradley Mitchell. Introduction to Latency on Computer Networks. 2018. url: https://www. lifewire.com/latency-on-computer-networks-818119 (visited on 06/05/2018). [36] Tom Arbuthnot. What are Thresholds for Good and Poor Network Packet Loss, Jitter and Round Trip Time for Unified Communications? 2018. url: http://tomtalks.uk/2018/05/what- are-thresholds-for-good-and-poor-network-packet-loss-jitter-and-round-trip- time-for-unified-communications/ (visited on 06/05/2018). [37] Steven Iveson. TCP Over IP Bandwidth Overhead. 2013. url: http://packetpushers.net/ tcp-over-ip-bandwidth-overhead/ (visited on 05/31/2018). [38] Charles M. Kozierok. The TCP/IP guide: a comprehensive, illustrated Internet protocols refer- ence. No Starch Press, 2005. [39] Ciminiera L. et al. “Distributed connectivity service for a SIP infrastructure”. In: IEEE Network 22.5 (2008), pp. 33–40. [40] Ying-Dar Lin et al. “How NAT-compatible are VoIP applications?” In: IEEE Communications Magazine 48.12 (2010). BIBLIOGRAPHY 71

[41] S. A. Baste and H. G. Schulzrinne. “An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol”. In: Proceedings IEEE INFOCOM 2006. 25TH IEEE International Conference on Computer Communications. 2006. [42] Thomas PhD Porter and Michael Gough. How to cheat at VoIP security. English. Rockland, Mass. : Syngress, 2007, 1 online resource (xx, 412 pages) : illustrations. isbn: 9780080553535 0080553532. [43] Houmansadr A. et al. “SWEET: Serving the Web by Exploiting Email Tunnels”. In: IEEE/ACM Transactions on Networking (2017). [44] Fakher Atout. “NAT/Firewall traversal:Issues and solutions”. In: Seminar on network Security. 2006. [45] Dan Wing et al. “Session traversal utilities for NAT (STUN)”. In: (2008). [46] Rohan Mahy, Philip Matthews, and Jonathan Rosenberg. “Traversal using relays around nat (turn)”. In: IETF, RFC 5766 (2010). [47] TURNserver. 2018. url: https://xirsys.com/pricing/ (visited on 06/14/2018). [48] Jonathan Rosenberg. Interactive connectivity establishment (ICE): A protocol for network address translator (NAT) traversal for offer/answer protocols. 2010. [49] Liwei Yang and Kai Lei. “Combining ICE and SIP protocol for NAT traversal in new classification standard”. In: Computer Science and Network Technology (ICCSNT), 2016 5th Interna- tional Conference on. IEEE, 2016, pp. 576–580. [50] Chapter: ICE-Lite Support on CUBE. 2018. [51] Yong Wang, Zhao Lu, and Junzhong Gu. “Research on symmetric NAT traversal in P2P applications”. In: Computing in the Global Information Technology, 2006. ICCGI’06. International Multi-Conference on. IEEE, 2006, pp. 59–59. [52] How fast is 4G? - 4G speeds and UK network performance. url: https://www.4g.co.uk/how- fast-is-4g/ (visited on 05/31/2018). [53] Chaim Gartenberg. Qualcomm’s simulated 5G tests shows how fast real-world speeds could actually be. 2018. url: https://www.theverge.com/2018/2/25/17046346/qualcomm-simulated- 5g-tests-san-francisco-frankfurt-mwc-2018 (visited on 05/31/2018). [54] Zeljko Savic. LTE Design and Deployment Strategie. url: https://www.cisco.com/c/dam/ global / en _ ae / assets / expo2011 / saudiarabia / pdfs / lte - design - and - deployment - strategies-zeljko-savic.pdf (visited on 05/31/2018). [55] Amir M. Ahmadzadeh et al. “Influence of overhead on LTE downlink performance: a comprehensive model”. In: Telecommunication Systems 67.3 (2018), pp. 485–517. [56] F. Lao and G. Teng. “3G-based Remote Video Surveillance and Control System for Facility Agri- culture”. In: 2011 Seventh International Conference on Computational Intelligence and Security. 2011, pp. 164–167. [57] W. Townsley. “Layer 2 Tunneling Protocol ”L2TP””. In: RFC 2661 (1999). [58] A. Houmansadr, C. Brubaker, and V. Shmatikov. “The Parrot Is Dead: Observing Unobservable Network Communications”. In: 2013 IEEE Symposium on Security and Privacy. 2013, pp. 65– 79. [59] Fetchmail. 2018. url: https://sourceforge.net/projects/fetchmail/ (visited on 05/01/2018). [60] Chien-Chao Tseng et al. “WiFi assisted NAT traversal scheme for surveillance patrol robot”. In: 76.04 (2013). 72 BIBLIOGRAPHY

[61] Fei-Yan Fan, Tang-Huai Fan, and Yi-Ming Mao. “Design and implementation of NAT traversal based on SCDMA access gateway”. In: Journal of High Speed Networks 23.4 (2017), pp. 341–359. [62] Chien-Chao Tseng et al. “Can: A context-aware NAT traversal scheme”. In: Journal of Network and Computer Applications 36.4 (2013), pp. 1164–1173. [63] Sechang Son, Bill Allcock, and Miron Livny. “Codo: Firewall traversal by cooperative on-demand opening”. In: High Performance Distributed Computing, 2005. HPDC-14. Proceedings. 14th IEEE International Symposium on. IEEE, 2005, pp. 233–242. [64] Martin Stiemerling et al. “NAT/firewall NSIS signaling layer protocol (NSLP)”. In: (2010). [65] Robert Hancock et al. “Next steps in signaling (NSIS): Framework”. In: (2005). [66] N. Steinleitner, H. Peters, and Xiaoming Fu. “Implementation and Performance Study of a New NAT/Firewall Signaling Protocol”. In: 26th IEEE International Conference on Distributed Computing Systems Workshops (ICDCSW’06). 2006. [67] Tine Stegel et al. “SCTP association between multi-homed endpoints over NAT using NSLP”. In: Electrotech.Rev 75.5 (2008), pp. 277–284. [68] Ruud Klaver. In: Using NSIS (Next Steps in Signaling) for support of QoS aware multimedia services (2007). [69] V. V. Preetham. Internet security and firewalls. English. Cincinnati, Ohio : Premier Press, 2002, 1 online resource (xxii, 337 pages). isbn: 9781931841979 1931841977 1417551933 9781417551934. [70] Ahmed Almusawi and Haleh Amintoosi. “DNS Tunneling Detection Method Based on Multilabel Support Vector Machine”. In: Security and Communication Networks 2018.6 (2018), pp. 1–9. [71] Maurizio Aiello, Alessio Merlo, and Gianluca Papaleo. “Performance assessment and analysis of DNS tunneling tools”. In: Logic Journal of the IGPL 21.4 (2013), pp. 592–602. [72] Alessio Merlo et al. “A comparative performance evaluation of DNS tunneling tools”. In: Com- putational Intelligence in Security for Information Systems. Springer, 2011, pp. 84–91. [73] Paul Mockapetris. “RFC 1035—Domain names—implementation and specification, November 1987”. In: (2004). [74] Graham Edgecombe. IP over DNS with Iodine. 2011. url: https://www.grahamedgecombe. com/blog/2011/06/01/ip-over-dns-with-iodine (visited on 05/11/2018). [75] Viivi Nuojua, Gil David, and Timo Hämäläinen.“DNS Tunneling Detection Techniques–Classification, and Theoretical Comparison in Case of a Real APT Campaign”. In: Internet of Things, Smart Spaces, and Next Generation Networks and Systems. Springer, 2017, pp. 280–291. [76] Greg Farnham and A. Atlasis. “Detecting DNS tunneling”. In: SANS Institute InfoSec Reading Room (2013), pp. 1–32. [77] UPnP Standards & Architecture. url: https://openconnectivity.org/developer/specifications/ upnp-resources/upnp (visited on 05/29/2018). [78] Christopher Daniel Widmer. In: NAT Traversal Techniques and UDP Keep-Alive Interval Opti- mization (2015). [79] Xiaoyu Zhao, Lan Wang, and Daqing Gu. “UPnP Extensions for Public IPv4 Sharing in IPv6 Environment”. In: Networking and Services (ICNS), 2010 Sixth International Conference on. IEEE, 2010, pp. 81–85. [80] Thiago M. Sales et al. “Multilevel security in UPnP networks for pervasive environments”. In: IEEE Transactions on Consumer Electronics 59.1 (2013), pp. 144–152. BIBLIOGRAPHY 73

[81] Yu Shi-Cai, Yan-Zhi Wu, and Run-Niu Guo. “A UPnp-based decentralized service discovery improved algorithm”. In: Computational and Information Sciences (ICCIS), 2013 Fifth Inter- national Conference on. IEEE, 2013, pp. 1413–1416. [82] Bryan Ford, Pyda Srisuresh, and Dan Kegel. “Peer-to-Peer Communication Across Network Address Translators.” In: USENIX Annual Technical Conference, General Track. 2005, pp. 179– 192. [83] Roberto Roverso, Sameh El-Ansary, and Seif Haridi. “Natcracker: Nat combinations matter”. In: Computer Communications and Networks, 2009. ICCCN 2009. Proceedings of 18th Internatonal Conference on. IEEE, 2009, pp. 1–7. [84] Satish Narayana Srirama and Mohan Liyanage. “Tcp hole punching approach to address devices in mobile networks”. In: Future Internet of Things and Cloud (FiCloud), 2014 International Conference on. IEEE, 2014, pp. 90–97. [85] Zhou Hu. “NAT traversal techniques and peer-to-peer applications”. In: HUT T-110.551 Semi- nar on Internetworking. Citeseer, 2005, pp. 04–26.