Masterarbeit. Implementation and Performance Testing of the NAT/FW NSIS Signaling Layer Protocol

Transcription

1 Georg-August-Universität Göttingen Zentrum für Informatik ISSN Nummer ZFI-BM Masterarbeit im Studiengang Angewandte Informatik Implementation and Performance Testing of the NAT/FW NSIS Signaling Layer Protocol Niklas Steinleitner am Lehrstuhl für Telematik Bachelor- und Masterarbeiten des Zentrums für Informatik an der Georg-August-Universität Göttingen 12. Dezember 2005

2 Georg-August-Universität Göttingen Zentrum für Informatik Lotzestraße Göttingen Germany Tel. +49 (5 51) Fax +49 (5 51) WWW

3 Ich erkläre hiermit, daß ich die vorliegende Arbeit selbständig verfaßt und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe. Göttingen, den 12. Dezember 2005

4 Acknowledgement I would like to acknowledge my advisors Dr. Xiaoming Fu and Prof. Dr. Dieter Hogrefe for the discussions and guidance, my parents and Doro for their support, Claudia for the proofreading and Henning Peters for his invaluable support, excellent work and encouragement.

5 Abstract This thesis describes the first implementation and performance testing of the path-coupled signaling protocol for Network Address Translator (NAT) and firewall configuration within an extensible IP signaling framework developed by the IETF Next Steps in Signaling (NSIS) working group, called the NAT/FW NSIS Signaling Layer Protocol (NAT/FW NSLP). This new protocol allows hosts to signal along a data path to configure NATs and firewalls according to the data flow needs. In comparison with prior works on firewall signaling, one major contribution of this thesis is that it presents a detailed performance study of the NAT/FW NSLP protocol through an experimental testbed. The performance results show that implementation can support firewall signaling for up to tens of thousands of flows in parallel, and scale well. Besides the limitation due to the low-end PC hardware, the overall performance bottleneck is found to lie in the utilized firewall implementation, not depending on the NAT/FW NSLP implementation.

6

7 Table of Content Table of Content... 1 Table of Figures Introduction Motivation and Scope of This Thesis Thesis Organization Basic Concepts Firewalls Tasks of a Firewall Firewall Components Packet Filter Stateful Filter Proxy Network Address Translation (NAT) Firewall Systems Hybrid Systems Distributed Systems Parallel Systems Middlebox Traversal Soft State The NSIS Framework and NAT/FW NSLP The NSIS Working Group and the NSIS Framework The Fundamental NSIS Signaling Concept NSIS Layered Model Overview Path-Coupled State Configuration Policy Rules for Middleboxes An Introduction to the NAT/FW NSLP Protocol Page 1

8 4. From Concept to Implementation Detailed Protocol Description and Analysis Protocol Overview Protocol Operations Message Types Overview Session Creating Reserving-External-Address Session Refresh Session Deleting Signaling Reservation for Firewalls Reporting asynchronous Events Diagnostic Capabilities within the NAT/FW NSLP Framework Session Lifetime Calculation Message Sequencing Authentication and Authorization Implementation Design Basic Design Overview iptables Finite State Machine (FSM) State Management Performance Testing Testing Methodology and Testbed Setup Testbed Setup Measurement Methods and Tools Testing Results Session Setup Time Processing Time Round Trip Time CPU and Memory Consumption Page 2

9 6. Further Work and Open Issues NAT/FW NSLP Framework NAT/FW NSLP Implementation Summary References APPENDIX A: Packet Format Overview B: Object Overview C: Installation and Usage Page 3

10 Table of Figures Figure 1: Distributed Firewall System with demilitarized Zone (DMZ) Figure 2: Parallel Packet Filters Figure 3: Simple Signaling and Data Flow Example Figure 4: The NSIS Protocol Components Figure 5: General View on NSIS in NAT/FW Case Figure 6: A Firewall Traversal Scenario Figure 7: Scenario with combines NAT and Firewall Figure 8: NAT/FW NSLP interworking Figure 9: Common NSLP Header Figure 10: Common NSLP Object Header Figure 11: Creation Message Flow Figure 12: Data Receiver behind NAT Figure 13: Reservation Message Flow Figure 14: State Refresh Message Flow, CREATE as Example Figure 15: Delete Message Flow, CREATE as Example Figure 16: Signaling Reservation Message Flow Figure 17: Tracing the Signaling Session Path Figure 18: Session Lifetime Calculation, CREATE as Example Figure 19: NAT/FW NSLP Architecture Figure 20: NSLP Initiator FSM Figure 21: NSLP Forwarder FSM Figure 22: NSLP Responder FSM Figure 23: Testbed-Setup Figure 24: Session Setup Time Figure 25: Processing Time Figure 26: NAT/FW NSLP Processing Time, no iptables-calls Figure 27: Session Setup Time Figure 28: Round Trip Time Figure 29: CPU Consumption Figure 30: Memory Utilization Page 4

11 1. Introduction Middleboxes, such as firewalls and Network Address Translators (NAT), have been used throughout the Internet for many years, and it is expected that they will remain present for the foreseeable future [16]. Firewalls are used to protect networks against certain types of threats, and NATs provide a virtual extension of the depleted IP address space. In most instances both types of devices only allow traffic created by entities, which have been specified before. These entities have to follow specified rules or a limited set of applications to traverse them, typical protocols with relatively predetermined and static properties. Applications which have more dynamic properties are unable to traverse firewalls and NATs unassisted. In practice this leads to the fact that the traffic of many applications is not able to traverse firewalls or NATs, even if these have additional functionality which attempts during the traversal or to restore the transparency of the network. Several approaches to enable applications to traverse such entities have been proposed, e.g. application level gateways (ALG) [41], middlebox communication (MIDCOM) [1] [2] [3], STUN [4] and TURN [5], and some of them are currently in use. All of these approaches introduce other problems which are generally hard to solve, e.g. the STUN proposal defines a special STUN server in the public address space to inform the STUN-enabled SIP client in the corporate (private) address space of the public NAT IP address and port being used for that particular session. However, there is a problem within this approach. Most today s uses NATs are symmetric. They create a mapping based on source IP address and port number as well as the destination IP address and port number, but the destination VoIP client address is different from that of the STUN server. The NAT will create a new mapping using a different port for outgoing traffic, which in turn means that the information contained in the call establishment messages is incorrect and the call attempt will fail. The same problem occurs for incoming traffic. Therefore, STUN relies on the fact that once the outgoing port has been mapped for the STUN server traffic, any traffic appearing from any part of the network, with any source IP address, will be able to use the mapping in the reverse direction and so reach the receive port on the client. Some other approaches depend on the type of NAT Page 5

12 implementation (full-cone, symmetric, etc.), other depend on certain network topologies. For NAT and firewall (NAT/FW) signaling it is convenient if signaling travels pathcoupled, meaning that the data packets follow exactly the same path that the signaling messages take, which is similar to Quality of Service (QoS) signaling. RSVP [6] is an example for a QoS signaling protocol that is path-coupled. Roedig et al. [7] proposes the use of RSVP as firewall signaling protocol but does not include NATs. Furthermore, they do not describe a matter-of-fact implementation or any performance evaluation. This thesis describes the implementation and performance testing of the path-coupled signaling protocol for NAT and firewall configuration within an extensible IP signaling framework developed by the IETF Next Steps in Signaling (NSIS) working group, called the NAT/FW NSIS Signaling Layer Protocol (NSLP) [8]. The general requirements for NSIS are defined in [9], whereas the general framework of NSIS is outlined in [10]. The implementation interoperates with the University of Goettingen s GIST implementation [11], which is the fundamental component of the NSIS Framework. Page 6

13 1.1. Motivation and Scope of This Thesis The thesis deals with a novel NAT/FW signaling approach proposed by the IETF. The major objective has been to design, develop and evaluate an implementation of the IETF NAT/FW NSLP Protocol. The implementation has been developed by Henning Peters and me at the University of Goettingen. Henning Peters contributed the NAT part while I implement the firewall part and testing and evaluate the whole protocol and implementation performance. One part of my work has been the implementation but the more important and difficult part has been to evaluate this implementation. This is due to the fact that different proposals for middlebox traversal exist. These however, are rarely implemented and, as far as we know, there is no evaluation of such an implementation at the present time. This leads to the fact that all evaluation methodology had to be self designed and acquired. However, by the absence of other comparable results, it is not possible to compare our evaluation results with others. Nevertheless, the evaluation may be regarded as emphasis of this thesis Thesis Organization This thesis is organized as follows: It starts with a review of the basic concepts in chapter 2, followed by a general overview of the NSIS Framework and the NAT/FW NSLP Protocol in chapter 3. The first part of chapter 4 deals with the detailed NAT/FW NSLP protocol description and analysis, and the second part deals with the implementation design and realization. Chapter 5 presents a performance and scalability testing study which represented a major contribution, since there are no well-known existing comparable investigations on this research topic. Chapter 6 points out the open issues and aspects for further discussion, whereas chapter 7 summaries this thesis. Page 7

14 Page 8

15 2. Basic Concepts This chapter describes the basic concepts which are necessary to understand this thesis. Therefore, firstly an introduction to the tasks and the different types of a firewall will be given. Due to a space limitation, an extensive description of the topic is not presented, and interested readers are suggested to refer to respective literatures as indicated in this thesis Firewalls A firewall is one of many possible measures to protect from special threats. Primarily a firewall is a proactive measure to the protection from threats. A firewall makes examinations and/or modifications of the data flowing over the network border at a transition point possible, on the basis of the given security requirements. Such a transition point is normally a border between two networks, which runs under separate administration policies. Accordingly, a firewall can only be used as a measure against those threats, which can be neutralized at the appropriate network transition, at which the firewall is used. A fundamental description for the function mode of a firewall can be found in [12] and [13] Tasks of a Firewall A firewall implements certain functions, in order to neutralize certain threats. From the available literatures there exist different views on which tasks and/or functions a firewall exactly has to take over. Essentially, all measures, which serve the avoidance of threats at a network border, can be awarded to a firewall. In general a firewall takes over the following tasks: Identity-referred access control, filtering and modification of data, hiding of structures as well as logging of security-relevant events. [14] Page 9

16 Access control: The firewall must be able to accomplish an access control function based on the identities of sender and receiver of the data flows over the firewall. The identities can be determined by the analysis of the data, or by other procedures. For example a user identification, a specified process on a node or a node can be used as identity. Filtering and Modification: Based on the information which is obtained by the analysis of the data flows over the firewall, it must be decided which of the conveyed data represent a threat. Due to this decision the data are forwarded or dropped. Additionally, it can be specified whether data must be modified before forwarding. Hiding: A firewall must be able to hide the structure at the network border on one side from the other side. This impedes the possibility to procure information about possible targets to an aggressor. Logging: Attacks on systems are unnoticed, if there is no possibility to detect irregularities. Therefore, a firewall must be able to accomplish this function Firewall Components The functions that a firewall implements must technically be realized in a firewall system, described by a firewall architecture. It is consist of the individual firewall components as well as the definition of their interaction principles. A firewall component represents the technical conversion of at least one subset of the fulfilling tasks. A firewall system consists of at least one firewall component. The firewall system represents the technical conversion from a firewall to fulfilling tasks. A firewall architecture describes the structure of individual firewall components, as well as the interaction of the individual firewall components within the firewall system. In principle any implementation of a firewall is permissible, if it makes the necessary firewall functions available. There are nevertheless some proven concepts, which can be used for the implementation of firewall components and firewall systems. Those will be described in detail in the following subsections. Page 10

17 Packet Filter A packet filter is realized as part of a network component which is used for connecting two different networks. Thus the network component is extended by a firewall functionality. The packet filter examines on the before fixed criteria basis whether the packets which can be passed on by the network component represent a threat. If a packet represents a threat, it is dropped. The values within the packets are compared with the rules specified before, in order to decide whether a threat is present or not. Mostly, the values of the header fields of the switching- and transport-layer are used for the analysis. Since each examination of a packet is without consideration of the packets which are already analyzed, a packet filter can accomplish only stateless examinations. For stateful analyses, a stateful filter or proxy must be used. An IP packet filter examines for example the packet according to the type of the packet (e.g. TCP or UDP), against IP addresses of the sender and receiver, as well as against the port numbers of the sender and receiver. Packets, which are addressed to a certain receiver, can be recognized as allow or deny and the forwarding of those packets allowed or prevented. A firewall which is realized only by the use of a packet filter, achieve the tasks of a firewall specified in chapter as follows: Access control: The packet filter can verify the identity of the communication participants on the basis of their port numbers and their IP addresses. Filtering and Modification: The firewall decides whether the data are forwarded or not. A modification of the data is not possible before the forwarding process. Hiding: Hiding of the internal network structure is not possible with a filter. Logging: If a packet is dropped by the firewall and is not forwarded, this is noted accordingly. Page 11

18 Stateful Filter A stateful filter is a packet filter, which is able to fall back at the examination of the current packets to the information which was won by the examination of before arrived packets. A stateful filter is able to examine whether a TCP package belongs to an already established TCP-connection or not. For those it is necessary that the stateful filter can note that a connection between sender and receiver is already established. If a packet is later examined by the stateful filter, it can determine whether the packet corresponds to a specified filter rule and fits additionally into the context of the current connections. A stateful filter can also be able to understand individual layers of the application layer and thus the stateful filter has experience about information which is available on this layer only. A firewall which is realized only by the use of stateful filter can fulfill the following tasks: Access control: The stateful filter can determine the identity of the communication participants on the base of their port numbers and their IP addresses. Additionally user-referred information which is within the application layer can be used. Filtering and Modification: The firewall decides whether the data are forwarded or not. A modification of the data is possible before the forwarding process. Hiding: Hiding of the internal network structure is not possible with a filter. Logging: If a packet is dropped or modified by the firewall, this is noted accordingly Proxy A proxy is brought into the communication path between two communication partners, by reflecting the communication endpoint for the respective communication participants. Thus the connection between two communication partners is divided by the proxy. All packets which are sent to the communication participant are received by the proxy and processed on the application level. Therefore, the proxy needs knowledge about the used application protocol. During the processing it is examined whether the data represent threats. As decision base the proxy can use only the data which are won Page 12

19 from the application layer; information which is contained in the data of a lower layer is not directly available to a proxy. A firewall which is realized only by the use of a proxy can fulfill the following tasks: Access control: The proxy can verify the identity of the communication participants on the base of the user-referred information, which maybe contained within the application layer. Filtering and Modification: The firewall decides whether the data are forwarded or not. A modification of the data is possible before the forwarding process. Hiding: Since the communication participants are completely separated on all layers from each other, the structure can be hidden by a proxy. Logging: If a packet is dropped or modified by the firewall, this is noted accordingly Network Address Translation (NAT) A NAT component makes it possible to modify the IP addresses of the IP-packets which are flowing over the component. How the addresses are converted is defined by the rules of the NAT. If the address is converted for a packet, the same conversion must be accomplished also for all other packets of the same data stream. With the help of this an entire subnet can be illustrated to one IP address. Nodes can only be addressed over the NAT, if the rules define an appropriate address conversion. A firewall, which is realized only by the use of a NAT component, can therefore fulfill the following tasks: Access control: The NAT can verify the identity of the communication participants on the base of their port numbers and their IP addresses. Filtering and Modification: The NAT decides whether the data are forwarded or not and whether an address conversion for a certain communication connection is accomplished or not. A modification of the data is necessary before forwarding in order to change the used IP addresses and port numbers. Hiding: The network structure is completely hidden by the NAT. Logging: If data are dropped or modified by the NAT, this is noted accordingly. Page 13

20 Firewall Systems In order to implement all functions necessary for a firewall, all before described firewall components are mostly combined into a firewall system Hybrid Systems A usual combination consists of connecting a proxy with a stateful filter and a NAT. The proxy is thereby on the same equipment as the stateful filter and the NAT. The components are able to interact over a capable interface with one another. The hybrid system thereby makes the functionality available, which arises as a result of the addition of the functionality of the individual components. Because an interaction is possible between proxy and stateful filter, the stateful filter can be limited to take care about the analysis of the data of switching- and transport-layer. The analysis of the application data is taken care of by the proxy. Today's firewall systems are mostly internally implemented as hybrid systems Distributed Systems The above-mentioned components are often used in such a way at a network border that the individual components of the data streams will successively go through. The individual used components cannot interact with each other. Thereby all necessary firewall functions are achieved and the overall system can make sure that a possible error in one component does not lead to a loss of security of the entire firewall. Figure 1 represents a frequently used setup of these components. The hybrid system is behind a packet filter firewall. This design allows some security redundancy. For example, even when the packet filter is cracked, an external attacker must still crack the hybrid system in order to attack the intranet. Further descriptions of such distributed firewall systems are in [12], [13] and [15]. Figure 1: Distributed Firewall System with demilitarized Zone (DMZ) Page 14

21 Parallel Systems Conventional firewall architectures mostly consist of at least one of the firewall components described above. However, the data transmission rates made available by these systems are not sufficient in high-speed networks. One possibility for firewalls to work in a high speed is the parallel use of several similar firewall components. Simple packet filter with similar configuration can be used in parallel, in order to avoid decreasing access speed. Several stateful filters as well as proxies can be operated as load balancer. Those packets come either from the internal or from the external network and reach a distributor. Here they are distributed on all processors. Each of the packet filters decide for itself with the help of an algorithm, which packets it (and only it) works on. Packets, which it does not work on, are dropped. Afterwards the packets are merged and sent into the goal network. But it is complex to use these techniques if the configuration can change dynamically. The complexity increases furthermore, if it is necessary to guarantee that all data of a communication connection flow over the same components. Figure 2: Parallel Packet Filters Page 15

22 2.2. Middlebox Traversal RFC 3234 [16] coins the term middleboxes for such devices: A middlebox is any intermediary device performing functions other than the normal, standard functions of an IP router on the datagram path between a source host and destination host. There are many different types of middleboxes. The most common ones may be network address translators (NAT) and firewalls. RFC 3234 identifies many other types of middleboxes. One way of classifying them is by the behaviour. The first group operates on packets, does not modify application-layer payloads and does not insert additional packets. This group includes NAT, NAT-PT, SOCKS gateways, IP tunnel endpoints, packet classifiers, markers, schedulers, transport relays, IP firewalls and application firewalls. Other middleboxes exist, such as TCP performance-enhancing proxies, application-level gateways, gatekeepers and session control boxes, transcoders, proxies, caches, modified DNS servers, content and applications distribution boxes and load balancers. In this thesis the term middlebox refers to firewalls and NATs only, other types of middleboxes are out of scope. The general purpose of NSIS NAT/FW NSLP signaling is to enable communication between endpoints across networks even in the presence of NAT and firewall middleboxes. Therefore, it is necessary dynamically install additional policy rules in all middleboxes along the data path. Firewalls must be configured in order to forward data packets matching the provided policy rule; NATs must be configured in order to translate data packets matching the provided policy rule. The behaviour of the middleboxes which enables the communication and allows the signaling and data traffic to traverse the middleboxes is called middlebox traversal. Page 16

23 2.3. Soft State The GIST NTLP and also the NAT/FW NSLP takes the soft state approach to manage the states in their nodes. A soft state is created and periodically refreshed by a refresh message. If no refresh message for a session arrived before the expiration of the lifetime value, the state will automatically be deleted. States can also be deleted by an explicit teardown message. In contrast, in the hard state approach reliable explicit messages are used to create, update and remove states. No refresh messages and no soft state timeout removal mechanisms are employed. A crucial concern within the hard state approach is the removal of orphaned states; because the hard state approach does not provide timeout based state removal. It must rely on an external signal to detect that it is holding an orphaned state [17]. The results of [17] show, that a soft state approach improves state consistency at the cost of introducing little additional signaling messages overhead. This and the addition of reliable explicit create, refresh and teardown further allows the soft state approach to achieve comparable and better consistency than the hard state approach. The soft state approach will also explain in chapter 4 with help of the NAT/FW NSLP Framework. Page 17

24 Page 18

25 3. The NSIS Framework and NAT/FW NSLP The following chapter gives a review of the Next Steps in Signaling (NSIS) Framework. Then an overview of the NAT/Firewall NSLP Framework will be given, which has also been developed by the NSIS Working Group The NSIS Working Group and the NSIS Framework The NSIS working group was formed in November 2001 as an IETF working group, with the original goal to elaborate a standard for an IP signaling protocol with QoS signaling as the first use case. For this, the group concentrates on a two-layer signaling paradigm and wants to reuse, where possible, the protocol mechanisms of the Resource Reservation Setup Protocol (RSVP) [6]. However, it should become simpler than RSVP by applying a more general signaling model. After an analysis of the requirements for a new signaling protocol and another analysis of existing protocols, the NSIS group presented their results in a number of papers and developed the NSIS Framework as a guideline for a next generation of internet signaling protocols. In order to support signaling for different types of services or resources - e.g. QoS, NAT & firewall traversal - the concept of NSIS based on a two-layer architecture. Thus the transport signaling and the application signaling can be separated. The Cross Application Signaling Protocol (CASP) [18] [19] was released in November 2003 an was the first implementation of the NSIS Framework and was accepted by the NSIS working group [20] for further exploration of its key design concepts into the General Internet Signaling Transport (GIST) [21] specification. The first implementation of GIST [11] [22] is available since June These implementations of both protocols have been developed and maintained by the University of Goettingen. The initially intended NSIS application was an improved and optimized QoS signaling protocol, which is defined in [23] and since is implemented [24] [25] under the CASP Framework. The second application is a middlebox traversal protocol, the NAT/FW NSLP [8], which this thesis focuses on. In order to correspond to the safety Page 19

26 requirements of such a next generation internet signaling protocol, the NSIS working group studies and analyzes the threats and security requirements for signaling The Fundamental NSIS Signaling Concept The NSIS framework has been developed with the goal of supporting different signaling applications which need to install and manipulate states in the network. This state belonged to a certain data flow and is installed and manipulated on all NSIS Entities (NEs) along the data flow. Not every node has to be such a NE. The basic protocol concept does not depend on signaling application. This section describes the fundamental entities, in which signaling takes place, as well as the intermediate interfaces. Two NSIS entities that communicate directly are defined in be in a peer relationship. This concept is also described as an NSIS hop. Such a NSIS hop must not be a single hop, a NSIS hop can respond to more real hops. Thereby, either or both NEs can store state information about the other NE, but it is not necessary to establish a long-term signaling connection between them. Figure 3: Simple Signaling and Data Flow Example Figure 3 shows one of the simplest possible signaling configurations. A data flow is flowing from an application in the sender via different routers to the receiver. The hosts and two of the routers contain NEs that exchange signaling messages about the flow. R3 does not contain a NE and forwards only the data. The signaling messages exchange is possible in both directions. Page 20

27 NSIS Layered Model Overview In order to solve the modular requirements for NSIS, which are explained in chapter 3.1., the NSIS protocol is structured in two layers: The Signaling Transport Layer (NTLP), which is responsible for moving signaling messages around and nevertheless independent from the underlying signaling application. The NTLP is implemented by GIST [11]. The Signaling Application Layer (NSLP), which allows application based functionalities, such as message formats and sequences. Figure 4 illustrates this modular NSIS approach and the mutual influence between the NTLP and the NSLP. Figure 4: The NSIS Protocol Components Functionality within the NTLP should be restricted only for transport and lower-layer operations. Other operations should be relocated to the signaling application layer. A short description of the NTLP can be: When a signaling message is ready to be sent, the NSLP give it over to the NTLP together with the information to which flow it belong. The NTLP has to care how the message is send to the next NE along the path and the NTLP is also responsible at the end of the path. The important advantage for the NTLP is the point that the NTLP did not must have any knowledge about addresses, capabilities, or status of any NEs along the path, only for the NEs which its direct peers. Page 21

28 Each intermediate NTLP which receives the message forwards the messages directly, or if the signaling application runs locally, passes it to the NSLP for further processing. After processing the NSLP can use the original message or generate another message and hands it over to the NTLP. With this procedure end-to-end message shipment is warranted. This restriction of the NTLP to peer-relationship scope simplifies the management and the complexity of the NSIS Transport Layer but increases the functionality and the complexity of the NSIS Signaling Layer. NTLP messages consist of a common header, and a variable number of Type-Length- Value (TLV) objects. Each object again consists of a common object header (type and length) and a body. There are a number of objects like Message Routing Information (MRI), Session ID (SID), Stack-Proposal, Stack-Configuration-Data and Network- Layer-Information (NLI). The MRI provides information about the path that the signaling should take and includes a flag to distinguish between the two directions that signaling messages can take, called upstream and downstream. This MRI is used inside the NAT/FW NSLP Framework to carry the filter specification; this will describe in chapter in detail Path-Coupled State Configuration Probably the best way to explain the differences between path-coupled and pathdecoupled is to quote it from RFC 4080 [10]. We can consider two basic paradigms for resource reservation signaling, which we refer to as "path-coupled" and "path-decoupled". In the path-coupled case, signaling messages are routed only through NEs that are on the data path. They do not have to reach all the nodes on the data path. Between adjacent NEs, the route taken by signaling and data might diverge. The path-coupled case can be supported by various addressing styles, with messages either explicitly addressed to the neighbour on-path NE, or addressed identically to the data packets, but also with the router alert option, and intercepted. In the second case, some network configurations may split the signaling and data paths ; this is considered an error case for path-coupled signaling. Page 22

29 In the path-decoupled case, signaling messages are routed to nodes (NEs) that are not assumed to be on the data path, but that are (presumably) aware of it. Signaling messages will always be directly addressed to the neighbour NE, and the signaling endpoints may have no relation at all with the ultimate data sender or receiver. The initial goal of NSIS and this framework is to concentrate mainly on the path-coupled case. [10] Policy Rules for Middleboxes Policy rules for firewalls are represented by a common 5-tuple, the source and destination addresses, the transport protocol and the source and destination port and an additional rule action with the value allow or deny. Such a policy rule in NAT/FW NSLP is bounded to a specified session. Policy rules for NATs stand for a translate this address -action and further information which allows this mapping, e.g. an internal IP address and an external IP address. Different from other signaling applications where policy rules are carried in one object, the policy rules in NAT/FW NSLP are divided into an action (allow/deny), the flow identifier and further information. The NTLP s message routing information (MRI) carries the filter specification, the additional information such as lifetime, session ID or message sequence number and the specified action are carried in NSLP s objects (see detailed discussions in section ). Page 23

30 3.2. An Introduction to the NAT/FW NSLP Protocol In October 2003 the NSIS working group published the first version of the NAT/Firewall NSIS Signaling Layer protocol draft [8]. This draft describes scenarios, problems and solutions for path-coupled network address translator and firewall signaling. This is one of the two NSIS Signaling Layer Protocols (NSLPs) that the working group has been developing. The main goal of NSIS NAT/FW signaling is to enable communication between two endpoints between different networks in face of the existence of NATs and firewall middleboxes. Firstly, it is assumed that these middleboxes will be configured in such a way that NSIS NAT/FW signaling messages can traverse them. Then the NSIS NAT/FW NSLP Protocol is used to dynamically install additional policy rules in all NAT/FW compatible middleboxes along the path. NATs will be configured by this protocol to translate data packets according to the policy rules which are provided by the NAT/FW NSLP signaling. Firewall will be configured to forward data packets according to the policy rules which are provided by the NAT/FW NSLP signaling. Additionally, the NAT/FW NSLP provides a mechanism to block explicit data flows at the point of upstream firewalls. A basic view of NSIS is that the end hosts are located behind middleboxes, e.g. a firewall. Figure 5 illustrates such a general view on NSIS in a NAT/FW case. So every application which is located behind a middlebox and wants to try to establish communication with a corresponding application on other end hosts must traverse all middleboxes along the data path. For this, the application triggers the local NSIS entity to provide middlebox traverse along the intended data path, e.g. via an API call. If the local NSIS entity supports NAT/FW NSLP signaling, this NSLP is used to establish policy rules at all middleboxes along the path, which allows the data to travel from the sender to the receiver and traverse all intermediate middleboxes. Page 24

31 Figure 5: General View on NSIS in NAT/FW Case Clearly, it is necessary for all intermediate NATs and firewalls to support the NSIS NAT/FW NSLP, but not necessary for other intermediate nodes to support NSIS NAT/FW or even NSIS. Figure 6 shows a general topology for NAT/FW NSLP within IP networks. Middleboxes are typically placed at the edge of a network and are often combining NAT and firewall, to reduce the number of elements in such a network. This thesis mainly deals with firewalls as middleboxes. Figure 6: A Firewall Traversal Scenario The NSLP Initiator (in the following called NI) sends NSIS NAT/FW NSLP signaling messages via the regular data path to the NSLP Responder (in the following called NR). It is assumed that NI, NR and every intermediate middlebox implements the NAT/FW NSLP. The signaling messages reach different intermediate NSIS nodes (in the following called NSLP Forwarder - NF) and every NAT/FW NSLP node processes the signaling messages under the terms which are explained in chapter and, if necessary, installs additional rules for the following data packets. As it can be seen in Page 25

32 figure 6, each host is behind a firewall and the firewalls are connected via the public Internet. This topology is the general topology this thesis deals with. There are several other possible scenarios for middlebox placement, such as: NAT with two private networks NAT with private network on sender side NAT with private network on receiver side Both end hosts behind a NAT, respectively IPv4/IPv6 with two private networks Multihomed network with NAT Multihomed network with firewall other scenarios like synchronizing firewalls, etc. They are not covered in this thesis. In addition, all scenarios in which end hosts behind NATs and firewalls or behind combined NAT and firewalls in one node are out of scope in this thesis, but figure 7 shows such a scenario for completeness. Figure 7: Scenario with combines NAT and Firewall Page 26

33 4. From Concept to Implementation After describing the basic concepts and scenarios for the NAT/FW NSLP Protocol in previous chapters, this chapter gives detailed descriptions about the NAT/FW NSLP protocol, the protocol operations and an overview about the implementation and the problems which are to be handled thereby Detailed Protocol Description and Analysis Protocol Overview As already described in chapter , the NSIS NAT/FW NSLP is carried over the NSIS Transport Layer Protocol (NTLP) defined in [21]. The interworking with the NTLP and the other components is shown in figure 8. A normal NAT/FW NSLP messages is initiated by the NSLP initiator (NI), may be handled by NSLP forwarder (NF) and finally processed by the NSLP Responder (NR). Therefore, it is required that at least the NI and NR implements the NAT/FW NSLP, NF need only to implement the NAT/FW NSLP, if they provide middlebox functionality. NSIS nodes without the NAT/FW NSLP functionality only forward the packets. Figure 8: NAT/FW NSLP interworking Page 27

34 The following sequence shows a NAT/FW NSLP event procedure: The NSLP initiator generates NAT/FW NSLP messages and sends those to the NSLP responder. The NI must not necessarily be the data sender; when using the RESERVE-EXTERNAL-ADDRESS (REA) message the NI must be the data receiver. Each traversed NSLP forwarder which supports the NAT/FW NSLP processes the NSLP message, checks their local policy rules and forwards the message toward the next NSIS node until the message reach the NR. The NSLP responder checks the received messages, processes it and generates a response messages and sends them back to the NI over the same NF chain. That is guaranteed via the established reverse message routing state in the NTLP. In some scenarios the NR may not necessarily be the data receiver, e.g. in a proxy mode scenario where an edge-nat terminates and replies to requests. Each traversed NF which supports NAT/FW NSLP processes the response messages again. When the NI received a successful response, the data sender can start to send data flow to the data receiver. This NAT/FW NSLP behaviour enables communication between the hosts but only for scenarios in which there are only firewalls on the path or NATs on sender side. The NAT/FW NSLP also supports scenarios with NATs on the receiver side. The above described appropriation assumes that both end hosts are NSIS-aware and fails when only one end is NSIS-aware. The NAT/FW NSLP also supports those scenarios by using a so-called proxy mode. Both cases are already implemented, but as this thesis only focuses on the firewall part these are out of scope. The basic functionality of the NAT/FW NSLP is to enable data flows to traverse firewalls and NATs with the help of opening pinholes and creating NAT bindings on these middleboxes. This is needed because firewalls normally work on deny-all policy; they block all traffic that does not match any existing firewall filter rule. NATs normally block all traffic that does not match any existing configured or installed binding or session. In contrast, some scenarios require to support allow-all policy firewalls. That means that only explicitly blocked traffic is not allowed to traverse these Page 28

35 firewalls. The NAT/FW NSLP provides the capability to install deny policy rules at upstream firewalls with the help of the REA-F message. As already described, the NAT/FW NSLP protocol works with soft states, so every installed state on NAT/FW-aware NSIS nodes will de-installed after a specified period of time. Only a just-in-time received session extension request can prevent this behaviour. To delete no longer needed NAT/FW reservations, the NAT/FW NSLP provides also an explicit state deletion mechanism Protocol Operations This chapter describes the NAT/FW NSLP protocol operations, meaning e.g. how to create a session, keeping it alive there and how to delete it. It also provides an overview about the mechanisms to reserve the external address, the REA-F mechanism, how to report asynchronous events and diagnostic capabilities within the NAT/FW NSLP Framework. The last three topics will only be discussed very shortly; this is due to a likely removal in a further version of the framework. Following will be a discussion about session lifetime calculation, message sequencing and authentication and authorization requirements. The NAT/FW NSLP protocol utilities six messages: CREATE: The create message is the most important component of the NAT/FW NSLP messages. It is a request message used to create, refresh and delete NAT/FW NSLP sessions. RESPONSE: This message is used to respond to CREATE, REA, REA-F and TRACE messages. RESERVE-EXTERNAL-ADDRESS (REA): The REA request is used for reserving an external address and port number. REA-F: This request message is used by data receivers to instruct upstream firewalls to block a specific data flow. TRACE: A request message which can be used by authorized NAT/FW-aware NSIS entities for diagnosis of installed NAT/FW NSLP states. Page 29

36 NOTIFY: An asynchronous message which is used by NAT/FW-aware NEs to alert upstream and/or downstream NAT/FW NEs about specific events, notably in case of failures. The important operations will be described in more detail in the following sections Message Types Overview It is advantageous to show the basic message types and message formats at first. A NAT/FW NSLP message is composed of a NSLP Header and one or more objects, which follow the header. The NSLP header is common for all NSLPs and objects are Type-Length-Value (TLV) encoded using big endian (network ordered) binary data representations. Header and objects are aligned to 32 bit boundaries and object lengths that are not multiples of 32 bits must be padded to the next higher 32 bit multiple. The whole NSLP message is carried as payload of a NTLP message. [8] The NSLP Header is the first part of the message and contains two fields, the NSLP message type and a reserved field. The message types are similar to the six messages types, which are descript in 4.1.2, the reserved field must be set to zero and is used in other NSLPs as a flag field. The total length is 32 bits. Figure 9 shows the common NSLP Header. Figure 9: Common NSLP Header Each NAT/FW NSLP object uses the common NSLP object header format which is defined by figure 10. The common NSLP object header contains two fields, the object type and the object length and additional flags. In total it is 32 bits long. Figure 10: Common NSLP Object Header Page 30

37 The possible values of Object Type and Object Length are describes at the end of this section. The Object Length is the total length of the object without the common NSLP object header. Fields marked with r are reserved for future use. The first two bits are used to signal the favoured treatment for objects which are not defined in the current framework. The NAT/FW NSLP uses part of the categories which are defined in GIST. AB=00 ("Mandatory"): If the object is not understood, the entire message containing it must be rejected with an error indication. AB=01 ("Optional"): If the object is not understood, it should be deleted and then the rest of the message processed as usual. AB=10 ("Forward"): If the object is not understood, it should be retained unchanged in any message forwarded as a result of message processing, but not stored locally. AB=11 ("Refresh"): Must not be used, since the NAT/FW NSLP refreshes its state end-to-end and not locally. Defined NAT/FW NSLP objects are: Session Lifetime Object, Length 2. External Address Object (IPv4/IPv6), Length 2/5. Extended Flow Information Object, Length 1. Response Code Object, Length 1. Proxy Support Type Object, Length 0, only Object Header. Nonce Object, Length 1. Message Sequence Number Object, Length 1. Data Terminal Information Object (IPv4/IPv6), Length 3/6. Trace Object, Length variable. For more details to NAT/FW NSLP messages and NSLP objects check [8] or the appendix. Page 31

38 Session Creating The NAT/FW NSLP uses the CREATE request to establish data flow between two end hosts in attendance of middleboxes. Therefore, the NI generates a CREATE message and hands it over to the NTLP. The NTLP forwards the message to NR. Forwarding is managed hop-by-hop and is transparent for NFs which do not implement NAT/FW NSLP and non NSIS-aware routers between NSLP hops. Each NAT/FW-aware NF along the path processes the message, but can also reject those messages based on local policy rules. When the message reaches the NR and the NR accepts it, the NR creates a response message to this request and the response is forwarded hop-by-hop back to the NI. Figure 11 displays the message flow in case of session creating. Figure 11: Creation Message Flow But the CREATE message is not only used for session creating, combined with the lifetime object it is used for several purposes, for session creating, session modification, session refresh and session deleting. So, the processing methods for a CREATE message depends on the message function, the lifetime and on the node at which the processing happens. The following displays how a CREATE message is processing in the different NSIS node types: NAT/FW NSLP Initiator: The NI only generates the initial CREATE message and hands them over to the NTLP. If the NI receives a successful response message, the session is established and the data path is configured to send data messages to the NR. If the NI receives an error response message, it may try to generate the CREATE message again or send a failure report to the application. Page 32

39 NAT/FW NSLP Forwarder (only firewall): Every NFs which receives an initial CREATE message must first check authentication and authorization with its local policies. This authentication and authorization bases on the combination of the NTLPs Message-Routing-Information (MRI) and the CREATE payload. If a firewall receives an initial CREATE message, the NSLP remembers the requested policy rules, but does not install the policy rules at this time. After this the message is forwarded to the next hop. After receiving a successful response to such a request, the NSLP locally installs the remembered policy rules. NAT/FW NSLP Receiver: If a NR receives an initial CREATE message it first must check authentication and authorization. If authentication and authorization is successful and the request is accepted, the NR must reply with a success RESPONSE message. If authentication and authorization fails, the NR should reply with an error RESPONSE message. This RESPONSE messages are sent back hopby-hop towards the NI, so every intermediate NF process it Reserving-External-Address The above described CREATE-mechanism works also well in presence of NATs and firewall on the path, if the data sender is located behind a NAT. It is catchier if the data receiver is located behind a NAT (compare figure 7), because the NSIS signaling must know the destination address in advance and may also be able to reach it. The NAT/FW NSLP solves this problem by using a common peer-to-peer networking approach, where the two end points learn each others IP address with the help of a third party, so-called Application Server. Figure 12 describes a typical peer-to-peer networking environment where a third party helps two end points to learn of each others IP address. Page 33

40 Figure 12: Data Receiver behind NAT If the data receiver is located behind a NAT then a signaling message will be addressed to the allocated IP address at the NAT. If no NAT forwarding state exists, the signaling message will terminate at the NAT device, because the message transmitted by the data sender cannot install the NAT binding there and the data sender has to know the detailed topology of the data receiver side. So data receivers behind a NAT must reserve an external IP address and port number to enable a following CREATE message. Figure 13 shows the reservation message flow. Figure 13: Reservation Message Flow The NI+ sends a REA message to the predefined opportunistic address (for more details on opportunistic address see [8]). The message is send downstream in reverse direction Page 34

41 of the normal message routing till it reaches the edge-nat. The NI+ includes the data sender s address information object, which is used by the edge-nat to restrict the possible NI addresses to only this address. So the NI+ can specify the IP address and port from where the following NSIS signaling message must arrive. The REA message creates NAT session state at any intermediate NF and ensures that the edge-nat is discovered. If the REA message reaches the edge-nat device, it responds with a RESPONSE message, which includes a success object and the public reachable IP address and port number. Now it is possible to forward an incoming CREATE signaling message towards the NR, which is located behind a NAT Session Refresh All NAT/FW NSLP sessions are maintained on a soft state basis. That means, that sessions and their policy rules, which are not refreshed, are removed automatically after a specified timeout. Each soft state must refresh by the same message type it was created, e.g. a state created by a CREATE must be maintained by CREATE. Refresh messages must carry the exact MRI and session ID as the initial message and a lifetime object with a lifetime greater than zero. NFs receiving session refresh messages must first check authentication and authorization. The NF should check the lifetime with its local policies if it can accept it for this session. NRs which receive such a refresh message, must reply with a RESPONSE message and forward it towards the NI. So, intermediate NFs can update their refresh period. For more details about the session lifetime calculation and the interaction with the message refresh rate see chapter or [8]. Figure 14 shows a refresh message flow, with CREATE as example. Figure 14: State Refresh Message Flow, CREATE as Example Page 35

42 Session Deleting NSLP initiators can delete NAT/FW NSLP sessions anytime by sending a CREATE, REA, or REA-F message with a lifetime object which is set to zero. Sessions created by CREATE can only be deleted by a CREATE message, which is similar for REA and REA-F sessions. Each NAT/FW NSLP node receiving such a message must first check authentication and authorization and must immediately delete the session and associated policy rules if authentication and authorization is verified. Afterwards the message is forwarded as long as it reaches the NR. Figure 15 shows an example delete message flow. Consider that non message with zero lifetime value generates any response. Figure 15: Delete Message Flow, CREATE as Example Signaling Reservation for Firewalls Data receiver can locate behind two types of firewalls; the deny-all and the allow-all firewall. If the receiver is located behind a deny-all firewall it must be able to inform the firewall about their willingness to receive NAT/FW NSLP signaling. In the case that the receiver is located behind an allow-all firewall it must be able to inform the firewall about unwanted traffic that the firewall should be blocked. To provide this capability the data receiver uses the REA-F (REA for firewalls) request message to allow or block incoming NAT/FW NSLP signaling messages. The NI+ generates the REA-F message and sends it to the address of the data sender. Each NF which receives a REA-F message must check authorization and authentication. The further processing depends on the type of the middlebox. NATs allocates a public IP address and port and forwards the message. Edge-NATs which receive a REA-F respond with an error response no edge-firewall. A non edge-firewall only keeps the session state and forwards the message. Edge-firewalls install the specified policy rule and generate a response message which is sent back to the DR. Page 36

43 If the NI+ receives a success response message it is ready to receive signaling or data traffic. Figure 16 shows an example signaling reservation message flow. Figure 16: Signaling Reservation Message Flow Reporting asynchronous Events To provide NFs and NRs the opportunity to report asynchronous events to other nodes, especially to the NI, the NAT/FW NSLP protocol goes together with the NOTIFY message. Currently defined asynchronous events are asynchronous session termination, re-authorization required and route change detected, but there are more possible events which may be defined in later versions of the NAT/FW NSLP Framework [8]. NFs and NRs may generate NOTIFY messages upon asynchronous events, with a response object indicating the reason of the event and a corresponding session ID. These messages are sent hop-by-hop upstream towards NI. NFs receiving a NOTIFY message must first check authentication and authorization, analyse the notified event, behave according to the reported event and forward it upstream towards the NI. NIs receiving a NOTIFY message must first check authentication and authorization, analyse the notified event and behave according to the reported event Diagnostic Capabilities within the NAT/FW NSLP Framework The NAT/FW NSLP Framework also provides a diagnosis capability to session owners, the NI or NI+. This capability allows the session owners to trace the NSIS nodes which are involved in a particular signaling session. The TRACE request message is used to detect the involved NSIS nodes along the signaling session and they return their Page 37

44 identifiers to the session owner. Figure 17 shows a tracing the signaling session path example. Figure 17: Tracing the Signaling Session Path The NSLP initiator generates TRACE request messages. Each NSLP forwarder which receives a TRACE message keeps session state and forwards the message to the DS. When a NSLP responder receives a TRACE message, it stops the forwarding and replies with a RESPONSE message which includes the NATFW_TRACE object and may fill this field with its IP address. Each NF may include its IP address into the NATFW_TRACE object and increment the hop counter by one. Afterwards, the NF must forward the message toward the NI. When the message receives the NI it stops the forwarding and checks the response message for further internal processing Session Lifetime Calculation The NAT/FW NSLP Framework uses the soft state mechanism to install sessions and the appropriate policy rules. A session is kept alive, as long as the session lifetime is valid. If a session expires, given that there was no interim session refresh, the session and the corresponding policy rules as well as the corresponding resources must be automatically removed or freed. The NI is responsible for the session lifetime extension messages and must choose a session lifetime value before sending any message. Each NF and NR along the path must keep the session lifetime but they are not responsible for session refreshing. In order to that the NTLP must handle routing changes, the session lifetime is mostly important for security aspects. The NAT/FW NSLP session lifetime calculation based Page 38

45 on the number of lost refresh messages that NFs can handle, the NI and NR end to end delay, the session hijacking vulnerability and the application data exchange duration. The NAT/FW NSLP message refresh rate (MRR) is calculated using an algorithm defined in [6]. The calculated lifetime and message refresh rate values are placed in the lifetime object of the message and the message is forwarded to the next NSLP hop. NAT/FW-aware nodes process the message according to their local policies. If the lifetime fit their policies they update their local session lifetime and forward the message. Otherwise they may change the lifetime value to fit their needs but must attend the corresponding refresh message period. NFs may also reject the requested lifetime and generate a lifetime to big error response message. If the message reaches the NR, it also may reject the lifetime according to the described proceeding. Otherwise, if the NR accept or change the lifetime, the NR change the local session lifetime value and generate an response message within the granted lifetime and forward it back hop-by-hop to the NI. Figure 18 shows an example for the session lifetime calculation within a CREATE example. The NI requests 60 seconds lifetime and NF1 shorted the lifetime to 20 seconds and NR to 15 seconds. Figure 18: Session Lifetime Calculation, CREATE as Example Message Sequencing A NAT/FW NSLP messages need to carry an identifier so that all nodes on the path can distinguish messages sent at different points of time. Messages can be lost, delayed or duplicated along the path and all NAT/FW NSLP nodes should be able to identify those messages. For this it is necessary to keep information about already received messages and that requires every NAT/FW NSLP message to carry a message sequence number (MSN). Page 39

46 This MSN must be set by the NSLP initiator and no other node has to set or modified this MSN. The NI generates randomly an initial value for the MSN which has to be unique only within this session and has to increment the MSN for every sent message. Each NSLP forwarder and the responder store the MSN which is sent with the initial packet as start value, bound to this session, and include the received MSN in their response messages. When a NAT/FW NSLP node receives a request message it uses the given MSN to appropriate how far the requested state is different to the already installed state. If the received MSN value is lower than or equal to the stored MSN value it has to discard the message in order to assume whether the message is duplicated, delayed or replayed. If the received MSN value is greater than the stored value, the node must update its stored state according to the received message and store the received updated MSN value Authentication and Authorization NAT/FW NSLP nodes which receive a signaling message must first check the authentication and authorization before performing the requested actions. The requirements on authentication and authorization may be quite different in the use cases. These use cases may be enterprise networks, home networks, IP telephone systems, etc. Some of these scenarios have strong authentication and authorization requirements, other have only low requirements. At the moment it is not completely clear or defined what the NAT/FW NSLP requirements for authentication and authorization. The NSIS working group currently works and researches on this part. Page 40

47 4.2. Implementation Design This section gives a general overview about the project design, how the software is arranged, the relationship with the GIST implementation of the University of Goettingen [11] or other software, and the choices of the middlebox implementation and how the NAT/FW NSLP interacts with it. This thesis focuses on the firewall part in the NAT/FW NSLP protocol, so the NAT part will not be discussed in more detail. The NAT part was implemented by Henning Peters Basic Design Overview As the GIST implementation was written in C++ and also provides a powerful NSLP- API, the decision to write the implementation in C++ has been very easy. In addition, this has made it easier to reuse already existing code, which can also be regarded as stable. Another by-product has been to test and improve the implementation of GIST- NSLP API. At the beginning of the work on the implementation, the NAT/FW NSLP draft was version 05 and already changes to version 08. Version 09 is expected to be published before the end of These frequent and rapid changes make an adaptable implementation very important. More importantly, a critical design goal for router software is performance and robustness, especially if a router must handle a large number of sessions. Probably the best way to achieve these requirements is to use a finite state machine (FSM) for the implementation. According to our experience, the implementation of a FSM is very easy and does not bring much performance overhead. More importantly, it provides the possibility to change or extend it with less complexity. Last but not least a FSM makes the code very clean. Based on FSM extended from [27] and described in section 4.2.3, our current NAT/FW NSLP implementation supports draft version 08 and is able to be easily updated to future versions. Given the choice of Linux as the platform for our NSIS protocol suite, we chose netfilter [26] (in the rest of this thesis it is also called iptables) as the packet filter for Page 41

48 firewall and network address translation. It is the broadest packet filter, a de facto standard and enjoys an excellent reputation and popularity with a very large community. The design of the iptables NAT/FW API-will be explained in detail in chapter The NAT/FW NSLP protocol behaviour is implemented in a server-process called NatFwServer. The NatFwServer uses GIST and the GIST-NSLP API to send or receive packets and to manage the NSLP-callbacks, uses the FSM to react according to the arriving event or callback, and the iptables NAT/FW-API to communicate with iptables. The communication between the NatFwServer and the GIST process is achieved via a Unix socket. An additional program called NatFwClient is used to trigger external events, for example a CREATE or a TEARDOWN. This client is used as a test-application and has to be replaced later by the application which wants to use the NAT/FW NSLP, e.g. an IP telephone or a peer-to-peer application. The NatFwClient also use a Unix socket to communicate with the NatFwServer. Figure 19 shows an overview of the project architecture. Figure 19: NAT/FW NSLP Architecture Page 42

49 The most important components of the implementation of such a protocol design are the FSMs, the APIs and the methodology which helps to achieve the soft state approach efficiently and flexibly. Therefore, these are described in detail in the following subsections iptables After the decision to use iptables as firewall and NAT solution there are two possible approaches to interact with it. The first is libiptc. libiptc is the iptables control library, designed for listing and manipulating rules in the iptables kernel module. This static library can be used to communicate with iptables. After the examination of using libiptc, the approach was dropped since the library underlies partly rapid changes between different versions. Furthermore the iptables-developers approve to use another approach. The second possibility is to use a direct system-call from the code using system(). The system function passes a command to the host operating system to run as an external command. The use and interpretation of the command string is implementation-specific. Thereby it has been decided to use the common iptables command inside the NAT/FW NSLP. The disadvantage is that a system call is less efficient than the usage of a static library. The API is divided in two parts, the NAT-API and the FW-API. Both seem to be similar but it is easier and more concise to divide them. This thesis will only explain the FW- API for example, but the concept for the NAT-API is akin. If the NatFwServer starts and detects that it is a firewall in itself, it automatically creates three additional chains inside iptables. These chains are called natfwforward, natfwinput and natfwoutput. They represent the standard iptables chains FORWARD, INPUT and OUTPUT for the NAT/FW NSLP. In the next step these chains are hooked into the appropriate iptables chain, which means natfwforward is hooked into FORWARD, natfwinput into INPUT and natfwoutput into OUTPUT. If the FW-API is requested by the NatFwServer to open a pinhole for a specified 5-tuple, it first checks whether it is not exist. If not, the API inserts the rule corresponding to the 5-tuple inside the appropriate chain and Page 43

50 updates the internal hashtable. If the API has to delete a pinhole, it first checks whether the rule exists and deletes it from the appropriate chain. Here, the FW-API handles its own chains, separating from the normal iptables chains. This approach allows one to check inside the FW-API whether a rule already exists or not without a system-call. Therefore, the API stores in a hashtable the maintained firewall rules. Furthermore, it avoids that the API deletes a before existing rule, since the FW-API can only delete rules inside its own chains. A second advantage of this approach is that it makes the NatFwServer shutdown and the deleting of all existing rules quite easily. The API must only delete the natfwforward, natfwinput and natfwoutput chains and has to delete the hooks in the corresponding chains. Therefore, it can use the iptables command flush, which deletes all rules from a specified chain. Afterwards the now empty chain can be deleted. If the FW-API inserted all rules directly into the standard iptables chains, it would have to delete all appropriate NAT/FW rules individually in order to avoid deleting of before existing rules in the case of a NatFwServer shutdown. Last but not least, this approach makes it easier to clean the iptables chains when encountering a crash of NatFwServer due to an improper handling. This has been shown very useful in the development process Finite State Machine (FSM) To implement the NAT/FW-NSLP Framework each session must maintain one of the three finite state machines. The NSLP initiator must maintain the NI-FSM; an NSLP forwarder must maintain the NF-FSM and the NSLP responder the NR-FSM. Figures show these FSMs. The FSMs are not meant to make an understanding of the detailed protocol behaviour available. They are rather suitable for implementers. These state machines are a little bit different from the current NAT/FW NSLP state machine draft [27]; they are based on the NAT/FW NSLP draft version 08 [8] and the experiences gained during the implementation; the NAT/FW NSLP state machine draft is based on NAT/FW NSLP draft version 07. An update to a new NAT/FW NSLP state machine draft [27] is in process. The state machines presented in this thesis are just one possible interpretation of the protocol. Other implementations may achieve the same results using different methods. Page 44

51 They also do not represent the final code regarding FSMs used in the implementation; rather, they are a result of compromise between clean and simple formal description and the experiences of the implementation. Figure 20: NSLP Initiator FSM Figure 20 represents the state machine for the NSLP initiator which is capable of NSLP NAT/FW signaling. Figure 21 describes the state machine for a NSLP forwarder within the signaling path capable of processing NAT/FW NSLP messages. Page 45

52 Figure 21: NSLP Forwarder FSM Page 46

53 Figure 22: NSLP Responder FSM Figure 22 presents the state machine for the NSIS responder which is capable of NSLP NAT/FW signaling. Page 47

54 State Management An important aspect of a signaling protocol is the way how the implementation handles soft state. For any NAT/FW NSLP implementation, it has to set timers for specified events, e.g. a session timeout. This timeout has a defined value commonly in the rage of seconds. If the timer is fired (this means the count for the timer has reached zero) the implementation has to trigger an event (usually handled by a callback function). If a refresh message for a session arrives before the expiration of the lifetime value, the timer for the timeout has to be extended to the new lifetime value. If no refresh message arrived and the session timeout timer is fired, the session will automatically be deleted. Sessions can also be deleted by an explicit teardown message. This soft state behaviour is implemented with the help of the NSLP-API of the GIST implementation [11]. This GIST implementation provides a powerful NSLP-API, which can be used for setting states and install timers and connecting them to a specified callback. This callback is bound to an event. These timers can be installed as one-off timer, which means that the timer is deleted after it is fired. The NSLP-API also allows defining periodic timers, meaning that a timer is fired e.g. every 15 seconds. With the help of the NSLP-API, NAT/FW implements the soft state approach as follows: A NAT/FW NSLP session is installed with a specified lifetime value at the NSLP forwarder and NSLP responder, e.g. 180 seconds. This timer is a one-off timer. The NSLP initiator session is installed with a periodic timer, which is used to refresh the session if the timer is fired, e.g. every 90 seconds. If the NSLP forwarder and NSLP responder receive a refresh message before the lifetime expired and the timer to delete the session is fired, it has to delete the timer with the old lifetime value and install a new timer with the new lifetime value. This approach can also be used for other timers within the NAT/FW NSLP Framework, e.g. the RESPONSE timer, the REA timer and the REA-F timer. Page 48

55 5. Performance Testing An implementation of the NAT/FW NSLP offers various possibilities for performance testing and evaluation. A large number of different tests could be run, in order to examine e.g. the scalability or the message parsing of the implementation as well as the iptables performance. Therefore, this thesis chose to evaluate the performance of the firewall related implementation, as firewall is being regarded one of the most common and representative middlebox traversal scenarios. It was intended that the main part of this performance testing focused on the evaluation of the NAT/FW NSLP implementation. In the course of the tests it became obvious that not the NAT/FW NSLP implementation itself was the bottleneck with regard to performance, but rather the firewall implementation (i.e., management of the policy rule set). Therefore, this thesis deals also with performance testing of the iptables implementation (netfilter); however, only were connected to the NAT/FW NSLP Framework Testing Methodology and Testbed Setup Before presenting results of the tests, an overview about the testing methodology and the testbed will be given. This performance testing represented a large challenge due to the fact, that currently no evaluation of such a middlebox traversal implementation is available. This demanded all performance testing methodology to be self designed and acquired. Therefore, the results presented in this thesis cannot be compared to results of other evaluation approaches. Page 49

56 Testbed Setup The testing experiments were running on standard PCs with a Debian Linux Kernel version They are equipped with the following hardware: Via Eden CPU 533 MHz 3 Realtek 100Mbps NICs 256 MB SDRAM PC GB HDD Figure 23 show how the nodes were connected for the experiments. The NSLP forwarders both run a firewall. The most experiments were performed with the topology shown in figure 23, but some experiments were performed with only one NSLP forwarder, namely the session setup time and the round trip time testing. Figure 23: Testbed-Setup Measurement Methods and Tools The following methods and tools were used for measurement and testing. To calculate the session setup time and round trip time (chapter and ) timestamps has been inserted directly into the source code. A simple script calculates the time between the two timestamps corresponding to one session. A similar approach is used to calculate the processing time for the implementation (chapter 5.2.2). Also, the processing time for the NAT/FW NSLP protocol behaviour and for iptables can be examined individually. A PHP script similar to Linux process monitoring tool top [32] is used to monitor CPU and memory consumption (chapter ). Gnuplot [33] is used to generate plots and summaries from the before extracted reports. Page 50

57 5.2. Testing Results This section presents the results of the different performance experiments. Aim of these experiments was to test how the scalability of the implementation behaves in the presence of increasing numbers of sessions on core routers. Thereby, limits and bottlenecks of the NAT/FW NSLP and iptables implementations can be detected. The tests are performed using the NatFwClient test-application described in chapter The application is run on the NSLP initiator and creates a new NAT/FW NSLP session every ¾ second. Each session has the same NSLP responder but different source and destination ports. Thereby we can assure that the NSLP forwarders must create a new pinhole for each session. All tests start with zero sessions and generate up to sessions between NI and NR without deleting or teardown existing sessions during the tests. The maximum of sessions is causes by the testbed machines and the iptables implementations; this will be described later with help of the testing results in more detail. GIST is configured to use a refresh rate of 180 seconds and the NAT/FW NSLP is configured to a refresh rate of 90 seconds. Taking account of possible measurement inaccuracy and errors due to our experimental environments, we did repeatedly all tests. The results in following subsections represent the average of those tests. Page 51

58 Session Setup Time The first performance test examined the session setup time of the implementation, meaning how long it takes to establish a NAT/FW NSLP session between NI and NR. The experiment has been performed using only three nodes of the testbed, the NSLP initiator, the NSLP responder and one NSLP forwarder. This is due to the fact that two NF will increase the session setup time and would make it more difficult to get results of the scalability of the implementation. Figure 24 shows the session setup time under different number of sessions. The first observation is that the increase of the session setup time is nearly linear. It can be noted that the implementation does not have low session setup time with only hundreds of sessions. When serving for approximately sessions, the NAT/FW NSLP implementation seemed overloaded with a setup time of about 520 ms. However, iptables is the much more crucial factor, which will be examined in the next experiment. Figure 24: Session Setup Time Page 52

59 Processing Time As shown above, results of the session setup time tests show the serving session number is limited by certain number. This motivated us to examine more closely the processing time distribution of the individual implementation components and to determine the performance bottleneck. Therefore, timestamps were inserted in the source code and the same test was executed again. Several timestamps assure that processing time for the NAT/FW NSLP implementation and the processing time of iptables can be observed individually. The iptables processing time can only be measured on a node using iptables. Hence, measurement was run on a NSLP forwarder and thus the NAT/FW NSLP processing time represents only the values for a NF. Figure 25 shows the processing time for only the NAT/FW NSLP implementation, and the overall processing time together within the iptables costs. As can be seen immediately, the processing time of the NAT/FW NSLP implementation is almost equal to ms, even with increasing number of sessions. In contrast, the processing time for adding a rule into the iptables rule set may be acceptable for up to 6000 sessions; with more than 6000 sessions it increases rapidly and amounts to nearly 400 ms with sessions. This shows that the iptables system-call to open a pinhole is the bottleneck in the experiments. Figure 25: Processing Time Page 53

60 These high values may be caused by the used machines in our testbed, which are, due to their hardware, not comparable with a core router machine. Much crucial for the bad iptables performance, however, is the way iptables implements the rule set; namely as a linked list. iptables uses a simple packet classification algorithm which traverses the rules in a chain linearly per packet until a matching rule is found or not. However, this approach lacks efficiency [28],[29]. So, the linear packet filtering approach is not feasible if many rules are inside the chains. The cost for inserting rules increases rapidly with increasing numbers of rules in the rule set and the processing time per packet also increases. Another critical aspect is that iptables stalls the packet processing during chain updates, e.g. when inserting a rule. Kadlecsik and Pásztor [28] and Hofmann et al. [29] have investigated this behaviour of the iptables implementation. Kadlecsik and Pásztor demonstrated that a high end router needs above 400 seconds to add rules into the rule set and that the cost to add a rule increases the more rules already exists. Several solutions were proposed over the time to solve this problem: ipset [30] is not a complete replacement or extension of iptables itself, but a new matching fully integrated into iptables. ipset supports matching of IP addresses, netblocks or port numbers stored in bitmaps, hashes or trees. nf-hipac [31] is a full featured packet filter for Linux and uses a binary tree to store and evaluate the rule. The user interface closely follows the syntax of iptables and besides the native nf-hipac matches, it can use non-native matches from iptables. However, nf-hipac supports only the filter table and does not provide the same functionality for network address translation. [28] and [29] show that both implementations reduce the number of memory lookups per packet. They are applicable for environments with large rule sets or high bandwidth networks and outperform iptables independent of the number of rules. Thereby, they do not impose any overhead, even for very small rule sets. They also can update their rule sets dynamic without stalling the packet processing in contrast to iptables, which has a worse update performance and stalled packet processing during updates. In order to be able to examine the performance of the implementation with large number of sessions, iptables would have to be replaced by a better scaling implementation. Page 54

61 However, this thesis does not aim to be an evaluation of firewalls, rather focusing on the firewall (and other middleboxes) traversal issue. Therefore, instead of using a different firewall implementation, the firewall was changed to allow-all policy and the calls to iptables are not performed. The experiment is performed to examine only the NAT/FW NSLP implementation without the overhead of a firewall implementation. This experiment approach is likely a good approximation to some realistic scenarios, as [28] and [29] show that the overhead of these firewall implementations can be neglected if the firewall is reasonably implemented. Figure 26 shows the results of this experiment. As it can be seen, the NAT/FW NSLP implementation is now able to handle up sessions, if no iptables implementation is present. This confirms the assumption that iptables represents the bottleneck in the experiments. The maximum of sessions is caused by the low-end PC hardware of the testbed machines; the implementation may be able to handle more sessions in a different environment. Figure 26: NAT/FW NSLP Processing Time, no iptables-calls The experiment demonstrated that the NAT/FW NSLP implementation can handle a larger number of sessions up to an amount of sessions. Hence the session setup Page 55

62 time experiment was run again. In this test - similar to in the previous one - the iptablescalls were not performed. Therefore, the results should demonstrate an approximation for results with a better scaling firewall implementation. Figure 27 shows the results of this experiment, and compares them with the results when the iptables-call was performed. As the figure shows, the session setup time without the iptables-call increases slowly linear. With sessions the session setup time remains under 150 ms. Figure 27 also shows the impact of the iptables implementation on the session setup time. With the iptables-calls, a maximum of sessions could be created and the session setup time increases over 550 ms. Without the iptables-calls - probably also with a better performed firewall implementation sessions could be created and the corresponding session setup time increases only very slowly, up to less than 150 ms. Performance tests with others firewall implementations than iptables are not possible in the scope of this thesis. However, they represent one interesting proposal for further study and performance testing. Figure 27: Session Setup Time Page 56

63 Round Trip Time Figure 28 shows the round trip time (RTT) under different number of sessions. Therefore, one session is created and the round trip time for the refresh message of this session is measured under increasing numbers of sessions. The round trip time with only a few sessions is very low, nearly 5 ms. With below 4000 sessions, the RTT is around 50 ms, however it increases linear when the number of sessions grows above The figure shows the average of the measured RTT for NAT/FW NSLP refresh messages. A detailed investigation showed that the most messages had an RTT of around 50 ms, but some messages had a high RTT. That is due to the fact that iptables stalls the packet processing while during a rule set update. If there are no rule set update presents when the message arrives, the RTT is furthermore around 50 ms. When a message correlated with a rule set update, the message processing has to wait until the rule set update is finish. With another firewall implementation it can be expected that the RTT will be almost around the above noted 50 ms. Figure 28: Round Trip Time Page 57

64 CPU and Memory Consumption The final experiment was to measure the CPU and memory consumption of the NAT/FW NSLP implementation. As described above we were only able to perform tests for less than sessions if iptables is running (and less than sessions if iptables is not running). That is likely due to the fact that the hardware of our testbed machines cannot handle more sessions. Figure 29 show the CPU load of the NSLP forwarder under different numbers of sessions. The first observation is that the CPU load of the iptables implementation increases rapidly if it has to handle more than 2000 sessions. The figure also confirms that the iptables implementation is the bottleneck in the experiments. Furthermore, we can see that the NAT/FW NSLP implementation does not introduce a large overhead. We can also see that the maximum number of sessions depends on the GIST implementation. That is due to the fact that the used GIST implementation [22] currently uses timers of XORP [34], which bring a large overhead to the GIST implementation. Figure 29: CPU Consumption Page 58

65 Figure 30 presents the impact of the number of sessions on the memory utilization of the GIST and NAT/FW NSLP implementations at an NSLP forwarder. The memory utilization of the GIST implementation increases nearly linear. The memory utilization of the NAT/FW NSLP implementation also increases nearly linear, however more slowly. This also suggests - on more advanced hardware - that the implementation may handle many more sessions. Figure 30: Memory Utilization Page 59

66 6. Further Work and Open Issues 6.1. NAT/FW NSLP Framework There are several - mostly minor - open issues in the current NAT/FW NSLP Framework which have to be solved in a later version. Examples are authentication and authorization as well as the AAA interaction, the protocol behaviour in the case of synchronized firewalls, the reacting to route changes and the updating of policy rules, which can be required due to node mobility. The working group is working on these issues and hopes to solve the issues before the NAT/FW NSLP become an RFC, which will estimated occur at the end of NAT/FW NSLP Implementation The current version NAT/FW NSLP implementation of the University of Goettingen supports the firewall part as well as the NAT part of the NAT/FW NSLP Framework. The implementation behaviour of both together is also tested, but not in detail. It is possible that some scenarios may fail and therefore need further study, work and testing. Currently, the implementation uses Unix sockets to communicate with the NTLP. [22] shows that a Plug-in architecture reduce the CPU consumption. The Unix socket solution might still prove worthy to testing and development but a Plug-In architecture is to prefer in a later version of the implementation. What is maybe the most important feature currently missing, is the IPv6 support. This mostly depends on the not yet finished IPv6 support of the GIST implementation. The last versions of the NAT/FW NSLP Framework come partially with rapid changes, so that some protocol operations are not definitively defined, e.g. the REA-F, TRACE and NOTIFY behaviour. This leads to the fact that these protocol operations are not implemented or not yet finally implemented. Performance tests with others firewall implementations than iptables represents one interesting proposal for further study and performance testing. Page 60

67 7. Summary Firewalls and other middleboxes are becoming more and more popular in the Internet. Middleboxes typically only allow traffic which follow specified rules or a limited set of applications to traverse them, typical protocols with relatively predetermined and static properties. Applications which have more dynamic properties are unable to traverse firewalls and NATs unassisted. In practice this leads to the fact that the traffic of many applications is not able to traverse middleboxes. This thesis provides a detailed discussion of the field in middlebox traversal and the first open source implementation and performance evaluation of a recent approach which is currently under the development of the IETF. The implementation proves that the path-coupled NAT/FW NSIS Signaling Layer Protocol Framework [8] of the NSIS working group [20] is technically feasible. The performance results show that the NAT/FW NSLP signalling protocol implementation along (without enabling actual firewall operations) is scale in our experimental environment. To the best of our knowledge, there have been no performance results of any middlebox traversal implementation available, the results presented in this thesis will be regarded as a pioneering work. The performance results show that the overall performance does not mainly depend on the NATFW NSLP implementation, but rather the utilized firewall implementation; here iptables [26]. Due to the low-end PC hardware used in our test environment, when iptables is enabled together with the NAT/FW NSLP signalling protocol, it is currently impossible to handle more than sessions as the drastic increase in session setup time (over 520 ms). This is caused by the processing time of iptables to insert a rule into the rule set. With more than 6000 sessions it increases rapidly and amounts to nearly 400 ms with sessions. This shows the iptables system-call for opening a pinhole to be the bottleneck in the experiments. Without the iptables system-call the implementation is able to handle sessions with nearly stable session setup time, round trip time and processing time. As the NAT/FW NSLP protocol is based on the IETF GIST protocol [10] for signalling transport, the maximal session number of the Page 61

68 NAT/FW NSLP implementation is limited by the GIST implementation [11] which we base on. Previous firewall performance tests in [28] and [29] showed that firewall implementations also can perform well with a large number of rules in the rule set, if the firewall rules are managed efficiently enough. In our implementation, the decision of using iptables implementation resulted in a limited performance for the firewall traversal implementation, as iptables stores the maintained rule sets using link lists. Further study with other firewall implementations will be necessary. So far the implementation has been mostly concerned with enabling and maintaining fixed hosts session-based firewall (and NAT) configurations in middleboxes. It does not dealing with mobile nodes or mobility aspects. This will be a very important step for enabling mobile support for the Internet and is currently being studied within the EU project ENABLE [42]. Lastly, the performance evaluation is currently performed for firewall, not NAT. We believe it is representative enough and expect NAT will exhibit similar scalability as they are based on the same protocol framework and implementation design. Page 62

69 8. References [1] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan, Middlebox Communication Architecture and Framework, RFC 3303 (Informational), August [2] R. P. Swale, P. A. Mart, P. Sijben, S. Brim, M. Shore, Middlebox Communications (MIDCOM) Protocol Requirements, RFC 3304 (Informational), August [3] M. Stiemerling, J. Quittek, T. Taylor, Middlebox Communication (MIDCOM) Protocol Semantics, RFC 3989 (Informational), February [4] J. Rosenberg, J. Weinberger, C. Huitema, and R. Mahy, STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs), RFC 3489, March [5] J. Rosenberg, Traversal Using Relay NAT (TURN), Internet draft (draftrosenberg-midcom-turn-08), September [6] B. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification, RFC 2205, September [7] U. Roedig, M. Goertz, M. Karten, R. Steinmetz, RSVP as firewall Signalling Protocol, Proceedings of the 6th IEEE Symposium on Computers and Communications, Hammamet, Tunisia, pp. 57 to 62, IEEE Computer Society Press, July [8] H. Tschofenig, M. Stiemerling, C. Aoun, A NAT/Firewall NSIS Signaling Layer Protocol (NSLP), Internet draft (draft-ietf-nsis-nslp-natfw-08), October [9] M. Brunner (Ed.), Requirements for Signaling Protocols, RFC 3726, April [10] R. Hancock, G. Karagiannis, J. Loughney, S. Van den Bosch, Next Steps in Signaling (NSIS): Framework, RFC 4080 (Informational), June [11] An Implementation of the Next Steps in Signaling (NSIS) Protocol Suite at the University of Goettingen, [12] W. Cheswick, S. Bellovin, Firewalls and Internet Security: Repelling the Wily Hakker, Addison-Wesley, 1994, ISBN Page 63

70 [13] E. D. Zwicky, S. Cooper, D. B. Chapman, D. Russell, Building Internet Firewalls (2nd Edition), O Reilly & Associates, 2000, ISBN [14] U. Roedig, Firewall-Architekturen für Multimedia-Applikationen, Dissertation, University of Darmstadt, [15] N. Pohlmann, Firewall-Systeme, MITP-Verlag, Bonn, Germany, 2000, ISBN [16] B. Carpenter, S. Brim, Middleboxes: Taxonomy and Issues, RFC 3234 (Informational), February [17] J. Ping, G. Zihui, J. Kurose, D. Towsley, A Comparison of Hard-state and Soft- State Signaling Protocols, Proceedings of SIGCOMM 03, Karlsruhe, Germany, August [18] H. Schulzrinne, H. Tschofenig, X. Fu, A. McDonald, CASP - Cross-Application Signaling Protocol, Internet draft (draft-schulzrinne-nsis-casp-01), March [19] GoCASP: An Implementation of the Cross-Application Signaling Protocol at University of Goettingen, [20] Charter of the NSIS Working Group, [21] H. Schulzrinne, R. Hancock, GIST: General Internet Signaling Transport, Internet draft (draft-ietf-nsis-ntlp-08), September [22] C. Dickmann, An Implementation and Evaluation of the General Internet Signaling Transport (GIST) Protocol, Bachelor Thesis, University of Goettingen, [23] J. Manner, G. Karagiannis, A. McDonald, S. Van den Bosch, NSLP for Qualityof-Service signalling, Internet draft (draft-ietf-nsis-qos-nslp-08), October [24] I. Juchem, Implementation of a Signaling Router for the Euro6IX Premium Service, Master Thesis, University of Goettingen, [25] An Implementation of QoS NSLP at the University of Goettingen, [26] Netfilter, firewalling, NAT, and packet mangling for Linux, Page 64

71 [27] C. Werner, X. Fu, H. Tschofenig, T. Tsenov, C. Aoun, N. Steinleitner, NAT/FW NSLP State Machine, Internet draft (draft-werner-nsis-natfw-nslp-statemachine- 01), July [28] J. Kadlecsik, G. Pásztor, Netfilter Performance Testing, [29] D. Hoffmann, D. Prabhakar, P. Strooper, Testing iptables, Proceedings of the 2003 conference of the Centre for Advanced Studies on Collaborative research, Toronto, Ontario, Canada, pp. 80 to 91, IBM press, [30] IP sets, [31] nf-hipac: High Performance Firewall for Linux Netfilter, [32] Top, Procps - The /proc file system utilities, [33] Gnuplot, [34] XORP, the extensible Open Router Platform, [35] H. Tschofenig, D. Kroeselberg, Security Threats for Next Steps in Signaling (NSIS), RFC 4081, June [36] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J. Arkko, Diameter Base Protocol, RFC 3588, September [37] M. Holdrege, P. Srisuresh, Protocol Complications with the IP Network Address Translator, RFC3027, January [38] M. Brunner, Requirements for Signaling Protocols, RFC 3726 (Informational), April [39] M. Stiemerling, Loose End Message Routing Method for NATFW NSLP, Internet draft (draft-stiemerling-nsis-natfw-mrm), September [40] X. Fu, H. Schulzrinne, H. Tschofenig, C. Dickmann, D. Hogrefe, Overhead and Performance Study of the General Internet Signaling Transport (GIST) Protocol, IEEE INFOCOM 2006, April [41] D. Raz, J. Schoenwaelder, B. Sugla, An SNMP Application Level Gateway for Payload Address Translation, RFC 2962 (Informational), October [42] ENABLE - Enabling efficient and operational mobility and large heterogeneous IP networks, Page 65

72 Page 66

73 APPENDIX Page 67

74 Page 68

75 A: Packet Format Overview Describes which Packet must/can carry which objects. CREATE o Lifetime object (Mandatory) o Extended flow information object (Mandatory) o Message sequence number object (Mandatory) o Proxy support object (Optional) o Nonce object (Mandatory if CREATE-PROXY message) RESERVE-EXTERNAL-ADDRESS o Lifetime object (Mandatory) o Message sequence number object (Mandatory) o Data terminal information object (Mandatory) o Proxy support object (Optional) o Nonce object (Mandatory if proxy support object is included) RESPONSE o Lifetime object (Mandatory) o Message sequence number object (Mandatory) o Response code object (Mandatory) o External address object (Optional), (Mandatory for success responses to REA) NOTIFY o Response code object with NOTIFY code (Mandatory) REA-F o Lifetime object (Mandatory) o Extended flow information object (Mandatory) o Message sequence number object (Mandatory) o Proxy support object (Optional) TRACE o Message sequence number object (Mandatory) Page 69

76 B: Object Overview Common NSLP Header, Length 1. Common NSLP Object Header, Length 1. Session Lifetime Object, Length 2. Page 70

77 External Address Object IPv4, Length 2. External Address Object IPv6, Length 5. Extended Flow Information Object, Length 1. Response Code Object, Length 1. Proxy Support Type Object, Length 0, only Object Header. Nonce Object, Length 1. Message Sequence Number Object, Length 1. Page 71

78 Data Terminal Information Object IPv4, Length 3. Data Terminal Information Object IPv6, Length 6. Trace Object, Length variable. Page 72