Reliable Progressive to Restricted PS-STUN Algorithm Mark Lim, Andre Tuason, Jay Go, Don Sta. Ana De La Salle University/Manila, Philippines [email protected]

Alexis V. Pantola De La Salle University/Manila, Philippines [email protected]

ABSTRACT Network Address Translations (NAT) offer solutions to the rapidly shrinking pool of IPv4 Internet addresses[1]. NAT brings new problems to direct peer-to-peer connection of hosts. Machines behind NAT-enabled routers face difficulties connecting to each other. Because of this, NAT traversal algorithms are introduced to solve these problems[2,3,4]. A solution proposed is the Predicting and Scanning STUN (PS-STUN), where it can traverses restricted and progressive symmetric NAT implementations[5]. The progressive symmetric to restricted NAT traversal algorithm of PS-STUN uses a significant amount of processing power for traversal. This paper discusses an optimized traversal algorithm for progressive symmetric to restricted NAT traversal based on the implementation used by PS-STUN.

Symmetric NAT implementations map internal addresses to different external addresses and ports numbers for each connection of each unique host. The machine behind the symmetric NAT implementation must be the host to initiate the connections. Symmetric NAT mappings can either be determined progressively or randomly. Progressive symmetric NAT determines internal to external address mappings using a pre-determined pattern within a range of IP addresses. Random symmetric NAT uses random external IP addresses to map internal addresses for each new connection. Predicting and Scanning Session Traversal Utilities for NAT (PS-STUN) offers a traversal algorithm for hosts between progressive symmetric and restricted NAT implementations. The proposed PS-STUN algorithm uses a noticeable amount of processing power to traverse NAT implementations of routers, and is unreliable in networks with a significant rate of connection failure.

Key Words - Network Address Translation, Symmetric NAT, Port Restricted NAT

I. INTRODUCTION Machines behind NAT-enabled routers experience difficulties with connections through NAT implementations. Algorithms are generally dependent on the type of NAT implementation of each router. Currently, there are four implementations of NAT: full cone, address restricted cone, port restricted cone and symmetric NAT types[6].

This paper discusses a modified progressive to restricted NAT traversal algorithm based on PS-STUN to limit the processing power needed for traversal and reliability of NAT traversal in unreliable networks. II. NAT TYPES

Full cone, address restricted cone and port restricted cone maps an internal IP address to an external address. Full cone implementations accept any incoming connections to the mapped IP addresses. Address restricted cone accepts connections originating from the host it initiates a connection with. Port restricted cone accepts connections from the host and specific port it initiates a connection with. Hosts behind both restricted NAT types must initiate connections.

1

Figure 1. Full Cone NAT The full cone NAT implementation as seen in Figure 1, maps an internal IP address to an external IP address, it also allows any address from outside the NAT device to connect to a host within the network.

who initiated the connection and the same port used in its destination was used by the external host to contact it. The main difference this NAT implementation has with port-restricted cone types is that the symmetric NAT implementation changes its mapping for every connection it makes. Mapping: Private: 192.168.1.10:1000 Public: 7.1.1.10: 1000 Public: 7.1.1.10: 1001 Public: 7.1.1.10: 1002

SRC: 7.1.1.10: 1000 DST: 7.1.1.20: 2000 SRC: 7.1.1.20: 2000 DST: 7.1.1.10: 1000 SRC: 7.1.1.20: 3000 DST: 7.1.1.10: 1000

7.1.1.20

SRC: 7.1.1.10: 1001 DST: 7.1.1.30: 4000 192.168.1.10: 1000

SRC: 7.1.1.30: 4000 DST: 7.1.1.10: 1001 7.1.1.30

Figure 2. Address Restricted Cone NAT Figure 4. Symmetric NAT

With the address restricted cone NAT implementation, as seen in Figure 2, an external host is able to connect to an internal host only if the internal host was the one who initiated the connection. For example host 7.1.1.30 initiated the connection, so the connection was rejected.

III. PS-STUN ALGORITHM PS-STUN is an algorithm designed to extend the STUN method of NAT traversal and allow it to traverse even Symmetric type NATs. The algorithm deals with the traversal of a host behind either a full cone, address restricted cone or port restricted cone type and a host behind a symmetric nat. This method is done in 4 steps: Step 1: Clients A and B send UDP packets to the central server using source ports X and Y respectively. These two ports are now mapped by the NAT-enabled router into ports X' and Y'. Step 2: Once the central server receives the packets from the clients, the server asks client A to send one UDP packet to client B using the same port X. Client A being the one behind the symmetric implementation, is assigned a new mapping by NAT A we now call X'+ ∆X. Because client B is behind an address restricted NAT, it will reject the packet sent to it. However, the NAT A will now accept packets forwarded to it by NAT B using port Y'.

Figure 3. Port Restricted Cone NAT With the port restricted cone NAT implementation, as seen in Figure 3, an external host is only able to connect to a an internal host only if the connection was first initiated by an internal host and that the same port number used by the initiating host as its destination is used as its source. For example, only host 7.1.1.20 with port 2000 is able to connect to the 192.168.1.10 machine.

Step3: The central server now predicts that the value of the change in x is not greater than the predicted change in x according to the type and the current workload of NAT A. The central server then asks client B to use port Y and send a UDP packet to client A using the predicted x as

In symmetric NAT implementations, the NAT uses different mappings for each connection. An external host is only able to connect to an internal host if and only if the internal host was the one

2

the destination port number. Although the predicted value is not certain, this procedure is repeated with client B sending to the destination port X' + change in predicted X progressively. This is also the scanning part of the PS-STUN.

client A’s symmetric NAT-enabled router. As said in the previous discussion, the NAT-enabled router of client B rejects the packet but by doing this NAT A will now accept packets forwarded to it from NAT B’s port Y’. Afterwards, client A once again sends a packet to the server but this time using a different port in order for the server to establish a range of ports to be iterated by client B.

Step 4: When client A receives a packet, it is now able to reply back to source port X. The difference is that NAT B now accepts the forwarded packet and sends it to client B, with this, NAT traversal succeeds.

Step 3: The central server now sends the port range to client B and tells client B to send packets to each of the ports in the range. Once a packet has been sent to the correct port, NAT A accepts the packet and NAT traversal succeeds.

The PS-STUN algorithm is already a great way to solve this NAT traversal issue however, should the algorithm fail because of a failure to deliver the packet to the symmetric host, the algorithm would proceed to exhaust all the port numbers and a retrial won’t be after some time.

What the algorithm has fixed is that now a range is used instead of free guessing. This solves the problem of reliability the PS-STUN has by making a way for the algorithm to be executed again in a short period of time if the initial execution fails.

3 – uses X' + predicted ∆X as destination port progressively

1 Client A Port X

1

Symmetric Central Server Restricted NAT A NAT B Mapped to X’ Mapped to Y’

RPS-STUN uses X’ + ? X in a given range until the correct port is reached

Client B Port Y

3 – packet

5 – Port Range

1

1

2 – mapped to X' + ∆X

Figure 6. PS-STUN NAT Traversal Algorithm

Client A Port X

IV. RPS-STUN Algorithm

Symmetric Central Server Port Restricted 6-Send to Ports NAT B NAT A Mapped to Y’ Mapped to X’

Client B Port Y

4 - Traversed

2 – Send packet to create mapping

The RPS-STUN or Reliable Predicting and Scanning Session Traversal Utilities for NAT, is an algorithm which is designed to further improve PS-STUN. It is named Reliable because it can retry to send data to the symmetric peer. This algorithm is done in 4 steps:

Figure 7. RPS-STUN NAT Traversal Algorithm IV. Experiment and Result The reliability of RPS-STUN relative to PS-STUN is measured through the use of a network simulation.

Step 1: Clients A and B send UDP packets to the central server using source ports X and Y, the two ports are now mapped into ports X’ and Y’ in the NAT-enabled router respectively.

The simulation is implemented using a Java program with the following Java objects: clients, server, hubs, routers, and Internet.

Step 2: The central server receives the packets and asks client A to send a few more packets with different destination ports to the server in order for the server to gain more data on what the ∆X is. The server then asks client A, still the one behind the symmetric NAT implementation, to send a packet to the same port X’ of client B used to contact the server. Now that it has sent a message to client B, there is now a mapping of X’+ ∆ on

The Internet object has a link stability parameter that controls the amount of packets that is successfully sent. For example, a 25% link stability means that there is 1 in a 4 chance that a packet will be successfully sent. In the experiment, a client object (Client A) is behind a router object with a progressive

3

RPS-STUN are compared in terms of the no. of overhead they contribute. Theoretically, RPS-STUN has more overhead since it sends an additional packet to the server to know the range of port numbers. This is verified in the simulation as PS-STUN has an average overhead count that is lesser than of the RPS-STUN. However, this is only observed when the link stability is above 96% (see Figure 9). Once the link stability becomes lower, the overhead count is greatly affected by the no. of attempts made by each algorithm. The more attempts made, the larger the no. of overhead packets are sent. This explains the similarity between the graphs in Figure 8 and Figure 9 even if they illustrate two different criteria (i.e. no. of attempts and overhead count).

symmetric NAT type. Another client object (Client B) is behind a port restricted NAT router. Since Client B is the one behind the port restricted NAT router, it has the task of guessing the port mapping used by Client A. The no. of attempts before Client B successfully guessed the port mapping used by Client A is recorded. The more attempts that Client B does in the simulation can be a gauge on the reliability of a NAT traversal algorithm. The router object is configured to use either PS-STUN or RPS-STUN NAT traversal. By testing PS-STUN and RPS-STUN with varying link stability, their performance in terms of reliability can be measured.

IV. Conclusion Figure 8 shows the no. of attempts made by Client B with varying link stability (20% to 100%) using PS-STUN and RPS-STUN.

Through a network simulation, it has been verified that PS-STUN can be improved in terms of reliability. RPS-STUN optimized the original algorithm by reducing the no. of attempts in guessing the port mapping. Less attempts means faster NAT traversal.

As expected, if the link stability is near ideal (90% to 100%) PS-STUN requires few attempts before successfully guessing the port mapping of Client A. However, as the link stability degrades, the no. of attempts increases. At 50% link stability, for example, the no. of attempts reaches 46. A link stability of less than 30% requires PS-STUN approximately 190 attempts before correctly guessing the port no.

In a real implementation, this can be equated to a higher reliability of the algorithm since more attempts can lead to consumption of router resources and higher latency. Aside from this, overhead is not a significant problem with RPS-STUN even if it sends an additional compared to RPS-STUN. In fact, at low link stability, RPS-STUN has a lower overhead compared to its predecessor.

The enormous no. of attempts of PS-STUN may be attributed to its lack of port range to test. Since it does not know the upper bound port no., it has no choice but to exhaust all possible port nos. before reattempting from the lower bound. For example, if the lower bound is port no. 3000, it will start guessing from the said port no. If this does not work, it will try to use succeeding port numbers (3001, 3002, etc.). If it exhaust all possible port nos. and it still does not work, it goes back and recheck port no. 3000 until the NAT traversal becomes successful.

REFERENCES [1] Cisco Systems, “How NAT Works”. Cisco Systems Inc., 2006. [2] J. Eppinger et al, “TCP Connections for P2P Applications: Solving the NAT Problem”. Carnegie Mellon University, 2005. [3] S. Guha and P. Francis, “Characterization and Measurement of TCP Traversal through NATs and Firewalls”. Cornell University, 2005. [4] Newport Networks, “Solving the Firewall and NAT Traversal Issues of MoIP”. Newport Networks, 2006.

RPS-STUN, on the other hand, is able to limit the no. of attempts since it determines both the lower and upper bounds. At 50% link stability, an average of 3 attempts is recorded. Even at a link stability of 20%, the no. of attempts is at most 6. Aside from no. of attempts, PS-STUN and

4

[5] Y. Wang et al, “Research on Symmetric NAT Traversal in P2P Applications”. International Multi-Conference on Computing in the Global Information Technology (ICCGI), 2006.

[6] K. Das, “Network Address Translation (NAT) Pros & Cons”. Available at HTTP: http://www.ipv6.com/articles/nat/NAT-Pros -and-Cons.htm.

No. of Attempts 200 180 160 140 PS-STUN RPS-STUN

120 100 80 60 40 20

Link Stability (%) 10

20

30

40

50

60

70

80

90

Figure 8. No. of Attempts in PS-STUN and RPS-STUN in Varying Link Stability

5

100

Overhead Count 200 180 160 140 PS-STUN RPS-STUN

120 100 80 60 40 20

Link Stability (%) 10

20

30

40

50

60

70

80

90

Figure 9. Overhead Count in PS-STUN and RPS-STUN in Varying Link Stability

6

100