Private networks intrusion detection system by satisfying network constraints

TRABAJO DE FIN DE GRADO EN INGENIERÍA INFORMÁTICA Private Networks Intrusion Detection System by Satisfying Network Constraints Francisco García Martínez Directed by: Thomas Dean Co-directed by: José Luis Vázquez-Poletti 08/06/2017 TASSEP PROGRAM Faculty of Engineering and Applied Science Queen’s University of Canada & Facultad de Informática Universidad Complutense of Madrid 2 3 Acknowledgements I want to express my sincere gratitude to Dr. Thomas R. Dean, Associate Professor of Queen’s University’s Electrical & Computer Engineering Department and director of this huge and amazing project, without whom any of this would have ever been possible. Thanks to all my project team members for their patience and kindness throughout this year, special mention to Siam Hasan and Ali ElShakankiry. Also, special thanks to my co-director in Spain, Dr. José Luis Vázquez-Poletti, Associate Professor of Complutense University’s Computer Architecture and Automation Department, for his support, help and availability. This research project is funded in part by the National Science and Engineering Research Council of Canada (NSERC) and the Department of National Defense (DND), Canada. 4 5 Abstract The great development of newer technologies also carries an important growth in the number of malicious attacks [ 1 ]. Even private networks without external Internet connections suffer from those attacks. These private networks play a crucial role in the country’s security. Imagine the consequences of turning the power of an entire city down or a denial of service [ 2 ] in an air traffic control system. Because of this fact, numerous politicians, including the recently named United States of America’s president, Donald Trump, are seriously taking into consideration the huge importance of protecting the private networks from intrusions in order to assure their countries’ peace. Some people even believe that efficient Intrusion Detection Systems (IDS) [ 3 ] could be a good protection against a possible Third World War. Thus, new and more powerful security solutions need to be developed to protect our organizations’ systems. Key words: Intrusion Detection System (IDS), Data Distribution Service (DDS), RealTime Publish-Subscribe Protocol (RTPS), private networks, intrusions, constraint engine, network constraints, trees. 6 Resumen El gran desarrollo de las nuevas tecnologías conlleva también un aumento considerable en el número de ataques maliciosos [1]. Incluso las redes privadas sin conexión externa a Internet sufren estos ataques. Estas redes privadas juegan un papel crucial en la seguridad de cada país. Imagínense las consecuencias de tirar abajo la corriente eléctrica de una ciudad entera o una denegación de servicio [2] en un sistema de control aéreo. Debido a este hecho, numerosos políticos, incluido el recientemente nombrado presidente de los Estados Unidos de América, Donald Trump, están concienciándose seriamente de la enorme importancia que supone proteger las redes privadas frente a intrusiones para asegurar la paz en sus países. Alguna gente cree incluso que unos Sistemas de Detección de Intrusiones (IDS) [3] efectivos pueden ser una buena medida de protección ante una posible Tercera Guerra Mundial. De esta forma, nuevas y más potentes medidas de seguridad tienen que desarrollarse para proteger los sistemas de nuestras organizaciones. Palabras clave: Sistema de Detección de Intrusiones (IDS), Servicio de Distribución de Datos (DDS), Protocolo de Publicación-Subscripción en Tiempo Real (RTPS), redes privadas, intrusiones, motor de restricciones, restricciones de red, árboles. 7 8 Glossary • ABS: Anomaly-Based System • ATC: Air Traffic Control • DAG: Directed Acyclic Graph • DDS: Data Distribution Service • DoS: Denial of Service • DDoS: Distributed Denial of Service • DPI: Deep Packet Inspection • IDS: Intrusion Detection System • IGMP: Internet Group Management Protocol • NIDS: Network Intrusion Detection System • OMG: Object Management Group • PCAP: Packet capture • QoS: Quality of Service • RTPS: Real Time Publish-Subscribe Protocol • SBS: Signature-Based System • SCL: Syntax Constraint Language 9 Glosario • ABS: Sistema Basado en Anomalías • ATC: Control de Tráfico Aéreo • DAG: Gráfico Acíclico Dirigido • DDS: Servicio de Distribución de Datos • DoS: Denegación de Servicio • DDoS: Denegación de Servicio Distribuida • DPI: Inspección Profunda de Paquetes • IDS: Sistema de Detección de Intrusiones • IGMP: Protocolo de Gestión de Grupos en Internet • NIDS: Sistema de Detección de Intrusiones en Redes • OMG: Grupo de Gestión de Objetos • PCAP: Captura de Paquetes • QoS: Calidad del Servicio • RTPS: Protocolo de Publicación-Subscripción en Tiempo Real • SBS: Sistema Basado en Firmas • SCL: Lenguaje de Sintaxis de Restricciones Private Networks Intrusion Detection System by Satisfying Network Constraints 16 1.2. Method We are firstly exploring the mentioned framework using two protocols: Internet Group Management Protocol (IGMP) [ 7 ] and Real Time Publish and Subscribe Protocol (RTPS) [ 8 ], being this last one based in the Data Distribution Service (DDS) mechanism [ 9 ]. DDS provides effective support and security for critical services, such as air traffic control management or financial trading. Hence, we start focusing our research on these protocols because they might be used by the kind of applications for what we are aiming our approach. But, once our program is properly working with these two protocols, our final goal is to build a software able to work among any protocol defined, allowing it to, once given the protocol’s definition using a specific language that we create, automatically develop and evaluate the set of constraints for that concrete protocol. Focusing on my particular job, for every defined constraint I will draw a tree that corresponds to its specification to, later on, handily define and create a skeleton for that tree structure in C. Additionally, I will implement all its respective functions to properly work within the system. 1.3. Document Structure First of all, I will go through all the previous background concepts that need to be taken into consideration in order to later better understand the project itself. Here I will talk about concepts such as private networks, deep packet inspection and Network Intrusion Detection Systems, as well as some protocols that will be used. Besides, in this section I will briefly describe our global project framework. Secondly, I will mention the network constraints that we have come up with so far, including a deeper explanation of the constraints I have personally been working on. The third section of the report contains the information related to the trees’ structures I have developed to build the constraints and everything related to the implementation of the constraints I have mentioned before. Thus, for each of those constraints, I will explain the four-phase mechanism that is followed from the creation to the deletion of their corresponding trees. In the fourth section it is described how the constraints are evaluated with my trees structures’ approach, differentiating it from my partner’s approach. Finally, the Conclusions and Future Work section includes the results of the evaluation of the constraints I have worked on using my approach, as well as some related work that could be done in the future. Private Networks Intrusion Detection System by Satisfying Network Constraints 17 2. Introducción El primer y vital paso para asegurar las redes privadas consiste en monitorizar constantemente el tráfico en marcha y definir un “comportamiento normal” de la red. Este comportamiento podría caracterizarse por una serie de restricciones de red [4], por lo que una violación de estas restricciones indicaría una posible intrusión. También, resulta crucial detectar estos intrusos tan pronto como sea posible para minimizar el daño que puedan causar a la red. Sin embargo, en grandes organizaciones en las que se mandan a la red miles de paquetes por segundo, esta tarea puede no resultar fácil. 2.1. Objetivos El propósito de este proyecto de investigación consiste en presentar un novedoso entorno para proteger redes privadas con un número de protocolos limitado ante ataques de intrusiones, a través de la detección de aquellos paquetes que difieran del comportamiento normal en tiempo real [5]. Para ello, modelaremos patrones que representen el tráfico normal en la red como restricciones y presentaremos cómo el entorno está evaluando dichas restricciones ante tráfico obtenido de una red experimental usando herramientas PCAP [6]. La Figura 1 representa a gran escala el comportamiento global del proyecto. Fig. 1. Arquitectura Global del Proyecto. Concretamente, yo estaré trabajando en el Motor de Restricciones y mi objetivo consistirá en el diseño, implementación y correcta prueba del rendimiento de tres restricciones ante el tráfico de prueba de nuestra red experimental. Private Networks Intrusion Detection System by Satisfying Network Constraints 18 2.2. Método En primer lugar, estamos explorando el entorno mencionado usando dos protocolos: el Protocolo de Gestión de Grupos en Internet (IGMP) [7] y el Protocolo de Publicación-Subscripción en Tiempo Real (RTPS) [8], estando este último basado en el mecanismo del Servicio de Distribución de Datos (DDS) [9]. DDS proporciona un apoyo eficaz y seguridad para tipos de servicios críticos, como pueden ser la gestión de control de tráfico aéreo o el comercio financiero. De ahí que empecemos a centrar nuestra investigación en estos protocolos, ya que podrían ser usados por el tipo de aplicaciones para los que estamos fijando nuestro objetivo. Pero una vez que nuestro programa funcione correctamente para estos dos protocolos, nuestro objetivo final consistirá en construir un software capaz de trabajar con cualquier protocolo que se le defina, permitiéndole, una vez especificada la definición de tal protocolo usando un lenguaje que nosotros mismos crearemos, desarrollar y evaluar automáticamente el conjunto de restricciones para dicho protocolo en concreto. Centrándonos en mi trabajo en particular, para cada una de las restricciones definidas, dibujaré el árbol que corresponda a su especificación para, más tarde definir y crear a mano un esqueleto para esa estructura de árbol en C. Adicionalmente, implementaré todas sus respectivas funciones para que puedan integrarse y funcionar correctamente dentro de nuestro sistema. 2.3. Estructura del documento Primero, explicaré brevemente todos los conceptos previos que necesitan ser comprendidos para más tarde entender mejor el proyecto en sí. Aquí, trataré conceptos tales como redes privadas, inspección profunda de paquetes y Sistemas de Detección de Intrusiones en Redes, así como algunos protocolos que serán usados. Además, en esta sección describiré por encima el entorno global de nuestro proyecto. En segundo lugar, mencionaré las restricciones de red que hemos encontrado hasta el momento, incluyendo una mayor explicación de las restricciones sobre las que yo he estado trabajando personalmente. La tercera sección de la memoria contiene toda la información relacionada con las estructuras de árboles que he desarrollado para construir las restricciones, y todo lo relacionado con la implementación de dichas restricciones que he mencionado anteriormente. Así, para cada una de esas restricciones, explicaré el mecanismo de cuatro-fases que es seguido por ellas desde la creación hasta la eliminación de sus árboles correspondientes. Private Networks Intrusion Detection System by Satisfying Network Constraints 19 En la cuarta sección se describe cómo las restricciones son evaluadas con ese enfoque de las estructuras de árboles, diferenciándolo del enfoque que daba mi compañero para su evaluación. Finalmente, la sección de Conclusiones y Trabajo Futuro incluye los resultados de la evaluación de las restricciones sobre las que he trabajado usando mi enfoque, así como trabajo relacionado con el tema que puede ser desarrollado en el futuro. Private Networks Intrusion Detection System by Satisfying Network Constraints 20 3. Background Handful open source IDS [ 10 ], such as Snort, Suricata or Bro [ 11 ], are currently available but, in spite of providing fantastic features and incredibly large rule sets, they all have a common flaw: they only support a few famous protocols, like HTTP [ 12 ] or TCP [ 13 ], and it results a truly tough task to add new rules to the data set. Due to the fact that most of the private networks use their own protocols built for specific purposes, these Intrusion Detection Systems fail to be effective. That is why we focus our approach on developing an IDS able to cope and produce satisfactory results with any protocol. 3.1. Global Project Framework Our previously research group’s proposed framework is divided into three modules: Scanning, Parsing and Constraint Engine [5]. Figure 2 shows a simplified idea of the interaction between those three modules. Basically, the data flow consists of reading and parsing the packets, and converting them into data structures able to be used by the Constraint Checker. Fig. 2. Modules of Intrusion Detection Framework. The scanning module is in charge of reading the packets from PCAP files using Wireshark [ 14 ] and extracting the essential data. Currently, two IP protocols are supported: IGMP and User Datagram Protocol (UDP) [ 15 ]. For every single packet, the Scanner passes the following information to the Parser: source IP, destination IP and arrival time. Besides, it will pass the source and destination ports if there is a UDP packet. The Parsing module receives these packets along with their information, parses them and converts them into C data structures. An alert is generated if the Parser fails to parse any packet. Some examples of failures could be malformed data, like non-sensitive date or time values, or errors in lengths, such as attempted buffer overflows [ 16 ]. On the contrary, if the packets are successfully parsed, they are passed along to the Constraint Engine, where I am going to focus my work. Private Networks Intrusion Detection System by Satisfying Network Constraints 21 The Constraint Checker is an engine that implements a several number of constraints related to the definition of the protocols. Currently, it is being handwritten by the research group, but it is designed as a template to be later automatically generated from a specific language specification which we are working on. My mission in the Constraint Engine is to develop an approach to define the network constraints as tree structures [ 17 ] and, later on, integrate my code with the Parser module and evaluate those trees against sample RTPS data generated by our experimental network. Concretely, I should be able to test my approach for three constraints. Our initial Parser, inherited from previous penetration testing research [ 18 ], used a general engine that is parameterized by a grammar graph. This graph is generated from a Syntax Constraint Language (SCL) protocol description [ 19 ]. SCL derives from ASN.1 [ 20 ], which contains XML markup [ 21 ] to provide both context sensitive parsing and general constraints. Our grammars for IGMP and RTPS were validated against multiple sources of network data to ensure that the grammar was correct. However, the Parser turned out to be too slow for our intrusion detection prototype when evaluated against packet data from an industrial partner. Consequently, we decided to develop a new Parser, which is a hand written, designed with the intention of being automatically generated in the future. Thus, we have manually followed a rigorous approach to translate the SCL to produce a hand coded parser. 3.2. Private Networks In networks such as our home Internet or a cafe’s Wi-Fi we can download apps, send emails, play games, use Facebook or watch YouTube videos. To sum up, there isn’t any restriction about the protocols used or the type of packets sent through the network. Not even about the type or number of devices connected to it. Consequently, it results a really tough work to monitor the ongoing traffic or determine what is “normal” in those networks. These are called public or conventional networks. On the other hand, private networks or intranets are networks created by a single organization that controls its security policies and network management. This means that the devices connected to them are clearly identified, and that the packets that they send belong to a certain type of allowed packets. They use a limited number of protocols. Examples of these networks are telecommunication, nuclear and power plants, or aircraft control systems, which represent critical infrastructures. Private networks increase their security by preventing external access, protecting their industrial control operation from outside attacks. However, a private network is Private Networks Intrusion Detection System by Satisfying Network Constraints 22 not fully secured, as malware could be injected by USB drives or installation discs. For instance, the worldwide known case of the Stuxnet worm used to attack a nuclear plant in Natanz was distributed by an USB flash drive [ 22 ]. As a result, even more protection needs to be developed. Perimeter checking, such as firewalls and authentication policies [ 23 ], are useful defensive techniques, but they can’t monitor the ongoing traffic. The only way of performing that duty is using an Intrusion Detection System [ 24 ]. 3.3. Network Intrusion Detection Systems Network Intrusion Detection Systems (NIDS) are the most efficient way of defending against network-based attacks. They consist in a device or software application that monitors a network for malicious activity or policy violations. NIDS are placed at strategic point or points of the organization and performs an analysis of passing traffic on the entire subnet. These systems are widely used among largescale IT infrastructures [ 25 ]. Basically, there are two main types of NIDS: signaturebased (SBS) and anomaly-based (ABS). On the one hand, signature-based IDS refers to the detection of attacks by looking for specific patterns, such as byte sequences in network traffic, or known malicious instruction sequences used by malware. They maintain a database of signatures of previously known attacks and compare them with the analyzed data. Thus, an alarm would be raised when the signatures were matched. The main advantage of this technique is that signatures are very easy to develop and understand if we know what network behavior we are trying to identify. Moreover, pattern matching can be done more efficiently as they can perform this matching with just a small rule set. For instance, if the system that is to be protected only communicates via DNS [ 26 ] and ICMP [ 27 ], all other signatures can be ignored. However, SBS only detect attacks whose signatures are previously stored in the database, so zero-day attacks [ 28 ] cannot be detected. On the other hand, anomaly-based IDS were primarily created to detect unknown attacks, due to the fast development of malware [ 29 ]. In contrast to SBS, they build a statistical model describing the normal network traffic and, and any abnormal behavior that deviates from the model is identified. As anomaly based detection is based on defining the network behavior, it requires a training phase to develop the database of general attacks and a careful setting of threshold level of detection. This accepted network behavior is prepared or learned by the specifications of the network administrators. The major drawback of ABS is defining its rule set. As a consequence, the efficiency of the system depends on how well it is implemented and tested on all protocols. Hence, we introduce the concept of constraints in our system because it represents more concise actions than rules [ 30 ]. Furthermore, even using dynamic rules of existing IDS, it results a really tough task to create a flexible Private Networks Intrusion Detection System by Satisfying Network Constraints 23 and expressive rule set which can represent a real complex attack scenario [5]. The major advantage over SBS is that a novel attack for which a signature does not exist can be detected if it falls out of the normal traffic patterns. 3.4. Deep Packet Inspection There is a large number of organizations protecting their networks with firewalls, simply limiting their traffic through the ports 22, 80 and 443, corresponding with the SSH [ 31 ], HTTP [9] and HTTPS [ 32 ] protocols respectively. Any packet transmitted by a protocol which does not correspond to any of these three ones, is automatically discarded. However, attackers have found the way of intruding those networks hiding their functionality under either the SSH, HTTP or HTTPS protocols [ 33 ]. As a result, they are able to snick into the network’s allowed traffic without being noticed and correspondingly rejected by the firewalls. Because of these attackers, a simply firewall is not enough to protect the networks, and more sophisticated techniques need to be developed. Here come to scene the term ‘Deep Packet Inspection’. DPI is an advanced method of packet filtering that functions at the Application layer of the OSI (Open Systems Interconnection) reference model [ 34 ]. “The use of DPI makes it possible to find, identify, classify, reroute or block packets with specific data or code payloads that conventional packet filtering, such as firewalls, which examines only packet headers, cannot detect” [ 35 ]. By looking deeply into the packet fields, it is possible to identify the real data that is being sent in each packet. This makes it effective against buffer overflow attacks, denial of service (DoS) attacks and certain types of malware. 3.5. Data Distribution Service The Data Distribution Service (DDS) is an Object Management Group (OMG) protocol whose goal is to provide reliable real-time and scalable communications at a high performance by using a publish-subscribe mechanism. Air traffic control, financial trading or other big data applications are examples of environments where a protocol like DDS is needed for their purposes. Besides, this standard is widely used among worldwide recognized institutions such as the NASA [ 36 ] or the Canadian Air Traffic Control System [ 37 ], as well as in the mining industry to check mining equipment and in the automobile sector to develop simulators [ 38 ]. As shown in Figure 3, DDS provides an infrastructure layer that enables many different types of applications to communicate with each other. Private Networks Intrusion Detection System by Satisfying Network Constraints 24 Fig. 3. DDS Infrastructure. Pardo-Castellote’s paper says: “Publish-subscribe applications are typically distributed applications with endpoint nodes that communicate with each other by sending (or publishing) data and receiving (or subscribing) data anonymously. Usually the only property that a publisher needs in order to communicate with a subscriber is the topic name and the definition of the data. What is more, the publisher does not need any information about the subscribers and vice versa”. Resultantly, the only needed thing to listen to certain data is the Topic Key of the data published and the Domain Id. As said in the RTI paper, “A publish-subscribe infrastructure is capable of delivering data to the appropriate nodes without having to set up individual connections between them”. Machines interested in receiving packets related to a certain topic just need to become a subscriber for that topic. Analogously, nodes willing to send data about a certain topic just need to become a publisher of that topic, and the DDS infrastructure will automatically assure that the published information is distributed to all subscribers interested in that topic, without the publisher needing to specify those destination ports. The specification for DDS is broken up into two separate layers: Data-Centric Publish-Subscribe (DCPS) and Data Local Reconstruction Layer (DLRL) [13]. For our purpose, we will only concentrate on the DCPS portion of the specification. RTI’s paper defines DCPS as following: “DCPS is the lower layer API that an application can use to communicate with other DDS-enabled applications”. This communication mechanism provides them the ability to specify several Quality of Service (QoS) parameters, such as rate of publication, rate of subscription or how long data is valid for. These parameters allow the system designers to build a customized distributed application based on their requirements. In DCPS, applications must use APIs to create entities (objects) in order to establish publishsubscribe communications between each other. DCPS has the following primary Private Networks Intrusion Detection System by Satisfying Network Constraints 25 entities: Domain, Domain Participant, Data Writer, Publisher, Data Reader, Subscriber and Topic. Figure 4 shows how entities in DDS are related. Fig. 4. DDS Entities. The Domain is the basic element needed to bind individual applications and start a communication between them. DDS has the capability of supporting both a single Domain of application’s data-centric [13] communications, and multiple Domains. If the system is using a single Domain, all the nodes will communicate within this Domain. On the contrary, if we have a system that can scale with effective data isolation, we might choose multiple Domains. Therefore, when specific data is published in one Domain, it will not be received by Subscribers residing on any other Domains. Moreover, multiple Domains are also a great way to control the introduction of a new functionality into an existing system. An application uses a Domain Participant to represent its activity within a Domain. This allows developers to define default QoS parameters for all Data Writers, Publishers, Data Readers and Subscribers in that Domain. Thus, this makes it easy to specify default behavior in the Domain. Obtained from Pardo-Castellote’s paper, “Data Writers are the primary access point for an application to publish data into a DDS domain”. An application uses Data Writers to send data. These are associated with a single Topic. An application can have multiple Data Writers and Topics. Besides, it can have more than one Data Writer for a particular Topic. However, before being able to perform a write call, Data Writers need to be created and configured with the correct QoS settings. The Publisher is just a container to group and manage together individual Data Writers. It represents the DCPS object responsible for the actual sending of data. Whereas a Data Writer can only be owned by a single Publisher a Publisher can own multiple Data Writers [ 39 ]. Hence, the same Publisher may be sending data for Private Networks Intrusion Detection System by Satisfying Network Constraints 32 As we already know, a Topic is the link that connects Publishers and Subscribers. Referring to the DDS manual, it is perfectly possible that a Participant can become a Publisher and a Subscriber of the same Topic at the same time. Hence, a Participant can listen to data on a certain Domain, alter this data and, eventually, forward it to the multicast group. This fact can lead to two possible attacks: a malicious Publisher sending illegitimate data; or a denial of service caused by increasing the network’s traffic. Accordingly, Constraint 7 prevents these scenarios by making sure that a current Publisher of a certain Topic in a Domain does not become a Subscriber of the same Topic in that Domain, and vice versa. C8. RTPS – Subscriber turning Publisher: A Topic Key can only be published from a specific set of hosts. RTPS is used in Air Traffic Control (ATC) [ 44 ] worldwide to provide securer air traffic management and communications. For instance, there must be just a specific set of radar information publishers, or a specific machine which allows a plane to land. In ATC, this means very sensible information that must be carefully taken care of to provide a safe and efficient movement of aircrafts in the airspace. Constraint 8 refers to defining a set of Publishers responsible for sending a restricted type of information. Therefore, any machine publishing restricted information that does not belong to the set of allowed Publishers for that Topic constitutes an intrusion. C11. RTPS – Validity of communication: Only a valid Publisher and a valid Subscriber can communicate. During an RTPS unicast communication, DATA packets are constantly being sent from Publishers to Subscribers. In our previous constraints we were checking that either the Participants were members of a valid multicast group or that Publishers were legitimate. Now, we are taking into consideration that when a Publisher sends a DATA packet, its destination is a valid Subscriber. For this type of constraints, it is not enough to check the validity of the Publisher, as an authorize host could be publishing “legitimate” information to intruders. Hence we must check that every DATA packet sent in our network is coming from a trustable Publisher and reaching an allowed Subscriber. Private Networks Intrusion Detection System by Satisfying Network Constraints 33 5. Implementation Once the packets are scanned and successfully parsed by the previous project’s modules (Figure 1), they are passed to the Constraint Engine. According to its protocol, it already receives the necessary parameters of each packet to deal with the constraints. Its basic function is to evaluate the data structures received by the Parser and prompt an alert when a constraint is violated. Figure 6 shows a simplified framework of constraint based IDS. Fig. 6. IDS Framework. As the project is coded in C and, unlike C++, there was not any tree or Directed Acyclic Graph (DAG) [ 45 ] structure available to use, my first approach was to develop our own tree class and tree structure myself, as well as all its functionality. Moreover, the trees were not always binary trees [ 46 ], and the number of children of each node could vary depending on the constraint, making it more difficult to represent our data. Every time a packet arrived, I had to loop through the tree to populate the leaf nodes, as well as to evaluate it (Figure 7 shows how the constraint trees look like). Hence, this approach resulted to be O(log n) and, therefore, considerably costly in time [ 47 ]. Private Networks Intrusion Detection System by Satisfying Network Constraints 34 Fig. 7. Constraint’s tree skeleton. As a result, I had to develop a better approach. This approach is still using trees to represent and solve the constraints. However, instead of creating a tree class, I have coded a new DAG structure (Figure 8), which represents a constraint as an array of nodes by just keeping a pointer to the Root Node and the length of the structure. With this structure I can uniquely represent a general skeleton for each single constraint. Also, every time I need to create a new instance for the tree I just have to allocate some memory and do a memcopy() [ 48 ], without having to walk through the tree to copy it. Fig. 8. Snippet of the DAG structure. Consequently, I have also developed a node structure (Figure 9) to be able to represent the differences between the operator and the leaf nodes. These differences refer to their values and number of children. Each node is composed by a value, an integer that indicates the position where its children start to be allocated in the array, an integer referring to its number of children and a type of node. Knowing the position and number of children allows us to build the hierarchy of the tree. The “eType” field indicates whether the node is an Operator Node or a Leaf node. Depending on the Leaf Node’s type (integer or char) its “vValue” field may vary. Finally, I distinguish between the various types of Operator Nodes: “andOp”, “orOp”, “eqOp” and “notEqOp” correspond to their logical expressions “&&”, “||”, “==” and “!=”. Whereas the “viol” and “aff” operators only refer to Root Nodes. The “viol” operator means that that tree Private Networks Intrusion Detection System by Satisfying Network Constraints 35 should prompt an alert if its evaluation is not satisfied, while the “aff” operator means that an alert should be prompt if the tree’s evaluation is satisfied. Fig. 9. Snippet of the Node structure. Due to this structure, I am able to know the exact position of every node in the array for each constraint, making every operation made on a node O(1), accessing directly to the position without having to loop through the tree. This will be easier to understand if we take a look to Figure 10 (Constraint 1 tree). Thereby, the four constraints’ trees I have developed and their corresponding snippets of code using this tree structure are as follow: Private Networks Intrusion Detection System by Satisfying Network Constraints 36 Fig. 10. Tree drawing of Constraint 1. Fig. 11. DAG structure for Constraint 1. Private Networks Intrusion Detection System by Satisfying Network Constraints 37 Fig. 12. Tree drawing of Constraint 5. Fig. 13. DAG structure for Constraint 5. Fig. 14. Tree drawing of Constraint 7. Private Networks Intrusion Detection System by Satisfying Network Constraints 38 Fig. 15. DAG structure for Constraint 7. Fig. 16. Tree drawing of Constraint 8. Fig. 17. DAG structure for Constraint 8. Private Networks Intrusion Detection System by Satisfying Network Constraints 39 Fig. 18. Tree drawing of Constraint 11. Fig. 19. DAG structure for Constraint 11. Additionally, I have created a Hash Table [ 49 ] structure for each type of constraint to keep track of the existing trees alive. Every Hash Table is formed by a key and a value. In my approach, I have created a “hashnode” structure where the key for each Hash Table is composed of the parameters that create that constraint and identify a single instance of the constraint, and the value is a pointer to the position where the Tree Root for that constraint is allocated. As a result, my Hash Table is an array of “hashnodes”. Thereby, this Hash Table allows me to easily find out whether a tree exists or not and, if it already exists, modify or delete it. Figure 20 shows how this structure looks like for Constraint 1. Similarly, it works for the other three constraints. Private Networks Intrusion Detection System by Satisfying Network Constraints 40 Fig.20. Snippet of the Hash Table structure for Constraint 1. Thanks to my partner’s previous research, we have come up with a four-phaseprocedure to solve the constraints. Thereby, when a new packet arrives and matches any of our constraints, it is classified to its corresponding phase. These four phases are Instantiate, Bind, Evaluate and Delete. 1. Instantiate: every constraint has an action that triggers the creation of a new tree and, consequently, makes us take into consideration different aspects of the machine causing it and follow up its behavior. This action is often related to a specific type of message. Thus, the Instantiate phase refers to the creation of a new tree skeleton and population of the first leaf nodes with the corresponding values of a packet that is sending a “trigger message” that matches any of our constraints. Besides, it is understood that such tree should not previously exist. 2. Bind: there are single packet constraints (already managed by the Parser) and multiple packet constraints. Within multiple packet constraints we can distinguish between two-packet constraints and more-than-two-packet constraints. The reason why we make this distinction is because of the Bind phase. This phase takes place when the arriving message corresponds to an expected message to fill in the remaining leaves from a previously created tree in the Instantiate phase. However, the constraint’s tree is not ready to be evaluated yet, because is still waiting for more packets. Hence, exclusively more-than-two-packet constraints contain this Bind phase. On the contrary, twopacket constraints would go directly for evaluation when one of those messages arrives. In addition, usually just taking a look at the drawing trees it is easy to know if that constraint has a Bind phase or not. So, if the number of children of the last level Operator Nodes is greater than two, it means that the tree has a Bind phase. Although sometimes it might need the Bind phase even if it the number is two. 3. Evaluate: similarly to the Bind phase, when an expected packet matching an Instantiation tree arrives, its remaining leaves are populated. The difference with Private Networks Intrusion Detection System by Satisfying Network Constraints 41 the Bind phase is that the constraint does not have to wait for more packets to be evaluated. As a result, when this phase takes place, the tree is ready for evaluation. Furthermore, it will prompt an alert if the evaluation results to be a violation of the constraint. 4. Delete: although we might think that every tree is being deleted after its evaluation, this assumption is not always valid. It could be possible that a tree is deleted right after being evaluated, but that does not usually happen. Normally, the trees are kept alive until a specific message or action says the contrary (this concept will better be understood when we will go through each single constraint’s case). When that happens, we will both free the memory of the tree itself and its reference in the Hash Map. According to this four-phase procedure, the five constraints I have been working on were developed as described below: 5.1. CONSTRAINT 1: A host is only allowed to send two successive Join Reports to a specific group. Just a reminder that a Join Report refers to a Membership Report sent by a host without previously having received a Membership Query from the router. This constraint was caused by the fact that a host might want to join a multicast group without have been queried by the router responsible for that group. Instantiate: this phase takes place when a host sends an IGMPv2 or IGMPv3 Report to a multicast group address and such address does not match to a previous Membership Query made from that address. Resultantly, if it did not exist yet in the Constraint 1 Hash Table (which would mean that the Join Report is not the first one sent by that host and its tree has already been instantiated), we create a new Constraint 1 tree and we populate its first leaf nodes. Besides, we insert it in the correspondent Hash Table. Figure 21 represents the part of the code corresponding to Constraint 1’s instantiation and Figure 22 shows how the tree would look like at the end of this phase. Private Networks Intrusion Detection System by Satisfying Network Constraints 48 Instantiate: we instantiate a C7a’s tree every time a Data(w) packet (which corresponds to a Publisher) arrives and it does not match to a corresponding instantiation tree created by the same host sending a Subscriber packet. Analogously, we instantiate a C7b’s tree every time a Data(r) packet (which corresponds to a Subscriber) arrives and it does not match to any previously instantiated tree created by the same host sending a Publisher packet. In any case, we have to insert them in their respective Hash Table. However, their drawing trees look exactly the same. Figure 32 shows how both C7a’s tree and C7b’s tree look like after instantiation. Fig. 32: Tree drawing after Instantiate phase for Constraint 7. Evaluate: similarly to how we have instantiated the trees works the Evaluate phase. This is also triggered by a Publisher or a Subscriber packet. On the one hand, we evaluate C7a when a new Publisher packet arrives and it already exists its correspondent C7b’s instantiation tree. On the other hand, we will send C7b for evaluation if a Publisher packet arrives and matches to its correspondent C7a’s instantiation tree. Figure 33 illustrate the evaluation trees for both C7a and C7b. Private Networks Intrusion Detection System by Satisfying Network Constraints 49 Fig. 33: Tree drawing after Evaluate phase for Constraint 7. Delete: when a host sends a Leave Report and it matches to a previously created Constraint 7’s tree we will both delete the respective tree and its reference in the Hash Table. 5.4. CONSTRAINT 8: A Topic Key can only be published from a specific set of hosts. For every Topic there is a list of legitimate Publishers, which are the only ones allowed to push data about that Topic. As a result, Constraint 8 just needs to check if a Data(w) message comes from one of those legitimate hosts. It might seem that this is a single packet constraint and, consequently, it should be evaluated by the Parser. However, here is where we introduce the concept of “Learning Mode” [52]. Every other constraint I have mentioned before is part of the “Checking Mode”, but our Constraint Engine also possesses a “Learning Mode” which has been developed by my partner. This “Learning Mode” allows our Constraint Engine to, as its own name implies, to learn from “facts” [52] and include them to our engine. Therefore, when we have a new Publisher packet we will include it to our “facts”, letting us know in the future that such host is a valid Publisher. Hence, our Constraint Engine is able to update itself and learn from those updates, dealing with constraints that, as happens with Constraint 8, might appear to be single packet constraints and, as a consequence, validated by the Parser. Thus, as it does not involve more than two packets to be evaluated, this constraint only has three out of our four phases. Instantiate: whenever we are in “Learning Mode” and we receive a message from a host wanting to become part of the Domain Participant, we will instantiate a new Private Networks Intrusion Detection System by Satisfying Network Constraints 50 Constraint 8’s tree. Like this, we will also insert it in its respective Hash Table. Figure 34 represents Constraint 8’s tree after instantiation. Fig. 34: Tree drawing after Instantiate phase for Constraint 8. Evaluate: after having instantiated our tree for Constraint 8, the following incoming Publisher packets from that host in that Domain will be sent for evaluation, without going through a Bind phase. Also, notice that, as happened with Constraint 5, we might have to evaluate Constraint 8 without having previously instantiated its tree. In other words, we have to check if every Publisher is trustable, resulting this in a violation of Constraint 8 if that Publisher did not belong to a previous instantiated tree. Figure 35 shows the state of Constraint 8’s tree after evaluation. Private Networks Intrusion Detection System by Satisfying Network Constraints 51 Fig. 35: Tree drawing after Evaluate phase for Constraint 8. Delete: as it happens with most of the constraints, the Delete phase takes place when that specific host sends a Leave Report to the multicast group. Consequently, we have to update our “facts” this time apart from removing the tree and its reference in the Hash Table. 5.5. CONSTRAINT 11: Only a valid Publisher and a valid Subscriber can communicate. Instantiate: the packet that triggers the instantiation of Constraint 11 is a Data(w) packet sent by a host that is notifying the router that wants to become a new Publisher. As a consequence, when this type of packet arrives we will store in the tree the packet’s respective IP and entity key to, later on, insert it in the correspondent Hash Table. This will mean that the host is a validated Publisher. Also, the search keys to find that tree in the Hash Table will be the Topic Key and the Publisher IP, so those are the values we will have to look for in the Bind phase. Figure 36 shows the state of the Constraint 11 tree after being instantiated. Private Networks Intrusion Detection System by Satisfying Network Constraints 52 Fig. 36: Tree drawing after Instantiate phase for Constraint 11. Bind: the Bind phase takes place when a Data(r) packet from a Subscriber arrives. As mentioned before we will have to look for the Topic Key and the Publisher IP that that Subscriber is willing to listen to. Depending on the result of that search we will have two different options: if we cannot find the tree it would be an error, or if, on the contrary it does, we would have to go for an intermediate phase called “Split” [52]. This consists on making an exact copy of the instantiation tree, populate the new values and update the new search keys, because the evaluation packet for Constraint 11 will be looking for the Publisher IP, Publisher port and Subscriber IP instead of the Topic Key and Publisher IP. Consequently, we will also delete the previous instantiation tree. Figure 37 helps visualizing the state of the tree after this phase. Private Networks Intrusion Detection System by Satisfying Network Constraints 53 Fig. 37: Tree drawing after Bind phase for Constraint 11. Evaluate: when a DATA packet is sent from a Publisher to a Subscriber Constraint 11 will go for evaluation. Thus, we will search for the Bind phase’s keys and store the remaining Leaf nodes. If after finishing populating the tree all its nodes are validated, we can assure that the DATA was communicated from a legitimate Publisher to an authorized Subscriber. We can visually see represented the Constraint 11 tree after the evaluation phase takes place in Figure 38. Fig. 38: Tree drawing after Evaluate phase for Constraint 11. Private Networks Intrusion Detection System by Satisfying Network Constraints 54 Delete: the corresponding tree for Constraint 11 will be destroyed when any of the respective participants leave the multicast group. Resultantly, that tree will also be removed from the Hash Table. Private Networks Intrusion Detection System by Satisfying Network Constraints 55 6. Evaluation Assuming that all the trees corresponding to a same constraint look alike could mean that keeping the full tree structure is no longer needed. In other words, if we know that, for example, the third node of the Constraint 7’s tree is always an “EQUAL” node, why do we have to loop through it and check that node’s value every time we evaluate Constraint 7? Besides, why do we have to keep all the Operator Nodes for every instance of a constraint’s tree if we already know what their values are always going to be? It should only be necessary to save the leaves’ values to evaluate the constraint. In fact, that is Siam’s approach: to assume that the Operator Nodes for a certain constraint never change, so we do not have to keep them and save memory for them every time we create a new tree for that constraint. In addition, he is evaluating the trees by simply comparing the leaf values with the operators that “we assume do not vary”, without looping through all the tree structure. However, we are not completely sure about that assumption. Thus, the purpose of this research is to compare the results of my evaluation to Siam’s, testing our Constraint Engine against sample generated traffic data. As a result, if the assumption that we are making is eventually true, we could test whether getting rid of the Operator Nodes and avoid walking through the trees is time costly significant. Therefore, focusing in my approach, it consists on keeping a copy of the full tree structure every time we create a new instance of that tree and walking through every node of the tree when it is sent for evaluation without obviating whether the Operator nodes are always the same. So, in order to evaluate the trees using my approach I created a structure that behaves similarly to a stack, shown in Figure 39. Its basic functioning consists in pushing the Operator nodes to the stack until we find an Operator node whose children are Leaf nodes. In that case, we will evaluate its children and update the Operator node’s value with that result. Following, we will start going backwards in the stack evaluating the Operator nodes of the higher levels with the results obtained in the previous lower levels of the tree. Fig. 39: Snippet of the auxiliary stack structure. In order to make the evaluation function easier, I have developed three auxiliary functions, which we can appreciate in Figures 40, 41 and 42. The first of them simply checks whether a certain node’s children are Leaf nodes. Thanks to that function, I can Private Networks Intrusion Detection System by Satisfying Network Constraints 56 easily identify which nodes belong to the last Operator nodes level and stop pushing the following nodes to the stack. Secondly, the CompareValues() function receives two nodes and an logic operator as parameters, and returns the result of evaluating those two node’s values against that parameter. This function results quite helpful to simplify the comparison between the Leaf nodes differentiating between the several types of logic operators. Finally, the getResults() method uses the previous function to gather the result of comparing the values of all of a certain node’s children according to that node’s operator, so I can compare more than two Leaf nodes and obtain a single result that will be used by the higher level Operator nodes to continue evaluating the tree. Fig. 40: Snippet of the auxiliary function HasLeafNode(). Private Networks Intrusion Detection System by Satisfying Network Constraints 57 Fig. 41: Snippet of the auxiliary function CompareValues(). Private Networks Intrusion Detection System by Satisfying Network Constraints 64 Private Networks Intrusion Detection System by Satisfying Network Constraints 65 9. Appendix 9.1. User Manual IMPORTANT: a Linux operative system is needed to run the program. 9.1.1. Learning Mode Go to the IDS/parserGenerator/F_Constraints folder and open the Constraints.c file with a text editor. Comment out (or make sure that it is commented out) the “#define LEARN” line. Save the file. Fig. 44: Snippet of code for Learning Mode. Open a new terminal and move to the IDS/parserGenerator/F_Constraints directory. Compile and link the program using make. It is possible than make has nothing to be done at all. Fig. 45: Using make command. Run the program using the following command: ./pcapparse LongStressTest.pcapng Once you have run it, the program will have “learned” from our Facts files and will be ready for execution. It is possible that some of the constraints that do not need to learn from facts for their evaluation were evaluated. You should get something like this: Private Networks Intrusion Detection System by Satisfying Network Constraints 66 Fig. 46: Running the program in Learning Mode. 9.1.2. Checking Mode Go to the IDS/parserGenerator/F_Constraints folder and open the Constraints.c file with a text editor. Comment (or make sure that it is commented) the “#define LEARN” line. Save the file. Fig. 47: Snippet of code for Checking Mode. Open a new terminal and move to the IDS/parserGenerator/F_Constraints directory. Compile and link the program using make. It is possible than make has nothing to be done at all. Fig. 45: Using make command. Run the program using one of the two following options: 1. ./pcapparse LongStressTest.pcapng. This option is thought for performance testing, so we do not specify any trace file where to write the outputs. Fig. 48: Running command for 2 arguments. Private Networks Intrusion Detection System by Satisfying Network Constraints 67 2. ./pcapparse LongStressTest.pcapng parsertrace [traceFileName]. This option, apart from showing the results of the execution in the terminal, it also writes the outputs to a trace file. Once the program has finished running, you can check the outputs opening the traceFile file which has been created in the same directory. Fig. 49: Running command for 4 arguments. In any case, you should get the same results printed out in the terminal, which should be similar to these: Fig. 50: Running the program in Checking Mode. Private Networks Intrusion Detection System by Satisfying Network Constraints 68 Private Networks Intrusion Detection System by Satisfying Network Constraints 69 References [ 1 ] Andreea Bendovschi . “Cyber-Attacks – Trends, Patterns and Security Countermeasures”, 2015 (7th International Conference on Financial Criminology 2015, Wadham College, Oxford, UK). [ 2 ] Qijun Gu, Peng Liu. “Denial of Service Attacks”, 2007. [ 3 ] Biswanath Mukherjee, L. Todd Heberlein, Karl N. Levitt. “Network Intrusion Detection”, 1994 (IEEE Network). [ 4 ] Pedro Salgueiro and Salvador Abreu. “Modeling Distributed Network Attacks with Constraints”, 2011. [ 5 ] Siam Hasan, A. ElShakankiry, T. Dean and M. Zulkernine. “Detection of Intrusion in Private Network by Satisfying Network Constraints”, 2016. [ 6 ] Stephen Deck and Hamed Khiabani. “Extracting Files from Network Packet Captures”, 2015. [ 7 ] B. Fenner, H. Be, B. Haberman and H. Sandick. “Internet Group Management Protocol (IGMP) Multicast Listener Discovery (MLD)-Based Multicast Forwarding (IGMP/MLD Proxying)”, 2006. (https://tools.ietf.org/html/rfc4605) [ 8 ] Gerardo Pardo-Castellote. “OMG Data Distribution Service: Real-Time Publish/Subscribe Becomes a Standard”, 2005. [ 9 ] G. Pardo-Castellote, B. Farabaugh and R. Warren. “An Introduction to DDS and Data-Centric Communications”, 2005. [ 10 ] O. Eldow, P. Chauhan, P.Lalwani and M. B. Potdar. “Computer Network Security IDS Tools and Techniques (Snort/Suricata). [ 11 ] V. Paxson. “Bro: A System for Detecting Network Intruders in Real-time”, 1999. [ 12 ] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach and T. BernersLee. “Hypertext Transfer Protocol—HTTP/1.1”, 1999. (https://tools.ietf.org/html/rfc2616) [ 13 ] “RFC 793: Transmission Control Protocol.” (https://www.ietf.org/rfc/rfc793.txt) [ 14 ] “Wireshark.” (https://www.wireshark.org/docs/wsug_html_chunked/ChapterIntroduction.html) [ 15 ] J. Postel. “RFC 768 - User Datagram Protocol”, 1980 (https://tools.ietf.org/html/rfc768) Private Networks Intrusion Detection System by Satisfying Network Constraints 70 [ 16 ] C. Cowan, P. Wagle, C. Pu, S. Beattie and J. Walpole. “Buffer Overflows: Attacks and Defenses for the Vulnerability of the Decade”. [ 17 ] “The Tree Data Model” – Stanford University (http://infolab.stanford.edu/~ullman/focs/ch05.pdf). Retrieved: April 8th 2017. [ 18 ] S. Marquis, T. R. Dean and S. Knight. “Packet Decoding Using Context Sensitive Parsing”, in Proceedings of the 16th IBM Centre for Advanced Studies Conference (SCASCON 06), pp. 263–274, 2006. [ 19 ] S. Marquis, T. R. Dean and S. Knight. “SCL: A Language for Security Testing of Network Applications”, in Proceedings of the 2005 conference of the Centre for Advanced Studies on Collaborative Research (CASCON 05), pp. 16–19, 2005. [ 20 ] “ASN. 1” (http://www.itu.int/en/ITU-T/asn1/Pages/introduction.aspx) Retrieved: April 10th 2017. [ 21 ] “XML 1.0 Specification”. World Wide Web Consortium (https://www.w3.org/TR/REC-xml/) Retrieved: April 10th 2017. [ 22 ] R. P. Andrew Clark, Quanyan Zhu and T. Basarauthor. “An Impactaware Defense Against Stuxnet American Control Conference, ACC, Washington DC, USA”, 2013. [ 23 ] A. Buecker, P. Andreas and S. Paisley. “Understanding the IT Perimeter Security”, IBM, 2008. [ 24 ] D. E. Denning. “An Intrusion-Detection Model”. IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, 1987. [ 25 ] Irfan Gul and M. Hussain. “Distributid Cloud Intrusion Detection Model”, 2011. [ 26 ] P. Mockapetris. “RFC 1035: Domain Names – Implementation and Specification”, 1987 (https://www.ietf.org/rfc/rfc1035.txt) [ 27 ] J. Postel.“RFC 792: Internet Control Message Protocol”, 1981 (https://tools.ietf.org/html/rfc792) [ 28 ] D. Hammarberg. “The Best Defenses Against Zero-day Exploits for Various-sized Organizations”, 2014. [ 29 ] V. Jyothsna, VV. R. Prasad and K. Munivara Prasad. “A review of anomaly based intrusión detection systems”, 2011. [ 30 ] D. Odden. “Rules v. Constraints”, 2007. [ 31 ] T. Ylonen and C. Lonvick. “The Secure Shell (SSH) Protocol Architecture”, 2006. (https://www.ietf.org/rfc/rfc4251.txt) Private Networks Intrusion Detection System by Satisfying Network Constraints 71 [ 32 ] E. Rescorla and A. Schiffman. “The Secure Hypertext Transfer Protocol”, 1999. (https://tools.ietf.org/html/rfc2660) [ 33 ] B. Wippich. “Detecting and Preventing Unauthorized Outbound Traffic”, 2007. [ 34 ] Rachelle L. Miller. “The OSI Model: An Overview”, 2001. [ 35 ] http://searchnetworking.techtarget.com/definition/deep-packet-inspection-DPI Retrieved: April 11th 2017. [ 36 ] “RTI: NASA Human Exploration Telerobotis”. (http://www.omg.org/hottopics/documents/dds/NASA_Telerobotics.pdf) [ 37 ] D. C. Schmidt, A. Corsaro and H. van’t Hag. “Addressing the Challenges of Tactical Information Management in Net-Centric Systems With DDS”, 2008. [ 38 ] RTI: “Why is DDS the Right Technology for the Industrial Internet?” (http://omgwiki.org/dds/sites/default/files/RTILunchAddressOMG2014v2.pdf) [ 39 ] RTI community – DataWriters/Publishers and DataReaders/Subscribers (https://community.rti.com/static/documentation/connextdds/5.2.3/doc/manuals/connext_dds/html_files/RTI_ConnextDDS_CoreLibraries_Users Manual/Content/UsersManual/DataWriters_Publishers_and_DataReaders.htm) [ 40 ] OMG – “The Real-time Publish-Subscribe Wire Protocol DDS Interoperability Wire Protocol Specification”, 2008. [ 41 ] V. Veselý, O. Ryšavý and M. Švéda. “Protocol Indepentent Multicast in OMNeT++”, 2014. [ 42 ] B. Cain, S. Deering, I. Kouvelas, B. Fenner and A. Thyagarajan. “RFC 3376: Internet Group Management Protocol, Version 3.” (https://tools.ietf.org/html/rfc3376) [ 43 ] U. Goyal, G. Bhatti and P. Singh. “A Novel Framework for Mitigating DDoS Attacks”, 2013. [ 44 ] Prismtech – OpenSplice DDS. (http://www.prismtech.com/sites/default/files/documents/OpenSplice_DDS_ATC_AT M_Overview.pdf) [ 45 ] R. A. Sahner adn K. S. Trivedi (IEEE). “Performance and Reliability Analysis Using Directed Acyclic Graphs”, 1987. [ 46 ] David G. Sullivan (Harvard Extension School). “Binary Trees and Huffman Encoding Binary Search Trees”, 2012. [ 47 ] C. T. Silva, J. S. B. Mitchell and P. L. Williams. “An Extract Interactive Time Visibility Ordering Algorithm for Polyhedral Cell Complexes”. Private Networks Intrusion Detection System by Satisfying Network Constraints 72 [ 48 ] Memcpy(3) Linux Programmer’s Manual. (http://man7.org/linux/manpages/man3/memcpy.3.html) Retrieved: April 13th 2017. [ 49 ] J. Triplett, P. E. McKenney and J. Walpole. “Resizable, Scalable, Concurrent Hash Tables”. [ 50 ] N. CANADA. “Av Canada: Media – the Canadian Automated Air Traffic System” (http://www.navcanada.ca/EN/media/Pages/publicationscorporate-direct-route-story1.aspx.) [ 51 ] G. Csmak. “Euroscope – Power of Control” (http://www.euroscope.hu.) [52] Siam Hasan and T. R. Dean. “A constraint-based IDS”. (Pending of revision for publication)