Peer-to-Peer Connectivity Using Firewall and Network Address Translator Traversal. R. Naber

Transcription

1 Peer-to-Peer Connectivity Using Firewall and Network Address Translator Traversal R. Naber April 22, 2005

2

3 Peer-to-Peer Connectivity Using Firewall and Network Address Translator Traversal Research Assignment Parallel and Distributed Systems Group Faculty of Electrical Engineering, Mathematics, and Computer Science Delft University of Technology R. Naber April 22, 2005

4

5 Abstract Network Address Translators (NATs) and Firewalls, also collectively called middleboxes, create problems for establishing connections in peer-to-peer (P2P) networks: They limit the outbound connections to the Internet, do not allow incoming connections, and break certain protocols. This happens because state is needed in the middleboxes, and absence of the correct state results in the failure of P2P application sessions. Connection reversal, relaying, Application Level Gateways (ALGs), hole punching, tunneling, and middlebox communication, are methods to set up the correct state in the middleboxes so P2P sessions can traverse them. Hole punching is the most effective way to setup P2P sessions. Knowledge on the behavior of middleboxes is used to punch a hole : Outbound packets cause the needed state to be setup. UDP hole punching can be used to establish a UDP session between most peers, using only the help of a few other peers. TCP hole punching is more difficult and error-prone, and might require servers on the public Internet, packet capturing, and/or superuser privileges. Since it is expected that firewalls and NATs will remain a part of the de facto Internet architecture, the design of any new P2P application will have to incorporate middlebox traversal techniques. i

6 ii

7 Preface In the contect of the I-Share project [24], I will be addressing the subject of firewall and network address translator (NAT) traversal in P2P networks. The work is carried out at the Parallel and Distributed Systems Group (PDS), which is part of the Faculty of Electrical Engineering, Mathematics, and Computer Science (EEMCS) of the Delft University of Technology. My work will consist of two parts: (1) A literature research project to investigate the problems that firewalls and NATs cause for P2P networks, and to detail the current methods used to address these problems, and (2) A Master of Science project to produce a Firewall and NAT traversal library, in which I will implement various traversal methods. This library will be a part of a P2P-Personal Video Recorder (P2P-PVR) application that is created as part of the I-Share Project. This report is the conclusion of the first part. Remko Naber April 2004 iii

8 iv

9 Contents 1 Introduction 1 2 Terminology Networks Sessions Network Address Translation Firewall Connectivity problems Limitations of an Internet connection Loss of the constant unique label Problems handeling incoming connections Protocol problems Connection failure problems Middlebox Traversal Connection reversal Static configuration Relaying TURN Application Level Gateways Middlebox communication UPnP for Gateway Devices SOCKS MIDCOM Realm Specific IP Hole punching STUN(T) Tunneling Teredo Applicability for P2P UDP hole punching Middlebox behavior for UDP Port-allocation behavior Packet-filter behavior Hairpin behavior Packet changes v

10 5.2 Middlebox detection for UDP Hole punching using UDP Step 1: Create the hole Step 2: Setup the filter Port prediction is error-prone Both peers behind a middlebox TCP hole punching Middlebox behavior for TCP Port-allocation behavior Packet-filter behavior Packet changes Middlebox detection for TCP Punching using TCP Step 1: Punching the hole Step 2: Accepting the incoming SYN Possible setup problems Examples Skype Azureus BitLord Three Degrees Activision games Conclusions 37 vi

11 List of Figures 2.1 A NAT router to share an Internet connection Unrestricted access to the Internet Access restricted by middleboxes Relaying by another peer Packet-filter behavior test First scenario for UDP hole punching Prediction failure: timing error Packets to multiple predicted ports Second scenario for UDP hole punching Intercepting packages Scenario for TCP hole punching vii

12 viii

13 Chapter 1 Introduction Peer-to-Peer (P2P) networks are popular, and the use of those networks has rapidly increased in the past years. The cost of a personal broadband connection is decreasing, while at the same time the broadband speeds are increasing. As a result, P2P networks constitute the largest amount of data traffic on ISP networks, and the amount of traffic is growing [8]. Due to the enormous growth in the past years, the Internet has evolved from the original architecture of [a] single universal logical addressing scheme, and the mechanisms by which packets may flow from source to destination essentially unaltered [10], to a network where Network Address Translators (NATs) are used to share a single broadband connection with multiple computers, and firewalls are used to protect personal computers and networks. One of the characteristics of both firewalls and NATs is that unsolicited incoming connections are refused. As a result it is becoming increasingly difficult to setup a direct connection between two peers of a P2P network. This is reflected in the following definition of P2P: P2P is a class of applications that takes advantage of resources storage, cycles, content, human presence available at the edges of the Internet... accessing these decentralized resources means operating in an environment of unstable connectivity and unpredictable IP addresses. Clay Shirky [33] A P2P application s main goal is to use resources available at peers running on nodes residing mostly at the edges of the Internet. These nodes are often located behind firewalls and NATs. Since it is more difficult to setup a connection to such a peer, its resources might not become fully available to the P2P network. It has been suggested that full IPv6 deployment will solve all connectivity problems. In [15] the full IPv6 deployment scenario is even named Heaven. However, as is also stated in [15], this scenario is not likely; IPv6 has not been fully deployed, and even if IPv6 is fully deployed, it is almost certain that firewalls and NATs will still be used. Firewall and NAT traversal methods can be used to improve connectivity, and this report will present those methods of traversal useful in peer-to-peer networks. The research focuses on solutions to the unstable connectivity problem. The problems introduced by unpredictable IP addresses are beyond the scope of this report. Firewalls and NATs are commonly called middleboxes. Middlebox is the name that is used to indicate a network intermediary that implements one or more middlebox services or functions: A middlebox function or a middlebox service is an operation 1

14 or method performed by a network intermediary that may require application specific intelligence for its operation [40]. The term middlebox thus includes every type of firewall from a large corporate firewall to a personal firewall, and it includes all different types of NATs. Throughout this document, a network intermediary in general will be referred to as a middlebox, and the name NAT or firewall is used where appropriate. Originally the Internet Protocol allowed packets to be routed from one host to another, without needing state or intelligence in the network. Firewalls and NATs changed this by introducing state and intelligence into the Internet. The state and intelligence is mostly hidden from the end hosts, but the (side-)effects are not. Most middleboxes are designed with the client/server paradigm in mind, allowing clients behind the middlebox to initiate connections to servers on the public Internet. These outgoing connections allow middleboxes to setup the state needed for the sessions. P2P networks however consist of peers that perform both client and server roles. These peers require the ability to receive incoming connections from the Internet. In middleboxes these incoming connections have no associated state, thus the connection is refused and dropped. Since connecting peers is the basis of every peer-to-peer network, the need for state and intelligence in the Internet is a problem for P2P networks. Successful traversal methods will thus depend on ways of setting the right state in the network to enable connections between peers. The question is: What are the best methods of middlebox traversal available for use in P2P networks? This report consist of the following chapters. In Chapter 2 an overview is given of the technologies and concepts related to middlebox traversal. Chapter 3 discusses the problems they present for P2P networks. Chapter 4 will then outline different methods of middlebox traversal. Chapters 5 and 6 will present a more detailed overview of UDP hole punching and TCP hole punching. This is followed by chapter 7, which presenting a few examples of P2P applications that use a form of middlebox traversal. Chapter 8 presents the conclusions of the report. 2

15 Chapter 2 Terminology The purpose of this chapter is to familiarize the reader with the technology and terms used in the context of middlebox traversal. The first section introduces the terms used when talking about a network. The second section will discuss the session concept. Then the working of a network address translator is described, and in the final section the working of the firewall. 2.1 Networks The following are the terms used in this document in relation to networks. The terms are taken from [39, 21] and adapted where needed for this report. Address realm (or) realm - An address realm is a collection of routers and end systems exchanging locally valid location knowledge. In the realm network addresses are uniquely assigned to entities such that datagrams can then be routed to them. Public/global network - A public or global network is an address realm with unique network addresses assigned by the Internet Assigned Numbers Authority (IANA) or an equivalent address registry. Private/local network - A private network is an address realm independent of external network addresses. A private network may also be referred to as a local network. The recommended address space for use in private networks is documented in [29]. External network - The external network is used to indicate the part of the network that is not influenced by the working of the middlebox. For example, for firewalls this corresponds to that part of the network not protected by the firewall. In most discussions the name external network is used as a synonym for the public/global network. Internal network - The internal network is the part of the network that is serviced by the middlebox. This is the private/local network for NATs, and for firewalls the protected part of the network. This is also used as synonym for private/local network. 3

16 2.2 Sessions The session is an important concept in the discussion about middleboxes. There is some confusion about what exactly constitutes a session. The name session is used in different situations: (1) To indicate a TCP or UDP session, (2) To indicate an application or protocol session, (3) to indicate a session managed as a unit in a middlebox. These types of sessions do not have to correspond. For example, an application might view a collection of TCP/UDP sessions as a single application session. In this report a type (1) session will be named a session or a TCP/UDP session. For an end host, a TCP/UDP session is identified by the 4-tuple (source IP address, source transport identifier, destination IP address, destination transport identifier). Each session has two endpoints, an endpoint is a 2-tuple (IP address, transport identifier), which is also referred to as a transport address or address. Two endpoints together form the session 4-tuple. Type (2) sessions will be named application or protocol session. Type (3) sessions will be named middlebox/nat/firewall session. There is a distinction between packet flow and session flow. Packet flow is the direction in which packets travels with reference to the middlebox. Outbound packet flow is packets traveling from the internal network to the external network. Inbound packet flow is packets going the other way around. The session flow indicates the direction in which a session was initiated with reference to the middlebox. Sessions started on the internal network, that traverse the middlebox to the external network, are considered outbound. Inbound sessions start on the external network, and traverse the middlebox to the internal network. A session has both an inbound and an outbound packet flow. Middleboxes have to maintain state to correctly handle sessions, therefore they have to identify the start and the end of a session. For TCP the start of the session is deduced from the initial SYN packet. For UDP there is no deterministic way of recognizing the start of a session, so a heuristic is to consider the first packet with a thus far unseen 4-tuple as the start. Detecting the end of a session is more difficult for a middlebox. A TCP session normally ends when both endpoints of the session have acknowledged FIN, or when either endpoint receives an RST. However, there is no guarantee that these packets will reach their respective endpoints after these packets traverse the middlebox. It is also possible that the communication ends without a FIN or RST. For example, when one of the endpoints crashes. For UDP there is again no deterministic way to detect the final packet. So for the middlebox a heuristic is needed to determine the end of a TCP or UDP session. This heuristic is often based on a timer. 2.3 Network Address Translation Network Address Translation (NAT) is a middlebox function that was invented in a time in which there was an exponential growth in the devices that used IP technology. In order to connect all those devices to the Internet, each of them would need a unique IP address. It was feared that the available IP addresses would be depleted in a matter of years. The inventor of NAT, Paul Francis, invented the NAT as a short-term stopgap solution to the address depletion problem [15]. In May 1994, The idea of the NAT was published as RFC1631 [11], The IP Network Address Translator. In [11] it was clearly stated that NAT is not a long term solution, and that further testing had to be done. Despite these words of caution, NAT proved to be a commercial success and has been ubiquitously deployed. 4

17 +---+ A \ \ \ \ Router (ISP Connection) B ---- w/ ((Internet)) / NAT / / C / Figure 2.1: A NAT router to share an Internet connection Network address translation is a method by which IP addresses are mapped from one address realm to another. A NAT router functions as a gateway to the Internet for a group of local hosts, see also Figure 2.1. These local hosts are assigned private addresses. These addresses are not globally unique, and thus cannot be used in the public address realm of the Internet. The NAT router is needed to route packets between the two address realms. The NAT uses intelligence to modify the address contents in the IP header, so that the header is valid in the address realm into which the datagram is routed. This way the NAT attempts to provide transparent routing for hosts in the private network to hosts on the Internet [39]. There are different types of NAT, and this report focuses on the traditional NAT types: Basic NAT, that translates only IP addresses; and Network Addresses and Port Translation (NAPT), that translates both IP addresses and transport identifiers. Other types of NAT are discussed in [39]. A Basic NAT router holds a set of globally unique IP addresses. When a private host tries to initiate a session with an Internet host, the Basic NAT router maps the private address to one of its public IP addresses for the duration of the session. NAPT extends this mapping method and includes the transport level identifier, i.e., the TCP/UDP port or the ICMP identifier. NAPT maps tuples of the type (local IP address, local transport identifier) to (global IP address, assigned transport identifier). This way multiple hosts behind the NAPT router can simultaneously connect to the Internet, using only a single external IP address. Each IP packet that traverses the NAT router has to be translated. In Basic NAT the IP address in the IP header is translated from the origin address realm to the destination realm. In NAPT also the transport level portion of the IP packet has to be changed. For outbound packets from the private network, the NAPT router translates the source IP address, source transport identifier, and all related fields such as the checksums of IP, TCP, UDP, and ICMP. On inbound packets, NAPT translates destination IP address, destination transport identifier, and again the IP and transport header checksums. For ICMP error messages, also the IP packet in the payload has to be changed. These changes include changes to the IP header, the checksum field, and the transport header of the packet in the payload. For the reader interested in the specific changes see [38]. In order to maintain transparency, the NAT middlebox maintains state for each session. At the detection of a new outbound session an address mapping is made, and state is setup to handle the session. All packets belonging to the session will be subject 5

18 to address lookup (and possibly transport identifier lookup) and translation. So when a datagram leaves one realm and enters another, it is forwarded to the right end-host in other realm. The minimum state needed for translation is the address mapping, but more information can also be maintained. For example the destination address, or the last seen sequence number of a TCP session, etc. The state is kept, and if needed updated, during the lifetime of the session, and only removed once the end of a session is detected. 2.4 Firewall A firewall is a middlebox service that screens network traffic, and blocks traffic it believes to be inappropriate, dangerous, or both. Firewalls are deployed for security reasons, either at network choke points, or running as a service on a client machine. It is important that applications continue to work properly in the presence of firewalls. This means that data traffic across the firewall should be allowed as long as it appears legit. The definition of legit depends on the needs of the person, or company, administering the firewall, but as can be seen from the following quotation, there is a tradeoff between security and usability. The only perfectly secure network is one that doesn t allow any data through at all and the only problem with such a network is that it is unusable [16]. There are three basic types of firewalls: Packet-filter firewalls, proxy-service firewalls, and stateful-inspection firewalls [16, 28]. A packet-filter firewall inspects each network packet, and then determines whether the packet is to be passed or dropped (blocked). This filtering is transparent to the user and the protocol. The decisions of this type of firewall are typically based on Access Control Lists (ACLs), which contain state on what traffic is allowed for certain combinations of source and destination IP addresses and port numbers. This is a permanent form of state, and no dynamic state is maintained. Control and logging capabilities are limited, but the working of the firewall is fast. A proxy-service firewall is based on a proxy server. The server relays the packets from the local host, thus making it look like the packets originated from the firewall. The proxy acts as server to the local host, and as a client to the external hosts. The proxy is either transparent to the local host, or requires the local host to use a special protocol mechanism to communicate with the proxy. Since the firewall acts like a protocol endpoint, it can perform protocol validity checks, allow only a subset of the protocol, and provide sophisticated filtering, logging, caching and even virtual private networking facilities [28]. There are two types of proxy firewalls: Circuit-level proxies and application-level proxies. Circuit-level proxies work like packet-filter firewalls, and do not maintain dynamic state, and thus provide a simple and fast filtering relay. Application-level proxies on the other hand use application and protocol intelligence. These proxies track and maintain state on both normal and application sessions, and also use packet-payload inspection to make decisions. Stateful-inspection firewalls monitor the entire OSI network stack. State is maintained for all the communication across the firewall using application and protocol intelligence, allowing the firewall to construct a contextual history. This enables the use of strict security policies and sophisticated packet filtering. It also allows the firewall to be more transparent to the end user. An FTP session for example consists of multiple 6

19 TCP session using different port numbers. By inspecting the FTP packets the firewall knows which ports will be used for each of the TCP sessions, and can setup the right state to allow these TCP sessions to cross the firewall. 7

20 8

21 Chapter 3 Connectivity problems In order for a P2P network to perform its function, connections have to be made between the peers. Before the introduction of firewalls and NATs, it was easier to setup a connection, because connections to and from the Internet were not restricted. In Figure 3.1, a (simple) example is shown with two peers, A and B. Both peers have a direct connection to the Internet with a fixed IP address. A session between them can be setup by either A or B, simply by connecting to the other peer s IP address A ((Internet)) B Figure 3.1: Unrestricted access to the Internet The various middleboxes form obstacles in the path to the Internet. Instead of a direct connection to the Internet, a peer (host) might be situated behind a NAT router, a firewall, a combination of a firewall and a NAT, or even behind a cascaded setting of middleboxes. This situation can be seen in Figure 3.2. Since most middlebox services are designed to be transparent, peers running on a client host might not know about the middleboxes, but the peers could still experience the (side-) effects of the working of the middleboxes. These effects can be divided in intentional and unintentional effects. Intentional effects are part of the function of a middlebox. For example, the firewall by nature reduces connectivity. Unintentional effect are side-effects, which are the result from the use of the middlebox function. NATs have the side-effect of limiting incoming connections, like the firewall. This is even marketed as a security feature of NAT [15]. This also shows that the distinction between the different middlebox services is fading. Another example of the fading boundaries is the proxy firewall, which uses a form of network address translation when it changes a packet s address, and replaces it with its own address. For the discussion the connectivity problems for P2P networks is devided into five problems, which are discussed in turn. 3.1 Limitations of an Internet connection The first problem is the limitations a peer could encounter when trying to connect to another peer. A firewall, for example, can be configured to deny access to the Internet for certain internal hosts, or deny access for every host during a certain time period. It is 9

22 NAT w/ Firewall ISP NAT Private NAT A ((Internet)) B Figure 3.2: Access restricted by middleboxes also possible to limit connections to the Internet to a certain protocol. For example, by only allowing HTTP. A proxy-service or stateful-inspection firewall can go even further, and limit the protocol by allowing only a safe subset of the protocol. For a NAT router a limitation is the total number of addresses available. For example, with basic NAT, the number of private hosts that can have a simultaneous connection to the external network is limited by the number of global addresses available. 3.2 Loss of the constant unique label An IP address can no longer be used as a constant unique label for a peer. The network address translator allows multiple hosts to share a single IP address, or to share multiple IP addresses on a round-robin basis. A proxy firewall also changes IP addresses of packets to its own IP address. In [10] some other reasons why an IP address is no longer a unique unique label are discussed, like dynamic address allocation. Thus using the IP address for identification is no longer a valid option, and another form of identification has to be found. For example, the identification problem can be solved by using a public key system. This peer identification problem is outside the scope of this report. 3.3 Problems handeling incoming connections Middleboxes create problems for incoming connections. Middleboxes favor the client/server model, where a session is setup from the internal network to the external network. The first packet of the session enables the middlebox to setup state, after which the return traffic can traverse the middlebox from the external network to the internal network. Thus, only if state is found for a packet arriving at the middlebox, can the packet be passed on. If no state is found the normal behavior of a middlebox is to drop the packet. As was stated above, for the firewall this is an intentional effect, because it is designed to block unsolicited connections. For the NAT this is a unintentional side-effect, packets arriving at a NAT-like middlebox, have as destination address the address of the middlebox. Without further knowledge provided by the state, the NAT does not know to which internal host to forward the packet. These packets are then simply dropped, or considered to be directed to the NAT itself. However in the last case, it is most likely that the packet isn t meant for the NAT, so the packet still does not reach its intended destination. 10

23 3.4 Protocol problems Middleboxes can break certain protocols. Protocols like FTP, H.323, SIP, and RTSP use multiple TCP/UDP sessions on various ports, both inbound and outbound, as a single protocol session. The outbound sessions might succeed, but without state in the middlebox to handle the inbound sessions the protocol session will still fail [22]. NAT changes IP addresses and port numbers, which introduces problems for protocols that cannot handle those changes. Encrypted protocol like IPsec check the IP address for changes, and discard all packets with changed address or port numbers. Other protocols, like FTP, include IP addresses and port numbers in their payload, but these will be invalid in the external address realm. 3.5 Connection failure problems The final problem is the increased brittleness of the connections, which can easily lead to connection failures. This is the result of the middleboxes keeping state for their working. If there is no state in the network, then state can only be destroyed when the endpoint itself breaks [9]. If state is kept at a certain middlebox in the network and that middlebox has a failure, then traffic dependent on that state cannot be routed around the failure. All sessions traversing the middlebox at that time will fail. This is called fate-sharing, the end hosts and the middlebox share the same fate: If the middlebox fails, then so do all the sessions to and from the hosts on the internal network. The fate-sharing problem is a fact that creators of P2P networks will have to cope with, but the problem is beyond the scope of this report. 11

24 12

25 Chapter 4 Middlebox Traversal Peer-to-peer networks have troubles with middleboxes, because they reduce connectivity. An answer to these problems is found in middlebox traversal. For middlebox traversal the following definition is used: Middlebox traversal consists of all methods and techniques that can be used to setup a session between two peers that traverses all middleboxes along the way. The definition is a general definition, and says nothing about the applicability of a method to a specific P2P network, or the feasibility of the method for implementation in a P2P application. For two peers A and B in a P2P network it is important that A can send data to B, and B can send data to A, preferably using direct communication. So, a traversal method can be considered a success when a P2P session is successfully established. The methods described in this chapter are traversal methods to increase connectivity in general, and help setup sessions that traverse middleboxes. Also examples of protocols that implement these methods are presented. Of the 5 problems discussed in the last chapter, only (1), (3) and (4) can be (partially) solved by middlebox traversal. Since these problems all have to do with the (lack of) state in the middleboxes, the traversal methods are based on ways of setting up the state needed for a session, or using the already available state to allow sessions to traverse a middlebox. For the explanation of some of the methods an example is used with three peers: A, B, and C. A wants to setup a connection to peer B. Peer C is available to help setup the connection, and is assume C is already connected to A and B. 4.1 Connection reversal Connection reversal is a simple method that can be used when two peers need to setup a session, but one of the peers is located behind a middlebox. For example, when A is not behind a middlebox, but peer B is, then A cannot initiate a session to B, because there is no state for the inbound session on the middlebox at B. Peer B, on the other hand, can start a session to A, since this would be viewed by the middlebox as an outbound session. The outbound session by B will setup the state for the return traffic from A. So if A wants to communicate with B, A has to request B to start the session. This request can be sent to B via peer C. 13

26 4.2 Static configuration Firewalls and NATs setup state dynamically for outbound sessions. Inbound sessions cannot be dynamically setup, but static configuration is possible. Permanent state is stored in the middlebox by the middlebox administrator to allow inbound sessions. In order to allow an incoming session to pass through a firewall, static rules can be setup in the firewall detailing which packets will be allowed to pass through the firewall to the internal network. In basic NAT a static mapping can be used to allow inbound access for a preselected internal host via a fixed public address [38]. In a NAPT router, an external IP address and port can be mapped to an internal IP address and port. For example, a NAPT router can route all incoming traffic to port 1214 to a certain internal node, by statically mapping port 1214 to port 1214 of the internal node. 4.3 Relaying Relaying is based on a third party that forwards or relays data traffic from one peer to another peer. This method can be used if both peers are behind a middlebox. The third party acts as a server for both peers. This way both peers communicate as the client of the client/server style; both peers initiate outbound sessions to the server. The third party can be a dedicate relay server, or in a P2P network the third party can be another peer. Using the example, peer A and B would use their connection to C, and let C relay data between A and B, see Figure C --+ / \ / \ A X Blocked X B Figure 4.1: Relaying by another peer TURN Traversal Using Relay NAT (TURN) is an example of a protocol designed for relaying data traffic to and from hosts behind a middlebox [30]. It works on the assumption that hosts behind middleboxes can make outward connections to TURN servers on the public Internet. The TURN servers function as the public endpoint for an end-host, and relay data sent by other hosts to these public endpoints back to the end-host. This allows inbound sessions to be setup to the host behind the middlebox. TURN provides features like security, authentication, the ability for end-hosts to request even or odd ports, and pre-allocation of higher ports. 4.4 Application Level Gateways Application Level Gateways (ALGs) use application intelligence to dynamically configure a middlebox. This can help protocol sessions to traverse the middlebox. ALGs 14

27 are different from proxies, they are not visible to end-hosts, and are not an endpoint of a session. Instead, an ALG examines application traffic in transit, and assists the middlebox in handling the session. The ALG uses its intelligence to set up state, and change the payload of certain packets, to allow an application to transparently maintain sessions across the middlebox. This way, protocols that use multiple TCP/UDP sessions as one protocol session like FTP, SIP and H.323 do not fail, if there is an ALG to aid the middlebox traversal of the protocol [22]. When correctly implemented, an ALG will undo the problems introduced by the middlebox for the specific protocol. In theory it is possible to create an ALG for all protocols, but for some protocols there are practical problems. For example, for certain protocols that require end-toend encryption or use another form of data protection an ALG might not work. These protocols are designed to detect and discard packets that were altered. In order to change the application packets so they are not discarded, the ALG would need access to the encryption keys. This is a trust issue, and it is difficult for an end-host to trust the middleboxes in its path to the Internet. 4.5 Middlebox communication Instead of having intelligence in the middleboxes, middlebox communication protocols allow the intelligence to be elsewhere. The protocols allow end-hosts to communicate their connectivity needs to the middleboxes. The end-hosts can request state, like port mappings and rules, to be setup to facilitate protocol traversal through the middlebox. The middlebox communication can either be done using an on-path or off-path signalling method [34]. On-path signaling works by sending a request into the network to the destination address. Every middlebox encountered along the way can then setup state if needed, and then pass the request packet on. This is done in an RSVP like fashion [7]. Off-path is the more common method. For this the endpoint has to know it is behind a middlebox, and send an explicit request to the middlebox to setup state for future data traffic UPnP for Gateway Devices As part of the overall UPnP architecture, UPnP for Gateway Devices targets NAT and firewall functionality, and is primarily for the consumer, home office, and small business networking domain. It provides features for middlebox traversal, these include: middlebox detection, addressing realm information retrieval, listing of current port mappings, creation and deletion of port mappings [42] SOCKS SOCKS (Version 5) provides authenticated firewall traversal based on network proxies at the transport level [25]. SOCKS uses a generic proxy server, where clients with the correct credentials can setup state in the firewall, and then transparently and securely traverse the firewall. These clients can be either inside or outside the firewall allowing bi-directional communication. Multiple SOCKS proxies can even be used in a cascaded setting. SOCKS provides a framework for TCP and UDP, but does not provide forwarding of ICMP messages. 15

28 4.5.3 MIDCOM MIDCOM (MIDdlebox COMmunication) is another framework to take application intelligence out of middleboxes. MIDCOM places application intelligence in MIDCOM agents and policy servers. The agents are external to the middlebox, and can be part of an application or an application proxy. Agents request a middlebox service, this can be a port mapping or a request for external access, etc. Each request from an untrusted agent has to be authorized by a policy server. MIDCOM is still a work in progress, for more information see [27] Realm Specific IP Realm Specific IP performs the same function as NAT, only in a different manner. RSIP is not transparent to the end user. Instead, it requires that clients are aware of the RSIP server to actively negotiate Internet access. RSIP is available on the IP address level as Realm Specific Address IP (RSA-IP), and on the transport level as Realm Specific Address and Port IP (RSAP-IP) [6, 5]. If a RSIP hosts needs a presence in another addressing realm, it requests resources from the RSIP gateway. This can be a public IP and a port number for TCP or UDP. Once the resources are granted, they can be used by the RSIP host for communication with the public Internet. The host can receive incoming connections on the awarded address, and use the address to setup sessions to other hosts. RSIP tunnels the packets between the RSIP host and the gateway, this way also encrypted protocols can be used by the end host. 4.6 Hole punching Hole punching relies on the behavior of firewalls and NATs; At the start of an outgoing session, state is setup for return traffic. Depending on the implementation of the middlebox, and the state that is recorded, the return packets can come from only the address the outbound session was destined for, or also from other locations. Hole punching can be used when two peers are both behind a middlebox. Hole punching is effectively tricking the two middleboxes into setting up a single session that both middleboxes see as an outbound session [14]. The hole punching method uses knowledge on the behavior of a middlebox to send the packets that trigger the setup of state for incoming data traffic. There are different types of hole punching, of which UDP hole punching is the best known and usable. Hole punching with TCP is also possible, but it is considerably more difficult STUN(T) Simple Traversal of UDP through NATs (STUN) is an example of a protocol that uses a client/server structure to enable hosts to use UDP hole punching [31]. An extension of the STUN protocol for TCP is STUNT [17]. A host runs a STUN(T) client that connects to a STUN(T) server on the public Internet. The client allows the host behind a middlebox to discover the presence of the middlebox in its path to the Internet, and discover the behavior of this middlebox. STUN(T) also provides the host with information on the public IP assigned by the NAT middlebox. This knowledge can then be used for UDP and TCP hole punching. 16

29 4.7 Tunneling Tunneling is an encapsulation mechanism for transporting protocol packets in the payload of another protocol. This can be handy in cases where an Internet connection is restricted by a firewall that only allows certain protocols to pass. For example, when a proxy firewall only allows outward HTTP sessions, the P2P protocol can be embedded in HTTP. Or after a UDP hole is punched on a NAT, TCP could be tunneled in the payload of UDP packets Teredo Teredo is service that allow hosts connected to an IPv4 NAT to obtain IPv6 connectivity by tunneling IPv6 packets over UDP. The service requires Teredo servers and relays. The relays are positioned between native IPv6 and the Teredo service. The servers are used to manage only a small part of the traffic between Teredo clients [23]. Teredo uses UDP hole punching techniques to obtain direct connections between Teredo clients behind middlebox. Teredo uses the name automatic tunneling for this hole punching technique. 4.8 Applicability for P2P The traversal methods discussed in this chapter are all capable of solving a part of the problems. For the creation of a P2P application, it is important to understand which of these solutions can be programmed into a client. Therefore the applicability of the methods are discussed here: Connection reversal - Is a very handy method if only one peer is located behind a middlebox. Static configuration - This is not a solution that can be programmed into a client, although the documentation of the P2P application could include good information on how to perform static configuration. Static configuration does however require that the user has the administrative powers and knowledge to perform the configuration, something not all users have. Relaying - Relaying is a technique that is effective, but since all data has to travel to and from the relaying node, it is costly in terms of bandwidth and processing power. Direct connections are thus preferred in P2P networks. ALGs - The problem with ALGs is that for every new protocol a new ALG has be created, also, creation alone is not enough, every middlebox device will have to be updated with the new ALG. This is something that is not simply feasible, so some middleboxes will have the ALGs while others do not. This means that some protocols will therefore traverse certain middleboxes, while they will fail on others. For a P2P developer it is important to remember that any protocol that requires special handling by NAT or firewall products will be more difficult to deploy than those that require no special handling [32]. Middlebox communication - Using middlebox communication, it is possible to setup state on a middlebox for P2P sessions, i.e., to enable inbound sessions. This means 17

30 that a P2P application could implement the code needed to talk to the middlebox using the middlebox communication protocol. However, in the case of cascaded middleboxes the peer may only be able to setup state on the nearest middlebox, after which the session could still fail on the next middlebox. Hole punching - Hole punching is an effective method to setup state in a middlebox. It is one of the simplest but most robust and practical [firewall and] NAT traversal techniques [14]. Hole punching will be discussed in detail in the next two chapters: First UDP hole punching, then TCP hole punching. Tunneling - Is a method that causes overhead if an existing protocol is embedded into another protocol. Also the advantages of the embedded protocol might not be available for the other protocol, this means that they have to be re-implemented in the tunneling protocol. Tunneling should only be seen as an optimization, with as best example the tunneling of a protocol in HTTP, when HTTP is the only protocol that can be used. 18

31 Chapter 5 UDP hole punching UDP hole punching is a technique that can be used to establish a UDP session between two peers, even if each peer is located behind a middlebox that blocks inbound UDP sessions. The basic mechanism of UDP hole punching is to let both peers start an outbound UDP session by sending a UDP packet to the other peer. Once these first UDP packets arrive at the respective middleboxes, they are seen as the start of an outbound UDP session. Both middleboxes then set up the state for these sessions. The state in each middlebox will allow the UDP packets from the other peer to pass through the middlebox. So the first outgoing UDP packet by each peer effectively punched a hole for the incoming UDP data traffic of the other peer. As a result a UDP session is established between the two peers. The setup of this chapter is as following. Because UDP hole punching depends on knowledge of the behavior of the various middleboxes, this behavior will be discussed first. Then the way to figure out this behavior, middlebox detection, is discussed. Once a peer has done the detection it has the knowledge needed to punch a hole in its middlebox. The steps to punch a hole in a middlebox are explained in the final section of this chapter. 5.1 Middlebox behavior for UDP Since middlebox behavior has not be standardized, there is no uniform handling of UDP sessions by middleboxes. The behavior depends fully on the implementation of the middlebox, and the configuration done by the administrator of the middlebox. Since most middleboxes are transparent to the hosts on the local network, this behavior cannot be observed by a local peer, but fortunately the behavior can be observed by other peers. Observations made by the other peers can be combined to form a picture of the behavior of the middleboxes in the path to the Internet. It is important to note, that it does not matter how many different middleboxes are situated in the path to the Internet. Only the most restrictive behavior will be observed by the other peers and it is the knowledge of this behavior that is needed to punch a hole. The following discussions focuses on the behavior that can be observed when a peer behind a middlebox initiates outgoing UDP sessions to other peers. It is assumed that all sessions are started from the same local IP address and local port. It is also assumed, that for a NAT there is only one global IP address available. So only the external port number, the destination IP address, and destination port number can vary. 19

32 5.1.1 Port-allocation behavior The port-allocation behavior determines the way the internal port number is mapped to an external port number. This behavior only applies to the middlebox services that change the port number of a packet, like the NAPT and the proxy firewall. The behavior can be divided in: the initial port assignment behavior for the first UDP session coming from a local IP:port, and the behavior towards the packets of further sessions that originate from the same local IP:port. For the initial port assignment, there are three different strategies that are used: Port preservation - When port preservation is used, an attempt is made to assign the same external port number as the internal port number the session was started from. Constant delta - The session is assigned to the next available external port. This external port is found by adding a constant number, the delta, to the last allocated port. If this port happens to be in use, then the delta is added again and again until a free port is found. Random - The session is assigned to a random free port. Port preservation is possible if the external port is not in use, or if port overloading is used when the external port is already in use. With port overloading, multiple sessions from different internal IPs using the same local port are mapped to the same external port. This only works if its possible to distinguish the sessions based on the destination IP and port number. Port overloading for UDP thus fails, if two internal hosts initiate a connection to the same external IP:port combination. If port preservation isn t possible, then one of the other two methods of assignment will have to be used. There are two weaker forms of port preservation: Range preservation and parity preservation. When range preservation is used, an attempt is made to allocate the port in the same range as the local port used. The port ranges are low, high, and dynamic. These are defined as , >= 1024, and >= 49152, respectively [17]. Some NATs preserve the parity of the local port used; An even port is mapped to an even port, and an uneven port is mapped to an uneven port. This is done for the RTP and RTCP protocols, where RTP uses even ports, and RTCP uses odd ports. Related to parity preservation is port contiguity: If RTP uses even port X, then a companion RTCP session will use odd port X+1. Subsequent UDP sessions from the same local IP:port are either mapped to the same external port, or mapped to a new port. On arrival of an UDP packet at the middlebox, the following mapping behavior can be distinguished: Not sensitive - All packets are mapped to the same external port number, regardless of the destination IP address or port number. Address sensitive - All packets to a certain destination IP address are mapped to the same external port, regardless of the destination port. A new external port is allocated for each distinct destination IP address in the UDP traffic. Port sensitive - Only packets to a distinct combination of destination IP address and destination port are mapped to the same external port. This implies that a new 20