Network Address Translation Problem

Transcription

1 Network Address Translation Problem A Decentralized Solution A Thesis Presented To Eastern Washington University Cheney, Washington In Partial Fulfillment of the Requirements for the Degree Master of Science By Ross E. Lanes Fall 2010

2 Thesis of Ross E. Lanes Approved By DATE Carol Taylor, Graduate Study Committee DATE Kosuke Imamura, Graduate Study Committee

3 Master s Thesis In presenting this thesis in partial fulfillment of the requirements for a master s degree at Eastern Washington University, I agree that the JFK Library shall make copies freely available for inspection. I further agree that copying of this project in whole or in part is allowable only for scholarly purposes. It is understood, however, that any copying or publication of this thesis for commercial purposes, or for financial gain, shall not be allowed without my written permission. Signature Date

4 iv Acknowledgements I would like to thank several people for their assistance in completing this thesis. Dr. Carol Taylor worked diligently as my advisor and provided direction and assistance when I was lost. Dr. Christian Hansen was a great help through correspondence and in person meetings as I conducted the analysis of the collected data. I would also like to thank Gary E. Duncan and Ross N. Barker for their hours of assistance in configuring, monitoring and providing status reports to me during the three months it took to complete the data collection process.

5 v Contents Acknowledgements... iv Table of Figures... vii 1 Introduction Literature Review Network Address Translation Classifications RFC Simple Traversal of User Datagram Protocol through Network Address Translators (STUN) RFC Network Address Translation Behavioral Requirements Known Solutions to the Network Address Translation Problem Connection Reversal UDP Hole Punching/STUN TCP Hole Punching (NATBLASTER) NAT Port Mapping Protocol (NAT-PMP) RFC Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) RFC IP Network Address Translator (NAT) Terminology and Considerations Proposed Solution Decentralized UDP Hole Punching Methods Simulation of a NAT Device Metric for NATed connections... 21

6 vi 5 Procedure Experiment Systems Data Collection Process Role of the Control Server UDP Packet Loss Handling Analysis of Data Analysis of Hypothesis One Analysis of Hypothesis Two Conclusion and Future Works Works Cited Appendix A: Enclosed DVD contents Appendix B: Experiment Application Configuration and execution instructions Appendix C Glossary of Terms UDP TCP DHCP Peer-to-Peer Client/Server VITA... 41

7 vii Table of Figures Figure 1 Private Network Address Blocks... 2 Figure 2 RFC 3489 Classification Diagrams... 7 Figure 3 Connection Reversal Figure 4 Network before UDP Hole Punching Figure 5 UDP Hole Punching Figure 6 After UDP Hole Punching Figure 7 Traversal using relays around NAT Figure 8 Main Effects Plot for LN(TTC) - using NAT Handlers Figure 9 Scatter plot of LN(TTC) vs. number of peers grouped by using Decentralized Hole Punching Figure 10 Scatter Plot of LN(TTC) vs. Number of peers by number of NAT handlers and using decentralized hole punching Figure 11 Main Effects Plot for LN(TTC) - using Decentralized Hole Punching Figure 12 Example of a Peer-to-Peer network Figure 13 Example of a Client/Server network... 40

8 1 1 Introduction Before the Internet, there were many different physical networks all using different network protocols that could not communicate with each other. However, people needed to be able to communicate across multiple networks in order to collaborate on projects, communicate with each other and share data. As such, Robert E. Kahn of the Defense Advanced Research Projects Agency (DARPA) recruited Vinton Cerf of Stanford University to work with him on the problem of network interoperability. The solution that they eventually devised became known as the Internet Protocol Suite or TCP/IP (1). To this day, the Internet is still based on Internet Protocol version 4 which was proposed as RFC 791 (2) in September Internet Protocol (IP) version 6(IPV6) has been proposed as the successor to IPv4 but has not yet been adopted on a large scale. In TCP/IP networks every device on the network is assigned an IP address that uniquely identifies the device. As the Internet grew, there was an increasing demand for IPv4 addresses. IPv4 addresses are 32-bit addresses, which limits the address space to 4,294,967,296 (2 32 ) possible unique addresses. Although four billion may seem like a lot, the Internet is now a global network and is running out of address space. Also, IPv4 reserves some of the address space for specific purposes such as private networks (~18 million addresses) or multicast addresses (~270 million addresses). Private Networks are networks that use TCP/IP but are not connected to the Internet directly. Therefore, these private networks do not need a unique address space assigned to them and in RFC 1918 (3) the address space for such private networks was defined to be one of three address blocks. These address blocks are shown in Figure 1. Eventually, private networks found a need to connect to the Internet. Some private networks still wanted to be private but have a bridge to the Internet. In order to facilitate such a bridge, Network Address Translation (NAT) was developed and proposed in May 1994 when RFC 1631 (4) was published.

9 2 Name Address range Number of addresses Class description 24-bit block ,777,216 Single Class A 20-bit block ,048, contiguous Class B blocks 16-bit block ,536 Contiguous range of 256 class C blocks Figure 1 Private Network Address Blocks Although, NAT was part of the solution to the dwindling number of public IP Addresses, it also caused new problems. The major problem that NAT created is that servers could not be within private networks and be accessible to the public Internet. Also, as Peer-to-Peer networking solutions became more popular, peers needed to directly connect to other peers. However, if the peer was behind a NAT, this was not possible. These problems became known as the Network Address Translation Problem. The NAT problem has become more complicated due to the non-standardization of NAT implementations. RFC 3489 (5) established four classifications of NAT implementations. However, many NAT devices do not strictly follow any one of the four classifications and instead use a hybrid system. This lack of standardization forces developers of Peer-to-Peer applications to assume that NATed peers will not be able to connect to other peers unless they are helped. Although, most NAT devices allow themselves to be configured to allow incoming connection requests to reach a host inside the private network, the user of the host may not be able to configure the device. For example, a large company uses a private network and they use a program that takes advantage of Peer-to-Peer networking. If this application is used by several hundred employees and those employees use the application to communicate with customers it may be impossible to configure the NAT device to allow for so many incoming connections. It is also possible, with

10 3 the advent of home networks, that a normal consumer with no networking experience could be using a NAT device to connect to the Internet. It would not be convenient for this consumer to configure their NAT device and as such the burden is on the developer to solve the problem within their application. There are currently several solutions to the NAT problem; however, all of them either rely on a server to act as a relay, servers to act as data providers or a NAT behavior that may or may not be present. Therefore, it is necessary to develop a system by which hosts within two different private networks using NAT to connect to the Internet can communicate with each other in a Peer-to-Peer fashion without the assistance of a server. In order to develop and evaluate a decentralized solution to the NAT problem it is necessary to first select a traditional solution to build upon. The traditional solution was one of the first proposed and easiest to implement. It provides simplicity as it is based on UDP as a method of communication and not TCP (See Appendix C for a discussion of UDP and TCP). This solution is called UDP Hole Punching and is explained in Section However, as the name implies UDP Hole Punching uses the most basic functions of a NAT device, the need to allow for a server to respond to a request through itself, in order to facilitate Peer-to-Peer communication. This method of NAT traversal only impacts the time it takes to connect to peers directly. As with all network hardware, the processing of the NAT devices itself does cause an impact; however, the impact caused by NAT devices will not be examined in this paper. Surprisingly, there has been no research examining the impact of UDP Hole Punching. Given that it is the only solution for UDP communication to traverse a NAT, it is necessary to show that it does, in fact, cause an impact on the time to connect two peers when compared to a publicly

11 4 routable network. One goal of this research is to document the time needed to establish connections with UDP Hole Punching. An improvement to UDP Hole Punching is proposed in Section 3 of this thesis, called Decentralized UDP Hole Punching, which will eliminate the requirement for a server. We anticipate that this new system will cause an increase in the metric of time to connect which is also discussed later in the paper. The benefit of decentralized UDP Hole Punching is not the fact that time to connect is reduced, but rather that there is no need for a server and therefore is a true Peer-to-Peer system. The benefit of a serverless system is that the system no longer has a single point of failure. Also, as the number of computers in the network grows the demand on the server increases. By removing the server the probability of the server bottleneck is reduced. The results of these two benefits are that the system becomes more redundant and therefore more robust. This research will investigate two cases related to UDP based solutions to the NAT problem: 1. A network that contains only peers who use NAT devices to connect to the Internet has a higher time to connect then that of a network where all peers are publicly routable, assuming that all peers are using the same application that uses UDP Hole Punching as a NAT traversal method 2. A network that contains only peers who use NAT devices to connect to the Internet and who use Decentralized UDP Hole Punching will have a higher time to connect then an identical network that has peers who use Traditional UDP Hole Punching In order to research these two cases, it is necessary to implement a system by which the same set of physical computers with no changes to the physical network can simulate a computer using a NAT device to connect to the larger network and one that connects directly(publicly routable). By use of such a system traditional and decentralized UDP Hole Punching can be examined.

12 5 VirtualBox, discussed later in section 4.1, is the method by which we simulate NAT behavior. Furthermore, a custom application, discussed in section 4.2, is developed allowing for an operator to queue experiments involving different types of networks of a given size. This application will collect data from each peer involved in the experiment and store the data in a database for easy retrieval and analysis. 2 Literature Review 2.1 Network Address Translation Classifications Network Address Translation is the process by which IP addresses are translated from/to a public IP and port from/to a private IP and port. The way in which this translation is accomplished dictates how we classify NATs. There are currently two methods of classification. The first was defined by RFC 3489 (5) in March The other, which is intended to replace the classification provided by RFC 3489 (5), was defined in RFC 4787 (6) in January Many researchers still use the RFC 3489 (5); however, the methods outlined in RFC 4787 (6) provide a much more robust method for classification RFC Simple Traversal of User Datagram Protocol through Network Address Translators (STUN) RFC 3489 defined the first STUN. This RFC is now obsolete and was replaced by RFC 5389 (7). The intent of RFC 3489 and RFC 5389 (7) is not to define a method for classifying NATs but rather a method for traversing them. However, RFC 3489 (5) needed to create a classification to illustrate the circumstances under which STUN could work. STUN will be discussed in the NAT Traversal Methods Section. The classification is rather simple. There are four NAT Variations: Full Cone, Restricted Cone, Port Restricted Cone, and Symmetric (5). If a NAT device maps all requests from the same internal IP and port to the same external IP and port, as well as, allowing any external host to

13 6 send requests to the internal host by sending the request to the external mapped address, it is called a Full Cone NAT. A Restricted Cone is the same as a Full Cone NAT except that a Restricted Cone will only allow an external host to send a request to the internal host if the internal host had previously sent a packet to the IP address of the external host. Port Restricted Cone is the same as Restricted Cone NAT, with the further limitation that an internal host may only receive packets from an external host who is sending packets from a source IP address and Port if the internal host had sent a packet to that IP address and port previously. The final variant of NAT is Symmetric NAT. Symmetric NATs are the most difficult for developers to deal with. A Symmetric NAT will create a unique mapping for any request sent from a given internal host to a given external host. Therefore, if the same host uses the same IP address and Port but sends a packet to two different external hosts, two different mappings are created. Furthermore, an external host may only send back a UDP/TCP packet to the internal host using the same external IP address and port. Full-cone NAT, also known as one-to-one NAT 1) Request Server 1 NAT Client 2) Server 2 can now Server 2

14 7 (Address) restricted cone NAT NAT Server 1 Client Server 2 Port-restricted cone NAT NAT Server 1 Client Server 2 Symmetric NAT NAT Server 1 Client Server 2 Figure 2 RFC 3489 Classification Diagrams RFC Network Address Translation Behavioral Requirements In January 2007 it became apparent that the classifications outlined by RFC 3489 were no longer adequate to classify NAT devices and their behaviors; therefore, RFC 4787 (6) was created to provide a detailed list of behaviors that a NAT devices could exhibit and recommend which behaviors a NAT device should exhibit. It should be noted that RFC 4787 s recommendations are only recommendations and therefore a NAT traversal solution should handle as many behaviors as possible.

15 8 RFC 4787 defines NAT devices based on a set of behaviors. A NAT can be classified based on its: network address and port translation (mapping) filtering of incoming packets hairpinning support for application level gateways deterministic properties how the NAT handles ICMP destination unreachable messages fragmentation of outgoing packets and receiving of fragmented packets Network Address and Port Translation Behavior The network address and port translation behavior is the behavior that determines how the NAT device assigns external IP address and ports when an internal host attempts to send a packet to an external host. This behavior is by far the most complex and therefore is broken down into the following 4 sub-behaviors: Address and Port Mapping Port Assignment Mapping Refresh Conflicting Internal and External IP Address Spaces Address and Port Mapping There are three possible behaviors that a NAT device can exhibit when it comes to address and port mapping. First, endpoint-independent mapping is when a NAT device reuses the port mapping for all packets sent to any external IP address or port given that it is sent from the same internal IP address and port. The second type of mapping is address-dependent mapping where the device reuses mappings for packets sent to a given external IP address given that the packet is sent from the same internal IP address and port. The last mapping type is address and port-dependent mapping. In this mapping method the NAT device will reuse the mapping for packets sent to the same external IP address and port given that the packet was sent from the same internal IP address and port. In order to avoid the use of relays, the device endpointindependent mapping must be used.

16 9 The RFC also makes note that some NAT devices can have multiple external IP address. In this situation there are two possible behaviors. The first is to randomly assign an IP address when a mapping is created. If this is the case, the NAT device is said to have an arbitrary IP address pooling behavior. The other option is to use the same external IP address for all mappings associated with a given internal host. If this is the case, the NAT device is said to have a paired IP address pooling behavior. The NAT device needs to use paired IP address pooling. If this requirement is not met, applications that use multiple ports originating from the same internal host may fail to work because their external IP address may not be equivalent and therefore the external host may see the one host as two. This is a common problem if the application uses RTP or RTCP Port Assignment The next sub-behavior is Port Assignment. Port Assignment is broken down even further in the RFC to the following categories: Port Assignment Behavior Port Parity Port Contiguity Port Assignment deals with how the NAT assigns external ports. There are many ways of assigning external ports when a new mapping is made. However, they can be grouped into two basic categories. First is port preservation, where the NAT attempts to use the same internal port for the external port and if the external port is already assigned it uses a method to vary the port number. The other option is port overloading, where the external port is equal to the internal port regardless of conflict. For most traversal techniques to work port overloading must not be used and it is recommended that if the source port is in the range of , the external port assignment also be made in the same range. Also, it is recommended that if the

17 10 internal port number was in the range of 1024 to the external port be in that range as well. Port parity is the behavior of preserving UDP port parity. It is recommended that the NAT have this behavior as protocols such as RTP/RTCP require that the RTP port be even and RTCP use ports that are odd. This is recommended to avoid breaking RTP. The last method of port assignment is Port Continuity. This method attempts to assign sequential external ports for a given application. This is an unneeded and possibly wasteful method and should not be used Mapping Refresh The next behavior to discuss is mapping refresh. The behavior outlines how a NAT decides when to remove a mapping. All mappings will expire after a period of time where no packets are sent over the mapping. However, it is recommended that a mapping not be removed unless a packet has not been sent through the mapping in the past two or more minutes Conflicting Internal and External IP Address Spaces How a NAT handles conflicting internal and external IP address space is the next behavior of discussion. If an ISP deploys a NAT device it is possible that their customers will also deploy a NAT device. If this happens it is also possible that the ISP s private network will use the same address space as the customer. NAT devices should still function even if such a scenario occurs. RFC 4787 suggests several solutions Filtering Behavior Filtering, along with Network address and port translation are the two most important behaviors. Filtering dictates what packets will be translated from the public to the private

18 11 address space. There are several methods to decide if a given packet from an external host should be forwarded. First there is endpoint-independent filtering. This is the recommended filtering method. In endpoint-independent filtering any packet sent to a given external address and port will be forwarded to its internal address and port. Another type of filter is address-dependent filtering, where only packets from the external host which received the packet that created the mapping can send packets to that mapping. In other words, if internal host A sends a packet to external host B, a mapping is created. Host B can now send data from any port to host A by using the mapping that was created. The last type of filtering is address-port dependent filtering. As the name suggests it is similar to address-dependent filtering except the external host may only send packets from the port that the internal host sent the initial packet Other NAT Device Behaviors The other NAT device behaviors are simple and self-explanatory. The first is hairpinning. Hairpinning is the behavior in which a NAT will detect if two hosts are attempting to connect to each other and facilitate the communication with each other. This should hold true even if host A uses a mapping created by host B when host B is in the same private networks as host A. The next behavior is Application Level Gateways (ALG). ALGs allow various protocols to negotiate Peer-to-Peer sessions. However, there is no way for an application to detect the presence of an ALG, and if there is an ALG, it can prevent non behavioral dependent methods from working; therefore, ALGs should be disabled by default. Consistency and ICMP messages are two additional behaviors expressed by a NAT device. NAT devices should also be consistent in their operation. This consistency is the deterministic

19 12 property behavior of a NAT device. NAT devices should also forward ICMP destination unreachable messages. This behavior is known as the ICMP Destination Unreachable Behavior. The last two behaviors to discuss are how a NAT device should handle incoming and outgoing fragmented packets. A NAT device should respond according to RFC792 if an internal host sends a packet with the Do NOT Fragment (DF) (a flag in the IP packet header) set to 1. If the DF is set to 0 the NAT device should fragment the packet and send the fragments in order. When the NAT device receives a fragmented packet it must be able to forward fragmented packets to their destination regardless of the order received. 2.2 Known Solutions to the Network Address Translation Problem NAT device behavior has been well defined. An overview of the existing NAT solutions is provided as background for the NAT problem Connection Reversal Connection Reversal is the method used to connect two peers where only one is using a NAT device. This method assumes that both clients are connected to a rendezvous Server S. Let Client A be within private network A, and private network A use NAT device A to connect to the Internet. Server S is connected to the Internet and Client B is also connected to the Internet. If Client A wants to connect to Client B it can without assistance and as long as Client B uses the same IP address and port number to respond, two way communication can be established. However, if Client B wants to connect to A, Server S is needed. Client B and A are both engaged in two way communication with S. When B wants to connect to A, B informs S of this need and in turn S informs A of B s need to establish a connection. A then sends a message to B opening a mapping for B to reply. It is unclear who originally discovered this technique; however, this

20 13 description of the method is based on a description provided in Peer-to-Peer Communication Across Network Address Translators by Bryan Ford, Pyda Srisuresh and Dan Kegel (8). Figure 3 Connection Reversal UDP Hole Punching/STUN As discussed in the previous section UDP Hole Punching can also be called UDP punch through or STUN and refers to a method of traversing NAT devices allowing two NATed nodes to communicate with each other. Although, UDP Hole Punching is a very basic protocol, it was able to successfully traverse 82% of all NAT devices (8). This protocol has been developed further into the Session Traversal Utilities for NAT (STUN) (7). STUN is outlined in RFC 5389 and is described in the Literature Review section. STUN is more focused on the details for communication (formatting of packets, timeout ranges, etc.) and less on the traversal of the NAT.

21 14 The protocol provides a means by which two clients can establish a Peer-to-Peer UDP session given that a well-known rendezvous server is available. The rendezvous server is used to store information about each peer in the network. This data is mainly connection data. When a peer joins the network they check in with the server and send an initial packet. In this initial packet they include the IP address and port number which was used to send the packet. In some cases this data is encoded as some NAT devices will attempt to scan the entire packet for IP addresses and translate the addresses. The server then stores what the peer believed to be their connection IP and port with the IP and port that was reported by the UDP packet header. Assuming that peer A and peer B are both within different private networks using a NAT device to connect to the Internet, there is a Server S and peer A wants to connect to peer B the following steps must be taken to accomplish the desired communication: 1. Peer A requests Peer B s connection information from Server S 2. Server S responds with Peer B s public and private endpoints 3. Server S informs peer B that peer A is attempting to connect and informs peer B of peer A s public and private endpoints 4. Peer A sends a UDP packet to what S provided as B s public and private endpoints. A will use whatever endpoint receives a response from B first. 5. Peer B sends a UDP packet to what S provided as A s public and private endpoints. B will use whatever endpoint receives a response from A first. The order in which steps 2 and steps 3, as well as step 4 and 5 occur is not important as long as they happen asynchronously. This method works for peers behind a common NAT, even if that NAT does not support hair pinning, as their connection attempt using private addresses will succeed. This method also works for peers behind different NATs and peers behind multiple levels of NAT (8) (7).

22 15 Figure 4 Network before UDP Hole Punching (1) Request Connection to B (2) Forward B s Endpoint to A (2) Forward A s Endpoints to B Server Internet Private Network NAT NAT Private Network Client B Client A (3) A and B both send packets to each other, as long as these two packets are not sent at the exact same time one will reach the destination The client who receives the packet must re-transmit a packet to the other to confirm to the other that the hole was created Figure 5 UDP Hole Punching

23 16 Figure 6 After UDP Hole Punching TCP Hole Punching (NATBLASTER) TCP hole punching was originally called NATBLASTER and was first introduced in NATBLASTER: Establishing TCP Connections Between Hosts Behind NATs by Andrew Biggadike, Daniel Ferullo, Geoffrey Wilson, Adrian Perrig (9). In this paper they propose the six basic methods of executing TCP hole punching, each to deal with different types of NAT devices. The reason why there are six is that less work is needed, depending on what type of NAT devices are in use; therefore, they also provide a method by which to detect NAT behaviors. They classify NAT devices using two behaviors, port allocation and source routing availability, and as such provide the following cases: Case 1: <predictable, predictable, LSR> Case 2: <predictable, predictable, no LSR> Case 3: <random, predictable, LSR> Case 4: <random, predictable, no LSR> Case 5: <random, random, LSR> Case 6: <random, random, no LSR>

24 17 In the above list LSR stands for Loose Source Route which is an IP option that allows for the sender to specify a list of mandatory IP address to be used in the packet s route, and random refers to random port allocation by the router compared to predictable which is a predictable port allocation. However, the authors admit that LSR is not allowed by most modern day NAT devices. In each case a combination of rendezvous servers, low TTL and port allocation predictions and/or discovery in order to accomplish the goal of true Peer-to-Peer communication using TCP through one or more NAT devices NAT Port Mapping Protocol (NAT-PMP) NAT Port Mapping Protocol (NAT-PMP) (10)is an Internet Engineering Task Force Internet Draft. This proposed protocol allows for an application to automatically configure a NAT device to allow for temporary port forwarding to the internal host. The problem facing this protocol is that it requires manufacturers of NAT devices to support the protocol on their devices RFC Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) RFC 5766 (11) defines TURN or Traversal Using Relays Around NAT. This protocol was proposed as a fallback for systems that use STUN and defines the control messages and how packets are to be wrapped so that a well known relay server can relay packets between the two peers. TURN is considered a fall back only as it defeats the purpose of a Peer-to-Peer system by converting the Peer-to-Peer system into a client Server Solution. In the diagram below all data from the PC on the right is sent to the server, the server in turn forwards the data onto the PC on the left. This process is reversible allowing for two way communication.

25 18 Figure 7 Traversal using relays around NAT RFC IP Network Address Translator (NAT) Terminology and Considerations Although, RFC 2663 (12) outlines much more then Application-Level Gateways (ALG), ALGs are one solution to the NAT problem. ALGs allow for NAT devices to be configured by applications to allow for automated port and address translation. The problem with ALGs is that they require the user to enable them and not all NAT devices support them. Also, there is no widely accepted implementation of ALGs, so each individual vendor implements their own version. 3 Proposed Solution Decentralized UDP Hole Punching In a decentralized version of UDP Hole Punching the rendezvous server is replaced by a peer who has a public IP address. This peer continues to operate as a member of the network just like any other peer; however, it volunteers for extra duties. We will call these peers ppeers and they shall be any peer that has a publicly global routable IP address. It should be noted that this decentralized system requires at least one ppeer and it is recommended that any implementation of the system have a dedicated ppeer in the event that no true ppeers exist. In other words, as with UDP Hole Punching, a fall back is recommended. If the network loses all

26 19 ppeers, a traditional rendezvous Server Should be present to maintain the network until a ppeer joins the network. In this model a peer, Peer A, wants to join the overlay network. It must know of at least one peer who is already a member of the network. Peer A must also be able to establish a UDP session with the initial peer. Let us call this initial peer, Peer I. Peer A sends a UDP packet to Peer I containing what Peer A believes to be its IP address. Similar to Traditional UDP Hole Punching, Peer I uses this information to determine if Peer A is behind a NAT device. Peer I then announces the existence of Peer A to all peers in the overlay network by transmitting peer A s public and private endpoints. Now all peers know of Peer A and its public and private endpoints. Peer I now sends a list of peers to Peer A, who establishes connections to all ppeers in the network as any of them could act as rendezvous servers. If ppeer A wants to connect to NATed Peer B they are already connected and Peer A may do so without effort. If NATed peer A wants to connect to NATed peer B, peer A randomly chooses a ppeer to act as a rendezvous server and uses standard UDP Hole Punching. This method removes the bottle neck that is the rendezvous server. 4 Methods It is our intention to simulate a Peer-to-Peer network in order to investigate the timing issues involved with traditional UDP Hole Punching and our proposed decentralized version. 4.1 Simulation of a NAT Device A method by which an operator can easily change a computer from representing a NATed peer to a public peer needed to be discovered. One option is to acquire 32 routers (physical NAT

27 20 devices); however, this is neither practical nor cost effective. Therefore, virtualization technology was employed. Since a standard computer network interface card receives an IP by virtualization an additional operating system on top of the host you can control how that virtualized OS receives data from the host. This control includes, in many cases, network access. However, as with physical NAT devices not all software NAT implementations meet the requirements outlined in RFC 4787 (6), as discussed in section These requirements must be met or as discussed earlier UDP Hole Punching will not be able to traverse the NAT. In order to fulfill the requirements, VirtualBox was selected and tested. VirtualBox is a free operating system virtualization application that allows the user to configure what adapters the guest environment will be granted access to and how the guest will access those adapters (13). One such adapter is the network interface card. The two primary options are Bridged and NAT. With a bridged adapter, the guest OS s network adapter will receive an IP address similar to the host Operating System and will be exposed to the external network. VirtualBox also allows for NAT adapters which place a NAT between the host OS and guest OS. In order to determine the behaviors of this virtual NAT, we created a simple program that listened on a given port and when it received data would respond from a different port but to the same IP and port that it received data from. We did this to test filtering behavior as it is the primary problem facing UDP Punch Through. This connection failed and as such, it was determined that the NAT device was not using endpoint independent filtering or address dependent filtering (see section ). We then tried responding from the same port that we received data. This attempt succeeded and as such we determined that VirtualBox uses address-port dependent filtering.

28 21 The next step was to discover what Address and Port Mapping behavior VirtualBox s virtual NAT would exhibit. To do this we sent a packet from the NATed guest OS to two different physical machines (Windows 7 and Ubuntu 10.04). Using Wireshark we discovered that VirtualBox s virtual NAT does follow the recommendation for address/port mapping of RFC 4787 (6) and does use end-point independent mapping (as discussed in section ). Therefore, it is safe to say that based on observed behavior, VirtualBox s virtual NATed network adapter will allow us to simulate a NAT device with the needed behaviors. Given the above discussion, it is apparent that VirtualBox has met all the requirements to facilitate single layer NAT traversal. It also represents a real world NAT as many enterprise NAT devices are servers implemented by an Internet service. These servers have two network interface cards (NIC) and handle the address translation via software. As with a server VirtualBox creates a secondary NIC on the host. Because of VirtualBox s ability to rapidly change the type of connection used and due to the fact that it meets the requirements outlined earlier in this section, it is a viable solution for simulating real world ideal conditions. 4.2 Metric for NATed connections A metric must be established to determine if the decentralized method adds a significant amount of time to the process of traversing NAT devices. This metric shall be the time it takes peer number n to send a UDP request to all other peers and receive a response. This metric shall be referred to as Time to Connect or TTC and was chosen because UDP Hole Punching only adds time to the establishment of a connection. 5 Procedure We will create a physical network using 25 computers connected through a network switch. One computer will act as a DHCP server (see Appendix C for a discussion on DHCP) and another will

29 22 act as a Control Server allowing the automation of the experiment. The role of the Control Server is described later in this paper. The remaining 23 computers will act as peers (NATed and public) and NAT handlers for the various experiments. An Experiment is defined by its configuration, number of publicly routable peers and number of non-publicly routable peers (NATed peers). All configurations will have P peers where 1<P<23. The network configurations are as follows: 1. Peer-to-Peer Communication with NO NAT All peers have publicly routable IP address and can freely connect to each other. This configuration shall act as a baseline for showing that traditional UDP Hole Punching adds time to TTC. 2. Traditional UDP Hole Punching There shall be n Peers behind NAT devices and M ppeers where n>0, M>0 and N+M=P for all values of P where 1<P<23. In this configuration ppeers will not participate as peers, they will only act as rendezvous servers. All peers will be given a list of peers including their public and private endpoints. This is done to avoid the need and time to conduct peer discovery which is outside the focus of the experiment. Once all connection information has been sent all peers will gather the TTC measurement using Traditional UDP Hole Punching. This configuration will result in a network of varying size that uses traditional UDP Hole Punching to traverse NAT devices. It shall be used in both comparisons to show that traditional UDP Hole Punching does add time to TTC and that traditional UDP Hole Punching is faster than the decentralized version. 3. Decentralized UDP Hole Punching This configuration shall be the same as Configuration Two. However, ppeers will act as peers and rendezvous servers. Also, the decentralized method of UDP Hole Punching will be used. This configuration will provide data on the TTC required for network that use Decentralized UDP Hole Punching. Data shall be collected for every configuration, of number of publicly routable peers and number of non-publicly routable peers (NATed peers) possible. It should be noted that for each experiment there were 25 batches with 25 runs per batch. Therefore each experiment generated 625 data points. For each batch the Control Server would randomly choose the peers that were to participate in the test. This set was used for 25 runs. This prevents biases due to differences in the machine even though every virtual machine is identical with the exception of the network interface.

30 Experiment Systems The 23 Dell OptiPlex computers are using the latest version of OpenSuse including all updates. OpenSuse is based on the Linux kernel. These computers have also had VirtualBox installed. Using VirtualBox, a virtual machine was created using the latest version of Ubuntu, also including all security patches. Ubuntu is based on the Debian GNU/Linux distribution. The virtual machine allows us control over the network interface as discussed earlier. The Ubuntu VM is running Python 2.6, as such, this is the version of Python that we utilized in order to conduct our data collection. Attempts were made to use Windows XP instead of Ubuntu; however, the windows version of Python does not provide the same resolution of benchmarks as the Linux version (see Python 2.6 documentation). Also, when using Windows as the guest operating system the experiments would take noticeably longer to complete. Although, using Ubuntu may not represent the majority of consumers who use NAT devices it does provide a significantly better measurement of TTC. 5.2 Data Collection Process Once all 25 computers were running, we started the Ubuntu VMs with bridged network adapters (publicly routable) and ran 22 experiments in Configuration One. Please note that Configuration One does not allow for non public peers. The next step was to convert one public peer into a NATed peer and run a series of experiments in Configuration Three as Configuration Two requires at least two NATed peers. Each experiment in the series had a different number of public peers involved. We then converted another public peer into a NATed peer and ran another series of experiments using Configuration Three. Again each experiment in this series had a different number of public peers. Then we performed the same experiment for Configuration Two before converting yet another public peer. Public peers were converted and experiments were run until all data was collected.

31 Role of the Control Server The Control Server communicates using TCP with every peer registered. After every experiment run every peer will send its calculated TTC back to the Control Server for storage in a SQLite database (see below for schema and the enclosed DVD for file). The Control Server will also inform the experiment run team when experiments are completed and/or when more NATed computers are needed. 5.4 UDP Packet Loss Handling Despite this being an ideal network UDP still does not guarantee delivery. If a message is sent and no response is received within 1 minute that run is considered invalid and re-run. The peer reports this failure to the Control Server who informs all other nodes to cancel the run. Once all nodes confirm that the run has been canceled the Control Server will restart the run. 6 Analysis of Data In order to prove that the statement, The decentralized method of UDP Hole Punching will not add a significant amount of time to the TTC compared to the traditional method, is more likely than not true the following test statistics will be used: Number of peers the number of peers participating in the sample (independent) Number of NAT handlers the number of hosts acting as rendezvous servers (independent) Used NAT Handlers a Boolean value (1 or 0) if 1, the configuration required NAT Handlers to be used. Peers acted as NAT handlers a Boolean value (1 or 0) if 1 public peers also acted as rendezvous servers within the network configuration. In order to test the following null and alternative hypothesis we shall utilize linear regression and Analysis of Variance (Generic Linear Modal). Linear regression will allow us to create a predictive model that will show our independent variables, Number of Peers and Number of NAT Handlers are significant in predicating our dependent variable, TTC. Analysis of Variance

32 25 will show how TTC varies with a given dependent variable and also demonstrates the significance of the effect. We shall use the following null and alternative hypotheses for our analysis: Null Hypothesis One: Networks that have all NATed peers will not have a greater TTC regardless of the number of NAT handlers when compared to networks with the same number of peers where all peers were ppeers. Alternative Hypothesis One: Networks that have all NATed peers will have a greater TTC regardless of the number of NAT handlers when compared to networks with the same number of peers where all peers were ppeers. Null Hypothesis Two: Given that two networks have the same number of peers and the same number of NAT handlers they will have the same TTC regardless of the value of peers acted as NAT handlers. Alternative Hypothesis Two: Given that two networks have the same number of peers and the same number of NAT handlers, the network that uses a value of 1 for peers acted as NAT handlers will have a larger TTC then one that has a value of Analysis of Hypothesis One 1 We extracted data from the SQLite file created by the Control Server where experiment configuration was 1 or 2. We also converted experiment descriptors into their related test statistics. Therefore, in the case of configuration: 1. Number of peers equals the number of public peers, Number of NAT handlers is always 0, Used NAT Handlers was zero and Peers acted as NAT handlers was disregarded. 2. Number of peers equals the number of NATed peers, Number of NAT handlers is the number of public peers, Used NAT Handlers was one and Peers acted as NAT handlers was disregarded. Using our collected data, a regression model was created. A regression model is the result of regression analysis which allows for the analysis of several variables and the relationship between a dependent variable and one or more independent variables. In this case we will use it to calculate a formula for predicting future outcomes and prove that our independent variables are significant in predicting our dependent variable. Similar to other statistical analysis 1 The raw data used can be found in the CSV file located on the DVD included.

33 26 methods regression cannot explain all the data provided; however, the goal is to explain as much data as possible with the model. The percentage of data represented is called the R squared value and is discussed below. In order to achieve a better R squared result and a better explanation of the data the response of the natural log of Time to Connect (log will be used as the dependent variable, and the predictors of Used NAT Handlers (n) and number of peers (p) as the independent variables. log was chosen after several other variations resulted in lower R squared values. Using the stated response and predictors the following regression equation is calculated: log = n p Equation 1 Regression equation for Hypothesis One This regression has an R-squared value of 85.5%. It also shows that the probability of observing any of the test statistics of this magnitude (or larger) if indeed the parameter is 0 is 0%. Therefore, we can reject the Null Hypothesis One and accept Alternative Hypothesis One. We have now shown that UDP Hole Punching does cause a significant impact on time to connect. However, is this impact positive or negative? To show this we will use Analysis of Variance. An Analysis of Variance is a collection of statistical models. In this paper, it will be used to refer to a general linear model. Analysis of Variance is a method by which the observed variance of a variable is partitioned into components based on other variables (often referred to as the source of variance). Unlike regression analysis, variance does not provide a model of prediction; however, it does provide a better explanation of how and why a variable varies based on others. Furthermore, the general linear model, which is used in a variety of statistical models, is a statistical linear model that can be written as Y = XB+U where Y is a matrix with series of multivariable measurements, X is a matrix of explanatory variables, B is a matrix containing

34 27 parameters that are to be estimated, and U is a matrix containing errors of noise. In other words it is a form that is used to develop our specific model. First, looking at the Main Effects Plot below, it is apparent that the use of NAT Handlers (Configuration Two) does cause the TTC to increase. However, to prove that this increase is significant we utilized an Analysis of Variance General Linear Model where our responses are the LN of TTC and the model is based on using NAT handlers. The model uses both test statistics in order to achieve a better fit. The R-Squared value for the model is 86.30%, which is acceptable. The Analysis of Variance shows that it is very likely that the difference is significant (P-Value of 0.00) for both using NAT handlers and peers. Figure 8 Main Effects Plot for LN(TTC) - using NAT Handlers 6.2 Analysis of Hypothesis Two For this test we use all data from Configuration Two and Configuration Three. The test statistics used are peers, NAT Handlers, and using Decentralized Hole Punching. The response used is

35 28 TTC. In Configuration Two the number of peers will be the number of non-publicly routable computers, the number of NAT Handlers will be the number of publicly routable computers and using Decentralized Hole Punching will always be 0. In Configuration Three the number of peers will be the number of computers involved in the experiment, the number of NAT Handlers will be the number of publicly routable computers and using Decentralized Hole Punching will always be 1. See below for a scatter plot of the data showing the natural log of TTC verses the number of peers grouped by using Decentralized UDP Hole Punching as well as number of NAT handlers. Also a graph showing the group just by using Decentralized UDP Hole Punching follows. Figure 9 Scatter plot of LN(TTC) vs. number of peers grouped by using Decentralized Hole Punching

36 29 Figure 10 Scatter Plot of LN(TTC) vs. Number of peers by number of NAT handlers and using decentralized hole punching Using this model the following regression equation can be derived: log = using Decentralized Hole Punching Equation 2 Regression equation for Hypothesis Two The regression also indicates that the probability of observing any of the test statistics of this magnitude (or larger) if indeed the parameter is 0 is 0%. This, given an R-squared value of 91.9%, gives enough evidence to reject the null hypothesis. In other words, the data indicates that the use of Decentralized Hole Punching does significantly change the time to connect metric. However, how it changes must also be determined. The change is shown in the Main Effect Plot for the natural log of TTC (Figure 11). For this graph the model indicates that the use of the Decentralized Hole Punching causes an increase in the time to connect metric. To determine

37 30 the significance of this increase an Analysis of Variance using the General Linear Model is conducted. Figure 11 Main Effects Plot for LN(TTC) - using Decentralized Hole Punching This Analysis of Variance indicates that the increase is significant (p-value = 0.00). The model used was the same as the one used for the regression. This model also had an R-squared value of 95.04%. 7 Conclusion and Future Works Despite the fact that using Decentralized Hole Punching does cause an increase in TTC, a system may still utilize it as a valid solution using this technique that may reduce the number of dedicated servers the Peer-to-Peer service provider needs to provide in order to allow users to connect to each other. However, there are several improvements to the experiment and implementations of the solutions that could lead to different results. The first limitation of this experiment is the limited number of computers. Although, the regression indicates that the behavior is consistent,

38 31 different behaviors may emerge with larger networks that were not seen within our limited sample size. Furthermore, the outcomes discussed in this paper resulted from a substantially parallelized implementation. Despite this parallelization each virtual machine was only allocated one CPU. As multi-core systems become more prevalent, further investigation is needed to see if the behaviors of these systems change with built-in parallel capability. Another possible improvement is that in the implementations a random number generator was used to select NAT handlers. Improvements may be made by including different load balancing algorithms. The introduction of load balancing may alleviate bottle necks created by random selection. There are also several areas that still require investigation. Here we examined the behavior when one or both peers were behind one layer of NAT. Yet, in many cases the ISP as well as the user implements NAT devices. This potentially yields multiple layers of NAT which is a situation not examined in this paper. There are several solutions to the NAT traversal problem presented in this paper. Yet, there are many other possible solutions including those using TCP as a transport method and improvements to existing implementations that could be examined. Also, it may be necessary to use other metrics besides TTC in order to adequately compare these solutions. The final area of inquiry is the number of NAT handlers needed for a given size of network. A pattern was noted during the analysis of data that indicates there may be a method by which system administrators can discover the number of NAT handlers that are needed for the size of network they wish to support.

39 32 Despite the limits of the implementation and the future areas of inquiry, both UDP Hole Punching and Decentralized UDP Hole Punching are both viable solutions to the NAT problem. They both have limitations and benefits to use; it is up to each developer to determine which solution will work best for their application.

40 33 8 Works Cited 1. Leiner, Barry M., et al. A Brief History of the Internet. Internt Society. [Online] [Cited: Febuary 4, 2010.] 2. Information Sciences Institute University of Southern California. RFC 791. Internet Engineering Task Force. [Online] September [Cited: May 05, 2010.] 3. Rekhter, Y., et al. RFC Address Allocation for Private Internets. Internet Engineering Task Force. [Online] Feb [Cited: May 5, 2010.] 4. Egevang, K. and Francis, P. The Internet Engineering Task Force (IETF). RFC The IP Network Address Translator (NAT). [Online] May Rosenberg, J., et al. RFC STUN - Simple Traversal of User Datagram Protocol (UDP). Internet Engineering Task Force. [Online] Internet Engineering Task Force, March [Cited: May 05, 2010.] 6. F. Audet, Ed. and Jennings, C. RFC Network Address Translation (NAT) Behavioral Requirements. Internet Engineering Task Force. [Online] Internet Engineering Task Force, January [Cited: May 5, 2010.] 7. Rosenberg, J., et al. RFC Session Traversal Utilities for NAT (STUN). The Internet Engineering Task Force. [Online] October [Cited: Nat 05, 2010.] 8. Peer-to-Peer Communication Across Network Address Translators. Ford, Bryan, Srisuresh, Pyda and Kegel, Dan USENIX 2005 Annual Technical Conference, General Track Proceedings. pp

41 34 9. NATBLASTER:Establishing TCP Connections Between Hosts Behind NATs. Biggadike, Andrew, et al. hangzhou, China : IEEE, Wireless, Mobile and Multimedia Networks, 2006 IET International Conference on. pp Cheshire, Stuart, et al. NAT Port Mapping Protocol (NAT-PMP). [Online] April 16, [Cited: November 14, 2010.] Mahy, R., Matthews, P. and Rosenberg, J. RFC Internet Engineering Task Force. [Online] April Srisuresh, P. and Holdrege, M. RFC IP Network Address Translator (NAT) Terminology and Considerations. Internet Engineering Task Force. [Online] August Orcale. VirtuaBox. VirtuaBox. [Online] [Cited: May 05, 2010.] An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol. Baset, Salman A. and Schulzrinne, Henning G th IEEE International Conference on Computer Communications.

42 35 9 Appendix A: Enclosed DVD contents All files used for this experiment are enclosed on the DVD at the end of this paper. The following directories contain the specified files: Directory Name Experiment Software Constance All Python 2.6 files needed to recreate the experiment. Python 2.6 is NOT included. Minitab15 Files NAT testing scripts the Minitab15 files used for data analysis All Python 2.6 files needed to test a NAT for different behaviors as described in the section Simulation of NAT device. RAW data The final res.db output from the Control Server

43 36 10 Appendix B: Experiment Application Configuration and execution instructions. There are two entry points into the application; however, the easiest way to run the client or server is to use run.sh and runserver.sh. The last line of run.sh will need to be edited to the following: sudo python TestNodeControler.py "$IP" <local port to run on> "<ip of Control Server>" <port of Control Server> The last line of runserver.sh will also need to sudo python ControlServer.py "$IP" <port that Control Server Should use> The system will notify you of problems and completed experiments by text message if you edit ControlServer.py line 119 to read: loginandsendmessage(<google voice account name>,<password in clear text>, [<list of phone number to send SMS to>],"queue Finished") Edit ControlServerBaseExperement.py in Line 23 in the same manner. RunServer.sh will start the Control Server while run.sh starts a node. Start the Control Server first, once it states that it is ready to accept peers, run run.sh on the other computers you wish to involve in the experiment. Once all computers are added, experiments can be added to the queue and execute experiment by using the following commands: Command queueexp1 eid ns nf t t2 sport fport Results Will add experiments of Configuration One(all public peers) to the queue

44 37 queueexp2 eid ns nf ms mf t t2 sport fport eid starting experiment id ns number of peers to start with nf max number of peers T number of batches to run t2- number of runs to run sport starting port fport end port Will add experiments of Configuration Two(traditional UDP Hole Punching) to the queue queueexp3 eid ns nf ms mf t t2 sport fport eid starting experiment id ns starting number of public nodes(nat handlers) to start with nf max number of public nodes(nat handlers) to start with ms starting number of peers(nated) mf ending number of peers(nated) T number of batches to run t2- number of runs to run sport starting port fport end port Will add experiments of Configuration Three(traditional UDP Hole Punching) to the queue getnumnodes eid starting experiment id ns starting number of public peers (NAT handlers) to start with nf max number of public peers (NAT handlers) to start with ms starting number of peers(nated) mf ending number of peers(nated) t number of batches to run t2- number of runs to run sport starting port fport end port Returns the number of nodes connected to the Control Server

45 38 exeexpqueue Executes all experiments in the queue A res.db file will be creating in the working directory with results.

46 39 11 Appendix C Glossary of Terms 11.1 UDP UDP or User Datagram Protocol is part of the IP Suite (TCP/IP). UDP is a transport protocol within the IP Suite that allows for a host to send a message (Datagram) to other hosts on an IP based network without any prior communication. Unlike TCP, UDP is connectionless and therefore does not guarantee delivery of Datagram TCP The Transmission Control Protocol is part of the IP Suite. TCP is a transport protocol within the IP Suite that allows for exchanging data directly between two networks. In particular, TCP provides reliable, ordered delivery of a stream of bytes from one computer to another computer. TCP is status and therefore can guarantee delivery of information. However, due to the overhead need to guarantee delivery it is slower than UDP DHCP The Dynamic Host Configuration Protocol is an auto configuration protocol using in IP based networks. The protocol allows computers connected to the network to discover their IP address and other needed information in order to connect to other clients Peer-to-Peer Peer-to-Peer or P2P is a distributed networking architecture where all Peers or computers within the network connect to each other to accomplish a given task. See below for an example of a P2P network, each black line represent a connection:

47 40 Figure 12 Example of a Peer-to-Peer network 11.5 Client/Server Client/Server is a networking architecture where clients all communicate with a server. If messages need to be sent to a client the server repeats the message. This is the traditional architecture using is such protocols as HTTP, FTP, DHCP, and DNS. See below for an example of a Client/Server network, each line represents a connection. Figure 13 Example of a Client/Server network