4.9 NTS (NAT Traversal Set of rules)

Connection-filtering-NATs are becoming increasingly frequent, and this is a situation that dificults the connectivity between peers. This set of rules introduces the extra functionality to handle those peers that are behind restricted-cone NATs and symmetric NATs.

The DBS module enables the communication for those peers that are behind full-cone NATs and peers that are behind those more restrictive NATs but that have dedicated an open port for the P2PSP traffic, but in the rest of the cases NATs will block the incoming packets. In order to known the reason of that problem, let’s examine the behaviour of restricted-cone and symmetric NATs.

When a restricted-cone NAT is used, the NAT entries can have four or five fields, depending on the exact type of NAT. Compared to a full-cone NAT, restricted-cone NATs entries have a fourth field which memorizes the destination IP address of the outcoming packet^{∗ ∗}Outcoming packets go from the private network towards the Internet. , i.e., we have a translation entry such as:

where RCNE stands for Restricted-Cone Nat Entry. Therefore, an incoming packet can cross the NAT only if it comes from a proccess that is running at a host whose IP address is $\mathcal{𝒲}$.

If the NAT is a port-restricted-cone one, NAT entries become:

where PRCNE stands for Port-Restricted Cone Nat Entry. In this case the NAT forwards the packet only if it was originated at the (public source port $\mathcal{𝒱}$, public source IP address $\mathcal{𝒲}$) end-point.

It is important to notice that in a cone NAT (restricted or not) only a public NAT port is assigned to each (private IP address $\mathcal{𝒴}$, private port $\mathcal{𝒵}$) end-point. This means that, although a peer is behind a cone NAT, the peers can be addressed using the unique public NAT end-point that the NAT has selected to create the corresponding translation entry. Thus, in order to reach the NAT-ed peer the only action that must be previously performed is to send a packet from this (private) peer to the interlocutor (public) peer, something that is already performed in the DBS.

Let us suppose that a new peer $X$ wants to join the team. Following the DBS, when $X$ is joining the team it receives the list of peers and sends a [hello] message to each peer of the list. These messages will be received by those peers that run at public hosts or full-cone NAT-ed hosts, but not otherwise.^{∗ ∗}Notice also that, if $X$ is behind a NAT, these [hello] messages creates one or more translation entries in the NAT of $X$ that makes possible that the rest of peers of the team reach $X$. To solve this problem, when a peer $X$ want to join the team, the splitter can send to the all NAT-ed peers of the team^{† †}Notice that in order to apply this rule, the splitter must know if a peer is behind a NAT or not. For this reason, it is compulsory that a NTS-graded peer implements also the EMS (see Section 4.8). the $X$’s end-point using the message:

where $\left(X\right)$ is the public $X$’s end-point asigned by its NAT. Thus, when the peers receive this message will send a [hello] to $\left(X\right)$, creating a translation entry in their NATs. After that, $X$ will be able to communicate with all the peers of the team, even if $X$ is behind a NAT.

Summarizing, when an arriving peer $X$ wants to join the team $T$ and after receiving the list of peers in $T$ from $S$, $S$ must carry out the steps refered in Algorithm 1 and each peer in $\mathcal{𝒩}\left(T\right)$ must follow the steps in Algorithm 2.

Unfortunately, symmetric NATs behaviour is different and the previously proposed algorithm does not work. A symmetric NAT assigns a different public port for each (public source port, public source IP address, private IP address, private port) combination. This means that, if a peer that is behind a symmetric NAT it will use different public NAT ports for communicating with any other peer and the splitter. Moreover, the algorithm used by a symmetric NAT to allocate the public ports is not standardized. Some NATs will assign ports sequentially (depending on their availability) and other will assign them at random. Notice also that symmetric NATs, by definition, are incompatible with the pure P2PSP philosophy. Each peer must sends messages to the rest of peers of the team and this means that $\left|T\right|$ ports will be allocated for each peer that is behind a symmetric NAT. For all these reasons, in order to run the P2PSP under symmetric NATs, the configuration presented in Section 7.6 should be used. However, if this solution if not factible, $\left|T\right|$ is small and the number of peers behind the symmetric NAT is also small, the following simple solution could be tried.

The first problem to solve here is to identify those peers that are behind symmetric NATs because their NAT traversal set of rules will be different of the rules that must follow those peers that are behind cone NATs. To indentify a symmetric NAT-ed peer $X$, the splitter sends to the monitor peer the public end-point of $X$ and the monitor peer search this end-point in his list of peers. If the peer is in the list, $X$ is behind a cone NAT, otherwise, $X$ is behind a symmetric NAT. Algorithm ?? sumarizes this procedure.

Most NATs use the port preservation port allocation technique which means that if a process that runs in the (NAT-ed) private network uses a local port $\mathcal{ℒ}$, then the NAT will try to use the same port at the public side, and if the public port $\mathcal{ℒ}$ has been already allocated then the NAT will check if port $\mathcal{ℒ}+\infty$ is free. Supposing this and taking into account that using the rules 5 and ?? of the DBS will allocate the ports $\mathcal{ℒ},\mathcal{ℒ}+1,\cdots ,\mathcal{ℒ}+\left|T\right|$ where, $\mathcal{ℒ}$ will be the port assigned for the NAT to talk with the splitter, $\mathcal{ℒ}+1$ will be the port assigned to talk with the first peer of the list of peers and $\mathcal{ℒ}+\left|T\right|$ will be the port to talk with the last peer of the list of peers. Notice that it is possible to determine whether the ports used by the symmetric NAT of the incoming peer $X$ are $\mathcal{ℒ},\mathcal{ℒ}+1,\cdots ,\mathcal{ℒ}+\left|T\right|$ after receiving the [hello] messages from $X$ to the rest of peers of the team, even if there are peers behind symmetric NATs, provided these peers have sent a [hello] towards $X$ using the corresponding public port at $X$’s NAT. Therefore, if after this phase of “regards” between $X$ and the rest of peers of the team, all these peers have received a [hello] from $X$, then we can conclude that $X$ has joined to the team correctly.

Algorithms 5 and 6 sumerize the steps that must be performed in order to incorporate to a team a peer $X$ that is behind a symmetric NAT.

Finally, we would like to stress that this algorithm must be executed only by those peers that are behind a (port-)restricted-cone or symmetric NAT. The rest of peers of the team do not need to be aware of the use of these techniques.