Experiments Design
Here we design experiments to analyze the DCR of ICE technique under NATs and observe the characteristics of ICE-UDP/TCP. Because traversal techniques suffer from NAT behavior, we analyze the UDP/TCP behaviors of 15 NATs and classify them into four types according to previous work [2]. For each experiment, the results of different combination of NAT types are different. We infer the upper-bound of DCR under various combinations of NAT types, observe the DCR of ICE in a real NAT environment, and understand whether the DCR of ICE can reach the upper-bound or not.
In our experiment environments as Figure 8 shows, we set two peers, caller and callee, and execute VoIP application for testing ICE DCR under 15 NATs. Also, we set STUN server to get NAT mapping and SIP server to exchange necessary candidates under ICE process.
Figure 8. ICE DCR test environment.
In the experiment, we test application under various NAT combinations to
establish peer-to-peer connectivity. There are 210 cases (15*15-15) for ICE-UDP and ICE-TCP respectively. The experiment starts by making a call from caller to callee to establish connection, and performs ICE process to traverse NAT. If both caller and callee establish bidirectional data transmission, the result of test case is success.
Otherwise the result is failure. The following is the test case procedure.
Step 1: Caller and callee set up application configuration and execute.
Step 2: Caller and callee register with SIP server and caller make a call to callee.
Step 3: Caller and callee perform ICE-UDP first and then ICE-TCP process. If the traversal is successful, they start to transmit data.
Step 4: Application will start or fail to transmit data.
NAT Classification and Analysis
Before measuring the ICE-UDP/TCP DCR, we have to understand the NAT behavior and further classify NAT types and realize which combination of types ICE could traverse so that we can figure out the DCR upper-bound in advance. Each peer runs the test program NATCheck [6] and Stunt [12] to test the UDP/TCP behavior of NAT and classify NATs. Table 3 shows the results, and we could reference the Table 1 and Figure 1 to estimate the upper-bound of DCR under UDP and TCP in experiment environment.
Table 3. Test results of NAT type
Testing Results
DCR of ICE-UDP and ICE-TCP
Table 4 shows the results and Table 5 summarized them. Table 5 displays the DCR in above four combinations and normalized DCR which means the DCR of entire cases of experiment. ICE-UDP and ICE-TCP techniques almost solve all cases SHOULD pass in combination 1 and 2 so that their DCR approach to the DCR upper-bound, this proves the conjecture of upper-bound is correct. The DCR upper-bound of ICE-UDP is 71.4% which is higher than ICE-TCP because handling TCP connection is complicated. We consider that NAT takes care of reliable and secure TCP connection so there are more Port Restricted NATs and Symmetric NATs for traversing TCP connections, increases the portion of combination 3 and combination 4 and decrease the DCR upper-bound. Because the Combination 3 and Combination 4 are the bottleneck of DCR upper-bound, port predict [13] traversal technique which guess the binding of Symmetric NAT, could be utilized in ICE and
raise the ICE-UDP and ICE-TCP DCR when the port mapping assignment of Symmetric NAT is sequential.
According the ICE-UDP test results, we observe a situation that caller behind NAT 6 and NAT 14, the UDP connection fail to traverse NAT, but it could pass when the role of caller and callee are changed. This situation is called Conntrack Bind problem [17] described in section 4.3.2.
Table 4. Total test cases of (a) ICE-UDP and (b) ICE-TCP, “O” means success case,
“▲” means success if we fix Conntrack Bind problem, space means fail case.
Table 5. (a) ICE-UDP and (b) ICE-TCP DCR testing analysis
Conntrack Bind Problem
From Table 5(a), we observe that caller under NAT 6 and 14 (Port Restricted NAT) could not traverse Port Restricted NATs, but this case should pass under the NAT combination because they are Corn NATs. This problem is proposed in [17]
when one of peer is under Linux-based NAT (Port Restricted NAT); Figure 9 illustrate the packet flows when the problem occurs. When an unsolicited packet attempts to traverse a Linux-based NAT, the NAT will block the old mapping (a) created by STUN session and assign a new mapping (b) in Figure 9 for new outbound packets, such mapping behavior is similar to Symmetric NAT. In Figure 7, we know callee always start connectivity check earlier than caller. After a Linux-based NAT creates the mapping a by STUN server for the caller, it drops an unsolicited STUN check packets from callee. That’s why the Conntrack Bind problem occurs.
Figure 9. Conntrack Bind problem occurs when peers under Linux-based NAT.
Here we propose a solution: Forestalling Low-TTL, solve the conntrack bind problem even if caller and callee under Linux-based NATs. In our solution, we consider that caller should send out a Low-TTL packet applying NAT to create a correct mapping before other side check packets arrive.
We demand the two sets of candidate for twice ICE process. If the fist ICE process fails, we presume that the Conntrack Bind problem occurs and then trigger the ICE process of second candidate set. We collect the extract (second) candidates and encode into SDP with original (first) candidates, after callee receives the SIP message with SDP, callee also collects the extract candidate and original candidates, and pairs two lists for checking. Before callee responses the SDP with candidates to caller, it send out the Low-TTL packet to caller’s second server reflexive candidate binding b on NAT in Figure 9, to create a mapping on NAT, and send SIP message to caller and starts the original ICE process. The caller receives callee’s candidates from SIP message and immediately sends a Low-TTL packet to callee’s second server reflexive candidate b’, at this time, two sides NAT have created mapping by outgoing Low-TTL packets. If the fist ICE process fails, we will start the extra ICE process; begin the extra ICE connectivity check after we have sent Low-TTL packet to created correct mapping on NAT. Therefore, even both peers are under Linux-based NATs, Conntrack
Bind problem cases could be solved in Table 4(a), and we improve the ICE-UDP DCR from 63.76% to 67%.
Figure 10. Solution: Forestalling Low-TTL for Conntrack Bind problem.
Although we have solved the Conntrack Bind problem, but the ICE-UDP DCR combination 1 (Table 3.) does not reach 100%. We consider this caused of particular NAT behavior since the DCR test result of NAT7 are similar Symmetric NAT, but NAT 7 doest not match the NAT behavior testing result according to Table 3, this may be a point for a further research.
The results show that the media protocol that runs over UDP and TCP, for example: RTP protocol, it prefer to use UDP protocol first on P2P application for NAT traversal cause of the higher DCR and upper-bound. If endpoint could not traverse NAT on UDP protocol, it attempted to change into TCP protocol to TCP NAT traversal, solve some special cases on UDP protocol such as Conntrack Bind problem.
Bottleneck of the upper-bound of NAT TCP DCR
In Table 2, the types of NAT TCP behavior are almost Port Restricted, this is an issue of implementation. When NAT handles TCP outbound connections, it binds a socket to establish connection to external endpoint, this TCP socket does not accept other SYN packets since TCP are unidirectional establishment, causing filtering behavior are strict. The NAT type of D-Link NAT on TCP is Full Cone NAT, we consider it handles outbound connections and accept inbound connections at the same time by open few sockets, but it has the resource issue that we do not discus here.
5. Conclusions and Future Works
Main Differences on Connectivity Checks and Implementation
In the thesis, we implement the ICE Library, which is used by VoIP application to realize ICE-UDP/ICE-TCP process for UDP/TCP NAT traversal, and analyze and compare their differences. Also, we design experiments to observe the characteristics and measure the ICE-UDP and ICE-TCP NAT traversal abilities with various combinations of NAT types.
The implementation of ICE-UDP and ICE-TCP are different on ICE session layer and socket layer. On socket layer, the implementation of UDP is simpler than TCP because ICE-UDP use the same socket handles few UDP connections while ICE-TCP must handle few TCP sockets, reuse them to establish TCP connections to STUN server, check connectivity, and accept inbound connections. On ICE session layer, ICE-UDP has “local to server reflexive” path for NAT traversal expect “local to local” path, and ICE-TCP has TCP simultaneous and active – passive path to perform TCP NAT traversal.
ICE
According to the experiment results we summarize: (1) It is complicate for NAT to handle TCP connections so that it limits the TCP traversal upper-bound; besides, TCP connection should be by modifying the implementation. (2) So far ICE could traverse the NAT types of combination 1 and combination 2 and almost reach 100%
of upper-bound of UDP and TCP. However, the Conntrack Bind problem may occur in the scenario of figure 8. Therefore, this thesis proposes the solution which is Forestalling Low-TTL to solve problems in combination 1 that ICE could not traverse.
As a result, it helps to raise the ICE-UDP DCR. (3) The utilization on media protocol run over on both of UDP and TCP recommends that always use UDP protocol to traverse NAT first and change to TCP protocol if it fail on UDP. (4) The TCP NAT behavior should be reformed by implementation to handling the inbound TCP connections, the TCP DCR upper-bound will be improved.
DCR Upper-bound Bottleneck on NAT implementation
So far the ICE traversal technique almost has reached the upper-bound on UDP and TCP. If we attempt to improve the DCR, combining the port predict technique in ICE could better DCR of combination 3 and combination 4. Furthermore, attacking upon the NAT infrastructure is a good way to enhance DCR. If the proportion of Full Cone and Address Restricted Cone NAT is higher, it could raise the upper-bound in combination 1 since Port Restricted NAT limits the DCR upper-bound when it meets Symmetric NATs. In addition, it needs NAT vendors to follow the RFC 4787 [3] and RFC 5382 [4] to reform the particular behavior like the behavior of NATs NAT 7 and Linux-based NAT.
References
[1] K. Egevang and P. Francis, “The IP Network Address Translator (NAT),” IETF RFC 1631, March 1994.
[2] J. Rosenberg, J. Weinberger, C. Huitema and R. Mahy, “STUN - simple traversal of user datagram protocol (UDP) through network address translators (NATs),” IETF RFC 3489, March 2003.
[3] E. F. Audet and C. Jennings, “NAT Behavioral Requirements for Unicast UDP,”
IETF RFC 4787, January 2007.
[4] J. Rosenberg, R. Mahy, P. Matthews, and D. Wing, “Session Traversal Utilities for (NAT) (STUN),” IETF RFC 5389, October 2008.
[5] J. Rosenberg, Interactive connectivity establishment (ICE), IETF Draft, October 2007.
[6] B. Ford, P. Srisuresh and D. Kegel, “Peer-to-Peer Communication Across Network Address Translators,” in USENIX Annual Technical Conference, Anaheim, CA, April 2005, pp.179-192.
[7] J. Rosenberg, C. Huitema, and R. Mahy, “Traversal using relay NAT (TURN),”
IETF Draft, February 2009.
[8] J. Rosenberg, TCP Candidates with Interactive Connectivity Establishment, IETF Draft, July 2008.
[9] A. Biggadike, D. Ferullo, G. Wilson, and A. Perrig, “NATBLASTER: Establishing TCP connections between hosts behind NATs,” in ACM SIGCOMM Asia Workshop, Beijing, China, April 2005.
[10] S. Guha, Yutaka Takeday, and P. Francis, “ NUTSS: A SIP-based approach to UDP and TCP network connectivity,” in ACM SIGCOMM Asia Workshops, August 2004.
[11] Y. Takeda, “Symmetric NAT Traveral using STUN,” IETF draft, June 2003.
[12] S. Guha, P. Francis, “Characterization and Measurement of TCPTraversal through NATs and Firewalls,” in ACM Internet Measurement Conference (IMC), Berkeley, CA, Oct 2005, pp. 199-211.
[13] J. Postel, “DoD standard Transmission Control Protocol,” RFC 761, January 1980.
[14] S. Guha, K. Biswas, B. Ford, S. Sivakumar, and P. Srisuresh, “NAT Behavioral Requirements for TCP,” IETF RFC5382, October 2008.
[15] H. Khlifi, Jean-Charles Gregoire and J. Phillips, “VoIP and NAT/Firewalls:
Issues, Traversal Techniques, and a Real-World Solution,” IEEE Communication Magazine, July 2006, pp. 93-99.
[16] S. Perreault and J. Rosenberg, “Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations,” IETF Draft, March 2009.
[17] Cheng-Yuan Ho, Fu-Yu Wang, and Chien-Chao Tseng, “To Call or to Be Called under NATs is Sensitive for Solving Direct Connection Problem,” Technical Report, Dept. D-Link Joint NCTU Research Center, July 2009.
[18] P. Srisuresh, B. Ford and D. Kegel, “State of Peer-to-Peer (P2P) Communication across Network Address Translators,” IETF RFC 5128, March 2008.