Inmap-t: Leveraging TTCN-3 to Test the Security Impact of Intra Network Elements

This paper rejuvenates the notion of conformance testing in order to assess the security of networks. It leverages the Testing and Test Control Notation Version 3 (TTCN-3) by applying it to a redefined notion of System under Test (SUT). Instead of testing, as it is classically done, a software/firmware/ hardware element, an intangible object, namely the network, is tested in order to infer some of its security properties. After a brief introduction of TTCN-3 and Titan, its compilation and execution environment, a couple of use cases are provided to illustrate the feasibility of the approach. The pros and cons of using TTCN-3 to implement a scalable and flexible network testing environment are discussed.


Introduction
This paper explores the usability of the Testing and Test Control Notation Version 3 (TTCN-3 [1]) to infer the presence of security related devices in a network. TTCN-3 is a standard maintained by ETSI that offers a modular testing language and an independent execution environment. Both are used and supported by a large community, very active in various industries. It is mostly used to assess the quality and conformance of a given implementation of a client or server for a specific protocol. Instead of testing a specific piece of software, the idea is to test the properties of an intangible object, namely the network connec-Journal of Computer and Communications tion taking place between two communicating parties. More precisely, the proposal is made to use TTCN-3 to detect the existence of communication artefacts generated by security devices, such as an Intrusion Prevention System (IPS) [2] or a firewall [3], to name only two. The novel contribution is thus to redefine the classical notion of System Under Test (SUT) and to leverage TTCN-3 in a new way to assess some network security properties.
In order to present these ideas, this article is structured as follows. Section 2 motivates this work by explaining the role of a number of devices that could exist on a path between two communicating parties and the security implications of their existences. Section 3 reviews the state of the art related to TTCN-3 on one hand and, on the other hand, to the various approaches related to the testing of network security properties. Section 4 (resp. 5), in order for this document to be self-contained, provides a brief introduction to TTCN-3 (resp. to Titan, its compilation and execution environment). Section 6 shows, thanks to three distinct test cases how TTCN-3 can be used to detect the presence of the devices introduced earlier. Section 7, discusses the pros and cons of this approach based on the lessons learned and Section 8 concludes the paper.

Motivation
"The Network is the Computer" was Sun Microsystems' vision in the 80's as defined, in 1984, by John Gage, the 21st employee of that company. The fact that the Cloudflare company has recently registered the trademark for that very same phrase [4] is emblematic of the regained importance of the network in everyone's daily lives. There is not a single meaningful application which, at some point, does not need to connect to another machine, somewhere on the Internet. It is thus of the uttermost importance to ensure the quality, availability, reliability, performability and security of network connections between machines.
There is a large community of experts that have been very active and successful in monitoring, assessing and improving the four first of these properties. The achievements of the network measurement community are to numerous to be mentioned here.
On the security front, things are very different and, somehow, for good reasons. The security aspects of the network itself have barely been considered because, following the seminal Dolev-Yao model [5], the presence of so called "active observers" is always assumed within the network. Security protocols have to be designed to resist against them by ensuring end-to-end security properties. It is the sole responsibility of the two edge devices to do what is necessary to ensure a secure communication. That is a sound and reasonable design assumption but, in practice, very few real world protocols resist to a powerful "active observer" as it requires strong, unbreakable, mutual authentication of both end devices which is difficult to achieve in practice.
Furthermore, one observes a growing number of devices that interfere, at various layers, with some aspects of these connections. In the same way that traffic shaping devices [6] can, positively or negatively, influence the performances of a  [7], web proxies [8], deep packet inspection tools [9], intrusion prevention systems [2], to only name the most well known ones, are of concern here. All these devices, and many others, can, and usually do, break the end-to-end assumption made about a client-server communication, even encrypted ones sometimes. Their deployment is usually done to improve network security but they are double-edged swords since they can also be deployed surreptitiously by an attacker for malicious purposes anywhere in the Internet to observe or modify data in transit. Last but not least, many protocols are vulnerable to man in the middle attacks at various layers of the protocol stack, as clearly laid out in the 2016 survey by Conti et al. [10] (ARP, DHCP, IP, TCP, DNS, HTTP, etc.).
Thus, in practice, the "active observers" of the Dolev-Yao model can exist under many forms but protocols that are vulnerable to them are still largely used without being even able to test for the presence of such adversary! Clearly, what is lacking is a generic framework capable of testing the security properties of a network connection between two end points. On one hand, such a framework could enable the users to verify that known security mechanisms are present and properly configured (e.g. the firewall is up and running and implements NATing properly). On the other hand, it could also detect the presence of unknown entities interfering between two endpoints (e.g. the HTTP traffic received is different from the one sent by the server).
Proposing such a framework is the intent of this work. More specifically, it shows how to leverage the TTCN-3 environment to run test campaigns to detect either that known devices are configured properly or to detect the presence of malicious ones.

Review of the State of the Art
The origins of TTCN-3 are almost 40 years old, starting with the ISO/IEC standard 9646: OSI Conformance Testing Methodology and Framework (CTMF) [11]. The interested reader is referred to the historical review by Grawoski et al. [12] to discover the various iterations that have led to today's version of TTCN-3 [1]. TTCN-3 is presented in Section 4 but, for the sake of completeness, it is worth mentioning that some competitors exist to this framework such as [13] [14] [15] but reviewing them falls outside the scope of this paper.

Introduction to TTCN-3
Simply speaking, TTCN-3 is a standardized framework defined to verify the conformance of a given implementation with respect to the specification of a • The Distributed mode corresponds to the parallel mode when the participating components do not run on the same machine.

TTCN-3 Core Language
The standardized testing language defined within TTCN-3 [1] has the look and feel of a regular programming language. It provides a well-defined syntax for the definition of tests independent of any application domain. A few important terms are defined here below. They will be used throughout this document, namely: • A component is a user specified entity, which contains user-defined ports, via which the component can interact with other components and the SUT.
Among the various components involved in a test campaign, some have a specific role, namely: -The Main Test Component (MTC) is unique and mandatory for each test campaign. It is created at the beginning of the test campaign and when its execution is over, the test campaign also ends. The MTC coordinates the creation of the needed other components, possibly on remote devices.
-A Parallel Test Component (PTC) is created, as per the MTC instruction, to help it in carrying out the test cases.
-The Test System Interface (TSI) component (also referred to as the system component) is an abstract interface to the SUT. It is used by the other components in order to obtain some information from the SUT (e.g., its IP address, the content of a log file, etc.). • Port: each component owns at least one port that is an interface towards the outer world. Two components can communicate with each other if they own the same type of port and if their ports are connected. The port definition includes the protocol supported to exchange data in a bidirectional flow. There are "Ethernet" ports but also "IP", "TCP", "HTTP" ones and several others. • A module corresponds to a compilation unit in traditional programming languages. It is divided into a definition and a control part. The former contains top-level definitions, such as type, data, constant, port, component, function and test cases. The latter defines the execution sequence of the test cases defined in the first part.  TTCN-3 does not come with any compiler for the language. A compilation environment, such as Titan [40] is needed to use TTCN-3 in practice. Titan also provides an execution environment that will, e.g., provide mechanisms under the hood for the MTC to launch PTCs remotely whenever needed. For this paper to be self-contained, Titan is briefly introduced in the next Section.

Introduction
Eclipse Titan is a TTCN-3 compilation and execution environment with an Ec- It is worth noting that 1) not everything defined in the TTCN-3 standard is supported by Titan and that 2) Titan introduces a couple of novel concepts to support the execution environment.

Titan Compilation Environment
Titan includes a TTCN-3 and ASN.1 Compiler that transforms the TTCN-3 Core Language modules into C++ code. The intermediary C++ files are then compiled into executable files. During the compilation phase other C++ files will be included, such as: • The Base Library which provides other C++ modules required for the correct compilation of the TTCN-3 Core Language structures and data types; • The Titan implementation of the Test Ports. They are defined in C++ files.
Titan supports a number of network protocols and provides also the so-called protocol modules that are APIs to encode/decode streams of bytes to be sent into test ports. For instance, when using a TCP test port, the HTTP protocol module simplifies the programmer's task if in need of sending/receiving HTTP messages.
The compilation environment can be installed from the Titan git repository [41]. The TTCN-3 modules compiled in this environment generate an executable file called the executable test suite. This file contains the test cases but also

Titan Execution Environment
To free the test designer from all the issues related to the communication, synchronisation and coordination aspects of a distributed system architecture, Titan introduces the notions of the Main Controller as well as of a Host Controller.
These elements support the transparent execution environment to run the tests in the TTCN-3 distributed mode. They are not part of the TTCN-3 standard.

Titan Ports
As eluded to before, Titan supports a number of different protocols by means of so called ports which are the interfaces used by components to communicate together. In the context of this work, three of them have been used, namely the LANL2, the IPL4 and the PIPE ports. Their characteristics are briefly given here below to ease the presentation of the test cases in the next Section.
• The LANL2 port [42]  and application) must be provided as a sequence of bytes.
• The IPL4 port [43] is a layer 4, i.e. transport layer, port. It is a general purpose, session independent port providing access to several Internet (IPV4 and IPV6) transport layers protocols such as TCP, UDP, SSL/TLS, etc. If the chosen protocol is connection-oriented then the test port will take care of the handshake messages. • The PIPE port [44] is a special port that establishes a connection between the TTCN-3 test executor and the Unix/Linux shell. It offers the test designer a simple way to execute commands on a machine and retrieve the information available on stdin, stdout, and stderr.
Whenever a LANL2 test port is used, the component using that port must know the name of the sending interface and the MAC address of the recipient (final destination or next hop gateway). These two information are not necessarily known before run time but they can be obtained from the host thanks to the PIPE port.
Some caution must be taken to initiate a TCP connection thanks to the LANL2 port. Sending the initial SYN packet is easy. The remote device, assuming it is listening on the targeted port, will then generate a SYN/ACK packet, as per the usual TCP three ways handshake. The initiating device will not know what to do with this reply since the LANL2 port has bypassed TCP/IP when sending the initial frame. No port is listening for the SYN/ACK packet. As a result, the kernel is very likely to generate a RST packet as a response, which will kill the TCP connection that is being established. To prevent this from happening, a specific iptables [45] rule must be inserted during the whole test case to prevent the emission of the RST packet.

Goal
Typically, when using the TTCN-3 framework, the test designer considers the SUT to be a specific hardware, firmware or software whose implementation compliance needs to be assessed with respect to a specific protocol specification.
In this work, TTCN-3 and the SUT are looked at from a different view point.
The SUT is an intangible object; it is the connection established between a client and a server. The goal is to test whether its behavior is consistent with what is expected from an end-to-end connection. In other words, the goal is to test whether any element between the two end points is interfering with this connection and, if yes, how.
Today's networks contain a number of elements that routinely interfer with the end-to-end connections, such as: In the general case, interfering with the expected end-to-end property of a connection is achieved with the best interest of the client in mind, e.g. to improve security, performance, latency, etc. However such practices are double edged swords and can also be used by malicious actors, anywhere in between the two end points in the network, to achieve some nefarious goal. Being able to test, and explain, such interferences are thus important for two reasons: 1) To verify that all the good elements are acting as they should.
2) To verify that no other element than the good ones is interfering with a connection.
The goal is thus to leverage the TTCN-3 environment to exchange especially crafted packets between a client and a server in order to determine whether or not any element is trying to attack the confidentiality, integrity or availability of the data in transit.
To achieve this goal, the INMAP-T 1 system has been built, named for Intra Network Mapping with Ttcn3. INMAP-T is made of a number of TTCN-3 test cases. The space allocated here does not enable a full description of all of them. Instead of an exhaustive presentation, three representative test cases have been chosen to exemplify the usage of TTCN-3.
The generic set up is first introduced, followed by a brief presentation of how to carry out tests thanks to TTCN-3. The discussion is limited to the atomic notion of a test case. Explaining how to combine them within a test campaign to precisely identify a specific interfering network element lies outside the scope of this paper.

Setup
The architecture used is very simple, made of three hosts: one for the MC and the MTC, one for the Client and one for the Server. The MC and MTC reside on the same host for the sake of simplicity. Both of them play a coordination role during the execution of the tests. The MC maintains a TCP connection not only with the HCs on the client and server machines but also with all the instantiated components (MTC and PTCs). These connections are used whenever the MTC commands the creation of a PTC: the MTC sends the request to the MC which forwards it to the target HC.

Test Cases
The following three test cases highlight how powerful TTCN-3 is to carry out the kind of tests of interest within this work.
1) The first test case uses fragmented packets to detect the presence of any 1 This name is an indirect reference to the nmap tool [46] that focuses on the edges of the network. 2) The second compares sequence numbers and leverages the MTC component to detect a man in the middle at the transport layer.
3) The third one takes advantage of an exporter to verify that encrypted channels are not eavesdropped.

Fragmented Packets
Packets in transit between two end points should only be handled at the physical, link and network layers. They should never be pushed to the transport and application layers. However, in some cases, an intermediary node must inspect the content of the payload before letting it pass. This is true, for instance with Network Based Intrusion Prevention systems [2] when carrying out Deep Packet Inspection. In such case, the packet goes up to the application layer to be scrutinized before being pushed back to the next hop. This is also true for firewalls who have rules that require the inspection of some TCP header values or of the application payload. If an IP datagram is split into two fragments, the IP layer needs to reassemble them in order to extract the layer 4 payload and to pass it over to the TCP layer which, then, can pass it to the application layer. Depending on the implementation, that payload, when resent, lies within a single reassembled IP datagram or is split into the two initial fragmented ones.
A test case has been built to detect such possible reassembly, in transit, of fragmented packets. The LANL2 test port has been used to send the packets because it enables to modify the datagram header and makes it possible to craft fragmented packets. Similarly, the server uses the LANL2 test port and has access to the raw packets sent. If the server receives two fragmented packets, its local verdict for the test is "Pass" and "Fail" otherwise. The local verdict of the client as well as of the MTC is always set to "Pass" if no error happens. Therefore, the global verdict will be uniquely defined by the server since "Fail" has a higher priority than "Pass", as explained in Section 4.2 on page 5.

Sequences Numbers
Sometimes, devices actively violate the end-to-end assumption by acting as a man in the middle at the transport layer. This is the case, for instance, for several kinds of proxies. They will pretend to be the server end point for the client and the client for the server. Two distinct TCP connections exist and the proxy pushes data from one to the other. It is worth noting that, to remain invisible, the proxy can spoof the other IP addresses so that its own will never appear in any of these two TCP connections.
One way to detect the existence of such man in the middle is to compare the initial sequence number sent by the client and the one received by the server.
Only a very meticulous attacker would pick the very same initial sequence number for the TCP connection he initiates with the server.
Such a test case has been built by taking advantage of the IPL4 test port this time. This enables to let the test port takes care of the three way handsakes for us. The LANL2 test ports are also needed though to extract the sequence numbers.
To decide whether the test has failed or not, it is a must to have access to information that only the client, on one hand, and the server, on the other hand, possess. Unfortunately, the only information they are normally supposed to send back to the MTC is their local verdict! This is where the Titan environment proves to be very resourceful. Indeed, Titan offers some language extensions 2 and one of them enables the programmer to let a PTCs return values 3 to the MTC at the end of a test case, together with their local verdict. This feature is used to let the client (resp. server) send a "Pass" local verdict to the MTC, together with the initial sequence number sent (resp. received). The MTC compares the two values to produce its own local verdict which will then determine the final global verdict. Here to, a number of experiments have been run that have confirmed that most implementations of invisible proxies or man in the middle attacks did not bother replicating the initial sequence number among both TCP connections. They can thus be detected by this approach.

Exporter
In the last example, the focus is on encrypted channels, such as the ones in a SSL/TLS session. The situation considered is one where a very stealthy attacker would defeat the previous detection and would decrypt the data in transit and, then, reencrypt it. In theory, this could remain invisible to all. To decrypt the 2 TTCN-3 Core Language offers a way to extend its functionalities and features thanks to the extension [1] clause. Journal of Computer and Communications payload, the attacker needs to know the session key. This is possible if he manages to impersonate the server. However, by design of the key establishment protocols, there will necessarily be two distinct session keys for the connection from the client to the attacker and from the attacker to the server.
A test case has been built to assess whether or not the encrypted sessions seen by the client and by the server rely on the same secrets. However, this information, for good reasons, is not available to external applications but resides securely within the TLS process memory space. Nevertheless, it is possible to use a mechanism known as an exporter, defined in the RFC5705 [47] (previously referred to as a TLS extractor). Thanks to this, it is possible, after a successful TLS handshake, to extract an hexadecimal value derived from the master secret of the session. In the absence of a man in the middle attack, the client and the server must derive the same value.

Discussion and Lessons Learned
The vision is to have a number of end points (servers) disseminated around the world so that clients could, on one hand, test their own equipment when communicating to the Internet and, on the other hand, detect the presence of malicious elements on certain routes, possibly sharing that information with a larger community.
A number of test cases have been implemented, on top of the three described here above. The examples given aim at letting the reader understand how easily it could be to test, for instance: • whether a firewall is correctly configured: which ports are blocked, which ones are forwarded, whether NATing is enabled, etc.
• whether a DPI is up and running by, e.g., sending a payload that matches a detection signature which should block the packet.
• whether some unknown device is interfering at any possible layer with a given connection.
• whether some man in the middle attack is taking place.
• whether some DNS poisoning attack has been realized.
Based on the experiments, rejuvenating the concept of SUT by defining it as being an intangible object, as opposed to, e.g., a server implementation, appears to offer a lot of opportunities. To do this, TTCN-3 and Titan offer all the func-A. Vitale, M. Dacier Journal of Computer and Communications tional blocks needed, not only to define the test campaigns but also to orchestrate the whole distributed architecture required. However, when running the experiments, a number of shortcomings appear that need to be addressed in order to build an easy to use and scalable testing environment. The most problematic issues are summarized here after: • As explained before, the executable test suite must contain, among other things, the code for all test cases. Adding a single new test case amounts to change the whole executable, install it on all participating hosts and restarting all components. Not only is this a very costly operation but, worse, neither TTCN-3 nor Titan do offer a mechanism to implement such software update.
• The more test cases exist, the bigger the executable test suite becomes. In particular, the more Titan ports are used, the more code needs to be included. As of now, the size of the executable is, roughly, of 17 MBytes. 2/5 of it comes from the three ports used, 2/5 of it is the code for the MTC, PTC, etc., the last 1/5 corresponds to code written for the test cases.
• TTCN-3 is a very rich and well defined language but its readability is influenced by its historic ties with the C++ language. This will please those used to it but may be a show stopper for newcomers.
• The TTCN-3 standard defines a single way to establish the global verdict, based on priorities among local verdicts, as explained in the text. It is possible, as shown in the text, to come around this limitation by implementing a decision function within the MTC based on values provided by the other elements and by forcing them all to generate a "Pass" verdict. This is a practical solution but definitely not an elegant one.
All these issues could possibly be addressed by "wrapping" the TTCN-3 environment within another one providing the missing functionalities. A first attempt at doing this has been achieved by one of the authors in [48]. Further work needs to be done in order to decide whether this is the right way to go or if, instead, it is preferable to recreate a new environment, from scratch, specifically tailored at network testing, inspired by the many good ideas and concepts from TTCN-3.

Conclusion
In this work, the rationales for testing the security properties of an end-to-end connection between a client and a server have been presented. The standardized TTCN-3 environment, while not designed for such tasks, could be leveraged by