Bachelor. Analysis of NAT approaches and explicit signaling for NAT traversal

Transcription

1 Georg-August-Universität Göttingen Zentrum für Informatik ISSN Nummer ZFI-BM Bachelor im Studiengang "Angewandte Informatik" Analysis of NAT approaches and explicit signaling for NAT traversal Henning Peters am Lehrstuhl für Lehrstuhl für Telematik Bachelor- und Masterarbeiten des Zentrums für Informatik an der Georg-August-Universität Göttingen 8. April 2006

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, dass ich die vorliegende Arbeit selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe. New York, den 8. April 2006

4

5 Bachelorarbeit Analysis of NAT approaches and explicit signaling for NAT traversal Henning Peters 8. April 2006 Betreut durch Prof. Dr. Hogrefe und Dr. Xiaoming Fu Lehrstuhl für Telematik Georg-August-Universität Göttingen

6 Contents 1 Introduction 5 2 Transport Control Protocol Overview Connection Establishment active/passive active/active Network Address Translation NAT Operation Session maintenance for TCP NAT Example NAT Terminology NAT Types Symmetrical NAT Full Cone NAT Restricted Cone NAT Port Restricted Cone NAT Type Compatibility Direct Connection Establishment Rendezvous Server Relay Server Connection Reversal Implicit NAT configuration P2PNAT NATBLASTER NUTSS Common NAT traversal mechanisms Hole Punching

7 Contents SYN Spoofing Port Prediction Source Routing Explicit NAT configuration NAT/Firewall NSLP NSIS Framework NAT Traversal Node Types Message Types REA CREATE RESPONSE Selected Objects Session Lifetime Object Message Sequence Number Object Data Terminal Object External Address Object Proxy Modes Implementation Evaluation Conclusion Acknowledgements Appendix NAT/Firewall NSLP Message Sequence Charts NAT/Firewall NSLP Client API Bibliography 51 3

8 List of Figures 2.1 Partial TCP State Transition Diagram TCP Connection Setup Nat Types: Symmetrical NAT, Full Cone NAT Nat Types: Restricted Cone NAT, Port Restricted Cone NAT NAT Type Compatibility Matrix Rendezvous Server Connection Reversal Hole Punching SYN Spoofing Prediction Failure Case NSIS Signaling Scenario REA message format (without optional objects) CREATE message format (without optional objects) RESPONSE message format (including External Address Object) NAT/Firewall NSLP Performance Measurements MSC with REA triggered at node 1 in a 4 hop scenario MSC with CREATE triggered at node 4 in a 4 hop scenario NAT/Firewall NSLP ethereal dissector screenshot

9 1 Introduction Network Address Translation (NAT) provides a solution for IP version 4 (IPv4) [18] address depletion and Internet scalability problems at large. The technique was introduced in 1994 by Egevang and Francis [5] and later refined [25] as a temporary arrangement until a final replacement for IPv4 is developed. NAT has since been unexpectedly popular, and it is in wide use today, especially in home and small office environments. NAT devices do address multiplexing for end hosts, thus virtually extending the address space. Unfortunately, Network Address Translation has major drawbacks, most fundamental is the maintenance of states inside the network, challenging the Internet s end-to-end principle [23]. Effectively, this means that on a NAT device, inbound message flows can not be assigned a multiplexed host behind a NAT. Although with IPv6 [4] a mature long-term solution as IPv4 replacement does already exist for many years, it is not foreseeable when the Internet will migrate to the next version. If this happens, NAT may finally become obsolete. One reason why there is only low motivation for a change might be that IPv4 addresses seem not to run out as quickly as forecasted a decade ago. Assuming the address allocation remains at a constant rate (constant rate model), complete depletion is likely to occur not before 2040 [12]. Mechanisms introduced to fight against address depletion, such as classless inter-domain routing (CIDR) [8] and NAT, have dramatically slowed down the consumption of IP addresses and therefore possibly led to a delayed migration towards IPv6. NAT restricts inbound message flows which leads to well-known connection difficulties for peer-to-peer application, such as file-sharing, instant messaging, telephony and games. The lack of standards for NAT behavior caused confusion and incompatibility, the IETF BE- HAVE working group tries to address this issue. Thorough analysis of current NAT devices by the Internet community led to several proposals for implicit NAT traversal [6, 2, 10]. Concurrently, IETF NSIS working group develops a path-coupled out-of-band signaling protocol for explicit NAT configuration called NSIS NAT/Firewall NSLP [28] that offers a standardized solution. Whereas implicit approaches work compatibly with a broad range of already-installed appliances, the explicit approach needs protocol support on all NATs along a path. This thesis analyzes these very promising contributions, extracts applied mechanisms and tries to compare the approaches with each other. The dissemination of common mechanisms and their generalization enables better understanding of the problem set and the possibilities to setup direct connectivity for hosts behind NATs. Furthermore, an applicability statement for implicit and explicit NAT configuration is given and an implementation of NAT/Firewall NSLP proves the feasibility of an yet uncommon explicit signaling approach. 5

10 1 Introduction A special focus is attributed to NAT traversal for TCP as its mechanisms are less understood and more elaborate than for UDP. Therefore, the first chapter starts with selected topics of TCP that are relevant to NAT traversal techniques. The rest of the document is structured as follows. An overview about NAT operation is given in chapter 3. Direct connection requirements are discovered in chapter 4. Chapter 5 provides explanation of recent contributions in the field and extracts common mechanisms. NAT/Firewall NSLP as a representative of explicit NAT configuration protocol is discussed and compared with implicit approaches in chapter 6. Finally, the thesis is concluded in chapter 7. 6

11 2 Transport Control Protocol This chapter gives an introduction to selected topics of the Transfer Control Protocol (TCP) [19, 3]. In contrast to UDP, NATs also maintain states that relate to connection setup and might take sequence numbers in account. These mechanisms only available in TCP are necessary to understand for the discussion of TCP NAT traversal. To fully understand TCP, a more thorough documentation such as [27] might be necessary as this document highlights mostly TCP connection establishment and segment identification aspects. This thesis does not cover NAT traversal for User Datagram Protocol (UDP) [3] as it is of less interest for most applications. Also, many techniques described for more complex TCP are applicable equally for better understood NAT traversal for UDP. 2.1 Overview TCP provides a connection-oriented, reliable, byte stream service. A TCP connection is a communication channel between two end hosts and is identified by a pair of sockets, its 4-tuple (source address, destination address, source port, destination port). TCP is a full-duplex protocol, meaning that each TCP connection supports a pair of byte streams, one flowing in each direction. TCP also implements flow control and congestion control mechanisms, but these are of less interest in this scope. From an application viewpoint, TCP transfers a contiguous stream of bytes. Stream data transfer transparency reflects a layered architecture, commonly known as TCP/IP. TCP groups bytes into segments and passes them to the IP layer for transmission. IP routing transports the segments encapsulated in IP datagrams to the destination. IP itself does not provide a communication channel service, however a connection can also be seen as a message exchange between two peers. Still, this loose affiliation is denoted as connectionless. In contrast, TCP maintains states in the end hosts that relate to a connection. The peers that want to communicate with each other have to agree (handshake) at TCP layer to establish a connection. A normal TCP handshake is three-way, meaning that it consists out of three messages that are exchanged between the peers. Depending on bits set in a six bits bitfield the messages for connection establishment are called SYN, SYN+ACK (SYN and ACK bit set) and ACK message. To provide the data transfer TCP must ensure the correct ordering of the segments before passing them to an application. TCP has introduced sequence numbers to identify a segment. This helps to maintain the order and to assure the affiliation of a segment within a connection. Each connection 7

12 2 Transport Control Protocol CLOSED CONNECT/SYN 1 2a SYN/SYN+ACK LISTEN SYN_RECEIVED CLOSE/- CLOSE/- LISTEN/- RST/- SEND/SYN 2b SYN/SYN+ACK (simultaneous open) SYN_SENT ACK/- ESTABLISHED SYN+ACK/ACK 3 Figure 2.1: Partial TCP State Transition Diagram endpoint randomly chooses a sequence number during three-way handshake. Two sequence numbers A, B with A higher than B indicates that B is older and must have been sent before A. Beside ordering and avoiding duplicates, this mechanism also protects against packet injection attacks. An attacker who knows a sequence number can spoof malicious packets and inject them into the virtual communication channel. To provide reliability, TCP introduces acknowledgement numbers that are used to positively acknowledge the reception of a data packet. The receiver of an acknowledgement knows that the sender of it received his previously sent data packet successfully. Data segments and acknowledgements that are lost between sender and receiver are resend until acknowledgement succeeds. TCP stack maintains an internal circular buffer using sliding window protocol to temporarily store out-of-order segments. Further, TCP has ports. A process binds an address and a port forming a socket. The socket is the virtual extension of a connection. So, many processes residing on a single host can communicate simultaneously using ports as multiplex keys. 2.2 Connection Establishment TCP uses a three-way handshake to establish a connection between two end hosts. TCP connection establishment can be accomplished differently. The most common approach is using active/passive open: one end host acts as client, the other one as server. This partitioning refers to the traditional client/server architecture. The server listens for incoming connections (passive open) while a client opens a connection to a listening server (active open). Another approach is using active/active open named TCP Simultaneous Open : Both end hosts act as clients and servers at the same time referring to upcoming peer-to-peer architecture. This involves a doubled two-way handshake. The latter is of special interest for NAT traversal as NAT 8

13 2 Transport Control Protocol A B A B 1 SYN (seq=x) 1 SYN (seq=x) time SYN+ACK (seq=y, ack=x+1) 2 time SYN (seq=y) 3 ACK (seq=x+1, ack=y+1) SYN+ACK (seq=y, ack=x+1) SYN+ACK (seq=x, ack=y+1) (a) Three-Way Handshake (b) Simultaneous Open Figure 2.2: TCP Connection Setup only allows outbound flows triggered by active connection setups. This method is less known and not widely in use due to missing operating system support in the past. Figure 2.1 depicts a partial TCP state transition diagram limited to connection setup. The diagram shows five states represented as boxes and transitions represented as arrows. Each arrow is fitted with a text for a condition and its action. For example, if LISTEN state is active and SYN message is received, state transition to SYN_RECEIVED occurs and a SYN+ACK message is generated as response. A dash (-) indicates that no action is triggered. Dashed arrows indicate non-default state transitions. Double-lined boxes indicate stable states: In CLOSED state no connection is present, in ESTABLISHED state a connection is established. The numbers 1, 2a/2b, 3 mark the transition order of an active/passive (a) and active/active (b) connection establishment. First, traditional active/passive, then active/active connection establishment is discussed active/passive A normal TCP handshake consists out of three messages: SYN, SYN+ACK, ACK. A SYN message is a TCP message with the SYN bit set in the TCP header and SYN+ACK, ACK respectively. A SYN message indicates a setup request. SYN+ACK indicates a request confirmation. A final ACK indicates confirmation of the confirmation. All three messages are substantial for both parties to confirm that the other peer has fully completed the handshake. The handshake is carried out as follows (see figure 2.2(a)): 1. A client A issues a connect() call targeting at the server s address and port. This triggers the TCP/IP stack to send a SYN packet to the server. The SYN message includes a randomly 9

14 2 Transport Control Protocol generated sequence number (seq=x). State transition from CLOSED to SYN_SENT (1) state occurs. 2. The server B receives the SYN message and state transition at the server from LISTEN to SYN_RECEIVED (2a) state occurs. If the server accepts the connection by issuing an accept() call, the TCP/IP stack replies to the client with a SYN+ACK message. This message contains its own randomly generated sequence number (seq=y) and the clients sequence number incremented by one as acknowledgement number (ack=x+1). 3. The client receives the SYN+ACK message. A correct acknowledgement number indicates that the server successfully received the connection request and wants to establish a connection. A state transition at the client from from SYN_SENT to ESTABLISHED (3) state occurs. Still, the server does not know yet, whether the SYN+ACK message was delivered to the client successfully or not. Therefore the client needs to send a final ACK message to the server with its incremented sequence number (seq=x+1) and with the servers sequence number incremented by one as acknowledgement number (ack=y+1). If the server receives the ACK message with correct sequence and acknowledgement numbers, state transition at the server from SYN_RECEIVED to ESTABLISHED occurs active/active If both end hosts are connecting to each other at the same time, TCP supports an incomplete handshake that lacks a final ACK message. This mechanism is called TCP simultaneous open and is less often used. Although it is part of TCP since its inception, it is less supported by operating system s TCP/IP stack such as Microsoft Windows. Windows XP supports TCP simultaneous open starting from SP2. An implementation that correctly implements TCP state machine should support active/active connection establishment (see SYN_SENT to SYN_RECEIVED transition in state transition diagram in 2.1. Especially peer-to-peer application semantics work nicely with a symmetrical situation. A simultaneous open happens if both end hosts trigger a SYN message by calling connect() at roughly the same time. Then, both end hosts are in SYN_SENT state simultaneously. Although both end hosts are not listening for an incoming connection, they accept the SYN message and respond with a SYN+ACK as if being in LISTEN state. A connection is formed without a final ACK message as both end hosts have been confirmed by SYN+ACK message that the other peer is accepting the connection. An active/active handshake consists out of four messages, each peer sending two. Note that the possibility of simultaneous active open is small as both peers have to use same connection parameters and trigger the connection attempt at the same time. The handshake is carried out as follows (see figure 2.2(b)): 1. Client A issues a connect() call targeting at the peer s address and port. This triggers the TCP/IP stack to send a SYN packet to the client B. At roughly the same time (at least before 10

15 2 Transport Control Protocol the SYN message arrived at client B) client B acts equally. The SYN messages contain sequence numbers randomly generated by client A (seq=x) and client B (seq=y). State transition from CLOSED to SYN_SENT (1) state occurs. 2. Both clients receive the SYN message and state transition from SYN_SENT to SYN_RECEIVED (2b) state occurs. This is an unusual transition as usually SYN_RECEIVED is reached from LISTEN. The clients create a SYN+ACK message in response. The reception of a SYN+ACK message leads to a state transition from SYN_RECEIVED to ESTABLISHED (3). Now, both peers have confirmed the connection setup. 11

16 3 Network Address Translation NAT devices are located on routers and separate two networks. One of these networks is called public, the other one private network. Private networks are assigned private addresses as specified in [20]. Hosts located on the private side are behind a NAT. NATs maintain a set of IP addresses that can be assigned dynamically to hosts behind a NAT on demand. NAT allocates IP addresses for each outbound flows and rewrite IP headers to NAT device as source for outbound and the initiating host as destination for inbound packets. This type of NAT is called basic or traditional NAT. It is rarely used as this form lacks address multiplexing. However, NAT might be extended to also maintain other resources than IP addresses, such as ports (NAPT [16]). NAPT stands for Network Address Port Translation and is the most used form of NAT. A NAPT allocates a pair of IP address for header manipulation. Many ports are allocated using a single IP address for multiplexing purposes to decrease IP address consumption. As NAPT is the most used form this document generally refers to NAPT even if only NAT is stated. In general, NATs maintain a set of resources that are shared among a group of hosts behind a NAT. This leads to the desired decrease in resource consumption. An assignment between two endpoints and a newly allocated NAT resource is a mapping. In case of a NAPT, a mapping consists out of both connection endpoints and a newly allocated address and port at the NAT. Also NAT separates administration boundaries. As NAT for outbound flows works transparently it can ease the partitioning of network administration responsibilities that leads to good deployment possibilities. The fast pace of the deployment nowadays challenges the adoption of new concepts. Interestingly, this property was seen as an advantage in an early RFC: The huge advantage of this approach is that it can be installed incrementally, without changes to either hosts or routers. [...]. As such, this solution can be implemented and experimented with quickly. If nothing else, this solution can serve to provide temporarily relief while other, more complex and far-reaching solutions are worked out. RFC 1631 NAT was meant as a short-term solution against IPv4 address depletion combined with a more distributed administration model. Despite its strong advantages, NATs break many valuable properties [14]: Global addressability Global uniqueness 12

17 3 Network Address Translation Persistence of host-to-address mapping Address structure Deployability of new transport protocols Deployability of new applications Reliability Scalability Private address spaces and VPNs Some of these problems are too fundamental to NAT operation itself to alleviate the situation, such as the separation into private and public address realm. Other problems exists, but are mostly not of relevance, such as reliability as most NATs are deployed within small networks and redundant connectivity would not exist in the first place. One major problem, namely the inability to accept inbound connections, make NAT break peerto-peer applications. This situation can be improved by several mechanisms. Most IP-based protocols, such as HTTP, are based on a traditional client/server architecture. This model assumes a client-initiated connection establishment. The main problem is that the NAT concept of resource sharing is unable to accept inbound connections, but the acceptance of inbound connections is necessary to offer services to yet unknown peers. NAT traversal and NAT configuration proposals focus on how to manipulate NAT devices to accept inbound traffic. Many applications, such as telephony, instant messaging, gaming and file-sharing would benefit from a compatible NAT traversal mechanism. The task of a NAT to maintain a state corresponding to the states in the end hosts of a session and to apply rules on network and transport layer to let messages seamlessly traverse a network boundary smoothly. Although static address translations are in use (i.e., load balancers, protocol translators), most environments using NAT depend on dynamic resource allocation. Resource allocation refers to allocate an external IP address (and port) that maps to an internal IP address (and port). 3.1 NAT Operation If a host behind a NAT creates a message flow targeted at the outside of the private address realm, the flow traverses a NAT device. Such a flow is called outbound as it traverses the NAT from the inner (private) network to the outer (public) network. Inversely, a flow that is targeted at the NAT device from an outer (public) network is called inbound. A NAT device allocates an IP address from a resource pool for outbound flows. The address is stored as mapping between existing flow information and newly allocated address. Then, the 13

18 3 Network Address Translation IP source address of the IP header of each datagram matching this flow is rewritten with the new source address. In case the NAT device is a NAPT, also source ports are allocated depending on the transport layer protocol and the transport layer header is rewritten accordingly. According to this processing, outbound flows traversing a NAT device will be rewritten with the NAT device being one of the new flow endpoints. Returning messages within the same flow will be received by the same NAT device, because the device became one of the flow endpoints after the address rewrite (route pinning). Incoming messages are matched against previously-created mappings installed by outbound flows. If a mapping is found, the outbound rewrite is reversely applied and the message is forwarded to the originating host. If no mapping is found, the message is either silently dropped or a notice is sent back to the sender. Note, that only for outbound flows NAT mappings are created. A NAT device is unable to assign an inbound flow to an internal host if a look-up for a previously created mapping fails. This inability makes it impossible for NATs to handle inbound flows. Due to the mapping maintenance, NATs behave stateful. Additionally, NATs might support state maintenance in respect to TCP connection setup and teardown (see section 2 for details). As this document focuses only on TCP as transport layer protocol, further sections assume that flows are TCP connections and vice versa. 3.2 Session maintenance for TCP Translating packets according to a previously established mapping requires the existence of a state with sufficient mapping information in the NAT device. Using implicit configuration (see chapter 5), a NAT device tries to synchronize states with the end hosts based solely on the traversing session flow. TCP connections start with sending a packet to the correspondent node with SYN bit set and ACK bit unset. This packet can easily be detected as the start of a session by a NAT device located on path between both end hosts. Note that TCP also supports a symmetric connection setup mode: TCP simultaneous open (see section 2.2.2). However, simultaneous open does not only need support by the end hosts, but also by the NAT devices along the path. Using explicit configuration (see chapter 6), a NAT device is configured using out-of-band signaling. Of course, the NAT still adjusts to the data when necessary, i.e. session teardown, but instead of implicitly manipulate NAT states, a more robust configuration protocol is present. This assumes cooperating NATs. However, most currently deployed NATs have little support for explicit configuration. 3.3 NAT Example NAT fits well into a centralized client/server Internet architecture where end hosts are not offering, but primarily accessing services. To access a well-known service only outbound connections are 14

19 3 Network Address Translation needed. For example, a web client wants to access a web server at ( ) via HTTP/1.0 [1] over TCP. The client is located in a private network, the web server is publicly reachable. A NAT is deployed on the path between client and server. For simplicity, DNS is not taken into account. 1. The client constructs a HTTP/1.0 GET request. It binds to a socket and connects to the server at IP address and port 80 (HTTP). As described in 2.2 the connect() call triggers a SYN message. The SYN message does not contain any data, yet. 2. The TCP SYN message arrives at the NAT device. The NAT assumes a connection request and tries to allocate resources from the shared resource pool. It creates a mapping between original address and port and newly allocated address and port that also contains TCP state information (SYN_SENT) matching the client state. The NAT rewrites the TCP/IP headers, changing the source address and source port to new address and new port. The new address and new port are now forming the NAT as new connection endpoint. The rewritten datagram is forwarded to the server. 3. The server is in LISTEN state, accepts the connection, state transition to SYN_RECEIVED occurs and responds with a SYN+ACK message. 4. The NAT receives the SYN+ACK message and looks up for a mapping for this flow. It finds the previously created mapping matching 5-tuple, state information and acknowledgment number. It assumes that the server agreed on the connection setup. The destination parameters for address and port of the message are reversely rewritten with the original flow information stored in the mapping. The state information is set to SYN_RECEIVED now matching the server state and the message is forwarded to the client. 5. The client receives the SYN+ACK message. This confirms that the server accepted the connection request. State transition from SYN_SENT to ESTABLISHED occurs and an ACK message is generated. A first data segment might be piggybacked on this message for optimization. 6. The NAT receives the ACK message and looks up for a mapping for this flow. It finds the previously used mapping matching 5-tuple, active state and acknowledgment number. It assumes that the client received the SYN+ACK message. The NAT rewrites the TCP/IP headers, changing the source address and source port to mapped address and mapped port. The state information is set to ESTABLISHED now matching the client state and the message is forwarded to the server. 7. The server finally receives the ACK message. State transition from SYN_RECEIVED to ES- TABLISHED occurs. Both end hosts and the NAT device now share the same state and have 15

20 3 Network Address Translation exchanged sequence and acknowledgement number with each other. A full-duplex connection is established through a NAT. The NAT being on the path between client and server learnt all connection parameters like a man-in-the-middle. The NAT rewrites further messages accordingly until the connection is teared down. 3.4 NAT Terminology The common type of NAT found in most networks are basic NATs extended by a NAPT. This type is especially popular for SOHO environments having multiple hosts, but an ISP which provides only a single globally routable IP address. A port multiplexing mechanism allows simultaneous access among several hosts within this local network via the same external IP. Address depletion of IPv4 addresses has been a driving force for the deployment of NAPTs since mid of 1990s. Placing several hosts behind a middlebox which allocates only a single IPv4 address decreases the consumption of IP addresses significantly. It has proven over the years to be a stable solution for most consumer Internet connections. However, there are major drawbacks which led to various architectural problems. A NAT maintains a session state that maps to a flow. The information stored in the state and which fields of incoming packet headers are compared with differentiates various NAT types. A handover is the change of the owner (i.e., process, host) of a session. It is possible if a NAT does non-strict matching on header fields. A Handover might involve the change of a port within the same host or the of an change an address among two hosts. Depending on the NAT matching resulting in different handover behavior, NAT is classified as one of the following types: Symmetrical NAT Full Cone NAT Restricted Cone NAT Port Restricted Cone NAT The following sections describe the properties of these types in detail. 3.5 NAT Types Symmetrical NAT Symmetrical NAT holds a complete mapping with incoming packet headers on most TCP header fields. This includes the five-tuple source IP address/port, destination IP address/port and transport protocol. Incoming packets originating from a different end host, but matching destination IP 16

21 3 Network Address Translation A Port X Port N 1 NAT X X X 2 Port Y Port Z Port Y Port Z B C A Port X 1 NAT Port N 2 Port Y Port Z Port Y Port Z B C (a) Symmetrical NAT (b) Full Cone NAT Figure 3.1: NAT Types: Symmetrical NAT, Full Cone NAT address and port, are rejected. Symmetrical NATs are the most restrictive form of NAT and are becoming more rare as it prevents any form of handover. There are opinions that discourage its use because it does not add any noticeable security for TCP connection if a NAT supports session tracking. Figure 3.1(a) shows a two-step example. In the first step, a mapping is created at the NAT by host A. In the second step, only host B from port Y can reply using this mapping. Packets from different ports or different hosts or both are discarded or will generate an error Full Cone NAT Full cone NAT is the least restrictive form of NAT. The matching applies only on destination address and destination port. If a mapping is created, any host can send packets through the NAT. This imposes a security risk as attackers can easily inject packets into the communication. Figure 3.1(b) shows a two-step example. In the first step, a mapping is created at the NAT by host A. In the second step, all other packets that share the destination address and destination port are matched Restricted Cone NAT Restricted NAT is a combination of symmetrical and full cone NAT. The matching is handled using all source and destination addresses and ports. Packets from the same host, but with different port are matched. This less restrictive matching still allows smooth traversal mechanisms. Figure 3.2(a) shows a two-step example. In the first step, a mapping is created at the NAT by host A. In the second step, only host B can send packets through the NAT as the matching does not regard source ports. 17

22 3 Network Address Translation A Port X 1 NAT Port N X X 2 Port Y Port Z Port Y Port Z B C A Port X 1 NAT Port N X X 2 Port Y Port Z Port Y Port Z B C (a) Restricted Cone NAT (b) Port Restricted Cone NAT Figure 3.2: NAT Types: Restricted Cone NAT, Port Restricted Cone NAT Port Restricted Cone NAT Port Restricted Cone NAT does the same as restricted NAT, but on ports. Although this seems to be similar, port restricted NATs impose almost the same difficulties for NAT traversal mechanisms as symmetrical NATs if one side is symmetrical. The strict matching on ports disallows adjacent port allocation, because both sides are unable to change their port mappings. Figure 3.2(b) shows a two-step example. In the first step, a mapping is created at the NAT by host A. In the second step, only host B and host C with the original destination port used as new source port can send packets through the NAT. The matching does not regard source address, but only destination address and ports. 3.6 Type Compatibility Takeda [9] classified NAT compatibility among different NAT types. This analysis is helpful to understand compatibility difficulties among NAT traversal mechanisms. Four compatibility classes are introduced, namely I, II, III and IV for grouping the above-mentioned NAT types. Class I containing the easiest, IV containing the toughest compatibility problems. Figure 3.3 depicts a compatibility matrix with all NAT types listed vertically for sender-side (S) and horizontally for receiver-side (R). Class I: No receiver-side NAT. There is no NAT problem present as the receiver owns a global endpoint and can easily receive inbound connections. A sender-side NAT scenario with no receiver-side NAT can be converted to this class by using connection reversal (see 4.3). Class II: Non-symmetric receiver-side NAT and no port restricted cone NAT on sender-side. This scenario can be traversed smoothly. The receiver can initiate an outbound connection 18

23 3 Network Address Translation Figure 3.3: NAT Type Compatibility Matrix that leads to a connection handover. This is possible as the NAT combinations in class II (full cone, restricted cone, port restricted cone) do not enforce strict matching. Class III: Receiver-side symmetrical NAT and no symmetrical or port restricted cone NAT at sender-side. This scenario is slightly more difficult. Both hosts behind NAT initiate a connection simultaneously to the peer s endpoint. This technique is called simultaneous hole punching or also known as symmetric RTP and is later discussed in Class IV: Combination of symmetrical and port restricted cone NAT or both sides symmetrical NAT. This is the most difficult scenario for NAT traversal. As connection handover is not possible due to symmetrical NAT, allocated ports must be known in advance. This mechanism refers to port allocation prediction and is generally unsafe. Port prediction is discussed in

24 4 Direct Connection Establishment If a handover is possible, a direct connection might be possible to be established between two hosts behind different NATs. The main question for NAT traversal approaches is how to establish a direct TCP connection. NAT traversal mechanisms for UDP can be found in many peer-to-peer applications already in use today. Due to its stateful properties NAT traversal for TCP is more complex. In contrast, an explicit NAT configuration approach does not have to deal with handovers at all, because the NAT is completely aware of upcoming data flow and its exact parameters. Still, there are other difficulties that need to be addressed. Although implicit and explicit paradigms are very different, both share common mechanisms that could be observed to be of general applicability. Rendezvous Server Relay Server Connection Reversal It seems that those techniques can be considered as basic building blocks that ultimately lead to direct connection establishment. The mechanisms are discussed in the following sections. 4.1 Rendezvous Server End hosts that are located behind NATs have no global endpoint. Such a global endpoint is necessary in the Internet for sending a message to a receiver. If the receiver has no global endpoint, because it is located behind a NAT, it is unable to receive messages. NATs only allow outbound connections as the installation of temporary global endpoints are only triggered by outgoing flows. This problem was already mentioned as a major NAT problem. If both end hosts are located behind a NAT, it is not possible to establish a direct connection between two end hosts behind a NAT without third-party support. Such a third party is often called Rendezvous Server, because both end hosts can use the service to meet each other. The rendezvous server must be located somewhere in the global name space, preferably close to the end hosts or on the path between both of them. Then, both end hosts can target messages at this global endpoint. NATs on the path between end host and rendezvous server will see the flow as outbound message flow and forward it. Both 20

25 4 Direct Connection Establishment NAT A 1a Rendezvous Server 1b NAT B Client A 2 Client B Figure 4.1: Rendezvous Server flows can then meet at the rendezvous server to let the initiating hosts exchange information aiming towards a handover or a direct connection attempt or just to set up a relay (see 4.2). For example, suppose two end hosts, client A and client B, have each established a connection (1a, 1b) with a publicly reachable rendezvous server as depicted in figure 4.1. Both end hosts are located behind different NATs and are assigned a private IP address. The NAT devices prevent direct connection attempts between the end hosts, because there is no temporary mapping installed, neither at NAT A for the flow A NAT B, nor at NAT B for the flow B NAT A. Instead of attempting a direct connection, the two end hosts can simply use the rendezvous server to relay control messages between them. Client A can send a message to the rendezvous server over its already-established client/server connection and the server can relay this message over its already-existing client/server connection to client B. The same processing applies for the opposite direction as well. A virtual connection (2) between client A and client B via the rendezvous server exists. 4.2 Relay Server This is a mechanism that is not truly supporting direct connection establishment, but emulating it. A Relay Server can be considered as a proxy to relay data traffic between two hosts behind a NAT. As NATs only allow outbound connections, the proxy supports the end host to communicate with each other. Obviously, the relay server is not an optimal solution, but it is the most compatible approach as it employs the traditional client/server model. The message processing on transport layer is higher than IP layer routing. The relay server is likely to be a bottleneck. Depending on the location of the relay server the message flow not taking the shortest path between sender and receiver. This causes message delay. 21

26 4 Direct Connection Establishment NAT A X :32000 Client A X :1234 1a 3 Rendezvous Server 2a :90 2b 1b Client B :5678 Figure 4.2: Connection Reversal TURN [21] is a protocol for relay server communication. According to the draft it is recommended to locate a TURN server inside the end host s ISP network or within its DMZ. 4.3 Connection Reversal If only one side is located behind a NAT, a mechanism called Connection Reversal can be used to mitigate the receiver-side NAT problem and convert it into an unproblematic sender-side NAT scenario. For example, consider a similar scenario as described previously in section 4.1, but with only one end host located behind a NAT (single-side NAT). Client A is behind a NAT and has no global endpoint, client B has a globally routable IP address as depicted in 4.2. Client A has private IP address and has established a TCP connection with the rendezvous server at IP address using local port 1234 and remote port 90 (1a). NAT A has created a temporary mapping assigned with TCP port for the flow initiated by client A at its own public IP address The rendezvous server might know that client A is located behind a NAT if the client A has transmitted its local address to the rendezvous server and it does not match with the global endpoint of the used TCP connection. Client B has public IP address and is running an application that wants to establish a direct connection to client A, this application uses local port Previously, client B had established a connection with the rendezvous server and received addressing information of client A. Then, client B can try to establish a connection with the local IP address of client A (2a). This attempt will fail, because the local IP address of client A belongs to the set of private IP addresses as specified in [20] and therefore is not globally routable. Client B can also try to establish a connection with NAT A s global endpoint that was temporarily created for the message flow between client A and the rendezvous server (2b). Depending how restrictive NAT A is, this attempt will also fail, the NAT device will either response to client B s SYN packet with a RST ICMP destination unreachable packet to close the connection attempt or silently drop it. 22

27 4 Direct Connection Establishment Assuming a most-restrictive symmetrical NAT, the message flow originated from client B does not match the message flow originated from the rendezvous server. Still, this problem can be solved if the connection establishment direction is just reversed. Client A can simply setup a connection with client B if the TCP handshake is initiated by client A. Client B has a globally routable address and NAT A allows outbound connections. The rendezvous server can assist the end hosts whether connection reversal can be used and which peer should initiate the connection. 23

28 5 Implicit NAT configuration It is assumed that both end hosts are each located behind a NAT. Furthermore, a connection to a rendezvous server is present or easily possible to establish. In this section, three recent NAT traversal proposals are discussed and common techniques are extracted and generalized. 5.1 P2PNAT The approach from Ford and Srisuresh [6] analyzed UDP hole punching and found the technique also applicable for TCP. Hole punching is the controlled sending of messages through a NAT that manipulate a NAT mapping to enable a connection handover. Multiple consecutive messages can increase the size of the hole. This mechanism is not exploiting NAT security, it rather works within a NATs security policy. A brief overview about UDP and the extension to TCP hole punching follows. Assuming a class II NAT scenario, UDP hole punching works as follows. The global and local endpoints of the two peers are learned using a rendezvous server. Using the same client address and port as with the rendezvous server each host directs a UDP datagram at the peer s global endpoint. As long as both datagrams leave the private address realm before reaching the other side, one datagram will be dropped and the other one will match an existing mapping that was previously created by the dropped datagram when traversing its NAT. If one might think of a virtual UDP connection formed by the two 4-tuples for both messages, the connections are now overloaded. The NATs maintain mappings for the end host that form a cone. A similar approach is taken for TCP. Also, a class II NAT scenario is assumed to be present. UDP can overload a socket with multiple connections as UDP is connectionless and does not care about different targets that are used when sending messages over a single socket. Doing the same with connection-oriented TCP was found to be possible, but it is rather an operating system socket API than a NAT issue. It was discovered that most operating systems support multiple address and port binding using SO_REUSEADDR option, thus leading to the same connection overloading as with UDP. A second difficulty involves simultaneous connection setup. As UDP does not have connection states, a NAT does not maintain connection setup and teardown states for UDP. The first two TCP messages that both peers send to each other are TCP SYN messages. Consequently, NATs have to accept a peer s SYN message while being in SYN_SENT state. This is the state transition for simultaneous open in TCP state diagram (see figure 2.1). A NAT not supporting simultaneous connection setup does not support TCP hole punching. The authors derive their findings to draft recommendations for NAT vendors and application 24

29 5 Implicit NAT configuration developers in BEHAVE working group. Their proposal based on TCP simultaneous open looks clean and robust, but has compatibility limitations. The focus is rather on providing a feasible stable solution than a hack. NAT vendors recently seem to adjust to NAT behavioral recommendations to improve support for peer-to-peer applications. A non-empirical evaluation performed by the authors has shown that currently only 64% of tested NAT devices would support TCP hole punching. In brief, the compatibility limitations include that a class II scenario is present (see 3.6), NAT have to support simultaneous TCP connection setup and the operating system socket API needs to support SO_REUSEADDR option. 5.2 NATBLASTER Biggadike, Ferullo, Wilson and Perrig [2] proposed a more complex solution to provide better compatibility for TCP NAT traversal. It is claimed that their NATBLASTER approach is not limited to well-behaving NATs, but can also support most-restricting symmetrical NATs. The authors found that NATs that allocate port in an unpredicted fashion pose the biggest problem to enable direct connectivity. That means, a client behind a NAT has no means to know the next port that its NAT will allocate for a new mapping. However, a NAT s next port allocation can be guessed upon a previously observed allocation strategy. If at least one side offers predictable port allocation, a series of initial outbound SYN message can be sent from the less restrictive side A to the more restrictive side B. The connection attempts create many incomplete mappings at NAT A. After the mappings are installed, NAT B then responds randomly to host A s global endpoint hoping to match a valid mapping. Furthermore, sequence and acknowledgement numbers are exchanged via a proxy to let the endhosts behind the NATs follow the assignments. This information is necessary to establish a TCP connection with the corresponding peer. NATs that do not have a mapping for a particular flow will usually drop connection attempts (TCP messages with SYN flag set). If the sequence of this message would be known by the peer behind the NAT that dropped the message, the connection attempt could be completed if the host acts if the message was not dropped at the NAT and it has received the TCP message instead. This assumes that the NAT silently drops the message and does respond with any error indicating that the connection attempt failed. This seems to be the case as most NAT devices are equipped with basic security mechanisms to prevent port scanning. A meaningful response on a TCP SYN message gives an attacker the information whether a service is running on this port or not. Another option the authors propose is the use of IP loose source routing to place the rendezvous server on the path between both end hosts. A rendezvous server on the path simplifies handover as the same mapping between both endhosts can be used to communicate indirectly with the rendezvous server. In conclusion, this approach gives better compatibility features due to port allocation prediction at higher cost. End hosts have to run with administrator privileges to use raw sockets. Unfortunately, 25

30 5 Implicit NAT configuration IP loose source routing is not widely deployed due to security reasons. 5.3 NUTSS The approach of Guha, Takeda and Francis [10] also uses a similar mechanisms based also on port allocation prediction and TCP connection spoofing. Doing port prediction makes this approach compatible with most restrictive symmetrical NAT devices. The main focus of this work lies in the coordination of TCP messages with assistance of STUNT (Simple Traversal of UDP Through NATs and TCP too) servers that make the communication to look like two three-way handshakes for both end hosts equally. As rendezvous server a simple proxy is chosen. This approach can be further extended to use Session Initiation Protocol (SIP) [22] as generic connection establishment protocol. Unlike the other approaches, the authors propose a differentiation between rendezvous server and endpoint learning server. STUNT is a extended version of STUN protocol to provide end hosts with information about their global endpoint. The proxy acts as a relay for control messages between both end hosts. Unlike the proxy server, the STUNT server has no relay function and there can be separate independent STUNT servers for each end host. The STUNT servers are used to learn the end host s global endpoints that were allocated at the NAT devices during initial connection setups. These endpoints are exchanged via proxy to let both end hosts complete their information about own and the foreign public endpoints. Having this information, both end hosts predict the port that will be allocated at each others NAT device. Port allocation prediction mechanism is described in As mentioned above, port allocation is unsafe and may fail in certain scenarios. Furthermore, the STUNT servers are used to spoof TCP packets in order to let the NATs between end host and STUNT server believe in a complete connection establishment. On the whole, this approach introduces STUNT server as a new entity. These servers provide endpoint information to hosts behind NATs and send spoofed SYN+ACK messages to NAT from outside. 5.4 Common NAT traversal mechanisms All three NAT traversal proposals share a common set of mechanism. The dissemination and classification of these mechanisms can present the minor and major difficulties connected to the direct connection problem. This section will demonstrate that port allocation prediction is the hardest and most unsafe mechanism. Yet, it is the only mechanism that enables class IV interoperability. Instead of [2, 10], the authors of [6] do not address this class in the first place, thus resulting in a more simple and clean approach. Following table shows all mechanisms that could be extracted from the proposals. Every mechanism indicates whether it was used in the respective proposal or not. 26

31 5 Implicit NAT configuration A Port X 1-4 Port N1 2 4 Port Y B NAT A 1 3 Port Z C Figure 5.1: Hole Punching P2PNAT NUTSS NATBLASTER Hole Punching yes yes yes SYN Spoofing no yes yes Port Prediction no yes yes Source Routing no no yes Hole Punching Hole punching is the basic technique to remotely manipulate NAT states and mappings. A NAT reacts on all messages that are sent through it. If the triggers and their reactions are known, they can be used for arbitrary manipulation. Consider the example from the beginning. A UDP datagram is sent through a NAT from private to public network. The NAT assumes that there could be either (1) a UDP response returning from the the peer s buddy that needs to traverse the NAT reversely or (2) a ICMP error message that was triggered by a failure due to the UDP datagram, i.e., type=3 (Destination Unreachable), code=3 (Port Unreachable). To forward these messages to the original peer, a NAT must maintain a mapping as long as it assumes returning messages. If there are several mappings for the same source, but different destination, it is called a hole. Sending out a UDP datagram for the reason to create such a hole is therefore named Hole Punching. Depending on the NAT type (see 3.5 for mapping matching behavior), incoming IP datagrams are either dropped or forwarded to the original peer. TCP hole punching is slightly more complex than UDP hole punching. TCP starts a connection with sending a SYN message and waiting for a SYN+ACK message. While the SYN message traverses a NAT, the NAT must create a mapping to forward a returning SYN+ACK to the original peer. Therefore, a TCP SYN message punches a hole the same way as a UDP datagram does. However, the SYN+ACK message must be received from public network and it must contain correct acknowledgement and sequence numbers. It was shown in [6] that TCP hole punching works nicely. Figure 5.1 depicts a hole punching example. Host A generates four messages with the same source address and port directed at two hosts at two distinct ports. All four messages traverse the same NAT resulting in four mappings with the same original source information. Any incoming message at NAT A that match any of the previously installed mappings will be forwarded to host A. 27

32 5 Implicit NAT configuration encapsulated SYN+ACK C 4 SYN+ACK (spoofed) A Port X 1 Port N1 NAT A 5 SYN (low TTL) X Port X B 3b 2a 2b 3a encapsulated SYN encapsulated SYN+ACK proxy Figure 5.2: SYN Spoofing SYN Spoofing The idea of SYN spoofing is to emulate TCP simultaneous open (see 2.2.2) as it is not widely spread among Microsoft operating systems. As previously described in 5.4.1, a NAT needs to receive a SYN or SYN+ACK message upon a TCP connection attempt to successfully enable the mapping. This SYN+ACK message must be received from outside and it must contain correct acknowledgement and sequence numbers. Acknowledgement and sequence numbers are randomly chosen upon connection setup by the two end hosts to protect against connection takeover by an attacker. Consider a scenario with both end hosts A, B behind a NAT. Host A initiates a TCP connection with host B, this generates a TCP SYN message. This message traverses NAT A from private to public network and will be received by NAT B from public network. As there was no matching mapping created at NAT B previously, it will either (1) drop the message silently, (2) respond with a TCP RST message or (3) respond with an ICMP destination unreachable message. In order not to mislead NAT B, NAT B must drop the message silently, otherwise NAT A would assume a connection failure and delete the previously created mapping. Most NATs are pre-configured to drop non-matching SYN messages to prevent port scanning for security reasons. If not, SYN messages can be equipped with a low IP TTL (time to live) value using raw sockets. The TTL counter is decremented by one at each IP hop. A TTL exceeded ICMP error message is also dropped by most NATs. We conclude that either NAT A or NAT B must drop the original or its ICMP error message. If the original SYN message is dropped, host B will not receive it, a connection can not be established, because host A would not receive a SYN+ACK message. If host B or a third party would generate a SYN+ACK message with correct sequence numbers, host A would assume a successful connection attempt. Spoofing such a message refers to the SYN Spoofing mechanism. 28

33 5 Implicit NAT configuration But there is a difficulty: (1) host B would not know when to send a SYN+ACK message and it also does not know the sequence number of the SYN message chosen by host A. The other way around, (2) a third party could know the sequence number when it is on the path of the SYN message, but it does not know which acknowledgement number host B would choose. The third party can not generate an acknowledgement number, because it is necessary that the third party fakes a TCP connection between host A and host B and does not establishes a regular connection between host A and itself. Figure 5.2 shows a scenario how a third party could be introduced to send a fake SYN+ACK message with correct acknowledgement and sequence numbers from the public network to NAT A. The figure shows only one NAT for simplification. Unless having two receiver-side NATs, the scenario is not practically useful as NAT A simply allows outbound connections. The mechanism shown here focuses on how to make a NAT assume that a TCP three-way handshake happened. (1) First, host A sends a TCP SYN message via raw socket to host B with low TTL. The message traverses NAT A and punches a hole into it. On the path between NAT A and NAT B the message must be dropped. (2) Over a pre-setup proxy/rendezvous server connection, host A sends its chosen sequence number to host B. (3) Host B replies with its chosen acknowledgement number. Both hosts now have complete knowledge about the connection. (4) This information is transferred to a third party in public address realm. (5) Finally, the third party is triggered to send a spoofed SYN+ACK message to NAT A with the connection parameters, including correct sequence and acknowledgement numbers. The NAT assumes a successful connection establishment. Note that the same mechanisms can also be used without any state setup inside the end hosts, but only in NATs. Here, also SYN messages are spoofed using raw socket interface. The major drawback of SYN spoofing is its use of raw sockets which require superuser rights on most operating systems Port Prediction Port allocation prediction is necessary when a symmetrical NAT as the most restrictive form is assumed to be installed. A mechanism that works with symmetrical NAT of course also works for all less strict NAT types, resulting in a most compatible traversal mechanism. As described above, symmetrical NATs only accept flows for which there are exact mappings in place. That means that source address/port, destination address/port and transport protocol have to fully match. Using symmetrical NATs connection handovers are impossible, because mappings are tightly bound to a specific IP address/port pair. A handover would change this setting and therefore drop any message that originates from a host that was handed the connection over. Unfortunately, NATs in use have different ways to assign ports to new connections. It can be observed that most NAT devices are either behaving predictively enough to guess the next port assignment or that they are behaving completely randomly. Predictively enough means that a NAT either allocates new ports with consistent allocation (internal port maps to the same external port if a collision is avoidable) or with incremental allocation (increasing port numbers for each new 29

34 5 Implicit NAT configuration msc ap1 ap2 NAT STUN Host Host t0:mapping Request t1:mapped Address t2:packet sent t3:packet sent Figure 5.3: Prediction Failure Case connection attempt). Note that port allocation prediction is an unsafe mechanism that may fail. Message sequence chart 5.3 shows a problem that occurs due to concurrent mapping requests. There might be also other reasons: 1. Concurrent mapping request between t0 and t2. 2. Overflow in port allocation with incremental allocation. 3. Random port/queued resource allocation An overflow occurs if the incremental port allocation reaches the upper bound. Incrementing a port number that reached already the upper bound, resets the port to the beginning. Queued resource allocation assumes a queue that stores available mappings. Once a mapping is deleted, it is available in the queue again. Since the lifetime duration of the mapping is variable, the port numbers get out of order as time progresses. Port prediction failure can be compensated by following approaches: Minimize the delay between t0 and t1. Implement a retry process. Multiple port prediction. Minimizing the delay between t0 and t1 minimizes the chance that another message can reserve the predicted resource. 30

35 5 Implicit NAT configuration Source Routing Source routing is an IP option that lets the sender specify the path IP datagrams shall take. It is differentiated between loose source routing and strict source routing. Both types are specified using an IP option type in the IP header. Whereas strict source routing is meant for defining the complete path, loose source routing allows only to define a subset of the path, single routers can be specified that the IP datagrams have to pass. Source routing can be used by NAT traversal methods to let datagrams traverse the rendezvous server between sender and receiver. Currently, most networks drop IP datagrams with source routing options set due to security reasons. Source routing is more vulnerable to attacks, because an attacker can spoof IP addresses and put himself on the return route. Less critical is the situation where end systems have a network stack that do accept source routed datagrams, but reply without source routing options set. 31

36 6 Explicit NAT configuration As more middleboxes are installed in the core, serious changes are imposed on the end-to-end model [23] of the Internet. These infrastructural changes greatly challenge the robustness of existing and future protocols. Although NAT traversal mechanisms exist and are applicable to a broad range of applications, it might be necessary to standardize a middlebox configuration for explicit protocol configuration. In the IETF NAT, BEHAVE, MIDCOM and NSIS working groups people analyzed the implications of NAT and other middleboxes to the network and discussed whether protocols for explicit middlebox configuration are desirable and how they should be designed. The scope of this chapter is the explicit configuration of NAT middleboxes. Explicit configuration refers to signaling communication between one configuration sender and many configuration receivers. In a simple case, there is only one configuration receiver (i.e., PFCP [15]) enabling a one-to-one communication between sender and receiver. More advanced scenarios, such as cascaded NATs and path-coupled NAT signaling take many configuration receivers into account needing a one-to-many communication protocol. The slow acceptance for IP multicast is compensated by overlay networks offering the same functionality at lower efficiency and throughput. Overlay networks use end-to-end transport protocols to build a distribution channel on top of the transport layer. Analogously, path-coupled signaling use overlay network techniques to enable one-to-many communication along the data path. This can be useful for dynamic, explicit NAT configuration. 6.1 NAT/Firewall NSLP NAT/Firewall NSLP is a middlebox configuration protocol to configure NATs and firewall devices along a path. It is based upon NSIS framework and is currently under active development in IETF NSIS working group. This chapter gives an overview about NAT/Firewall NSLP key design elements and discusses use cases. This document only discusses NAT operation within NAT/Firewall NSLP. Although firewall configuration is covered by the protocol, it is not considered in this document. 6.2 NSIS Framework The NSIS framework [11] has been developed by IETF NSIS working group with the goal of creating a common signaling transport layer, including a set of signaling protocols which need to install 32

37 6 Explicit NAT configuration A App B 11 C D E 1 2 NSLP 10 9 NSLP 7 4/8 6 NSLP NTLP NTLP NTLP NTLP 3 5 IPC signaling traffic data traffic Figure 6.1: NSIS Signaling Scenario and manipulate states along a path. It was observed that middlebox configuration protocols share a common set of features which could be isolated using a distinct layer. NSIS-based protocols are not following the traditional client/server approach, but forming an overlay network between a group of nodes along a path. This means that not every node on the path necessarily needs to be an NSIS node. A peer discovery process determines the next NSIS-aware hop and includes only supporting nodes into the path. The path is established into one direction only. On top of the signaling transport layer, the signaling layer resides. The two layers are defined as follows: NSIS Transport Layer Protocol (NTLP): GIST [24] NSIS Signaling Layer Protocol (NSLP): QoS NSLP [13], NAT/Firewall NSLP [28], etc. The layer separation keeps the NSLP layer lightweight and less complex than if each signaling protocol would include an own NTLP alternative. The transport layer also hides complexity. This facilitates a better view of core signaling protocol functionality during protocol development and implementation. Such an abstraction allows the use of multiple underlying transport protocols or security properties. An NTLP instance like GIST is able to provide transport layer transparency. Its design supports UDP, TCP, SCTP and security protocols such as IPSec and TLS transparently. During association establishment, two NSIS peers might negotiate these parameters independently. Currently GIST is the only NTLP proposal under active development. First interoperable implementations were released summer 2005 at IETF63 conference in Paris, France. Figure 6.1 shows a NSIS signaling scenario. Consider two hosts A, E and three routers B, C, D. Application at host A wants to send data traffic to host E. Prior to sending data, it might want to configure the middleboxes along the path to adjust them to the upcoming data traffic. Nodes A, B, 33

38 6 Explicit NAT configuration C, E support GIST as NTLP, but only the subset A, C, E supports a particular NSLP. Node D is a regular router without NSIS support. 1. An application triggers an NSLP to establish a signaling session for a specified data stream from host A to host E. 2. The NSLP creates a message and handles it to NTLP layer for path-coupled transmission. It also defines data stream parameters provided by the application. 3. As next NSLP aware peer, host C is discovered. Based on the capabilities of the nodes along a path, only nodes that support that particular NSLP are included in the signaling session. Host B is not included, because it does not support that particular NSLP. The NTLP delivers the message to the host s NSLP. 4. The NSLP located on host C processes and forwards the message. The NSLP might install, modify or release states that matches the signalled data stream. 5. The NTLP peer discovery process chooses host E as the next hop and includes it in the signaling session. The NTLP delivers the message to the host s NSLP. 6. The NSLP on host E processes the message and decides to reply back with a new message directed session-upstream. The NSLP might install, modify or release states that matches the signalled data stream. 7. The existing peer association between host D and host E is reused and the NTLP delivers the reply to the NSLP at host C. 8. see see The initiating NSLP on host A processes the message and delivers the signaling session state and additional session information to the application. 11. Based on the signaling session state, the application decides to transmit the data stream directed at host E. The signaling session may have installed states along the data path that let the middleboxes adjust to the data traffic. 6.3 NAT Traversal Based on the NSIS framework described above, NAT/Firewall NSLP assumes that all NATs along the path are NAT/Firewall NSLP aware. Thus, a signaling session that includes all relevant nodes 34

39 6 Explicit NAT configuration can configure them accordingly. In terms of NAT that means that a signaling session can install and release NAT mappings or mapping reservations at participating hosts. Consider above signaling scenario again with host C as a NAT, the specified generic NSLP as NAT/Firewall NSLP, and host D and host E located in the NATs private address realm. As NATs only allow outbound connections, a direct connection from host A to host E fails. Assuming connection reversal is not applicable (or host A is also located behind a NAT), host A can use NSIS signaling to install a mapping at host C to allow an inbound connection from host E. Consequently, NSIS signaling have to traverse a NAT prior to the data stream. As the same NAT issues apply for NSIS equally, NAT/Firewall NSLP uses two signaling sessions: One session from receiver towards the NAT and one from the sender end-to-end to the receiver. If several NATs are placed between sender and receiver, the receiver has to establish a signaling session to his outermost NAT (edge-nat) to reserve a global end point. As the mapping should be created by the sender-side signaling session matching the data stream, the NAT mapping created by receiver-side signaling is not a full mapping, but only a reservation. A reservation already allocates resources to prevent allocation collision. Thus, the reservation state waits to be activated by the end-to-end sender-side signaling session. For migration purposes NAT/Firewall NSLP also offers support for limited path support. These so-called proxy modes can cope with scenarios that are not fully NAT/Firewall NSLP aware, but limited to partially complete paths. At least a path from receiver to edge-nat must be NAT/Firewall NSLP aware. 6.4 Node Types Nodes are differentiated between their function, namely NSLP initiators (NI), NSLP responder (NR) and NSLP forwarder (NF). A downstream signaling path starts at an NI, traverses zero or more NF and ends at an NR. Signaling paths can also be established upstream from NR to NI. This direction is necessary in NAT/Firewall NSLP to install receiver-side states at NATs. 6.5 Message Types NAT/Firewall NSLP supports five message types. There are two general types CREATE and REA, an answer type RESPONSE, a type for asynchronously triggered events NOTIFY and a TRACE type for monitoring purposes. RESPONSE messages are sent as a reaction of receiving CREATE, REA or TRACE messages within the same session. NOTIFY messages never get answers. Also, there can not be a RESPONSE for a RESPONSE. Whereas CREATE messages travel end-to-end, REA messages are only meant for communication between NR and edge-nf. The edge-nf is the last NF before leaving a hosts administrative domain. 35

40 6 Explicit NAT configuration Message Type = REA P A B Object Type = SL Object Length = 1 Session Lifetime A B Object Type = MSN Object Length = 1 Message Sequence Number A B Object Type = EFI Object Length = 1 Rule Action = {allow, deny} Subsequent Ports Figure 6.2: REA message format (without optional objects) CREATE REA NOTIFY TRACE end-to-end yes no no yes stateful yes yes no no initiator NI NR NF,NR NI trigger RESPONSE yes yes no yes It has to be noted that the NI or NR of a signaling session does not necessarily have to match with the data sender or data receiver. This is the case when the data path is not fully NSIS or NAT/Firewall NSLP-aware. NAT/Firewall NSLP introduces a proxy mode to handle these scenarios. See 6.7 for details. CREATE (CREATE-RESPONSE) and REA (REA-RESPONSE) messages are of main interest, because they are responsible for all middlebox state configuration. REA messages (see 6.5.1) are used to install, maintain and release NAT and firewall states that correspond to resources allocated for upcoming CREATE signaling on the receiver-side network. CREATE messages (see 6.5.2) are used to install, maintain and release NAT and firewall states for a specified flow REA A major purpose of NAT/Firewall NSLP is the allocation of receiver-side NAT resources, especially the edge router information needs to be exchanged with a peer that wants to establish a communication with the host behind the middleboxes. NAT/Firewall NSLP introduces a message type named 36

41 6 Explicit NAT configuration REA (RESERVE-EXTERNAL-ADDRESS) to perform this task. REA messages 6.2 are sent flowupstream from the data receiver (NR) to the data sender, states are installed on the forward-path. In case of an error noticed on the return-path, the states are teared down. This mechanism assures: Resources allocated on the forward-path assures that the edge-nf is the last hop that allocates resources. The edge-nf decision should be considered as final decision for all participating NF. If the resources would be allocated on the return-path, conflicts due to concurrent REA could arise and would need to be resolved. Thus, states in NF along the signaling path are installed path if and only if all middleboxes on the path successfully participated. By default, REA messages contain three objects, session lifetime, extended flow information and a message sequence number. REA messages also have a P flag in the common header to denote so-called proxy mode CREATE CREATE messages 6.3 can install, maintain and release middlebox states that relate to NAT and firewall policies along a path under control of the NI. NSIS architecture allows to send CREATE messages in an end-to-end manner traversing the same set of middleboxes as upcoming data flow. NTLP routing tries to maintain path-coupled signaling by sending a signaling flow with preferably same properties in the same direction. This technique is also known as path-directed signaling. All NAT and firewall devices on the path need to support NSIS and NAT/Firewall NSLP in order to communicate properly. Every participating node decides either to forward or to deny a request. So, there can be as many decision points as middleboxes exist between NI and NR. Forwarded CREATE requests are sent until the NR is reached, an RESPONSE is generated as answer and sent back upstream. Resource allocation is split. First, when sending downstream CRE- ATE messages, only a reservation is made. Secondly, this reservation is turned into a mapping after a successful RESPONSE is received. This prevents inconsistent states along a path. An error that occurred on the forward-path will stop the CREATE forwarding and generate a direct RESPONSE that will trigger to upstream nodes to release reservations. Without the reservation mechanism on the forward-path, but a single allocation on the return-path resource allocation could lead into an erroneous path with some nodes having resources allocated, others have not. Figure 8.2 shows a sample CREATE session setup using message sequence chart notation. Important to note is the allocation symmetry between mapping reservation and mapping creation. 37

42 6 Explicit NAT configuration Message Type = CREATE P A B Object Type = SL Object Length = 1 Session Lifetime A B Object Type = MSN Object Length = 1 Message Sequence Number A B Object Type = EFI Object Length = 1 Rule Action = {allow, deny} Subsequent Ports Figure 6.3: CREATE message format (without optional objects) Message Type = RESPONSE A B Object Type = SL Object Length = 1 Session Lifetime A B Object Type = MSN Object Length = 1 Message Sequence Number A B Object Type = IC Object Length = 1 Class Response Code Object Type = {CREATE, REA, TRACE} A B Object Type = EA Object Length = 2 Port Number IPv4 Address Figure 6.4: RESPONSE message format (including External Address Object) 38

43 6 Explicit NAT configuration RESPONSE RESPONSE messages 6.4 are sent in response to REA, CREATE and NOTIFY messages. They contain an Information Code Object stating the result of a signaling action. The NAT/Firewall NSLP draft specifies a whole range of error and success codes. Furthermore, if triggered by a REA, the message might contain an External Address Object. This object includes information of a global endpoint mapping reserved at the edge-nf. In contrast to port prediction as discussed in 5.4.3, exact endpoint information (address, port) is derived. Figure 6.4 shows a common RESPONSE message format including External Address Object. 6.6 Selected Objects NAT/Firewall NSLP messages contain multiple objects, the allowed combinations are specified according to the message type. An object may either be required by a message type, optional or depend on another objects presence. Each object is a word padded chunk fitted with a common object header. The header specifies type and length and extensibility flags. The specified objects are the following as of current draft version: Session Lifetime Object (SL) External Address Object (EA) Extended Flow Information Object (EFI) Information Code Object (IC) Nonce Object Message Sequence Number Object (MSN) Data Terminal Information Object Trace Object NI Credential Object ICMP Types Object A selection of these objects is discussed in the following paragraphs. 39

44 6 Explicit NAT configuration Session Lifetime Object NAT/Firewall NSLP is a soft-state protocol. All states will be released after a certain period of time. This time is specified during state creation. The lifetime object sets the lifetime of such a state at a processing node. The lifetime range might be restricted under policy, but leaves some room for optimizations that can be controlled by the node that initiates the signaling session Message Sequence Number Object Message sequence numbers enforce validity of subsequent messages. This prevents also the processing of doubled messages and packet injection attacks Data Terminal Object The data terminal object specifies the data sender during a REA message exchange. It contains IP address, port, protocol and SPI fields to identify a flow at a NAT device from outside. This object models the mapping behavior of different NAT types. A symmetrical NAT could be emulated with all IP and TCP fields set, whereas a full cone NAT could be emulated not including the Data Terminal Object in the message External Address Object Responses to REA messages include a External Address Object if an address allocation succeeded. The payload might contain a allocated address and port that reflects a hosts global endpoint. With a controlled resource allocation using REA message type, port prediction as it is common for implicit approaches is not necessary. 6.7 Proxy Modes NAT/Firewall NSLP supports two proxy (REA-PROXY and CREATE-PROXY) modes to cope with limited protocol support on the path. In REA-PROXY mode, the NR asks the last NF of its administrative domain (edge-nf) to take over the role of an NI that initiates a signaling path reversely back to the NR. This is useful for scenarios where the NI does not support NAT/Firewall NSLP. Still, there need to be full protocol support along all middleboxes from NR to edge-nf. In CREATE-PROXY mode, the NI asks the last NF on the path towards NR to take over the role of the NR. This is useful for scenarios where the NR (or penultimate NF) does not support NAT/Firewall NSLP. In both cases, proxy mode is expressed through enabling a proxy flag in the REA or CRE- ATE message. There is a major problem with REA-PROXY mode as the control of the signaling path is bound to an NI, but in this case, the NI was triggered by a received REA-PROXY message 40

45 6 Explicit NAT configuration 600 NAT/FW NSLP-processing NAT/FW NSLP+iptables-processing 600 Session Setup Time - no iptables-calls Session Setup Time - with iptables-calls Time in msec 300 Time in msec Sessions Sessions (a) Average Processing Time (b) Average Session Setup Time Figure 6.5: NAT/Firewall NSLP Performance Measurements at an edge-nf. The control of the NI depends on the existence of the REA state at the edge-nf. Furthermore, the control through REA messages is limited to the creation and deletion of the CREATE signaling. When REA state is teared down, the CREATE session is teared down accordingly. More comprehensive control is not specified. Consider following example: A CREATE is triggered by a REA-PROXY, but fails on the path between edge-nf (now: NI) and NR. Also, the failure is detected after the edge-nf already sent back a successful REA-RESPONSE to the NR. Now, there might be need to report to the NR that triggered CREATE failed. 6.8 Implementation An NSIS implementation [7] is freely available licensed under GPL from University of Göttingen. It contains GIST signaling transport protocol and was extended with an implementation of NAT/Firewall NSLP by the author and enhanced with firewall configuration capabilities by Niklas Steinleitner. The code is also licensed under GPL and is distributed as part of Goettingen NSIS framework. GIST and NAT/Firewall are implemented in C++ using standard template library and custom additions, such as a generic state machine template, an efficient hash table template, an event timer class and a message object code generator. GIST employs a NSLP API using UNIX sockets for inter-process communication. The NAT/- Firewall NSLP uses this API for sending and receiving messages with GIST. NAT/Firewall itself also offers a simple client API for integration into applications. An example command line client is provided within the release. Also, an ethereal dissector was developed in parallel for debugging 41

46 6 Explicit NAT configuration purposes. It is available in a separate NSIS ethereal dissector release [17]. A screenshot in the appendix 8.3 shows a three hosts scenario. The client API was designed with extensibility and simplicity in mind. The code is called only at the beginning of a signaling session and when a response is delivered back to the application. Control information is small, mostly only some dozen bytes if all attributes are exchanged at once. Therefore, a very simple approach was chosen (see 8.2 for source code excerpts). The API mainly consists only out of two C++ structs that the application either sends to the server by calling NatFw- Client::trigger() or receives from the server issuing a blocking NatFwClient::waitResponse() call. In each case, a pointer to a struct is passed. All relevant attributes in this struct need to be set or are set upon reception. A performance evaluation based upon this implementation was recently performed by Steinleitner, Peters, Tschofenig and Fu [26]. Although this study focused on firewall operation, the results are also equally applicable for NAT as the state machine and message processing code base is shared substantially between NAT and firewall parts. It was observed that the overall NAT/Firewall implementation performs well, but iptables system calls are slowing down processing heavily. As indicators of implementation performance, session setup time and processing time were chosen. Session setup time is of interest for the signaling applications, processing time for NAT administrators. Average processing time refers to the time a host needs in average to create a new session depending on the number of already-installed sessions. More concurrent sessions demand more optimized data structures. As it can be seen in figure 6.5(a), NAT/Firewall NSLP processing is constantly low, whereas iptables processing time increases almost linearly. Iptables uses a linked-list to store mappings. An insert causes a complete traversal with cost O(n). However, NAT/Firewall NSLP uses a hash table with mappings as keys. Hash table inserts are possible in O(1). Session setup time refers to the time an NI needs to signal all middleboxes along a path. Of course, more NAT/Firewall NSLP nodes located on the path are slowing down session setup due to time-consuming GIST discovery and association establishment. A three node scenario within a local network with low latency was chosen for the measurements. Figure 6.5(b) shows again a weak iptables performance due to less optimized data structures. 6.9 Evaluation Although still in draft state, NAT/Firewall NSLP specification is robust enough to be used for protocol implementation. The layered NSIS architecture allows easy development of lightweight NSLPs. However, the protocol has properties that might limit the quick adoption and deployment of it. The operation of NAT/Firewall NSLP usually spans two administrative domains, one at the sender, another one at the receiver side. The path might traverse additional domains in the global name space, but usually there are no NATs deployed. It might also span more than two administrative domains if cascaded NATs are controlled by different operators. Authentication and authorization among these domains is an important aspect for the protocol 42

47 6 Explicit NAT configuration to be deployed. Normal NAT policy is very simple as it just allows only outbound connections whereas inbound connections are dropped. Similarly, NAT/Firewall NSLP nodes could authorize requests from inside whereas requests from outside have to provide extra credentials. Authorization of requests from outside, such as CREATE message received by receiver-side edge- NAT, seems to be a problem. This expects a trust relationship between the domains that are spanned by the signaling path. Inter-domain trust relationship is a difficult as operators would allow other networks to manipulate states in their network. It might be argued that inter-domain IP routing is also based on trust relationships in form of contractual agreements between network operators. However, while for route distribution only data is read, NAT/Firewall NSLP would allow the manipulation of states in another s network. Even if configuration access is limited to its extend, NAT/Firewall NSLP remains a configuration protocol: it s duty is to manipulate states. Also, a too strict access policy would render it ineffective. Assuming that inter-domain trust relationship for middlebox configuration remains a complex issue in a foreseeable future, NAT/Firewall is fitted with proxy modes for partial path support. A normal two-domain scenario could be easily split into two one-domain scenarios where each operator controls one half of the middleboxes. This relates also to most current NAT deployments. Considering a small and home office environment, only the network owners have configuration access to NATs. Limiting NAT/Firewall NSLP to REA-PROXY and CREATE-PROXY case only enables the protocol to work in a intra-domain scenario without external contact. Unfortunately, important protocol features are lost. For example, the REA-PROXY makes the edge-nf act as a NI, creating a full mapping instead of a mapping reservation at the edge-nat. A mapping reservation can leave the data sender unspecified until a CREATE message fixes it. Currently, NAT/Firewall NSLP specification does not take port prediction problems into account. These difficulties are known from implicit NAT traversal mechanisms. Port prediction is necessary for class IV NAT scenarios. Consider two end hosts, each end host located behind a NAT. All nodes are running NAT/Firewall NSLP without trust relationship between each other. The two end hosts want to establish a direct TCP connection between them. If using REA-PROXY, the data terminal object cannot be fully specified as the port allocation of the other NAT is not known in advance. REA-PROXY allocates resources directly without prior reservation. This limitation could be alleviated by introducing more control over the resource allocation process. Compared with implicit NAT traversal mechanisms such a REA-PROXY scenario seems very complicated just for simply punching a hole in the NAT. The cost in complexity for only slightly more control is very high. For UDP, a single datagram can be sent to the data sender that results in the same effect. For TCP it is a bit harder as the NAT must receive a valid SYN+ACK message from outside. While the matching behavior depends usually on the NAT type, NAT/Firewall NSLP can specify the fields that shall be matched. Additionally, NAT/Firewall NSLP limited to REA-PROXY can still terminate timer-based mappings, has fine-grained access control, enables services behind dynamically configured NATs or can also configure firewalls at the same time. 43

48 6 Explicit NAT configuration Although NSIS does not employ a traditional client/server model, it also does not adopts the peer-to-peer principle. Path-coupled signaling rather can be considered as a client/server approach with capability-based path discovery. Oppositely, implicit approaches for direct connectivity rely on simultaneous open or try to emulate it. If NAT/Firewall is used consequently enough, it has to be integrated inside the applications or within a common lower layer interface, such as operating systems socket API. Then, NAT/Firewall NSLP could be used in conjunction with a session setup protocol to configure all middleboxes along the data path. 44

49 7 Conclusion This thesis gives an overview about NAT traversal techniques to enable direct connectivity between hosts behind NATs. Recent proposals from research community and IETF are explored. The document differentiates between implicit and explicit approaches, analyzes common mechanisms and shows their limitations and benefits. Both classes are aiming at slightly different targets. While study of implicit approaches in BE- HAVE working group focuses on analysis of the existing situation and provide recommendations to vendors and application developers, explicit NAT signaling can be seen as a robust standardized solution. NAT configuration based on path-coupled NAT/Firewall NSLP offers a clean and robust solution recently under development in NSIS working group. The author s implementation proved the protocol s feasibility with convincing performance attributes. However, as long as inter-domain deployment of NSIS is still not foreseeable, NAT/Firewall NSLP can not be used to its full extend. Limiting the protocol to REA-PROXY mode only, important functionality is lost, yet equally-compatible implicit approaches for direct connection establishment exist. Implicit approaches lack fine-grained control, but might be sufficient for a broad range of applications. It was shown that implicit approaches offer a strong compatibility for direct connection establishment with minimal deployment difficulties. The situation is likely to improve further if NAT vendors adopt recent recommendations to support TCP hole punching and to avoid symmetrical behavior. In case direct connectivity is not possible, applications can always fall back to connection relaying, providing a feasible, but inefficient solution. NAT has proven to be a successful concept. Although originally meant to be only a temporary solution, NAT is widely used today. Although it poses major difficulties, at least the direct connectivity problem can be alleviated using recent NAT traversal mechanisms. As IP address depletion is already delayed by many years, mid-term solutions that facilitate innovative peer-to-peer applications need more consideration. It should be also taken into account that NAT traversal might extend IPv4 lifetime artificially, similar to CIDR and NAT. This could postpone its displacement, resulting in a further delay of IPv6 introduction. 45

50 7 Conclusion 7.1 Acknowledgements The author thanks Hannes Tschofenig for pointing him to this interesting topic, Martin Stiemerling and Elwyn Davies for valuable feedback during the official IETF meetings, Niklas Steinleitner for his support on extending the NAT/Firewall NSLP implementation and Christian Dickmann for great discussions. 46

51 8 Appendix 8.1 NAT/Firewall NSLP Message Sequence Charts msc REA node 1 NR/NI+ node 2 NF node 3 edge-nf node 4 NI/NR+ REA waitrea reserve mapping REA RESPONSE reserve mapping RESPONSE rea rea Figure 8.1: MSC with REA triggered at node 1 in a 4 hop scenario 47

52 8 Appendix msc CREATE node 1 NR/NI+ node 2 NF node 3 edge-nf node 4 NI/NR+ CREATE waitresponse CREATE reserve mapping waitresponse CREATE reserve mapping waitresponse RESPONSE session create mapping RESPONSE session create mapping RESPONSE session Figure 8.2: MSC with CREATE triggered at node 4 in a 4 hop scenario 48

53 8 Appendix 8.2 NAT/Firewall NSLP Client API Listing 8.1: NatFwClient::trigger() 1 void NatFwClient :: trigger (NatFwClientRequest msg ) 2 { 3 send (sock, msg, sizeof ( NatFwClientRequest), 0); 4 } Listing 8.2: NatFwClient::waitResponse() 1 void NatFwClient :: waitresponse(natfwclientresponse msg ) 2 { 3 recv (sock, msg, sizeof ( NatFwClientResponse ), 0); 4 if ( msg >apirev!= NATFW_APIREV) { 5 NatFwDebugLogger : : print (DEBUG_WARN, 6 "client api revision mismatch, client : %d, server : %d ", 7 NATFW_APIREV, msg >apirev ); 8 } 9 } 1 typedef struct { Listing 8.3: NatFwClientRequest 2 char apirev ; // API revision number 3 int type ; // message type 4 bool proxy ; // proxy mode 5 short mode ; / / tr a ns p or t mode 6 int lifetime ; // session lifetime 7 short policy ; // policy rule 8 short subports ; // subsequent ports 9 IPaddr opp_address ; // opportunistic address 10 IPaddr ds_address ; // data sender address 11 char ds_prefix ; // data sender prefix 12 char ds_protocol ; // data sender protocol 13 short ds_port ; // data sender port 14 IPaddr saddr ; // source address 15 IPaddr daddr ; // destination address 16 short sport ; // source port 17 short dport ; // destination port 18 unsigned char sid [16]; // session identifier 19 } NatFwClientRequest; 49

54 8 Appendix 1 typedef struct { Listing 8.4: NatFwClientResponse 2 char apirev ; // API revision number 3 int codeclass ; // response class 4 int code ; // response code 5 IPaddr ext_address ; // external address 6 short ext_port ; // external port 7 unsigned char sid [16]; // session identifier 8 } NatFwClientResponse ; Figure 8.3: NAT/Firewall NSLP ethereal dissector screenshot 50