NAT/FW traversal in P2P communication

Abstract: P2P (Peer-to-Peer) communication has developed rapidly and has a great impact. Like traditional communication, P2P communication is also restricted by the NAT/FW traversal problem. Therefore, it is very important to solve the NAT/FW traversal problem. Compared with traditional communication, NAT/FW traversal in P2P communication has many unique issues and many different technologies have been developed. This article first describes the general problems of NAT/FW traversal in P2P communication, then introduces some major technologies, and focuses on the representative direct communication traversal methods. The impact of NAT/FW types and behaviors on P2P traversal is also discussed. As an example, it describes the traversal mechanism adopted by Skype and JXTA.
Keywords: P2P NAT/FW traversing Skype JXTA
 
I. Introduction
P2P communication applications attract a large number of users on the Internet due to their many outstanding features and are developing very rapidly. In addition to common file and content sharing and distribution P2P applications such as Kazaa, BT, Napster, eDonkey/eMule, and Gnutella, P2P multimedia communication applications represented by Skype have become increasingly popular in recent years. Currently, Skype has 0.367 billion million users worldwide, and the number of users in China is also astonishing, reaching 15.5 million. This type of P2P communication, represented by Skype, is generally called a "Rendezvous" P2P application. This article focuses on "confluence" P2P communication.
Currently, P2P communication is mainly used on IP networks, which are divided by public networks and various private networks. NAT/FW serves as an address translation and network security device. Conventional communication, such as VoIP and Videoconferencing/videotelephony, are all restricted by NAT/FW. If you want to communicate between the public network and the private network or multiple different private networks, you must perform NAT/FW traversal. NAT/FW provides address translation, so that IP data streams can reach private/public addresses that cannot be routed without address translation, but it may affect the transport layer and application layer protocols. The so-called traversal is to overcome these effects so that communication can proceed normally. Currently, various application-layer protocols, such as H.323 and SIP, and transport-layer protocols, such as TCP and UDP, are presented with the corresponding traversal technology. For P2P communication, NAT/FW traversal must also be solved. In addition, the efficiency and advantage of P2P communication come from the fact that any Peer node can establish a connection with other Peer nodes, and the number of Peer nodes is extremely large; at the same time, the application layer protocol of P2P communication is more complex than traditional communication. Therefore, compared with traditional Client/Server Communication, the NAT/FW traversal problem of P2P communication is more complex and difficult.
Fortunately, after recent years of research, many NAT/FW traversal technologies have been developed for P2P communication. This article will introduce the main technologies.
II. General NAT/FW traversal problems in P2P communication
First of all, we should make it clear that there is no universal and omnipotent Traversal method. In general communication, this is especially true in P2P communication. Various factors will affect the success or failure of a specific traversal technology, and in any specific network scenario and the combination of NAT/FW types, it may be necessary to use a combination of multiple traversal methods to work. A typical example is Skype, which integrates multiple traversal policies and technologies and is used in different scenarios. To understand this, we first need to discuss some general issues of P2P communication. We introduce the typical network scenarios shown in Figure 1. This scenario involves almost all possible situations. The elements in the figure are briefly described as follows: Generally, "confluence" P2P systems all have a central registration Server (called Login Server in Skype ), all user nodes must first be registered with the registration server. The registration can achieve the following purposes: first, verify the legitimacy of a user node that requires to be added; in addition, the newly added node can "ad" itself online to other nodes in the Skype network and their friends nodes, and discover the online super nodes. Super nodes are actually elected from common nodes, it must have a public IP address and its machine has a larger memory, stronger processing capability, and sufficient bandwidth to connect to the network.
We should consider the following general questions:
1. Relationship between nodes of both parties and NAT/FW
Assume that the communication parties are P1 and P2, there are three possible reasons:
(1) If both P1 and P2 are on the public network, you do not need to consider NAT/FW traversal;
(2) P1 is on the private network, while P2 is on the public network, or vice versa;
(3) P1 and P2 are on their respective private networks;
In the above three cases, the NAT/FW traversal policy is different from the specific technology used.
2. Multi-layer NAT/FW
For an ISP, a user's enterprise network or home network can access an ISP's own network instead of directly accessing the public network. Compared with the Internet, this ISP network is a "larger" private network, and is equivalent to a public network compared with the Enterprise Network/home network connected to it. This solution ensures better management and security, while also saving public IP addresses. However, NAT/FW traversal adds more difficulties and complexity.
3. Impact of NAT/FW types on Traversal
The NAT/FW type has an impact on the traversal policy and specific technologies used. A more scientific classification of NAT/FW is based on its implementation of Address/port translation. According to the strict degree of restriction conditions, you can divide them into four types: Full cone, restricted cone, port restricted cone, and symmetric. The stricter the NAT/FW, the more restrictive the traversal, the most difficult currently to traverse is symmetric NAT/FW. From whether to remember all the previous communication statuses, NAT/FW can be divided into stateless NAT/FW and stateful NAT/FW. Stateful NAT/FW may cause some difficulties for the transfer layer or application layer protocol traversal that requires multiple handshakes during session establishment.
4. Transport Layer traversal and application layer Traversal
Transport Layer traversal mainly solves how to establish TCP or UDP connections through NAT/FW, so as to ensure that TCP or UPD data packets can be correctly sent and received between P1 and P2. Transfer Layer traversal is easier to find common technologies. The Transport Layer traversal only opens a channel for the application layer traversal. Because there are many protocols at the application layer and the behavior of each protocol is different, the traversal is very complicated and it is difficult to find common methods, especially in P2P communication. Therefore, for Application Layer traversal, the so-called ALG (Application Layer Gateway) is generally used, that is, the Application Layer Gateway, which provides different processing for different Application Layer protocols. Of course, there is also a way to "change the application layer to" Transport Layer traversal, that is, the tunneling technology-completely passing the data packets at the application layer through a certain "tunnel" such as UPD "tunnel" through NAT/FW, making the NAT/FW "invisible" application layer packets.
Iii. Main technologies
Currently, various P2P communication traversal technologies can be roughly divided into the following three types:
1. Relaying Method
If P1 and P2 are located on their respective private networks, that is, after their respective NAT/FW, the communication stream cannot directly reach the other party, and a relay entity S is required for forwarding. That is, P1 is sent to S and then forwarded to P2 by S, and vice versa. S, as a relay entity, can be a dedicated server for this purpose, or a super node or even a common node, usually on the public network. For P1 and P2, the address is reachable. Relay methods are frequently used and are rarely restricted. However, the major disadvantage is that the relay entity requires strong processing capabilities and a lot of resources, such as memory and network connection bandwidth. When there are many nodes in a P2P network, the Scalability is relatively poor when the relay method is used.
2. Connection Reversal Method
If one of P1 and P2 is on the public network and the other is on the private network, the general NAT/FW is called "outbound, that is, if P1 located after NAT/FW tries to establish a session connection with P2 located on the public network, NAT/FW allows it to establish a connection; however, if P2 tries to establish a connection with P1 first, it will not be allowed. So when P2 first needs to establish a connection with P1, P2 first sends the request to a cross-server S. S is on the public network, but in the registration phase, P1 has established a connection with S, so S can forward the request to P1, and P1 actively establishes a connection with P2 after receiving the request, NAT/FW allows connection establishment, so the traversal is successful. Its disadvantage is that the application has great limitations. If P1 and P2 are on various selfish websites, this method will not work.
3. Direct Communication Method
With the help of server S traversal, a direct communication connection is established between P1 and P2. P1 and P2 can be located on their respective private networks. Two common direct communication technologies are:
(1) Hole-punching Technology: with the help of server S, p1 and P2 get the private address/port of the other party and the Public Address/port translated by NAT/FW, and then use the information to establish a communication connection. For detailed principles, see section 4.
(2) "tunneling" technology: If a UDP or TCP connection has been established between P1 and P2 (for example, through "drilling holes, the application layer protocol and the media stream can both pass through the NAT/FW through a "Tunnel" established by the transport layer protocol, while the NAT/FW is "invisible" the application layer protocol and the media stream packets.
 
 
Iv. Drilling Method
This section describes the basic principles and work projects of the "drilling holes" method ." The drilling method is described in IETF RFC3027. For the sake of simplicity, we will introduce the "drilling" Process of UDP protocol traversal. The TCP protocol process is similar, but it is a little complicated and may be affected by some factors such as the Implementation Details of the TCP protocol stack software. Therefore, we will not discuss it here. Figure 3 shows the most complex scenario: P1 and P2 are located on each selfish network, each with its own NAT/FW, And the NAT/FW deployed by the ISP exists, this is a typical multi-layer NAT/FW situation. NA and NB indicate the NAT/FW of P1 and P2 respectively, and NC indicates the NAT/FW of ISP. In this case, for P1 and P2, there are three different IP addresses and ports. See table 1.
 
Table 1 three different IP addresses/ports of P1 and P2
IP address/port \ node P1, P2 P1 P2
Private Network Address/port 10.0.0.1: 4321 10.1.1.3: 4321
ISP private network address/port 10.0.1.1: 4500 10.0.1.2: 5500
Public Network Address/port 155.99.25.11: 6200 155.99.25.11: 6205

The ISP private network address has been mentioned earlier. For the enterprise network/home network, it has the public network attribute. For the real public network, it also has the private network attribute, therefore, it is a "semi-public network" address. The "half-Public Network" addresses/ports of P1 and P2 are allocated by their respective NAT/FW, I .e., NA and NB. The public IP address is allocated by the NC. Before communication between P1 and P2, you have established a connection with S through the server (such as registration. S. Through this connection, we have obtained their own private network address/port from the IP packets from P1 and P2, in addition, the corresponding public IP Address/port is obtained from the registration information of P1 and P2. If P1 wants to establish a connection with P2, it cannot know the P2 address/port information. It sends the request to S, and S forwards the request to P2 after receiving the request, append the Public Address/port and private address/port of P1, send a reply message to P1, and append the Public Address/port and private address/port of P2. After receiving the two messages, P1 and P2 respectively send UDP packets to the public IP Address/port of the other party. For NA, it converts the address/port of the packet from P1 to the "half public network" Address/port 10.0.1.1: 4500. When the packet arrives at the NC, the NC identifies the destination public network address 155.99.25.11 as a public network address that it has allocated, therefore, it is determined that the node corresponding to the target public IP address is on the private network under its jurisdiction. At the same time, the NC can determine that the target node is on the private network under the NB jurisdiction based on the target port 6205. Therefore, NC will not send packets from P1 to the public network, but "loopback" (loopback) to the private network, and replace the address and port at the same time, replace the source address/port of the packet with 155.99.25.11: 6200, And the destination address/port with the "half-Public Network" Address/port 10.0.1.2: 5500 of P2. After receiving the packet, NB can send the packet to P2 Based on the destination address/port. Likewise, messages from P2 finally reach P1 through NC and NA through a similar process. The NC must be required to support this recognition of the target address/port in its own jurisdiction over the private network and "loop back" the packets, this is technically called Hairpin in NAT/FW ). With the popularization and use of the "Drilling Hole" technology, the market has seen an increasing number of NAT/FW products that support the "Legal card" feature.
The idea of "drilling holes" is as follows: when the first packet from P1 first reaches NA, NA records the destination address/port 155.99.25.11: 6205. When the P2 packet from NC "loop back" arrives at NA, NA finds that its source address/port is 155.99.25.11: 6205, which is recorded and therefore allowed to pass, the first packet equivalent to P1 first opens a hole in na to let packets from P2 pass. Likewise, packets from P2 are first "drilled in" on NB to allow packets from P1 to pass through. If P1 and P2 start to send packets to the other party after receiving the S message, there is no guarantee that the hole already exists when the packet arrives at the NAT/FW of the other party. If the hole does not have an opening packet, it will be discarded and needs to be tried multiple times. In addition, Sequential hole-punching can also be used. This method is especially applicable to the TCP protocol. If a UDP session does not pass the packet after a certain period of time, it will be terminated by NAT/FW. This "time" is determined by the NAT/FW timer and there is no standard value. Therefore, P2P applications need to periodically send the keep-alive packet to NAT/FW to keep the UDP "hole" alive.
 
It should be noted that, although from the name, it is easy for people to think of security threats, but in fact, the "drill holes" method is safe. Therefore, it is safe to implement NAT/FW traversal based on "drilling holes. Because the "drilling holes" method allows P2P applications to work normally within the maximum range of NAT/FW default security policies, on the path of P2P data packet transmission, it is acceptable to properly instruct each NAT/FW that the session is "invited. Obviously, "drilling holes" completely adopt the practice permitted in security policies. Unlike some NAT/FW traversal technologies, they need to be implemented by forging packets and other means with certain security risks. The direct communication NAT/FW Traversal method based on "drilling holes" has technical advantages in the supervision and control of P2P communication by operators, so it is easily accepted by operators.
V. Introduction to the NAT/FW traversal mechanism of Skype
Skype's ability to traverse various NAT/FW has been fully tested and praised by the industry. At the same time, because its technology is private, the outside world cannot understand the details. However, in the past few years, some academic research institutions have used Skype as a "black box" to study its NAT/FW traversal behavior, many technical enthusiasts also discuss this on their blogs. Recently, some theoretical descriptions have been provided in the technical White Paper of Skype, and the results are similar to external analysis. This section briefly introduces the principle of the traversal mechanism based on these materials.
 
Skype actually uses a variety of NAT/FW traversal technologies. The analysis is as follows:
 
(1) The Private variant STUN Protocol detects NAT/FW behavior. Skype's superior traversal capabilities come from "know yourself and know yourself" first. Therefore, it is necessary to accurately detect and predict the types and behaviors of NAT/FW. The IETF's STUN Protocol is a good tool for testing. Skype's detection mechanism is very similar to STUN, but it may be more powerful and has better performance. Therefore, it is a private variant of STUN.
(2) relay technology. As mentioned above, if the entity of a relay is one or a few central servers, its Scalability is very poor. Sky solves this problem. An important feature of Skype is the use of a super node P2P architecture. Super nodes or other nodes on the internet can assume the role of a relay entity. However, Skype is not easy to use relay, and it may only use relay technology if the "drill-down" technology cannot work.
(3) connection reversal technology. If one of the two nodes for communication is on the Internet, the connection can be reversed. For detailed principles, see section 3rd.
(4) direct communication technology. In the case that the nodes on both sides of the communication are on various selfish networks, Skype first considers using the "drilling holes" method to try to establish direct communication. If the "Hole Drilling" fails, the relay technology may be used.
According to people's research results, the bandwidth occupied by super nodes is less than 5% more than the average of normal nodes. Therefore, relay is not frequently used, that is to say, its "drilling" technology can solve most of the traversal problems.
 
Of course, without the official release of Skype technology, people can only try to understand its internal working mechanism through this type of non-direct research. Maybe the truth will not be revealed until Skype decrypts its technology.
Vi. Introduction to the NAT/FW traversal mechanism of JXTA
JXTA (JuXTApose) is an open protocol specification that allows any device supporting this specification to perform P2P communication. Therefore, JXTA provides a basic platform (C/C ++ and JAVA) unrelated to the specific programming language for P2P application development, in fact, JXTA has become an effective platform for many P2P application development. JXTA supports NAT/FW traversal. Figure 4 provides an example where the application is implemented using the CORBA component. The underlying JXTA supports NAT/FW traversal, this allows upper-layer applications to transparently implement free communication across multiple security domains.
 
In a JXTA-Based P2P network, "confluence" nodes can be connected to thousands of common nodes, and each "confluence" Node knows the location of other "confluence" nodes. All "confluence" nodes form a hierarchical system to ensure scalability. JXTA uses the trunk mechanism for traversing, as shown in principle 5. A relay node provides the traversal function. Generally, it is required that the relay node be located on the public network. The relay node continuously listens for external connections on an opened port on the NAT/FW. For nodes located behind NAT/FW, you need to know at least one relay node. To communicate with another node on the JXTA Network, the node sends a request to the relay node. The relay node sends the request to the target node, and the target node sends the Response Message to the relay node. The communication initiator node periodically queries the relay node for response messages from the target node. If there is a response message, the message is taken from the message queue for processing.
VII. Impact of NAT/FW types and behaviors on Traversal
This section describes the impact of NAT/FW types and behaviors on NAT/FW traversal in P2P communication, and also introduces NAT/FW requirements. The NAT/FW that meets this requirement is called "P2P friendly" NAT/FW. More and more NAT/FW on the market already have the "P2P friendly" feature. For the "P2P friendliness" feature, the BEHAVE Working Group of IETF has carried out in-depth research. The following describes the "P2P friendliness" feature from several aspects.
1. Address/port translation consistency
One premise for the "Hole Drilling" method is that the translation of NAT/FW addresses/ports should be consistent. This consistency means to always translate the same address/port on the private network into the same public address/port or "half-Public Network" Address/port, NAT/FW is a cone-type NAT/FW. In the example in section 4, if P1 communicates with the server S for the first time (registration), its private network address/port is 10.0.01: 4321, and NA translates it into 10.0.1.1: 4500, then it is translated into 155.99.25.11: 6200 by NC. S considers this as the public IP address of P1 and tells P2. P2 sends UDP packets to P1 based on this address/port. When P1 sends the first packet to P2, if the translation of NA is inconsistent, another result is translated for 10.0.01: 4321 on NA, therefore, this opening hole cannot be used for packets sent from P2. So in order to support "drilling holes", NAT must be cone-shaped. However, if it is a more rigorous symmetric type, the results of the two translations are certainly different, so the "drill holes" cannot be successful. In order to deal with symmetric NAT/FW, "drilling holes" technology has evolved into variants. As long as the NAT/FW translation address/port method is predictable, it can also be successfully crossed in most cases. The premise of prediction is to detect NAT/FW behavior, which can be implemented using protocols such as STUN. However, predicting NAT/FW behavior deviations may lead to unpredictable results, which poses a considerable risk.
2. Ability to correctly process "not invited" TCP connections
For TCP "drilling", NAT/FW may receive a SYN packet from the public network that appears to be "unsolicited. In this case, the correct solution is to quietly discard the packet. However, some "unfriendly" NAT/FW actively reject the message by sending tcp rst packets or even ICMP error report messages, which may cause the TCP "holes" to be disturbed or even fail.
 
3. Do not interfere with or process IP address information in the net load.
"P2P-friendly" NAT/FW should not interfere with and process IP address information in the net load, but only process IP address information in the packet header. This is important. Unfortunately, many NAT/FW are doing this intelligently. This type of NAT/FW scans the data in the net load to identify and process the 4-byte information that looks like an IP address, thus interfering with the traversal behavior. Of course, for P2P applications, you can change the IP address information in the net load so that NAT/FW cannot identify the IP address information when scanning the Net Load content.
4. "method card" Features
Previously, we have pointed out that NAT/FW should support the "Legal card" feature and correctly "Ring Back" the packets from the private network under its jurisdiction to the private network rather than to the public network.
VIII. Conclusion
P2P communication is booming. To promote the development of P2P communication, the NAT/FW traversal problem must be well studied and solved. Although IPv4 address insufficiency is one of the root causes of NAT, even in the IPv6 era, at least when IPv4 and IPv6 coexist in the early stage, NAT/FW needs to increase. In addition, the security benefits such as the anonymity and unaccessibility of the private network nodes brought by NAT/FW are also the reasons for their continued existence. Therefore, the NAT/FW traversal problem in P2P communication will exist for a long period of time and should be paid the full attention of researchers in this field. We believe that the technological advances and market demands of P2P communication will lead to more and more effective NAT/FW traversal technologies, and the latter will in turn push forward P2P communication more quickly.

This article from the CSDN blog, reproduced please indicate the source: http://blog.csdn.net/Ryanwen/archive/2009/05/06/4154551.aspx