A Measurement of NAT & Firewall Characteristics in Peer to Peer Systems

Transcription

1 A Measurement of NAT & Firewall Characteristics in Peer to Peer Systems L. D Acunto, J.A. Pouwelse, and H.J. Sips Department of Computer Science Delft University of Technology, The Netherlands l.dacunto@tudelft.nl Keywords: P2P, NAT, firewall Abstract NATs and firewalls break the original model of IP end-to-end connectivity across the Internet, since their presence creates a new Internet architecture made of many private networks. This architecture, designed upon the client/server model, introduces complications in communication between hosts and has performance impacts, especially for P2P protocols, since hosts outside a private network are not able to initiate a connection to hosts inside that private network. In this paper we present a study of the current distribution and characteristics of the NATs and firewalls existing in the Internet, with respect to UDP communication. We believe that our study provides valuable insights for the development of P2P systems that intend to address the NAT/firewall issue effectively. 1 Introduction In the last years there has been a significant rise in the use and development of peer-to-peer (P2P) technology. Its scalability and robustness made this technology popular in a large spectrum of application domains, such as distributed file sharing [2, 3, 4], Internet telephony [5], live streaming and video on demand [15, 16]. A major obstacle encountered in P2P communication is the presence of Network Address Translators (NATs) and firewalls, because they can cause some peers not to be reachable at any globally routable IP address. Such devices are, in fact, becoming a default setting among home users, who often do not have the knowledge on how to configure them to allow P2P traffic. Nevertheless, many P2P algorithms do no take this into account in their design [14]. We believe that it is necessary for the P2P developers to be aware of the presence of NAT/firewall boxes, if they want to build effective systems. In the last decade, the Internet Engineering Task Force (IETF) has put some effort into investigating the impact of NATs and firewalls on Internet protocols and into promoting a set of requirements that those devices should meet in order to be P2P friendly [8, 11]. If NAT/firewall vendors comply with some standardized behaviour for their boxes, e.g. by following the advice in [11], it would then be possible to increase the performance of P2P applications and make them work also in hostile (NATted) environments. We believe that finding out how widespread NATs and firewalls in the Internet are, and if they (or how many of them) are P2P friendly, is a mandatory step for any solution aiming to address this problem. In order to do so, we have conducted an in-depth study of different NATs and firewalls existing in the Internet, by measuring our BitTorrent-based P2P system, Tribler [1]. In this paper we focus on the NAT/firewall behaviour with respect to UDP communication only and we do not investigate TCP at all. It has been shown that, since TCP is a stateful protocol, it is much more difficult to make it work through such devices [10]. To date, no elegant solution for P2P TCP-based communication through NATs/firewalls has been found. This paper is organized as follows. In Section 2 we give a brief description of how we characterize NAT/firewall devices as well as how their presence can be detected. In Section 3 we describe how the measurements were conducted and in Section 4 we show the results. Finally, in Section 5 we discuss related work and in Section 6 we present our conclusions. 2 NAT/firewall detection and characterization A Network Address Translator is a device that al-

2 lows multiple machines on a private network to communicate with the Internet using a single globally unique IP address [7, 13]. This is accomplished by modifying the network information (IP address and port) in the packets that transit through it. The way a given internal pair <IP address, port> is translated to a given external pair <IP address, port> is called address mapping policy. Though initially created as a temporary solution for alleviating the Ipv4 address shortage, the NAT technology is still in use and it will probably continue to be part of the Internet in the future. A firewall is a device (or set of devices) which inspects network traffic passing through it, and filters (i.e. denies or permits) the transmission based on a set of rules. NATs and firewalls break the end-to-end connectivity principle of the Internet, since they prevent the hosts they are protecting from receiving connections initiated from external hosts. This architecture is very suitable for client/server communication, in the typical case when the client is inside the private network and the server is outside and has a public address, but it is not suitable for P2P communication. To make things even more difficult, there is no standardized NAT/firewall behaviour. However, a classification of different kinds of NATs can be made according to a combination of address mapping policy and filtering behaviour for UDP traffic [13]: Full Cone NAT and port are mapped to the same external IP address and port. Furthermore, any external host can send a packet to the internal host, by sending a packet to the mapped external address. Restricted Cone NAT and port are mapped to the same external IP address and port. Unlike a Full Cone NAT, an external host (with IP address A) can send a packet to the internal host only if the internal host had previously sent a packet to IP address A. Port restricted cone NAT This behaves like a Restricted Cone NAT, but the restriction includes port numbers. Specifically, an external host can send a packet, with source IP address A and source port P, to the internal host only if the internal host had previously sent a packet to IP address A and port P. Symmetric NAT and port, to a specific destination IP address and port, are mapped to the same external IP address and port. If the same host sends a packet with the same source address and port, but to a different destination, a different mapping is used. Furthermore, only the external host that receives a packet can send a UDP packet back to the internal host. Since the address mapping policy for Symmetric NAT is endpoint dependent, it is very difficult to predict which external port will be used for which destination. This behaviour represents a big threat to P2P communication without adding any security benefit and is therefore strongly discouraged by the IETF [11]. In order to discover and classify the NAT/firewall devices, we used the Session Traversal Utilities for NATs (STUN) [13]. STUN is a lightweight protocol that allows applications to discover the presence and types of NATs and firewalls between them and the public Internet. In the case of a NAT, it also provides the ability for applications to determine the IP addresses allocated to them by the device. The protocol requires the assistance of some network servers (STUN servers) located on the public Internet. 3 Measurements Strategy Our study of the NATs and firewalls characteristics is based on measurements conducted on our P2P system, Tribler [1]. We have set up a number of central entities (servers and special superpeers) which, by interacting with the peers in the system, are able to gather the measurement data we need. This architecture is shown in Figure 1. A superpeer can periodically request a peer its network configuration (step 1 in Figure 1). The receipt of such a request activates the peer s NAT-check functionality. This functionality basically permits the peer to perform (step 2) a simple check of the NAT/firewall type (according to the classification in Section 2) and (step 3) of the duration of a given mapping in the NAT/firewall when not used for a while (i.e. after how long a mapping in a NAT/firewall expires if there is no communication going through). We call this value the NAT timeout. The NAT type check is done by using a simplified version of the STUN protocol and requires the assistance of some STUN servers, while the timeout check requires the assistance of a so-called timeout server. Finally, once all the data has been collected, the peer sends it back to the superpeer which made the request (step 4). 4 Results and Analysis In this section we present the results we obtained from our measurements in the period between 27/10/2008 and 25/11/2008, during which we collected data from a total of about 3500 unique peers.

3 Country USA NL ES UK IT CA FR DE Weight Open Internet Full Cone NAT Restricted Cone NAT Port Restricted Cone NAT Symmetric Cone NAT UDP Blocked Table 1: Distribution of peers connection type per country (percentage) STUN servers Finally, the results show that only a small percentage of peers is behind boxes that provide only firewall characteristics. Most of them either do not have any box installed or are located behind NAT boxes, which combine address translation and firewall filtering. 2: get NAT type 1: NAT check request Superpeer Log 4: NAT check reply Peer 3: get NAT timeout Figure 2: Distribution of peers connection type Timeout server Figure 1: Collecting measurement data The measurement results have been divided into three categories: connection type, geographical distribution and timeout. 4.1 Connection type The distribution of peers connection type is shown in Figure 2. We can observe that almost 90% of the peers is behind a NAT or a firewall. The Port Restricted Cone NAT appears to be the most popular (40%). Full Cone NATs is much less in use (12.5%) and the Restricted Cone NAT is almost absent (5%). There is also a consistent percentage of users (about 30%) behind a P2P unfriendly NAT (16% Symmetric NAT and 14% UDP Blocked). 4.2 Geographical distribution In order to analyze our results further, we used the publicly available database provided by MaxMind s GeoIP [6] to geo-locate the Tribler users involved in our measurements. By doing so, it is possible to compare different locations according to their weight (i.e. the percentage of users located in a given country over the total) and the connection characteristics of their users. Most of the results come from peers located in Europe or in North America. Table 1 shows the connection type distribution per country. The countries are listed according to their descending weight. Even if each country has a specific connection distribution, we can notice that the general trend is similar. For instance, the peers directly connected to the Internet are a minority (10-20%) and the Port Restricted Cone NAT appears to be the most popular everywhere (reaching peaks of 60% in France and Ger-

4 many), while the Restricted Cone NAT is quite uncommon (often below 10%). 4.3 Timeout We also measured the NAT timeout. This information is especially useful for tuning the frequency of keep-alive packets in NAT traversal techniques. Results are shown in Figure 3. We can observe that in most of the cases (62%) the timeout value is between 2min and 2.5min. Less than 10% is below 1min and around 25% is between 1 and 2 min. Finally, only a very small percentage (around 5%) of NATs have a timeout greater than 2.5min. This data shows that many NATs/firewalls are still not perfectly compliant with what is suggested by RFC 4787 [11] which recommends a timeout value of 5 min and requires it to be no less than 2 min (so to avoid too many keep-alive packets). All these findings suggest that there is no decrease of the employment of NAT/firewall boxes in the Internet. 6 Conclusions and Future Work In this paper we have shown that the number of NATted peers is very high and apparently increasing, affecting many countries to a similar extent. Moreover, we have analyzed the characteristics of the NATs/firewalls present in the Internet and found out that a consistent percentage of them has an unfriendly behaviour towards P2P communication. To the best of our knowledge, this is the first comprehensive study of the connection characteristics of P2P users with the specific purpose of checking whether, and to which extent, they cause problems to P2P protocols. We believe that our findings can be employed to design an effective mechanism for NAT traversal. For example, in the case of P2P friendly NATs and firewalls, it would be possible to employ the UDP hole punching mechanism [9] and tailor it on the specific characteristics of the peers NATs involved (i.e. type and timeout). Less efficient methods, like relaying [9], would then be needed only when there is no alternative (i.e. in the case of P2P unfriendly NATs and firewalls). References [1] Tribler, Figure 3: Frequency distribution of NAT timeout for UDP 5 Related work A 2007 study conducted by Xie et al. [15] on the CoolStreaming video streaming system found that 89% of its users are behind a NAT or a firewall. Their measurements are also in line with our observation that the firewalls are only a small percentage compared to NATs. However, they did not make any categorization of the NATs they encountered. Another recent study about a deployed P2P streaming system, PPLive [16], also found that the percentage of peers behind NATs is high (80%). However, they show no correlation between their statistics and the geographical location of the peers nor looked at the NAT timeout. Finally in [14] the authors measured (from data gathered between 2005 and 2008) that, in the average swarm of a public BitTorrent community, two third of the peers are firewalled. [2] Bit Torrent, [3] Lime Wire, [4] Kazaa, [5] Skype, [6] GeoIP, [7] P. Srisuresh and M. Holdrege, RFC IP Network Address Translator (NAT) Terminology and Considerations, August [8] M. Holdrege and P. Srisuresh, RFC Protocol Complications with the IP Network Address Translator, January [9] B. Ford, P. Srisuresh, D. Kegel, Peer-to-peer Communication Across Network Address Translators, in Proceedings of USENIX, [10] S. Guha and P. Francis, Characterization and Measurement of TCP Traversal through NATs and Firewalls, in Proceedings of the 2005 Internet Measurement Conference (IMC05), October 2005.

5 [11] F. Audet and C. Jennings, RFC Network Address Translation (NAT) Behavioral Requirements for Unicast UDP, January [12] C. Jennings, NAT Classification Test results, Internet-Draft, July [13] J. Rosenberg, R. Mahy, P. Matthews, D. Wing, RFC Session Traversal Utilities for NAT (STUN), October [14] J.J.D. Mol, J.A. Pouwelse, D.H.J. Epema, H.J. Sips, Free-riding, Fairness, and Firewalls in P2P File-Sharing, 8-th IEEE International Conference on Peer-to-Peer Computing, [15] S. Xie, G. Y. Keung, and B. Li, A Measurement of a Large-Scale Peer-to-Peer Live Video Streaming System, In Proceedings of the IEEE International Conference on Parallel Processing Workshops, [16] Yan Huang, Tom Z. J. Fu, Dah-Ming Chiu, John C. S. Lui, Cheng Huang, Challenges, Design and Analysis of a Large-scale P2P-VoD System, In Proceedings of ACM SIGCOMM 08, October 2008.